Version 1.16. This version is no longer supported. For information about how to upgrade to version 1.28, see Upgrade clusters in the latest documentation. For more information about supported and unsupported versions, see the Versioning page in the latest documentation.

클러스터 업그레이드

새 버전의 bmctl을 설치하면 이전 버전으로 생성된 기존 클러스터를 업그레이드할 수 있습니다. 클러스터를 최신 베어메탈용 GKE 버전으로 업그레이드하면 클러스터에 추가 기능 및 수정 사항이 적용됩니다. 또한 클러스터가 지원 상태로 유지됩니다. bmctl upgrade cluster 명령어나 kubectl을 사용하여 관리자, 하이브리드, 독립형, 사용자 클러스터를 업그레이드할 수 있습니다.

업그레이드 프로세스에 대한 자세한 내용은 클러스터 업그레이드 수명 주기 및 단계를 참조하세요.

업그레이드 계획하기

이 섹션에는 클러스터를 업그레이드하기 전에 고려해야 하는 정보와 해당 링크가 포함되어 있습니다.

권장사항

베어메탈용 Anthos 클러스터의 클러스터 업그레이드 권장사항에서 클러스터 업그레이드를 준비하는 데 도움이 될 정보를 참조하세요.

프리플라이트 검사 업그레이드

실행 전 검사는 클러스터 업그레이드의 일부로 실행되어 클러스터 상태와 노드 상태의 유효성을 검사합니다. 실행 전 검사가 실패하면 클러스터 업그레이드가 진행되지 않습니다. 실행 전 검사에 대한 자세한 내용은 실행 전 검사 이해를 참조하세요.

업그레이드를 실행하기 전 실행 전 검사를 실행하여 클러스터의 업그레이드 준비 상태를 확인할 수 있습니다. 자세한 내용은 업그레이드를 위한 실행 전 검사를 참조하세요.

알려진 문제

클러스터 업그레이드와 관련된 잠재적 문제에 대한 자세한 내용은 베어메탈용 Anthos 클러스터 알려진 문제를 참조하고 업그레이드 및 업데이트 문제 카테고리를 선택하세요.

업그레이드 옵션 구성

클러스터 업그레이드를 시작하기 전에 업그레이드 프로세스의 작동 방식을 제어하는 다음 업그레이드 옵션을 구성할 수 있습니다.

선택적 워커 노드 풀 업그레이드: 특정 워커 노드 풀을 나머지 클러스터와 별도로 업그레이드합니다.
동시 업그레이드: 노드 그룹 또는 노드 풀을 동시에 업그레이드하도록 업그레이드 프로세스를 구성합니다.

이러한 옵션은 중요 애플리케이션 및 서비스의 중단 위험을 줄이고 전반적인 업그레이드 시간을 크게 줄여줄 수 있습니다. 이러한 옵션은 중요한 워크로드를 실행하는 수많은 노드 및 노드 풀이 있는 대규모 클러스터에 특히 유용합니다. 이러한 옵션의 기능과 사용 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

선택적 워커 노드 풀 업그레이드

기본적으로 클러스터 업그레이드 작업은 클러스터의 모든 노드와 노드 풀을 업그레이드합니다. 클러스터 업그레이드가 중단되고 시간이 오래 걸릴 수 있으며, 이로 인해 각 노드가 드레이닝되고 연결된 모든 포드가 다시 시작/예약됩니다. 이 섹션에서는 워크로드 중단을 최소화하기 위해 클러스터 업그레이드에 일부 워커 노드 풀을 포함하거나 제외하는 방법을 설명합니다. 관리자 클러스터에서는 워커 노드 풀을 허용하지 않으므로 이 기능은 사용자, 하이브리드, 독립형 클러스터에만 적용됩니다.

다음과 같은 상황에서 선택적 노드 풀 업그레이드를 사용할 수 있습니다.

