베어메탈용 GKE를 업그레이드하는 경우 업그레이드 프로세스에는 여러 단계와 구성요소가 포함됩니다. 업그레이드 상태를 모니터링하거나 문제를 진단하고 해결하려면 bmctl upgrade cluster 명령어를 실행할 때 발생하는 결과를 이해하는 것이 좋습니다. 이 문서에서는 클러스터 업그레이드의 구성요소와 단계를 자세히 설명합니다.
개요
업그레이드 프로세스는 베어메탈용 GKE 클러스터를 현재 버전에서 상위 버전으로 이동합니다.
이 버전 정보는 관리자 클러스터에서 클러스터 커스텀 리소스의 일부로 다음 위치에 저장됩니다.
status.anthosBareMetalVersion: 클러스터의 현재 버전을 정의합니다.spec.anthosBareMetalVersion: 대상 버전을 정의하며 업그레이드 프로세스가 실행되기 시작할 때 설정됩니다.
성공적인 업그레이드 작업은 모두 대상 버전을 표시하도록 status.anthosBareMetalVersion에서 spec.anthosBareMetalVersion으로 조정합니다.
버전 차이
버전 차이는 관리자 클러스터와 관리형 사용자 클러스터 간의 버전 차이입니다. 베어메탈용 GKE 클러스터는 Kubernetes와 동일한 스타일을 따릅니다. 관리자 클러스터는 관리형 클러스터보다 부 버전 하나만 높을 수 있습니다.
업그레이드 버전 규칙
새 버전의 bmctl을 다운로드하고 설치할 때 이전 버전의 bmctl로 만들거나 업그레이드한 관리자, 하이브리드, 독립형, 사용자 클러스터를 업그레이드할 수 있습니다. 클러스터를 더 낮은 버전으로 다운그레이드할 수는 없습니다.
사용 중인 bmctl의 버전과 일치하는 버전으로만 클러스터를 업그레이드할 수 있습니다. 즉, bmctl 버전 1.28.400-gke.77을 사용하는 경우 클러스터를 버전 1.28.400-gke.77로만 업그레이드할 수 있습니다.
패치 버전 업그레이드
지정된 부 버전의 경우 상위 패치 버전으로 업그레이드할 수 있습니다. 즉, Y가 X보다 크면 1.28.X 버전 클러스터를 1.28.Y 버전으로 업그레이드할 수 있습니다. 예를 들어 1.16.0에서 1.16.1로 업그레이드하고 1.16.1에서 1.16.3으로 업그레이드할 수 있습니다. 가능할 때마다 클러스터에 최신 보안 수정이 적용되도록 최신 패치 버전으로 업그레이드하는 것이 좋습니다.
부 버전 업그레이드
패치 버전과 관계없이 클러스터를 한 부 버전에서 다음 부 버전으로 업그레이드할 수 있습니다. 즉, 1.N.X에서 1.N+1.Y로 업그레이드할 수 있습니다. 이때 1.N.X는 클러스터의 버전이고 N+1은 다음으로 사용 가능한 부 버전입니다. 이 경우 패치 버전 X 및 Y는 업그레이드 로직에 영향을 미치지 않습니다. 예를 들어 1.16.3에서 1.28.400-gke.77로 업그레이드할 수 있습니다.
클러스터를 업그레이드하는 경우 부 버전을 건너뛸 수 없습니다. 클러스터 버전보다 부 버전 두 개 이상 높은 부 버전으로 업그레이드하려고 하면 bmctl에서 오류가 발생합니다. 예를 들어 1.15.0 버전 클러스터를 1.28.0 버전으로 업그레이드할 수 없습니다.
관리자 클러스터는 동일하거나 이전 부 버전에 있는 사용자 클러스터를 관리할 수 있습니다. 관리되는 사용자 클러스터는 관리자 클러스터보다 부 버전이 둘 이상 낮아지면 안 됩니다. 따라서 관리자 클러스터를 새 부 버전으로 업그레이드하기 전에 모든 관리되는 사용자 클러스터가 관리자 클러스터와 동일한 부 버전에 있는지 확인하세요.
노드 풀 버전 관리 규칙
노드 풀을 선택적으로 업그레이드하면 다음 버전 규칙이 적용됩니다.
클러스터 버전은 워커 노드 풀 버전 이상이어야 합니다.
베어메탈용 GKE 부 출시 버전 1.28에서 워커 노드 풀 버전을 클러스터(제어 평면) 버전보다 최대 2 부 버전까지 높일 수 있습니다. 이 n-2 버전 편향은 (미리보기) 기능으로 제공됩니다. 이 미리보기 기능은 클러스터 구성 파일에서 주석으로 사용 설정됩니다. 이 미리보기 기능을 사용 설정하지 않으면 워커 노드 풀과 클러스터 간의 최대 버전 편향은 부 버전 하나입니다.
워커 노드 풀은 클러스터 버전보다 시간순으로 늦게 출시된 버전에 있을 수 없습니다.
예를 들어 버전 1.16.4가 버전 1.28.0-gke.425 이후에 출시되면 클러스터를 버전 1.28.0-gke.425로 업그레이드할 수 없고 워커 노드 풀을 버전 1.16.4에 그대로 둘 수 없습니다. 마찬가지로 클러스터를 버전 1.28.0-gke.425로 업그레이드했지만 워커 노드 풀을 버전 1.16.3으로 유지한 경우 나중에 워커 노드 풀을 버전 1.16.4로 업그레이드할 수 없습니다.
다음 표에는 특정 클러스터 버전에 허용되는 지원되는 노드 풀 버전이 나와 있습니다.
| 클러스터(제어 영역) 버전 | 지원되는 워커 노드 풀 버전 | |||
|---|---|---|---|---|
| 1.28.400-gke.77 |
|
|
|
|
| 1.28.300-gke.131 |
|
|
|
|
| 1.28.200-gke.118 |
|
|
|
|
| 1.28.100-gke.146 |
|
|
|
|
| 1.28.0-gke.425 |
|
|
|
|
구성요소 업그레이드
구성요소는 노드와 클러스터 수준 모두에서 업그레이드됩니다. 클러스터 수준에서 다음 구성요소가 업그레이드됩니다.
- 네트워킹, 관측 가능성, 스토리지를 위한 클러스터 구성요소
- 관리자, 하이브리드, 독립형 클러스터의 경우 수명 주기 컨트롤러
gke-connect-agent
클러스터의 노드는 다음 역할 중 하나로 실행되며 노드의 역할에 따라 다른 구성요소가 업그레이드됩니다.
| 노드 역할 | 함수 | 업그레이드할 구성요소 |
|---|---|---|
| 작업자 | 사용자 워크로드 실행 | Kubelet, 컨테이너 런타임(Docker 또는 containerd) |
| 제어 영역 | Kubernetes 제어 영역, 클러스터 수명 주기 컨트롤러, Google Kubernetes Engine(GKE) Enterprise 버전 플랫폼 부가기능을 실행합니다. | Kubernetes 제어 영역 정적 포드(kubeapi-server, kube-scheduler, kube-controller-manager, etcd)
수명 주기 컨트롤러(예: lifecycle-controllers-manager 및
anthos-cluster-operator)Google Kubernetes Engine(GKE) Enterprise 버전 플랫폼 부가 기능(예: stackdriver-log-aggregator 및 gke-connect-agent) |
| 제어 영역 부하 분산기 | kube-apiserver에 트래픽을 제공하는 HAProxy 및 Keepalived를 실행하고 MetalLB 스피커를 실행하여 가상 IP 주소를 요청합니다. |
제어 영역 부하 분산기 정적 포드(HAProxy, Keepalived)
MetalLB 스피커 |
다운타임 예상
다음 표에서는 클러스터를 업그레이드할 때 예상되는 다운타임 및 잠재적인 영향을 자세히 설명합니다. 이 표에서는 여러 클러스터 노드와 HA 제어 영역이 있다고 가정합니다. 독립형 클러스터를 실행하거나 HA 제어 영역이 없는 경우 다운타임이 추가로 발생할 수 있습니다. 특별히 언급되지 않은 경우 이 다운타임은 관리자 및 사용자 클러스터 업그레이드에 모두 적용됩니다.
| 구성요소 | 다운타임 예상 | 다운타임이 발생하는 경우 |
|---|---|---|
Kubernetes 제어 영역 API 서버(kube-apiserver), etcd, 스케줄러 |
다운타임 없음 | 해당 사항 없음 |
수명 주기 컨트롤러 및 ansible-runner 작업(관리자 클러스터만 해당) |
다운타임 없음 | 해당 사항 없음 |
Kubernetes 제어 영역 loadbalancer-haproxy 및 keepalived |
부하 분산기가 트래픽을 리디렉션할 때 발생하는 일시적인 다운타임입니다(1~2분 미만). | 업그레이드 절차를 시작합니다. |
관측 가능성 pipeline-stackdriver 및 metrics-server |
연산자가 드레이닝되고 업그레이드되었습니다. 다운타임은 5분 미만이어야 합니다.
DaemonSet은 다운타임 없이 계속 작동합니다. |
제어 영역 노드 업그레이드가 완료된 후 |
| 컨테이너 네트워크 인터페이스(CNI) | 기존 네트워킹 경로에 다운타임이 없습니다. DaemonSet이 다운타임 없이 2개씩 배포되었습니다. 연산자가 드레이닝되고 업그레이드되었습니다. 다운타임이 5분 미만입니다. |
제어 영역 노드 업그레이드가 완료된 후 |
| MetalLB(사용자 클러스터만 해당) | 연산자가 드레이닝되고 업그레이드되었습니다. 다운타임이 5분 미만입니다.
기존 서비스의 다운타임 없음 |
제어 영역 노드 업그레이드가 완료된 후 |
| CoreDNS 및 DNS 자동 확장 처리(사용자 클러스터만 해당) | CoreDNS에는 자동 확장 처리가 포함된 여러 복제본이 있습니다. 일반적으로 다운타임이 없습니다. | 제어 영역 노드 업그레이드가 완료된 후 |
| 로컬 볼륨 프로비저닝 도구 | 기존 프로비저닝된 영구 볼륨(PV)에 다운타임 없음
작업자에게 5분 동안 다운타임이 발생할 수 있습니다. |
제어 영역 노드 업그레이드가 완료된 후 |
| Istio / 인그레스 | Istio 연산자가 드레이닝되고 업그레이드되었습니다. 다운타임이 약 5분입니다. 기존의 구성된 인그레스는 계속 작동합니다. |
제어 영역 노드 업그레이드가 완료된 후 |
| 기타 시스템 연산자 | 드레이닝 및 업그레이드 시 5분의 다운타임 | 제어 영역 노드 업그레이드가 완료된 후 |
| 사용자 워크로드 | 고가용성과 같은 설정에 따라 달라집니다. 자체 워크로드 배포를 검토하여 잠재적인 영향을 파악합니다. |
워커 노드가 업그레이드된 경우 |
사용자 클러스터 업그레이드 세부정보
이 섹션에서는 사용자 클러스터 업그레이드의 구성요소 업그레이드 순서 및 상태 정보를 자세히 설명합니다. 다음 섹션에서는 관리자, 하이브리드 또는 독립형 클러스터 업그레이드의 이 흐름에서 편차를 자세히 설명합니다.
다음 다이어그램은 사용자 클러스터 업그레이드의 프리플라이트 검사 프로세스를 보여줍니다.
위의 다이어그램은 업그레이드 중에 발생하는 단계를 자세히 보여줍니다.
bmctl upgrade cluster명령어는PreflightCheck커스텀 리소스를 만듭니다.- 프리플라이트 검사는 클러스터 업그레이드 확인, 네트워크 상태 점검, 노드 상태 점검과 같은 추가 확인을 실행합니다.
- 이러한 추가 확인 결과가 결합되어 클러스터가 대상 버전으로 성공적으로 업그레이드되는 기능을 보고합니다.
프리플라이트 검사가 성공하고 차단 문제가 없으면 다음 다이어그램과 같이 클러스터의 구성요소가 지정된 순서로 업그레이드됩니다.
위의 다이어그램에서 구성요소는 다음과 같이 업그레이드됩니다.
- 업그레이드는
spec.anthosBareMetalVersion필드를 업데이트하여 시작됩니다. - 제어 영역 부하 분산기가 업그레이드됩니다.
- 제어 영역 노드 풀이 업그레이드됩니다.
- 이와 동시에 GKE 연결이 업그레이드되고, 클러스터 부가기능이 업그레이드되고, 부하 분산기 노드 풀이 업그레이드됩니다.
- 부하 분산기 노드 풀이 성공적으로 업그레이드되면 워커 노드 풀이 업그레이드됩니다.
모든 구성요소가 업그레이드되면 클러스터 상태 점검이 실행됩니다.
상태 점검은 모든 점검이 통과할 때까지 계속 실행됩니다.
모든 상태 점검을 통과하면 업그레이드가 완료된 것입니다.
각 구성요소에는 클러스터 커스텀 리소스 내에 자체 상태 필드가 있습니다. 다음 필드에서 상태를 확인하여 업그레이드 진행 상황을 이해할 수 있습니다.
| 시퀀스 | 입력란 이름 | 의미 |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
상태가 제어 영역 노드 풀 상태에서 복사됩니다. 이 필드에는 제어 영역 노드 풀의 노드 버전이 포함됩니다. |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
클러스터에 적용된 lifecycles-controllers-manager 버전입니다. 이 필드는 관리자, 독립형 또는 하이브리드 클러스터에만 사용할 수 있습니다. |
| 2 | status.anthosBareMetalManifestsVersion |
마지막으로 적용된 매니페스트의 클러스터 버전입니다. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
상태가 제어 영역 부하 분산기 노드 풀 상태에서 복사됩니다. Cluster.Spec에 별도의 제어 영역 부하 분산기가 지정되지 않은 경우 이 필드는 비어 있습니다. |
| 3 | status.anthosBareMetalVersions |
노드 번호에 대한 버전의 집계된 버전 맵입니다. |
| 4 | status.anthosBareMetalVersion |
업그레이드된 버전의 최종 상태입니다. |
관리자, 하이브리드, 독립형 클러스터 업그레이드 세부정보
bmctl 버전 1.15.0부터 자체 관리형(관리자, 하이브리드, 독립형) 클러스터의 기본 업그레이드 동작은 인플레이스 업그레이드입니다.
즉, 클러스터를 버전 1.15.0 이상으로 업그레이드하는 경우 업그레이드는 부트스트랩 클러스터 대신 수명 주기 컨트롤러를 사용하여 전체 업그레이드 프로세스를 관리합니다. 이 변경사항 덕분에 프로세스가 간소화되고 리소스 요구사항이 줄어 클러스터 업그레이드의 안정성과 확장성이 향상됩니다.
업그레이드에 부트스트랩 클러스터를 사용하지 않는 것이 좋지만 이 옵션도 사용할 수 있습니다. 업그레이드 시 부트스트랩 클러스터를 사용하려면 --use-bootstrap=true 플래그와 함께 bmctl upgrade 명령어를 실행합니다.
업그레이드 단계는 사용하는 방법에 따라 다릅니다.
인플레이스 업그레이드
자체 관리형 클러스터의 기본 인플레이스 업그레이드 프로세스는 사용자 클러스터 업그레이드 프로세스와 유사합니다. 그러나 인플레이스 업그레이드 프로세스를 사용할 때는 클러스터 프리플라이트 검사와 상태 점검이 실행되기 전에 preflightcheck-operator의 새 버전이 배포됩니다.
사용자 클러스터 업그레이드와 마찬가지로 업그레이드 프로세스는 Cluster.spec.anthosBareMetalVersion 필드를 대상 버전으로 업데이트하면서 시작됩니다. 다음 다이어그램과 같이 구성요소가 업데이트되기 전 두 가지 추가 단계가 실행됩니다. lifecycle-controller-manager는 대상 버전으로 자체 업그레이드한 다음 대상 anthos-cluster-operator 버전을 배포합니다. 이 anthos-cluster-operator가 업그레이드 프로세스의 나머지 단계를 수행합니다.
성공하면 anthos-cluster-operator가 대상 버전을 spec.anthosBareMetalVersion에서 status.anthosBareMetalVersion으로 조정합니다.
부트스트랩 클러스터를 사용한 업그레이드
관리자, 하이브리드 또는 독립형 클러스터를 업그레이드하는 프로세스는 이전 섹션에서 설명한 사용자 클러스터와 비슷합니다.
주요 차이점은 bmctl upgrade cluster 명령어가 부트스트랩 클러스터를 만드는 프로세스를 시작한다는 것입니다. 이 부트스트랩 클러스터는 업그레이드 중에 하이브리드, 관리자 또는 독립형 클러스터를 관리하는 임시 클러스터입니다.
클러스터의 관리 소유권을 부트스트랩 클러스터로 전송하는 프로세스를 피벗이라고 합니다. 나머지 업그레이드는 사용자 클러스터 업그레이드와 동일한 프로세스를 따릅니다.
업그레이드 프로세스 중에는 대상 클러스터의 리소스가 비활성 상태로 유지됩니다. 업그레이드 진행은 부트스트랩 클러스터의 리소스에만 반영됩니다.
필요한 경우 부트스트랩 클러스터에 액세스하여 업그레이드 프로세스를 모니터링하고 디버깅할 수 있습니다. bmctl-workspace/.kindkubeconfig를 통해 부트스트랩 클러스터에 액세스할 수 있습니다.
업그레이드가 완료된 후 클러스터의 관리 소유권을 다시 이전하기 위해 클러스터는 부트스트랩 클러스터에서 업그레이드된 클러스터로 리소스를 피벗합니다. 업그레이드 프로세스 중에는 클러스터를 피벗하기 위해 수행하는 수동 단계가 없습니다. 클러스터 업그레이드가 성공하면 부트스트랩 클러스터가 삭제됩니다.
노드 드레이닝
베어메탈용 GKE 클러스터 업그레이드는 노드가 드레이닝될 때 애플리케이션을 중단시킬 수 있습니다. 이 드레이닝 프로세스를 수행하면 노드에서 실행되는 모든 포드가 종료되고 클러스터의 나머지 노드에서 다시 시작됩니다.
배포는 이러한 중단을 견디는 데 사용될 수 있습니다. 배포는 실행할 애플리케이션 또는 서비스의 여러 복제본을 지정할 수 있습니다. 여러 복제본이 있는 애플리케이션은 업그레이드 중에 중단이 거의 또는 전혀 발생하지 않습니다.
포드 중단 예산(PDB)
포드 중단 예산(PDB)을 사용하면 정의된 수의 복제본이 항상 정상 실행 조건의 클러스터에서 실행되도록 할 수 있습니다. PDB를 사용하면 포드 일정을 변경해야 할 때 워크로드의 중단을 제한할 수 있습니다.
하지만 베어메탈용 GKE는 업그레이드 중에 노드가 드레이닝될 때 PDB를 따르지 않습니다.
대신 노드 드레이닝 프로세스가 권장됩니다. 일부 포드가 Terminating 상태로 멈춰서 노드 비우기를 거부할 수 있습니다. 노드의 드레이닝 프로세스가 20분 넘게 걸리면 포드가 중단된 상태에서도 업그레이드가 진행됩니다.