중요합니다
AKS 플랫폼에서 시작한 업그레이드. 2027년 6월 1일부터 AKS는 60일 플랫폼 지원 유예 기간이 종료된 후 지원되지 않는 Kubernetes 버전에 유지되는 모든 클러스터를 자동으로 업그레이드합니다. 플랫폼에서 시작한 업그레이드 는 유지 관리 기간을 따르지 않고, 지원 중단된 API 사용 때문에 중지되지 않으며, 노드 드레이닝을 차단하는 Pod Disruption Budget를 재정의할 수 있으므로 워크로드가 중단될 수 있습니다. 업그레이드 월 전에 대상 Kubernetes 버전에서 제거된 API를 바꾸고 호환되지 않는 자체 관리형 추가 기능을 업데이트합니다. 플랫폼에 의해 시작되는 업그레이드를 방지하려면 지원되는 Kubernetes 버전에 클러스터를 유지하세요. 자세한 내용은 AKS에서 플랫폼에서 시작한 업그레이드 준비를 참조하세요.
AKS(Azure Kubernetes Service) 롤링 업그레이드를 수행하여 실행 중인 워크로드의 중단을 최소화합니다.
대부분의 프로덕션 워크로드에서 AKS Automatic은 해당하는 경우 권장되는 기본값입니다. AKS Automatic에는 자동 Kubernetes 버전 업그레이드, OS(자동 노드 운영 체제) 이미지 업데이트, 관리되는 시스템 노드 작업 및 수동 오버헤드를 줄이는 기본 제공 보호 장치와 같은 업그레이드 작업에 대한 프로덕션 준비 기본값이 포함됩니다. 자세한 내용은 AKS 자동 소개를 참조하세요.
이 문서에서는 AKS 업그레이드 메커니즘을 설명하고 AKS 자동 및 AKS 표준이 다른 위치를 강조 표시합니다.
필수 조건
업그레이드 모델: AKS 자동 및 AKS 표준
AKS 자동 및 AKS 표준 클러스터 모드는 동일한 Kubernetes 업그레이드 기본 사항을 사용하지만 기본값과 운영 소유권은 다릅니다.
| 업그레이드 관련 문제 | AKS 자동화 | AKS 표준 |
|---|---|---|
| 프로덕션 위치 지정 | 해당하는 경우 대부분의 프로덕션 워크로드에 권장되는 기본값 | 기본적으로 더 많은 수동 구성을 사용하는 유연한 모델 |
| Kubernetes 마이너 버전 업그레이드 | 미리 구성된 자동 업그레이드 채널 | 기본적으로 수동, 선택적 자동 채널 |
| 노드 OS 이미지 업그레이드 | 미리 구성된 자동 노드 OS 이미지 채널 | 기본적으로 수동, 선택적 자동 채널 |
| 시스템 노드 풀 작업 | AKS에서 관리 | 고객이 관리 |
| 계획된 유지 관리 창 | 기본적으로 사용 가능 | 선택적 구성 |
| 워크로드 중단 제어 | 복제 전략, 준비 동작 및 중단 정책을 포함한 고객 소유 자산 | 복제 전략, 준비 동작 및 중단 정책을 포함한 고객 소유 자산 |
메모
AKS 자동은 플랫폼 작업을 간소화하지만 공유 책임은 여전히 적용됩니다. 워크로드 수준 가용성 디자인 및 제거 정책 동작은 여전히 고객의 책임입니다.
AKS의 롤링 업그레이드 동작
AKS는 노드를 바꾸거나 이미지로 다시 설치하는 동안 용량을 유지하는 롤링 패턴을 사용하여 노드 풀을 업그레이드합니다. 이 동작은 모든 AKS 클러스터 모드에서 동일합니다.
AKS는 높은 수준에서 다음을 수행합니다.
- 업그레이드 설정에 따라 임시 추가 용량을 제공합니다.
- 노드를 차단 및 드레인하여 작업 부하를 이동합니다.
- 노드에 대상 버전 이미지를 다시 적용하거나 교체합니다.
- 완료 후 일시적 증설 용량을 제거합니다.
롤링 업그레이드 예제
이 예제에서는 maxSurge가 1(으)로 설정된 상태에서 2노드 클러스터를 Kubernetes 1.30에서 1.31로 업그레이드하는 예를 보여 줍니다.
1단계: 초기 설정
클러스터는 각각 애플리케이션 Pod를 호스팅하는 버전 1.30을 실행하는 두 개의 노드로 시작합니다.
- 노드 1: 포드 A, 포드 B
- 노드 2: Pod C, Pod D
- 서지 노드: 비어 있음(DaemonSets 및 새 Pod 제외)
2단계: 첫 번째 노드를 격리하고 배수하기
AKS는 새 Pod 예약을 방지하기 위해 노드 1을 차단하여, 기존 Pod를 제거합니다.
- Pod A → 제거되고 서지 노드에서 대체됨
- 노드 2에서 Pod B → 제거 및 교체됨
3단계: 첫 번째 노드 업그레이드
노드 1은 Kubernetes 버전 1.31로 재이미지화되는 동안 다른 노드에서는 pod가 계속 실행됩니다.
- 노드 1: v1.31로 업그레이드
- 노드 2: Pod B, Pod C, Pod D
- 서지 노드: Pod A
4단계: 두 번째 노드를 격리하고 배수 처리하기
AKS는 노드 2에 대한 프로세스를 반복하고, Pod가 제거되고, 스케줄러가 해당 노드를 사용 가능한 적절한 노드에 재배포합니다.
- 노드 1에서 Pod C, B → 제거 및 교체됨
- Pod D → 제거되고 서지 노드에서 대체됨
- 노드 2: v1.31로 조정 및 이미지 다시 설치
5단계: 서지 노드 제거
모든 영구 노드 업그레이드가 완료되면 서지 노드는 차단되고, 드레인된 후 삭제됩니다.
- 노드 1에서 Pod A → 제거 및 교체됨
- 노드 2에서 Pod D → 제거 및 교체됨
- 서지 노드: 삭제됨
최종 상태
이제 모든 노드에서 Kubernetes 버전 1.31이 실행되며, 클러스터 전체에 Pod가 배치되고 있습니다.
- 노드 1 (v1.31): Pod A, Pod C
- 노드 2(v1.31): Pod B, Pod D
제한적인 포드 중단 예산(PDB) 동작
제한적인 PDB가 제거를 차단하는 경우 노드 드레이닝이 지연되거나 방지될 수 있습니다. AKS는 구성된 동작에 따라 Cordon 드레이닝할 수 없는 노드 동작을 사용하여 업그레이드 가능한 다른 노드의 업그레이드를 계속할 수 있습니다. 차단된 노드는 차단 조건이 해결될 때까지 이전 버전에 남아 있을 수 있습니다.
메모
플랫폼에서 시작한 업그레이드는 다르게 동작합니다. AKS는 먼저 일반 드레인을 시도하지만 드레이닝 시간이 초과되거나 실패하면 클러스터가 지원되는 Kubernetes 버전에 도달하게 되도록 PDB를 재정의합니다.
제한적인 PDB 예제
이 예제에서는 maxSurge가 2로 설정된 상태에서 Kubernetes 1.30에서 1.31로 2노드 클러스터를 업그레이드할 때 첫 번째 노드의 드레인 작업을 차단하는 PDB가 있는 경우를 보여줍니다.
1단계: 제한적인 PDB를 사용한 초기 설정
클러스터는 버전 1.30을 실행하는 두 개의 노드로 시작하며 PDB는 Pod A를 제거로부터 보호합니다.
- 노드 1: Pod A(PDB로 보호), Pod B
- 노드 2: Pod C, Pod D
- 서지 노드: 새로 만든 2개의 노드
- PDB: Pod A 제거 방지
2단계: 첫 번째 노드 드레이닝 시도(차단됨)
AKS는 노드 1을 차단하지만 PDB 제한으로 인해 포드 A를 드레인할 수 없습니다.
- 노드 1: 제외되어 격리된 것으로 표시됨 (Pod A 중단).
- Pod B → 제거되고 서지 노드 1에서 대체되고, 서지 노드 2는 일시적으로 사용되지 않습니다.
- 상태: 노드 1 업그레이드가 차단됨
3단계: 두 번째 노드로 진행
노드 1이 격리되면 AKS는 노드 2를 계속 업그레이드합니다.
- 노드 1: 격리된 상태로 유지(v1.30)
- 노드 2: 제외되고 드레이닝됨
- Pod C → 제거되고 서지 노드 2에서 대체됨
- Pod D → 제거되고 서지 노드 2에서 대체됨
4단계: 두 번째 노드 업그레이드
노드 2가 Kubernetes 버전 1.31로 성공적으로 재이미징되었습니다.
- 노드 1: v1.30에서 Pod A와 함께 여전히 격리 중
- 노드 2: v1.31로 업그레이드
- 서지 노드 1: Pod B
- 서지 노드 2: Pod C, Pod D
5단계: 한 서지 노드는 제거되는 다른 서지 노드의 영구적인 대체 노드가 됩니다.
노드 1은 격리된 상태로 유지되므로 서지 노드 1은 v1.31을 실행하는 영구 교체가 되고 서지 노드 2는 삭제됩니다.
- 노드 1: 격리됨(v1.30) - 수동 개입 필요
- Pod C, Pod D → 서지 노드 2에서 제거되고 노드 2에서 대체됨
- 서지 노드 1(v1.31): Pod B(현재 영구)
- 서지 노드 2(v1.31): 삭제됨
최종 상태
수동 개입이 필요한 격리된 노드 1개로 업그레이드가 완료됩니다.
- 노드 1: Pod A로 격리됨(v1.30) - 고객이 수동으로 해결해야 합니다 ( 드레인할 수 없는 노드 확인 참조)
- 노드 2(v1.31): 정상적으로 실행
- 이전 서지 노드(v1.31): 이제 영구 교체
중요합니다
격리된 노드(노드 1)는 고객이 관리할 책임이 있습니다. 다음 중 하나를 수행해야 합니다.
- Pod A의 제거를 허용하도록 PDB를 조정합니다.
- Pod A를 수동으로 삭제합니다.
- 차단 조건을 수정한 후 노드를 삭제하고 다시 만듭니다.
PDB 차단 업그레이드에 대한 주요 고려 사항
-
정의할 수 없는 노드 동작: 노드 풀에 대해 이 격리 동작을 사용하도록 설정합니다
Cordon. - 고객 책임: 격리된 노드를 해결하려면 수동 개입이 필요합니다.
- 클러스터 용량: 서지 노드가 영구화되어 클러스터 용량 계획에 영향을 미칠 수 있습니다.
- 모니터링: Azure Monitor 또는 kubectl을 통해 격리된 노드를 추적하여 적시에 해결합니다.
팁 (조언)
격리 시나리오를 완전히 방지하려면 자동 PDB 관리를 사용하여 배포 복제본을 자동으로 확장하여 드레이닝이 시작되기 전에 PDB 제약 조건이 충족되도록 할 수 있습니다. 이를 통해 차단 없이 제거를 진행할 수 있으므로 수동 격리 확인이 필요하지 않습니다.
Blue-Green 노드 풀 업그레이드(수동 제어)
Blue-Green 업그레이드는 워크로드를 마이그레이션하기 전에 새 노드 풀의 전체 집합을 수동으로 만들어 보다 제어된 업그레이드 방법을 제공합니다. 이 수동 접근 방식을 사용하면 업그레이드 프로세스 및 타이밍을 완전히 제어할 수 있습니다.
자세한 내용은 AKS에서Blue-Green 노드 풀 업그레이드를 참조하세요.
Blue-Green 업그레이드를 사용하는 경우
수동 Blue-Green 노드 풀 업그레이드는 명시적 마이그레이션 검사점, 사용자 지정 유효성 검사 게이트 또는 엄격하게 제어되는 컷오버와 같은 특수 요구 사항에 대한 고급 전략입니다.
필요한 경우 수동 Blue-Green 사용합니다.
- 운영자가 제어하는 마이그레이션 단계입니다.
- 커밋하기 전에 사용자 지정 유효성 검사 및 수락 조건입니다.
- 내부 운영 절차서에 연계된 명시적 롤백 절차.
해당하는 대부분의 프로덕션 워크로드의 경우 AKS 자동 기본 업그레이드 동작이 기본 시작점이며, 수동 Blue-Green 일반적으로 예외적인 경우를 위해 예약됩니다.
주요 개념
- 파란색 노드 풀: 현재 Kubernetes 버전을 실행하는 기존 노드 풀입니다.
- 녹색 노드 풀: 대상 Kubernetes 버전을 실행하여 만드는 새 노드 풀입니다.
- 수동 제어: 마이그레이션 프로세스의 모든 측면을 관리합니다.
- 유효성 검사점: 진행, 일시 중지 또는 롤백할 시기를 결정합니다.
Blue-Green 업그레이드의 이점
- 모든 권한: 각 단계가 발생하는 시기를 정확하게 결정합니다.
- 사용자 지정 유효성 검사: 고유한 유효성 검사 조건 및 타이밍을 구현합니다.
- 점진적 마이그레이션: 원하는 속도로 워크로드를 이동합니다.
- 간편한 롤백: 원래 노드는 삭제할 때까지 계속 사용할 수 있습니다.
Blue-Green 업그레이드에 대한 주요 고려 사항
- 수동 작업: 프로세스 전체에서 활성 관리가 필요합니다.
- 할당량 요구 사항: 업그레이드하는 동안 노드 용량의 2배가 필요합니다.
- 계획: 유효성 검사 조건 및 롤백 절차를 문서화합니다.
수동 Blue-Green 업그레이드 프로세스 예제
이 예제에서는 Blue-Green 배포를 사용하여 Kubernetes 1.30에서 1.31로 2노드 클러스터를 수동으로 업그레이드하는 방법을 보여 줍니다.
1단계: 녹색 노드 풀 만들기
먼저 기존 노드 풀과 함께 대상 Kubernetes 버전을 사용하여 새 노드 풀을 수동으로 만듭니다.
- 파란색 노드 풀(v1.30): Pod A, Pod B, Pod C, Pod D(기존)
- 녹색 노드 풀(v1.31): 비어 있음(사용자가 수동으로 만든)
- 귀하의 작업: 새로운 Kubernetes 버전 적용
2단계: 블루 노드를 수동으로 격리하기
기존 Pod는 계속 실행한 채 새 Pod가 스케줄되지 않도록 파란색 노드를 차단합니다.
-
작업:
kubectl cordon각 파란색 노드에서 수행하기 - 파란색 노드: 차단됨, 새로운 Pod 예약 안 됨
- 녹색 노드: 워크로드를 받을 준비가 완료됨
3단계: 수동으로 파란색 노드 드레이닝(제어된 속도)
노드를 한 번에 하나씩 또는 일괄 처리로 수동으로 드레이닝하여 마이그레이션 속도를 제어합니다.
-
귀하의 동작:
kubectl drain선택한 파란색 노드 - Pod 마이그레이션: Pod가 자동으로 녹색 노드로 다시 할당됨
- 유효성 검사: 계속하기 전에 녹색 노드에서 워크로드 확인
4단계: 유효성 검사 및 결정
워크로드를 마이그레이션한 후 녹색 노드에서 애플리케이션 성능의 유효성을 검사합니다.
이 단계에서는 다음을 수행할 수 있습니다.
- 모니터: 애플리케이션 메트릭 및 로그 확인
- 테스트: 녹색 노드 풀에서 유효성 검사 테스트 실행
- 결정: 녹색으로 커밋하거나 파란색으로 롤백
5단계: 커밋 또는 롤백
유효성 검사에 따라 업그레이드 또는 롤백을 수동으로 완료합니다.
옵션 A - 커밋(성공):
-
작업: 다음을 사용하여 파란색 노드 풀 삭제
az aks nodepool delete - 결과: 녹색 노드 풀이 기본이 됩니다.
옵션 B - 롤백 (문제 감지됨):
-
조치: 파란색 노드를 차단 해제하려면
kubectl uncordon을(를) 사용하고, 초록색 노드를 드레인하려면kubectl drain을(를) 사용하고, 초록색 NodePool을 삭제하려면 다음을 사용하세요.az aks nodepool delete - 결과: 워크로드가 파란색 노드로 돌아갑니다.
업그레이드 계획에 대한 프로덕션 고려 사항
-
서지(
maxSurge) 구성: 업그레이드 중에 생성된 서지 노드 수를 제어합니다. 값이 높을수록 업그레이드 속도가 빨라지지만 더 많은 리소스를 사용합니다. - Pod 중단 예산(PDB): 업그레이드 프로세스 중에 애플리케이션 가용성을 보장하도록 PDB를 구성합니다.
- 노드 풀 업그레이드: 각 노드 풀은 독립적으로 업그레이드됩니다. 그에 따라 업그레이드 전략을 계획합니다.
- 용량 및 할당량: 업그레이드 기간 전에 임시 및 안정적인 상태 용량 요구 사항의 유효성을 검사합니다.
- 모니터링 및 경고: 업그레이드가 시작되기 전에 모니터링 및 경고를 설정합니다.
AKS Automatic에서는 프로덕션 준비 상태를 위해 몇 가지 플랫폼 수준 업그레이드 선택 항목이 미리 구성됩니다. AKS Standard에서 팀은 일반적으로 이러한 선택을 명시적으로 수행합니다.