워크로드 중단 없이 보안 수정사항 적용: 제어 영역 노드 (및 부하 분산기 노드)만 업그레이드하면 워커 노드 풀을 중단하지 않고도 Kubernetes 취약점 수정사항을 적용할 수 있습니다.
모든 워커 노드를 업그레이드하기 전에 업그레이드된 워커 노드의 하위 집합이 올바르게 작동하는지 확인: 다른 노드 풀을 업그레이드하기 전에 워커 노드 풀을 선택적으로 업그레이드하여 업그레이드된 노드 풀에서 워크로드가 제대로 실행되는지 확인할 수 있습니다.
유지보수 기간 단축: 대규모 클러스터를 업그레이드하는 데 시간이 많이 걸릴 수 있으며 업그레이드가 완료되는 시점을 정확하게 예측하기 어렵습니다. 클러스터 업그레이드 시간은 업그레이드하는 노드 수에 비례합니다. 노드 풀을 제외하여 업그레이드하는 노드 수를 줄이면 업그레이드 시간이 단축됩니다. 여러 번 업그레이드하지만 유지보수 기간이 더 짧고 예측 가능하면 예약에 도움이 될 수 있습니다.

워커 노드 풀을 선택적으로 업그레이드하기 위한 버전 관리 규칙은 Lifecycle 및 클러스터 업그레이드 단계의 노드 풀 버전 관리 규칙을 참조하세요.

클러스터 제어 영역과 선택한 노드 풀 업그레이드

초기 클러스터 업그레이드에서 워커 노드 풀을 선택적으로 업그레이드하려면 다음 안내를 따르세요.

클러스터 업그레이드에 포함할 워커 노드 풀의 경우 NodePool 사양을 다음 중 하나로 변경합니다.
- NodePool 사양의 anthosBareMetalVersion을 클러스터 대상 업그레이드 버전으로 설정합니다.
- NodePool 사양에서 anthosBareMetalVersion 필드를 생략하거나 빈 문자열로 설정합니다. 기본적으로 워커 노드 풀은 클러스터 업그레이드에 포함됩니다.
업그레이드에서 제외할 워커 노드 풀의 경우 anthosBareMetalVersion을 클러스터의 현재(업그레이드 전) 버전으로 설정합니다.
클러스터 업그레이드 시작에 설명된 대로 업그레이드를 계속합니다.

클러스터 업그레이드 작업은 다음 노드를 업그레이드합니다.
- 클러스터 제어 영역 노드
- 부하 분산기 노드 풀(클러스터에서 하나(spec.loadBalancer.nodePoolSpec)를 사용하는 경우). 기본적으로 부하 분산기 노드는 일반 워크로드를 실행할 수 있습니다. 부하 분산기 노드 풀은 선택적으로 업그레이드할 수 없으며, 항상 초기 클러스터 업그레이드에 포함됩니다.
- 업그레이드에서 제외하지 않은 워커 노드 풀

예를 들어 클러스터 버전이 1.15.0이고 워커 노드 풀이 2개(wpool01 및 wpool02) 있다고 가정해 보겠습니다. 또한 제어 영역과 wpool01을 1.16.8로 업그레이드하되 wpool02를 버전 1.15.0으로 유지한다고 가정합니다.

다음 클러스터 구성 파일 발췌문에서는 이 부분 업그레이드를 지원하도록 클러스터 구성을 수정하는 방법을 보여줍니다.

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.15.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

노드 풀을 현재 클러스터 버전으로 업그레이드

클러스터 업그레이드에서 노드 풀을 제외했다면 노드 풀을 대상 클러스터 버전으로 가져오는 클러스터 업그레이드를 실행할 수 있습니다. 클러스터 업그레이드에서 제외된 워커 노드 풀에는 NodePool 사양의 anthosBareMetalVersion 필드가 이전(업그레이드 전) 클러스터 버전으로 설정되어 있습니다.

워커 노드 풀을 현재 업그레이드된 클러스터 버전으로 가져오려면 다음 안내를 따르세요.

현재 클러스터 버전으로 가져오려는 워커 노드 풀의 클러스터 구성 파일에서 NodePool 사양을 수정합니다. anthosBareMetalVersion을 현재(업그레이드 후) 클러스터 버전으로 설정합니다.

