새 버전의 bmctl을 설치하면 이전 버전으로 생성된 기존 클러스터를 업그레이드할 수 있습니다. 클러스터를 최신 Google Distributed Cloud 버전으로 업그레이드하면 클러스터에 추가 기능 및 수정사항이 적용됩니다. 또한 클러스터가 지원 상태로 유지됩니다.
bmctl upgrade cluster 명령어나 kubectl을 사용하여 관리자, 하이브리드, 독립형, 사용자 클러스터를 업그레이드할 수 있습니다.
업그레이드 프로세스 및 버전 관리 규칙에 대한 자세한 내용은 클러스터 업그레이드 수명 주기 및 단계를 참조하세요.
업그레이드 계획하기
이 섹션에는 클러스터를 업그레이드하기 전에 고려해야 하는 정보와 해당 링크가 포함되어 있습니다.
권장사항
Google Distributed Cloud 클러스터의 업그레이드 권장사항에서 클러스터 업그레이드를 준비하는 데 도움이 될 정보를 참조하세요.
프리플라이트 검사 업그레이드
실행 전 검사는 클러스터 업그레이드의 일부로 실행되어 클러스터 상태와 노드 상태의 유효성을 검사합니다. 실행 전 검사가 실패하면 클러스터 업그레이드가 진행되지 않습니다. 실행 전 검사에 대한 자세한 내용은 실행 전 검사 이해를 참조하세요.
업그레이드를 실행하기 전 실행 전 검사를 실행하여 클러스터의 업그레이드 준비 상태를 확인할 수 있습니다. 자세한 내용은 업그레이드를 위한 실행 전 검사를 참조하세요.
알려진 문제
클러스터 업그레이드와 관련된 잠재적 문제에 대한 자세한 내용은 베어메탈용 Google Distributed Cloud 알려진 문제를 참조하고 업그레이드 및 업데이트 문제 카테고리를 선택하세요.
업그레이드 옵션 구성
클러스터 업그레이드를 시작하기 전에 업그레이드 프로세스의 작동 방식을 제어하는 다음 업그레이드 옵션을 구성할 수 있습니다.
선택적 워커 노드 풀 업그레이드: 특정 워커 노드 풀을 나머지 클러스터와 별도로 업그레이드합니다.
동시 업그레이드: 노드 그룹 또는 노드 풀을 동시에 업그레이드하도록 업그레이드 프로세스를 구성합니다.
이러한 옵션은 중요 애플리케이션 및 서비스의 중단 위험을 줄이고 전반적인 업그레이드 시간을 크게 줄여줄 수 있습니다. 이러한 옵션은 중요한 워크로드를 실행하는 수많은 노드 및 노드 풀이 있는 대규모 클러스터에 특히 유용합니다. 이러한 옵션의 기능과 사용 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
선택적 워커 노드 풀 업그레이드
기본적으로 클러스터 업그레이드 작업은 클러스터의 모든 노드와 노드 풀을 업그레이드합니다. 클러스터 업그레이드가 중단되고 시간이 오래 걸릴 수 있으며 이로 인해 각 노드가 드레이닝되고 연결된 모든 포드가 다시 시작되고 예약됩니다. 이 섹션에서는 워크로드 중단을 최소화하기 위해 클러스터 업그레이드에 일부 워커 노드 풀을 포함하거나 제외하는 방법을 설명합니다. 관리자 클러스터에서는 워커 노드 풀을 허용하지 않으므로 이 기능은 사용자, 하이브리드, 독립형 클러스터에만 적용됩니다.
다음과 같은 상황에서 선택적 노드 풀 업그레이드를 사용할 수 있습니다.
워크로드 중단 없이 보안 수정사항 적용: 제어 영역 노드 (및 부하 분산기 노드)만 업그레이드하면 워커 노드 풀을 중단하지 않고도 Kubernetes 취약점 수정사항을 적용할 수 있습니다.
모든 워커 노드를 업그레이드하기 전에 업그레이드된 워커 노드의 하위 집합이 올바르게 작동하는지 확인: 다른 노드 풀을 업그레이드하기 전에 워커 노드 풀을 선택적으로 업그레이드하여 업그레이드된 노드 풀에서 워크로드가 제대로 실행되는지 확인할 수 있습니다.
유지보수 기간 단축: 대규모 클러스터를 업그레이드하는 데 시간이 많이 걸릴 수 있으며 업그레이드가 완료되는 시점을 정확하게 예측하기 어렵습니다. 클러스터 업그레이드 시간은 업그레이드하는 노드 수에 비례합니다. 노드 풀을 제외하여 업그레이드하는 노드 수를 줄이면 업그레이드 시간이 단축됩니다. 여러 번 업그레이드하지만 유지보수 기간이 더 짧고 예측 가능하면 예약에 도움이 될 수 있습니다.
마이너 버전 노드 풀 버전 편향 2개
버전 1.28 이상 클러스터의 경우 워커 노드 풀 버전은 클러스터 (제어 영역) 버전보다 최대 2 부 버전까지 낮을 수 있습니다. n-2 버전 편향 지원을 사용하면 해당 클러스터 이전의 부 버전 2개에서 클러스터와 동일한 부 버전으로 워커 노드 풀을 업그레이드할 때 부 출시 버전을 건너뛸 수도 있습니다.
이처럼 워커 노드 풀에 대한 n-2 버전 편향 지원은 Fleet 업그레이드를 계획할 때 더 많은 유연성을 제공합니다.
예를 들어 버전 1.28 클러스터가 있는 경우 일부 1.28, 1.16, 1.15 버전의 워커 노드 풀을 사용할 수 있습니다. 클러스터를 버전 1.29로 업그레이드하려면 먼저 1.15 워커 노드 풀을 업그레이드 전의 1.28 버전 클러스터에서 지원되는 버전으로 업그레이드해야 합니다. 클러스터를 버전 1.29로 업그레이드하기 전에 버전 1.16 워커 노드 풀을 버전 1.28로 업그레이드할 필요가 없습니다. 클러스터가 버전 1.29로 업그레이드된 후 버전 1.16 워커 노드 풀을 버전 1.29로 업그레이드하기로 결정하면 버전 1.28을 건너뛰고 한 번에 업그레이드할 수 있습니다.
지정된 클러스터 버전에서 지원되는 워커 노드 풀 버전 목록을 포함한 자세한 내용은 노드 풀 버전 관리 규칙을 참조하세요.
1.29
출시 버전 1.29에서는 워커 노드 풀에 대한 n-2 버전 편향 지원이 모든 클러스터 유형에 정식 버전으로 제공됩니다. 이 기능은 기본적으로 버전 1.29의 클러스터에서 사용 설정됩니다.
이 기능을 공개 미리보기에서 정식 버전으로 전환하더라도 하이브리드 클러스터의 경우 다음과 같은 상황에서 여전히 미리보기 주석이 필요합니다. 버전 1.16.y 워커 노드 풀과 버전 1.28.x 하이브리드 클러스터가 있는 경우, 버전 1.29.z로 업그레이드하기 전에 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 주석을 클러스터에 추가해야 합니다.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
type: hybrid
profile: default
anthosBareMetalVersion: 1.28.400-gke.77
...
1.28
워커 노드 풀의 n-2 버전 편향 지원은 출시 버전 1.28에서 미리보기로 제공됩니다. 이 미리보기 기능을 사용 설정하려면 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 주석을 클러스터 구성 파일에 추가합니다.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: baremetal-demo
namespace: cluster-baremetal-demo
annotations:
preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...
이 미리보기 기능을 사용 설정하지 않으면 워커 노드 풀과 클러스터 간의 최대 버전 편향은 부 버전 하나입니다.
워커 노드 풀을 선택적으로 업그레이드하기 위한 버전 관리 규칙에 대한 자세한 내용은 수명 주기 및 클러스터 업그레이드 단계의 노드 풀 버전 관리 규칙을 참조하세요.
클러스터 제어 영역과 선택한 노드 풀 업그레이드
초기 클러스터 업그레이드에서 워커 노드 풀을 선택적으로 업그레이드하려면 다음 안내를 따르세요.
클러스터 업그레이드에 포함할 워커 노드 풀의 경우 NodePool 사양을 다음 중 하나로 변경합니다.
- NodePool 사양의
anthosBareMetalVersion을 클러스터 대상 업그레이드 버전으로 설정합니다. - NodePool 사양에서
anthosBareMetalVersion필드를 생략하거나 빈 문자열로 설정합니다. 기본적으로 워커 노드 풀은 클러스터 업그레이드에 포함됩니다.
- NodePool 사양의
업그레이드에서 제외할 워커 노드 풀의 경우
anthosBareMetalVersion을 클러스터의 현재(업그레이드 전) 버전으로 설정합니다.클러스터 업그레이드 시작에 설명된 대로 업그레이드를 계속합니다.
클러스터 업그레이드 작업은 다음 노드를 업그레이드합니다.
- 클러스터 제어 영역 노드
- 부하 분산기 노드 풀(클러스터에서 하나(
spec.loadBalancer.nodePoolSpec)를 사용하는 경우). 기본적으로 부하 분산기 노드는 일반 워크로드를 실행할 수 있습니다. 부하 분산기 노드 풀은 선택적으로 업그레이드할 수 없으며, 항상 초기 클러스터 업그레이드에 포함됩니다. - 업그레이드에서 제외하지 않은 워커 노드 풀
예를 들어 클러스터 버전이 1.28.0이고 워커 노드 풀이 2개(wpool01 및 wpool02) 있다고 가정해 보겠습니다. 또한 제어 영역과 wpool01을 1.29.100-gke.251로 업그레이드하되 wpool02는 버전 1.28.0으로 유지한다고 가정해 보겠습니다.
다음 클러스터 구성 파일 발췌문에서는 이 부분 업그레이드를 지원하도록 클러스터 구성을 수정하는 방법을 보여줍니다.
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user001
namespace: cluster-user001
spec:
type: user
profile: default
anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
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.28.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.29.100-gke.251로 업그레이드했지만 노드 풀 wpool02는 여전히 업그레이드 전의 이전 클러스터 버전 1.28.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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: wpool01
namespace: cluster-user001
spec:
clusterName: user001
anthosBareMetalVersion: 1.29.100-gke.251
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
노드 풀 업그레이드 롤백
워크로드 성능에 영향을 줄 수 있는 kubelet 또는 플러그인과의 호환성 등 많은 종속 항목이 있습니다. 워커 노드 풀을 업그레이드한 후 문제가 발생한 경우 노드 풀을 이전 버전으로 롤백할 수 있습니다.
노드 풀 롤백 기능은 버전 1.29 클러스터(버전 1.29의 제어 영역 노드가 있는 클러스터)에서 미리보기로 제공됩니다. 이 기능이 미리보기 상태인 동안에는 preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable 주석을 Cluster 리소스에 추가하여 이 기능을 사용 설정해야 합니다.
노드 풀 업그레이드를 롤백하려면 다음 단계를 따르세요.
bmctl
bmctl을 사용하여 노드 풀 업그레이드를 롤백하는 경우 클러스터 구성 파일을 수정하고 bmctl update 명령어로 변경사항을 적용합니다.
이전 버전으로 롤백할 워커 노드 풀의 클러스터 구성 파일에서
NodePool사양을 수정합니다.anthosBareMetalVersion을 이전(업그레이드 전) 클러스터 버전으로 설정합니다.... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.600-gke.163 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...롤백 대상으로 여러 워커 노드 풀을 선택한 경우 클러스터 사양의
spec.nodePoolUpgradeStrategy.concurrentNodePools값에 따라 동시에 롤백되는 노드 풀 수가 결정됩니다. 워커 노드 풀을 동시에 롤백하지 않으려면 롤백할 노드 풀을 한 번에 하나씩 선택하거나nodePoolUpgradeStrategy설정을 업데이트합니다. 마찬가지로NodePool사양의spec.upgradeStrategy.parallelUpgrade.concurrentNodes값이 동시에 롤백되는 노드 수를 결정합니다.bmctl update를 사용하여NodePool사양 변경사항을 적용합니다.bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG다음을 바꿉니다.
CLUSTER_NAME: 업데이트하려는 클러스터의 이름ADMIN_KUBECONFIG: 관리 클러스터(관리자, 하이브리드 또는 독립형)의 kubeconfig 파일 경로
롤백은 자동으로 시작됩니다.
롤백이 실행되면 Google Distributed Cloud가 각 노드에 대해 다음 활동을 수행합니다.
- 노드를 유지보수 모드로 전환
- 노드에서 재설정 작업을 실행하여 초기 상태로 전환
- 노드에서 머신 실행 전 검사 실행
- 노드에서 machine-init 작업을 실행하여 대상 롤백 (업그레이드 전) 버전에서 다시 설치
- 유지보수 모드에서 노드 삭제
롤백이 성공하면
NodePool리소스의nodePool.status.anthosBareMetalVersion값이 대상 롤백 버전으로 설정됩니다.
kubectl
kubectl을 사용하여 NodePool 리소스를 직접 수정하여 노드 풀 업그레이드를 롤백할 수 있습니다.
워커 노드 풀을 롤백하려면 수정할
NodePool리소스를 엽니다.kubectl edit nodepool NODE_POOL_NAME \ --namespace CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG다음을 바꿉니다.
NODE_POOL_NAME: 롤백하려는 노드 풀의 이름CLUSTER_NAMESPACE: 노드 풀이 배포되는 네임스페이스의 이름. 클러스터 네임스페이스입니다.ADMIN_KUBECONFIG: 관리 클러스터(관리자, 하이브리드 또는 독립형)의 kubeconfig 파일 경로
spec.anthosBareMetalVersion값을 이전(업그레이드 전) 버전으로 변경합니다.... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: wpool01 namespace: cluster-user001 spec: clusterName: user001 anthosBareMetalVersion: 1.28.600-gke.163 nodes: - address: 10.200.0.1 - address: 10.200.0.2 - address: 10.200.0.3 ...편집기에서
NodePool리소스를 저장하고 닫습니다.롤백은 자동으로 시작됩니다.
롤백이 실행되면 Google Distributed Cloud가 각 노드에 대해 다음 활동을 수행합니다.
- 노드를 유지보수 모드로 전환
- 노드에서 재설정 작업을 실행하여 초기 상태로 전환
- 노드에서 머신 실행 전 검사 실행
- 노드에서 machine-init 작업을 실행하여 대상 롤백 (업그레이드 전) 버전에서 다시 설치
- 유지보수 모드에서 노드 삭제
롤백이 성공하면
NodePool리소스의nodePool.status.anthosBareMetalVersion값이 대상 롤백 버전으로 설정됩니다.
동시 업그레이드
일반적인 기본 클러스터 업그레이드에서는 각 클러스터 노드가 한 번에 하나씩 순차적으로 업그레이드됩니다. 이 섹션에서는 클러스터를 업그레이드할 때 여러 노드가 동시에 업그레이드되도록 클러스터 및 워커 노드 풀을 구성하는 방법을 보여줍니다. 노드를 동시에 업그레이드하면 특히 수백 개의 노드가 포함된 클러스터의 경우 클러스터 업그레이드 속도가 크게 빨라집니다.
클러스터 업그레이드 속도를 높이는 데 사용할 수 있는 동시 업그레이드 전략에는 두 가지가 있습니다.
동시 노드 업그레이드: 여러 노드가 동시에 업그레이드되도록 워커 노드 풀을 구성할 수 있습니다. 노드의 동시 업그레이드는 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.29.100-gke.251 ... nodePoolUpgradeStrategy: concurrentNodePools: 0 ...이 예시에서는
concurrentNodePools필드가0으로 설정되었습니다. 즉, 클러스터 업그레이드 중에 모든 워커 노드 풀이 동시에 업그레이드됩니다. 노드 풀에 있는 노드의 업그레이드 전략은 NodePool 사양에 정의되어 있습니다.이전 관리자, 독립형, 하이브리드, 사용자 클러스터 업그레이드 섹션에 설명된 대로 클러스터를 업그레이드합니다.
동시 업그레이드 기본값
동시 업그레이드는 기본적으로 중지되어 있으며, 동시 업그레이드와 관련된 필드는 변경할 수 있습니다. 언제든지 필드를 삭제하거나 기본값으로 설정하여 후속 업그레이드 전에 기능을 중지할 수 있습니다.
다음 표에는 동시 업그레이드 필드와 기본값이 나와 있습니다.
| 필드 | 기본값 | 의미 |
|---|---|---|
nodePoolUpgradeStrategy.concurrentNodePools(클러스터 사양) |
1 |
워커 노드 풀을 하나씩 순차적으로 업그레이드합니다. |
upgradeStrategy.parallelUpgrade.concurrentNodes(NodePool 사양) |
1 |
노드를 하나씩 순차적으로 업그레이드합니다. |
upgradeStrategy.parallelUpgrade.minimumAvailableNodes(NodePool 사양) |
기본 minimumAvailableNodes 값은 concurrentNodes 값에 따라 달라집니다.
|
minimumAvailableNodes에 도달하면 업그레이드가 중단되고 사용 가능한 노드 수가 minimumAvailableNodes보다 큰 경우에만 계속됩니다. |
클러스터 업그레이드 시작
이 섹션에는 클러스터 업그레이드에 대한 안내가 포함되어 있습니다.
bmctl
bmctl의 새 버전을 다운로드하여 설치하면 이전 버전으로 만든 관리자, 하이브리드, 독립형, 사용자 클러스터를 업그레이드할 수 있습니다.
bmctl의 특정 버전에서는 클러스터를 동일한 버전으로만 업그레이드할 수 있습니다.
Google Distributed Cloud 다운로드에 설명된 대로 최신
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.29.100-gke.251bmctl upgrade cluster명령어를 사용하여 업그레이드를 완료합니다.bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG다음을 바꿉니다.
CLUSTER_NAME: 업그레이드할 클러스터의 이름ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
클러스터 업그레이드 작업에서는 프리플라이트 검사를 실행하여 클러스터 상태와 노드 상태를 검증합니다. 프리플라이트 검사가 실패하면 클러스터 업그레이드가 진행되지 않습니다. 문제 해결 정보는 클러스터 설치 또는 업그레이드 문제 해결을 참조하세요.
모든 클러스터 구성요소가 성공적으로 업그레이드되면 클러스터 업그레이드 작업이 클러스터 상태 점검을 수행합니다. 이 마지막 단계를 통해 클러스터가 정상 작동 상태인지 확인합니다. 클러스터가 모든 상태 점검을 통과하지 못하면 통과할 때까지 계속 실행됩니다. 모든 상태 점검을 통과하면 업그레이드가 성공적으로 완료됩니다.
클러스터 업그레이드 이벤트 시퀀스에 대한 자세한 내용은 클러스터 업그레이드 수명 주기 및 단계를 참조하세요.
kubectl
kubectl로 클러스터를 업그레이드하려면 다음 단계를 수행합니다.
클러스터 구성 파일을 수정하여
anthosBareMetalVersion을 업그레이드 대상 버전으로 설정합니다.업그레이드를 시작하려면 다음 명령어를 실행합니다.
kubectl apply -f CLUSTER_CONFIG_PATHCLUSTER_CONFIG_PATH를 수정된 클러스터 구성 파일의 경로로 바꿉니다.bmctl을 사용하는 업그레이드 프로세스와 마찬가지로 프리플라이트 검사는 클러스터 업그레이드의 일부로 실행되어 클러스터 상태와 노드 상태를 검증합니다. 프리플라이트 검사가 실패하면 클러스터 업그레이드가 중단됩니다. 부트스트랩 클러스터가 생성되지 않으므로 실패를 해결하려면 클러스터 및 관련 로그를 검사합니다. 자세한 내용은 클러스터 설치 또는 업그레이드 문제 해결을 참조하세요.
kubectl로 업그레이드하는 데 최신 버전의 bmctl이 필요하지는 않지만 최신 bmctl을 다운로드하는 것이 좋습니다. 클러스터가 정상 작동을 유지할 수 있도록 상태 점검 및 백업과 같은 다른 태스크를 수행하려면 bmctl이 필요합니다.
업그레이드 일시중지 및 재개
업그레이드 일시중지 및 재개 기능을 사용하면 클러스터 업그레이드가 완료되기 전에 일시중지할 수 있습니다. 클러스터 업그레이드가 일시중지되면 업그레이드가 재개될 때까지 새 워커 노드 업그레이드가 트리거되지 않습니다.
이 기능은 부 버전 1.28 이상의 모든 제어 영역 노드가 있는 클러스터에서 미리보기로 제공됩니다. 부 버전 1.29 이상의 모든 제어 영역 노드가 있는 클러스터에서는 이 기능이 정식 버전으로 지원됩니다.
다음과 같은 이유로 업그레이드를 일시중지할 수 있습니다.
업그레이드 중 클러스터 워크로드에서 문제가 감지되어 문제를 조사하기 위해 업그레이드를 일시중지하려고 합니다.
유지보수 기간이 짧으므로 기간 간의 업그레이드를 일시중지하려고 합니다.
클러스터 업그레이드가 일시중지된 동안에 다음 작업이 지원됩니다.
업그레이드가 일시중지된 동안에 새 노드가 추가되면 업그레이드가 재개되고 완료될 때까지 머신 검사 작업이 실행되지 않습니다.
클러스터 업그레이드가 일시중지된 동안에는 다음 클러스터 작업이 지원되지 않습니다.
활성 클러스터 업그레이드가 일시중지된 동안에는 새 클러스터 업그레이드를 시작할 수 없습니다.
업그레이드 일시중지 및 재개 사용 설정
Google Distributed Cloud 1.29
업그레이드 일시중지 및 재개 기능은 부 버전 1.29 이상의 모든 제어 영역 노드가 있는 클러스터에 기본적으로 사용 설정됩니다.
Google Distributed Cloud 1.28
업그레이드 일시중지 및 재개 기능은 미리보기 상태이지만 클러스터 리소스의 주석으로 이 기능을 사용 설정할 수 있습니다.
업그레이드 일시중지 및 재개를 사용 설정하려면 다음 단계를 수행합니다.
preview.baremetal.cluster.gke.io/upgrade-pause-and-resume주석을 클러스터 구성 파일에 추가합니다.apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo annotations: preview.baremetal.cluster.gke.io/upgrade-pause-and-resume spec: ...변경사항을 적용하려면 클러스터를 업데이트합니다.
bmctl update CLUSTER_NAMEnodePoolUpgradeStrategy.pause필드는 변경 가능합니다. 언제든지 추가하고 업데이트할 수 있습니다.
업그레이드 일시중지
클러스터 사양에서 nodePoolUpgradeStrategy.pause를 true로 설정하여 클러스터 업그레이드를 일시중지합니다.
활성 클러스터 업그레이드를 일시중지하려면 다음 단계를 수행합니다.
nodePoolUpgradeStrategy.pause를 클러스터 구성 파일에 추가하고true로 설정합니다.apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: true ...bmctl을 사용하여 업그레이드를 시작한 경우 다음 단계를 수행하려면 새 터미널 창이 필요합니다.변경사항을 적용하려면 클러스터를 업데이트합니다.
bmctl update CLUSTER_NAME업그레이드 작업이 일시중지됩니다. 새 노드 업그레이드가 트리거되지 않습니다.
bmctl을 사용하여 업그레이드를 시작했고 장기간 일시중지할 계획이라면 Control+C를 눌러bmctl을 종료합니다. 그렇지 않으면bmctl이 계속 실행됩니다.bmctlCLI는 업그레이드 일시중지 상태에서의 변경사항을 감지하지 않으므로 자동으로 종료되지 않습니다. 하지만bmctl을 종료하면 관리자 워크스테이션의 클러스터 폴더에 있는cluster-upgrade-TIMESTAMP로그 파일과 Cloud Logging에 대한 로깅 업그레이드 진행이 중지됩니다. 따라서 일시적인 일시중지의 경우bmctl을 계속 실행할 수 있습니다. 업그레이드가 일시중지된 동안에bmctl이 장시간 실행되면 결국 타임아웃됩니다.
일시중지된 업그레이드 재개
클러스터 사양에서 nodePoolUpgradeStrategy.pause를 false로 설정하거나 사양에서 nodePoolUpgradeStrategy.pause를 삭제하여 일시중지된 클러스터 업그레이드를 재개합니다.
일시중지된 클러스터 업그레이드를 재개하려면 다음 단계를 수행합니다.
nodePoolUpgradeStrategy.pause를 클러스터 구성 파일로 설정하고false로 설정합니다.apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: baremetal-demo namespace: cluster-baremetal-demo ... spec: ... nodePoolUpgradeStrategy: pause: false ...또는
pause필드의 기본값이false이므로 이 필드를 삭제할 수 있습니다.변경사항을 적용하려면 클러스터를 업데이트합니다.
bmctl update CLUSTER_NAME업그레이드 작업은 중단된 지점부터 재개됩니다.
업그레이드 상태를 확인하려면 먼저
status에anthosBareMetalVersion이 있는 리소스 목록을 가져옵니다.kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces다음을 바꿉니다.
RESOURCE: 가져올 리소스의 이름입니다.Cluster,NodePool,BareMetalMachine리소스 모두anthosBareMetalVersion상태 정보가 포함되어 있습니다.ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
다음 샘플에서는
BareMetalMachine커스텀 리소스의 응답 형식을 보여줍니다. 각BareMetalMachine은 클러스터 노드에 해당합니다.NAMESPACE NAME CLUSTER READY INSTANCEID MACHINE ABM VERSION DESIRED ABM VERSION cluster-nuc-admin001 192.0.2.52 nuc-admin001 true baremetal://192.0.2.52 192.0.2.52 1.28.0 1.28.0 cluster-nuc-user001 192.0.2.53 nuc-user001 true baremetal://192.0.2.53 192.0.2.53 1.16.2 1.16.2 cluster-nuc-user001 192.0.2.54 nuc-user001 true baremetal://192.0.2.54 192.0.2.54 1.16.2 1.16.2status.anthosBareMetalVersion(현재 리소스 버전)을 확인하려면 개별 리소스의 세부정보를 검색합니다.kubectl describe RESOURCE RESOURCE_NAME \ --kubeconfig ADMIN_KUBECONFIG \ --namespace CLUSTER_NAMESPACE다음 샘플에서는 IP 주소가
192.0.2.53인 클러스터 노드의BareMetalMachine세부정보를 보여줍니다.Name: 192.0.2.53 Namespace: cluster-nuc-user001 ... API Version: infrastructure.baremetal.cluster.gke.io/v1 Kind: BareMetalMachine Metadata: Creation Timestamp: 2023-09-22T17:52:09Z ... Spec: Address: 192.0.2.53 Anthos Bare Metal Version: 1.16.2 ... Status: Anthos Bare Metal Version: 1.16.2이 예시에서 노드는 Google Distributed Cloud 버전 1.16.2에 있습니다.