업그레이드 대상으로 여러 워커 노드 풀을 선택한 경우 클러스터 사양의 spec.nodePoolUpgradeStrategy.concurrentNodePools 값에 따라 동시에 업그레이드되는 노드 풀 수가 결정됩니다. 워커 노드 풀을 동시에 업그레이드하지 않으려면 업그레이드할 노드 풀을 한 번에 하나씩 선택하세요.
클러스터 업그레이드 시작에 설명된 대로 업그레이드를 계속합니다.

클러스터 업그레이드 작업은 anthosBareMetalVersion을 현재 업그레이드된 클러스터 버전으로 설정한 이전에 제외된 워커 노드 풀만 업그레이드합니다.

예를 들어 클러스터를 버전 1.16.8로 업그레이드했지만 노드 풀 wpool02가 아직 업그레이드 전 이전 클러스터 버전 1.15.0이라고 가정해 보겠습니다. 업그레이드된 노드 풀 wpool01에서 워크로드가 제대로 실행되고 있으므로 이제 wpool02도 현재 클러스터 버전으로 가져오려고 합니다. wpool02를 업그레이드하려면 anthosBareMetalVersion 필드를 삭제하거나 이 필드의 값을 빈 문자열로 설정하면 됩니다.

다음 클러스터 구성 파일 발췌문에서는 이 부분 업그레이드를 지원하도록 클러스터 구성을 수정하는 방법을 보여줍니다.

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

동시 업그레이드

일반적인 기본 클러스터 업그레이드에서는 각 클러스터 노드가 한 번에 하나씩 순차적으로 업그레이드됩니다. 이 섹션에서는 클러스터를 업그레이드할 때 여러 노드가 동시에 업그레이드되도록 클러스터 및 워커 노드 풀을 구성하는 방법을 보여줍니다. 노드를 동시에 업그레이드하면 특히 수백 개의 노드가 포함된 클러스터의 경우 클러스터 업그레이드 속도가 크게 빨라집니다.

클러스터 업그레이드 속도를 높이는 데 사용할 수 있는 동시 업그레이드 전략에는 두 가지가 있습니다.

동시 노드 업그레이드: 여러 노드가 동시에 업그레이드되도록 워커 노드 풀을 구성할 수 있습니다. 노드의 동시 업그레이드는 NodePool 사양(spec.upgradeStrategy.parallelUpgrade)에서 구성되며 워커 노드 풀의 노드만 동시에 업그레이드할 수 있습니다. 제어 영역 또는 부하 분산기 노드 풀의 노드는 한 번에 하나씩만 업그레이드할 수 있습니다. 자세한 내용은 노드 업그레이드 전략을 참조하세요.
동시 노드 풀 업그레이드: 여러 노드 풀이 동시에 업그레이드되도록 클러스터를 구성할 수 있습니다. 워커 노드 풀만 동시에 업그레이드할 수 있습니다. 제어 영역 및 부하 분산기 노드 풀은 한 번에 하나씩만 업그레이드할 수 있습니다.

노드 업그레이드 전략

여러 노드가 동시에 업그레이드되도록 워커 노드 풀을 구성할 수 있습니다(concurrentNodes). 업그레이드 프로세스 동안 워크로드를 실행할 수 있는 노드 수의 최소 기준점을 설정할 수도 있습니다(minimumAvailableNodes). 이 구성은 NodePool 사양에서 지정합니다. 이러한 필드에 대한 자세한 내용은 클러스터 구성 필드 참조를 확인하세요.

노드 업그레이드 전략은 워커 노드 풀에만 적용됩니다. 제어 영역 또는 부하 분산기 노드 풀에 노드 업그레이드 전략을 지정할 수 없습니다. 클러스터 업그레이드 중에 제어 영역과 부하 분산기 노드 풀의 노드는 한 번에 하나씩 순차적으로 업그레이드됩니다. 제어 영역 노드 풀과 부하 분산기 노드 풀은 클러스터 사양(controlPlane.nodePoolSpec.nodes 및 loadBalancer.nodePoolSpec.nodes)에 지정됩니다.

노드의 동시 업그레이드를 구성할 때는 다음 제한사항에 유의하세요.

concurrentNodes 값은 노드 풀에 있는 노드 수의 50% 또는 고정된 수(15개) 중 더 적은 값을 초과할 수 없습니다. 예를 들어 노드 풀에 노드가 20개 있으면 10보다 큰 값을 지정할 수 없습니다. 노드 풀에 노드가 100개 있으면 지정 가능한 최댓값은 15입니다.
concurrentNodes와 함께 minimumAvailableNodes를 사용하는 경우 결합된 값이 노드 풀의 총 노드 수를 초과할 수 없습니다. 예를 들어 노드 풀에 노드가 20개 있고 minimumAvailableNodes가 18로 설정된 경우 concurrentNodes는 2를 초과할 수 없습니다. 마찬가지로 concurrentNodes가 10으로 설정되면 minimumAvailableNodes는 10을 초과할 수 없습니다.

다음 예시는 노드가 10개인 워커 노드 풀 np1을 보여줍니다. 업그레이드 한 번에 노드가 5개씩 업그레이드되며 업그레이드를 진행하려면 최소 4개의 노드를 계속 사용할 수 있어야 합니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

노드 풀 업그레이드 전략

여러 워커 노드 풀이 동시에 업그레이드되도록 클러스터를 구성할 수 있습니다. 클러스터 사양의 nodePoolUpgradeStrategy.concurrentNodePools 불리언 필드는 클러스터의 모든 워커 노드 풀을 동시에 업그레이드할지 여부를 지정합니다. 기본적으로(1) 노드 풀은 하나씩 순차적으로 업그레이드됩니다. concurrentNodePools를 0으로 설정하면 클러스터의 모든 워커 노드 풀이 동시에 업그레이드됩니다.

제어 영역과 부하 분산 노드 풀은 이 설정의 영향을 받지 않습니다. 이러한 노드 풀은 항상 한 번에 하나씩 순차적으로 업그레이드됩니다. 제어 영역 노드 풀과 부하 분산기 노드 풀은 클러스터 사양(controlPlane.nodePoolSpec.nodes 및 loadBalancer.nodePoolSpec.nodes)에 지정됩니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

동시 업그레이드 수행 방법

이 섹션에서는 동시 업그레이드를 위해 클러스터 및 워커 노드 풀을 구성하는 방법을 설명합니다.

워커 노드 풀과 워커 노드 풀의 노드를 동시에 업그레이드하려면 다음을 수행합니다.

NodePool 사양에 upgradeStrategy 섹션을 추가합니다.

클러스터를 업데이트할 때 이 매니페스트를 별도로 또는 클러스터 구성 파일의 일부로 적용할 수 있습니다.

예를 들면 다음과 같습니다.
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10
```
이 예시에서 concurrentNodes 필드 값은 5입니다. 즉, 5개 노드가 동시에 업그레이드됩니다. minimumAvailableNodes 필드는 10으로 설정됩니다. 즉, 업그레이드 중에 워크로드에 10개 이상의 노드를 계속 사용할 수 있어야 합니다.

참고: 제어 영역 또는 부하 분산기 노드 풀에 노드 업그레이드 전략을 지정할 수 없습니다.
클러스터 구성 파일의 클러스터 사양에 nodePoolUpgradeStrategy 섹션을 추가합니다.
```
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.8
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
이 예시에서는 concurrentNodePools 필드가 0으로 설정되었습니다. 즉, 클러스터 업그레이드 중에 모든 워커 노드 풀이 동시에 업그레이드됩니다. 노드 풀에 있는 노드의 업그레이드 전략은 NodePool 사양에 정의되어 있습니다.
이전 관리자, 독립형, 하이브리드, 사용자 클러스터 업그레이드 섹션에 설명된 대로 클러스터를 업그레이드합니다.

동시 업그레이드 기본값

동시 업그레이드는 기본적으로 중지되어 있으며, 동시 업그레이드와 관련된 필드는 변경할 수 있습니다. 언제든지 필드를 삭제하거나 기본값으로 설정하여 후속 업그레이드 전에 기능을 중지할 수 있습니다.

다음 표에는 동시 업그레이드 필드와 기본값이 나와 있습니다.

필드	기본값	의미
`nodePoolUpgradeStrategy.concurrentNodePools`(클러스터 사양)	`1`	워커 노드 풀을 하나씩 순차적으로 업그레이드합니다.
`upgradeStrategy.parallelUpgrade.concurrentNodes`(NodePool 사양)	`1`	노드를 하나씩 순차적으로 업그레이드합니다.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes`(NodePool 사양)	기본 `minimumAvailableNodes` 값은 `concurrentNodes` 값에 따라 달라집니다. `concurrentNodes`를 지정하지 않으면 `minimumAvailableNodes`는 기본적으로 노드 풀 크기의 2/3입니다. `concurrentNodes`를 지정하지 않으면 `minimumAvailableNodes`는 기본적으로 노드 풀 크기에서`concurrentNodes`를 뺀 값입니다.	`minimumAvailableNodes`에 도달하면 업그레이드가 중단되고 사용 가능한 노드 수가 `minimumAvailableNodes`보다 큰 경우에만 계속됩니다.

클러스터 업그레이드 시작

이 섹션에는 클러스터 업그레이드에 대한 안내가 포함되어 있습니다.

`bmctl`

bmctl의 새 버전을 다운로드하여 설치하면 이전 버전으로 만든 관리자, 하이브리드, 독립형, 사용자 클러스터를 업그레이드할 수 있습니다. bmctl의 특정 버전에서는 클러스터를 동일한 버전으로만 업그레이드할 수 있습니다.

베어메탈용 GKE 다운로드의 설명대로 최신 bmctl을 다운로드합니다.
클러스터 구성 파일의 anthosBareMetalVersion을 업그레이드 대상 버전으로 업데이트합니다.

업그레이드 대상 버전은 다운로드한 bmctl 파일의 버전과 일치해야 합니다. 다음 클러스터 구성 파일 스니펫은 최신 버전으로 업데이트된 anthosBareMetalVersion 필드를 보여줍니다.
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.16.8
```
bmctl upgrade cluster 명령어를 사용하여 업그레이드를 완료합니다.
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 업그레이드할 클러스터의 이름
- ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
클러스터 업그레이드 작업에서는 프리플라이트 검사를 실행하여 클러스터 상태와 노드 상태를 검증합니다. 프리플라이트 검사가 실패하면 클러스터 업그레이드가 진행되지 않습니다. 문제 해결 정보는 클러스터 설치 또는 업그레이드 문제 해결을 참조하세요.

모든 클러스터 구성요소가 성공적으로 업그레이드되면 클러스터 업그레이드 작업이 클러스터 상태 점검을 수행합니다. 이 마지막 단계를 통해 클러스터가 정상 작동 상태인지 확인합니다. 클러스터가 모든 상태 점검을 통과하지 못하면 통과할 때까지 계속 실행됩니다. 모든 상태 점검을 통과하면 업그레이드가 성공적으로 완료됩니다.

클러스터 업그레이드 이벤트 시퀀스에 대한 자세한 내용은 클러스터 업그레이드 수명 주기 및 단계를 참조하세요.

`kubectl`

kubectl로 클러스터를 업그레이드하려면 다음 단계를 수행합니다.

클러스터 구성 파일을 수정하여 anthosBareMetalVersion을 업그레이드 대상 버전으로 설정합니다.
업그레이드를 시작하려면 다음 명령어를 실행합니다.
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
CLUSTER_CONFIG_PATH를 수정된 클러스터 구성 파일의 경로로 바꿉니다.

bmctl을 사용하는 업그레이드 프로세스와 마찬가지로 프리플라이트 검사는 클러스터 업그레이드의 일부로 실행되어 클러스터 상태와 노드 상태를 검증합니다. 프리플라이트 검사가 실패하면 클러스터 업그레이드가 중단됩니다. 부트스트랩 클러스터가 생성되지 않으므로 실패를 해결하려면 클러스터 및 관련 로그를 검사합니다. 자세한 내용은 클러스터 설치 또는 업그레이드 문제 해결을 참조하세요.

kubectl로 업그레이드하는 데 최신 버전의 bmctl이 필요하지는 않지만 최신 bmctl을 다운로드하는 것이 좋습니다. 클러스터가 정상 작동을 유지할 수 있도록 상태 점검 및 백업과 같은 다른 태스크를 수행하려면 bmctl이 필요합니다.