AKS(Azure Kubernetes Service) 클러스터에 대한 업그레이드 옵션 및 권장 사항

적용 대상: ✔️ AKS 자동 ✔️ AKS 표준

대부분의 프로덕션 워크로드에서 AKS Automatic은 권장되는 기본 클러스터 환경입니다. 관리되는 업그레이드 동작, 기본 제공 보호 기능, 운영 오버헤드 감소 등 클러스터 및 노드 수명 주기 작업에 대한 프로덕션 준비 기본값을 제공합니다.

AKS 표준은 업그레이드 메커니즘, 네트워킹 선택 또는 노드 풀 동작에 대한 보다 심층적인 수동 제어가 필요한 시나리오에서 계속 사용할 수 있습니다.

이 문서에서는 AKS 자동 및 AKS 표준 모두에 대한 업그레이드 옵션, 일반적인 시나리오 및 권장 사항을 다루어 AKS 업그레이드를 위한 기술 기반을 제공합니다.

이 문서에서 다루는 내용

이 기술 참조는 다음을 다룹니다.

• AKS 자동이 대부분의 워크로드에 권장되는 프로덕션 준비 기본값인 이유입니다.
• AKS 자동 및 AKS 표준 간에 업그레이드 동작이 어떻게 다른지.
• 수동 및 자동화된 업그레이드 경로 및 각 경로를 사용해야 하는 경우
• 특정 권장 사항이 있는 일반적인 업그레이드 시나리오입니다.
• 성능 및 최소한의 중단을 위한 최적화 기술입니다.
• 유효성 검사 프로세스 및 업그레이드 전 검사입니다.

관련 지침:

• AKS 자동 개요 및 기본값은 AKS(Azure Kubernetes Service) 자동 소개를 참조하세요.
• 프로덕션 지향 AKS 업그레이드 전략 세부 정보는 AKS 프로덕션 업그레이드 전략을 참조하세요.
• 상태 저장 워크로드 업그레이드 패턴은 상태 저장 워크로드 업그레이드 패턴을 참조하세요.
• 시나리오 주도 지침은 AKS 업그레이드 시나리오: 경로 선택을 참조하세요.
• AKS 업그레이드를 처음으로 사용하는 경우 업그레이드 시나리오 허브 에서 안내 지원을 받으세요.

빠른 탐색

운영 모델 업그레이드

AKS 자동 (권장 프로덕션용 기본값)

AKS 자동은 기본적으로 프로덕션 준비 작업을 위해 설계되었습니다. 업그레이드의 경우 AKS Automatic은 다음을 제공합니다.

• 관리되는 시스템 노드 풀.
• 플랫폼 관리 기본값을 사용하는 자동 클러스터 업그레이드 동작입니다.
• 보안 중심 주기를 사용하는 자동 노드 OS 이미지 업그레이드 동작입니다.
• 지원 중단된 Kubernetes API에 대한 기본 제공 검사 기능.
• 계획된 유지 관리 일정 지원.

수동 업그레이드 오케스트레이션을 최소화하고 프로덕션 클러스터를 지원되는 버전에 맞게 유지하려는 경우 AKS Automatic을 사용합니다.

AKS 표준(고급 제어 모델)

AKS 표준은 업그레이드 시퀀싱 및 튜닝을 직접 제어할 수 있게 해줍니다. 다음을 선택하고 관리합니다.

• 수동 또는 자동 업그레이드 구성.
• 채널 선택을 업그레이드합니다.
• 노드 풀 및 급증 동작
• 유지 관리 기간 및 워크로드 중단 예산에 대한 운영 절차.

환경에 AKS 자동 기본값을 초과하는 사용자 지정이 필요한 경우 AKS 표준을 사용합니다.

업그레이드 옵션

수동 업그레이드 수행

AKS 표준 또는 특수 운영 워크플로에 주로 적용됩니다.

수동 업그레이드를 사용하면 클러스터가 새 Kubernetes 버전으로 업그레이드되는 시기를 제어할 수 있습니다. 이러한 업그레이드는 테스트, 단계별 출시 및 대상 버전 채택에 유용합니다.

• AKS 클러스터 업그레이드
• Azure Kubernetes Fleet Manager를 통해 여러 AKS 클러스터 업그레이드
• 노드 이미지 업그레이드
• 노드 서지 업그레이드 사용자 지정
• 프로세스 노드 OS 업데이트

자동 업그레이드 구성

AKS Standard의 경우 자동 업그레이드는 정책 및 일정에 대한 제어를 유지하면서 지원되는 버전에서 클러스터를 유지하는 데 도움이 됩니다. AKS 자동에서 업그레이드 자동화 및 가드레일은 이미 기본 운영 모델의 일부입니다.

• AKS 클러스터 자동 업그레이드
• Azure Kubernetes Fleet Manager를 통해 여러 AKS 클러스터 자동 업그레이드
• 계획된 유지 관리를 사용하여 업그레이드 예약 및 제어
• API 호환성이 손상되는 변경에서 자동으로 AKS 클러스터 업그레이드 중지(미리 보기)
• AKS 클러스터 노드 운영 체제 이미지 자동 업그레이드
• GitHub 작업을 사용하여 AKS 노드에 자동으로 보안 업데이트 적용

여러 가용성 영역에 걸쳐 있는 노드 풀에 대한 특별 고려 사항

AKS는 노드 풀에서 최상의 영역 분산을 사용합니다. 업그레이드가 급증하는 동안 가상 머신 확장 집합의 서지 노드에 대한 영역은 미리 알 수 없으므로 일시적으로 불균형 영역 구성이 발생할 수 있습니다. AKS는 업그레이드 후 서지 노드를 삭제하고 원래 영역 균형을 복원합니다.

영역의 균형을 유지하려면 서지를 3의 배수 노드로 설정합니다. Azure 로컬 중복 스토리지 디스크를 사용하는 영구 볼륨 클레임은 영역에 바인딩되어 있으며 서지 노드가 다른 영역에 있는 경우 가동 중지 시간이 발생할 수 있습니다. PDB(Pod 중단 예산)를 사용하여 드레이닝 중에 고가용성을 유지합니다.

업그레이드를 최적화하여 성능 향상 및 중단 최소화

계획된 유지 관리 기간, 최대 서지, PDB, 노드 드레이닝 시간 제한 및 노드 흡수 시간을 결합하여 중단이 적은 성공적인 업그레이드 가능성을 높입니다.

AKS 자동화

AKS 자동에서는 플랫폼 수준 업그레이드 동작이 미리 구성됩니다. 튜닝은 워크로드 복원력과 용량 대비에 집중하세요.

• Pod 중단 예산 및 복제본 수의 유효성을 검사합니다.
• 예상 증가에 대한 할당량 및 서브넷 용량을 확인합니다.
• 트래픽이 적은 기간에 맞춰 계획된 유지 관리 일정을 설정합니다.
• 업그레이드 이벤트 및 중요한 워크로드 준비 상태를 모니터링합니다.

AKS 표준

AKS 표준에서 업그레이드 컨트롤을 직접 조정합니다.

• 계획된 유지 관리 기간: 트래픽이 적은 기간 동안 자동 업그레이드를 예약합니다. 최소 4시간을 사용합니다.
• 최대 서지: 값이 높을수록 업그레이드 속도가 빨라지지만 워크로드가 중단될 수 있습니다. 프로덕션에 33% 사용합니다.
• 최대 사용 불가: 용량이 제한된 경우 사용합니다.
• Pod 중단 예산: 업그레이드 중에 Pod 중단을 제한하도록 설정합니다. 서비스의 유효성을 검사합니다.
• 노드 드레이닝 시간 제한: Pod 제거 대기 기간을 구성합니다. 기본값은 30분입니다.
• 노드 흡수 시간: 가동 중지 시간을 최소화하기 위해 시차를 두고 업그레이드 기본값은 0분입니다.

업그레이드 프로세스에 사용되는 유효성 검사

AKS는 업그레이드 전 유효성 검사를 수행하여 클러스터 상태를 확인합니다.

• API 호환성이 손상되는 변경 내용: 사용되지 않는 API를 검색합니다.
• Kubernetes 업그레이드 버전: 유효한 업그레이드 경로를 확인합니다.
• PDB 구성: 잘못 구성된 PDB(예: maxUnavailable=0)를 확인합니다.
• 할당량: 서지 노드에 대한 충분한 할당량을 확인합니다.
• 서브넷: 충분한 IP 주소를 확인합니다.
• 인증서/서비스 주체: 만료된 자격 증명을 검색합니다.
• 관리되는 리소스 잠금 검사: 관리되는 클러스터 리소스 그룹에 적용된 리소스 잠금을 확인합니다.

이러한 검사는 AKS에 적용됩니다. AKS 자동에서는 관리되는 업그레이드 경로에 통합됩니다. AKS Standard에서 운영 워크플로의 일부입니다.

일반적인 업그레이드 시나리오 및 권장 사항

시나리오 1: 용량 제약 조건

클러스터가 제품 계층 또는 지역별 용량으로 제한되는 경우 서지 노드를 프로비전할 수 없을 때 업그레이드가 실패할 수 있습니다. 이러한 상황은 특수 제품 계층(예: GPU 노드) 또는 리소스가 제한된 지역에서 일반적입니다. 사용 가능한 용량에 비해 SKUNotAvailable이(가) 너무 높게 설정된 경우, AllocationFailed, OverconstrainedAllocationRequest, 또는 maxSurge와 같은 오류가 발생할 수 있습니다.

AKS 자동 지침

• 계획된 유지 관리 기간을 그대로 유지합니다.
• 예상 업그레이드 기간 전에 구독 할당량 및 서브넷 헤드룸의 유효성을 검사합니다.
• 워크로드 크기 조정 및 중단 예산을 유지 관리 기간에 맞게 유지합니다.

AKS 표준 지침

• 새 노드를 급증시키는 대신 기존 노드를 사용하여 업그레이드하려면 maxUnavailable을(를) 사용합니다. 자세한 내용은 업그레이드하는 동안 사용할 수 없는 노드 사용자 지정을 참조하세요.
• maxSurge을 낮춰 추가 용량 필요성을 줄입니다. 자세한 내용은 노드 서지 업그레이드 사용자 지정을 참조하세요.
• 보안 전용 업데이트의 경우 서지 노드가 필요하지 않은 보안 패치 이미지 다시 설치를 사용합니다. 자세한 내용은 Azure Kubernetes Service에서 Linux 노드에 보안 및 커널 업데이트 적용을 참조하세요.

시나리오 2: 노드 드레이닝 오류 및 PDB

업그레이드를 수행하려면 노드 드레이닝(Pod 제거)이 필요합니다. Pod 종료 속도가 느리거나 엄격한 PDB(Pod 중단 예산)로 인해 Pod 제거가 차단되면 드레이닝이 실패할 수 있습니다.

오류 예제는 다음과 같습니다.

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

AKS 자동 지침

• PDB 및 복제본 전략을 기본 안정성 제어로 처리합니다.
• 프로덕션 배포 전에 스테이징 환경에서 장애 허용 예산을 검증하세요.
• 중요한 워크로드가 롤링 제거에 성공하도록 구성된 상태를 유지합니다.

AKS 표준 지침

옵션 1: 강제 업그레이드, PDB 제약 조건 무시

PDB가 중요한 업그레이드를 방지하고 해결할 수 없는 경우에만 강제 업그레이드를 사용합니다. 이 작업은 PDB 보호를 재정의하며 업그레이드 중에 전체 서비스를 사용할 수 없게 될 수 있습니다.

요구 사항: Azure CLI 2.79.0 이상 또는 AKS API 버전 2025-09-01 이상

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

옵션 2: PDB를 준수하면서 드레이닝할 수 없는 노드 처리

업그레이드 실패를 방지하면서 PDB의 무결성을 유지하려면 이 보수적인 접근 방식을 사용하십시오.

비울 수 없는 노드의 동작 구성:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

동작 옵션:

• 일정(기본값): 차단된 노드를 삭제하고 교체를 급증합니다.
• Cordon (권장): 노드를 코든 처리하고 kubernetes.azure.com/upgrade-status=Quarantined로 레이블을 지정합니다.

차단된 최대 노드(미리 보기):

• 드레이닝에 실패해도 허용되는 노드 수를 지정합니다.
• undrainable-node-behavior를 설정해야 합니다.
• maxSurge 값을 지정하지 않으면 기본값은 (일반적으로 10%)입니다.

최대 차단 노드에 대한 필수 구성 요소

최대 차단 노드 기능을 사용하려면 Azure CLI aks-preview 확장 버전 18.0.0b9 이상이 필요합니다.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

최대 차단 노드를 사용하는 예제 구성

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

옵션 3: 자동 PDB 관리(미리 보기)

자동 PDB 관리 확장을 사용하여 PDB 보호를 무시하거나 격리된 노드의 수동 정리를 요구하지 않고 PDB 차단 드레인을 사전에 해결합니다. 자동 PDB 관리는 PDB가 코드된 노드에서 제거를 차단하고 배포의 복제본을 일시적으로 확장하여 중단 예산이 충족되는 경우를 감지합니다. 드레이닝이 완료되면 복제본 수를 원래 개수로 다시 조정합니다.

또한 자동 PDB 관리는 하나도 없는 배포용 PDB를 자동으로 만들어 업그레이드 드레이닝 중에 워크로드가 보호되도록 할 수 있습니다. 설치 및 구성 세부 정보는 AKS 업그레이드 중에 자동으로 Pod 중단 예산 관리를 참조하세요.

드레이닝 오류를 방지하기 위한 권장 사항

• 하나 이상의 Pod 제거를 허용하도록 PDB에서 설정 maxUnavailable
• 중단 예산 요구 사항을 충족하도록 Pod 복제본 늘리기
• 워크로드에 더 많은 시간이 필요한 경우 드레이닝 시간 제한을 연장합니다. (기본값은 30분입니다.)
• 자동 PDB 관리를 사용하여 드레이닝 작업 중에 PDB 만들기 및 복제본 크기 조정을 자동화합니다.
• 스테이징에서 PDB를 테스트하고, 업그레이드 이벤트를 모니터링하고, 중요한 워크로드에 청록색 배포를 사용합니다. 자세한 내용은 AKS 클러스터의 파란색-녹색 배포를 참조하세요.

드레이닝이 불가능한 노드 확인

• 차단된 노드는 Pod에 대해 예약되지 않으며 레이블 "kubernetes.azure.com/upgrade-status: Quarantined"로 표시됩니다.

• 업그레이드 시 드레이닝 노드 오류가 발생하는 경우 차단된 노드에서 레이블을 확인합니다.

  kubectl get nodes --show-labels=true
  

드레인할 수 없는 노드 해결

1. 책임 있는 PDB를 제거합니다.

   kubectl delete pdb <pdb-name>
   

2. 레이블을 제거합니다.kubernetes.azure.com/upgrade-status: Quarantined

   kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-
   

3. 필요에 따라 차단된 노드를 삭제합니다.

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. 이 단계를 완료한 후에는 설명된 대로 선택적 필드 없이 업데이트 작업을 수행하여 클러스터 상태를 조정할 수 있습니다 az aks. 또는 업그레이드된 노드 수와 동일한 수의 노드로 노드 풀의 크기를 조정할 수 있습니다. 이 작업을 수행하면 노드 풀이 의도한 원래 크기가 됩니다. AKS는 차단된 노드를 제거하는 것을 우선시합니다. 이 명령은 또한 클러스터 프로비전 상태를 Succeeded로 복원합니다. 다음 예제에서 2은(는) 업그레이드된 노드의 총 수입니다.

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

시나리오 3: 느린 업그레이드

보수적인 설정 또는 노드 수준 문제는 업그레이드를 지연할 수 있으며, 이는 패치 및 개선 사항으로 최신 상태를 유지하는 기능에 영향을 줍니다.

느린 업그레이드의 일반적인 원인은 다음과 같습니다.

• 낮은 maxSurge 또는 maxUnavailable 값(병렬 처리 제한됨)
• 높은 흡수 시간(노드 업그레이드 간의 긴 대기).
• 드레이닝 실패(노드 드레이닝 실패 참조).

AKS 자동 지침

• 유지 관리 일정을 최신 상태로 유지합니다.
• 업그레이드 이벤트 상태 및 워크로드 준비 상태를 모니터링합니다.
• 지연 시간이 길어지는 것을 방지하기 위해 차단 PDB 또는 용량 문제를 신속하게 해결합니다.

AKS 표준 지침

• 프로덕션에 maxSurge=33%, maxUnavailable=1을(를) 사용합니다.
• 개발/테스트에 maxSurge=50%, maxUnavailable=2을(를) 사용합니다.
• OS 보안 패치를 사용하여 대상 패치를 빠르게 지정합니다(전체 노드 이미지 다시 설치 방지).
• --undrainable-node-behavior을(를) 사용하여 업그레이드 차단을 방지합니다.

시나리오 4: IP 고갈

서지 노드에는 더 많은 IP가 필요합니다. 서브넷이 용량에 근접하면 노드 프로비전이 실패할 수 있습니다(예: Error: SubnetIsFull). 이 시나리오는 Azure Container Networking Interface, 높음 maxPods 또는 큰 노드 수에서 일반적입니다.

AKS 자동 지침

• 프로덕션 확장 전에 서브넷 및 용량 계획의 유효성을 검사합니다.
• 일상적인 작업의 일부로 네트워크 사용률을 모니터링합니다.

AKS 표준 지침

• 서브넷에 모든 노드, 서지 노드 및 Pod에 대한 충분한 IP가 있는지 확인합니다. 수식은 Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)입니다.

• 사용되지 않는 IP를 회수하거나 서브넷을 확장합니다(예: /24에서 /22까지).

• 서브넷 확장이 불가능한 경우 maxSurge을 낮추세요.

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• Azure Monitor 또는 사용자 지정 경고를 사용하여 IP 사용량을 모니터링합니다.

• 노드당 사용량을 줄이고 maxPods , 유실된 로드 밸런서 IP를 정리하며, 대규모 클러스터에 대비한 서브넷 크기 조정을 계획합니다.

자주 묻는 질문

프로덕션 업그레이드에 AKS 자동 또는 AKS 표준을 사용해야 하나요?

대부분의 프로덕션 워크로드의 경우 AKS Automatic을 사용합니다. 관리형 업그레이드 동작과 기본 제공 보호 장치를 갖춘, 프로덕션 환경에 바로 사용할 수 있는 기본 옵션으로 설계되었습니다.

업그레이드 시퀀싱, 인프라 선택 또는 노드 풀 작업에 대한 고급 수동 제어가 필요한 경우 AKS 표준을 사용합니다.

유효성 검사에 오픈 소스 도구를 사용할 수 있나요?

예. 많은 오픈 소스 도구가 AKS 업그레이드 프로세스와 잘 통합됩니다.

• kube-no-trouble(kubent): 업그레이드하기 전에 사용되지 않는 API를 검색합니다.
• Trivy: 컨테이너 이미지 및 Kubernetes 구성에 대한 보안 검사입니다.
• Sonobuoy: Kubernetes 적합성 테스트 및 클러스터 유효성 검사입니다.
• kube-bench: 보안 벤치마크는 Center for Internet Security 표준에 대해 검사합니다.
• Polaris: Kubernetes 모범 사례의 유효성 검사입니다.
• kubectl-neat: 유효성 검사를 위해 Kubernetes 매니페스트를 정리합니다.

업그레이드하기 전에 API 호환성의 유효성을 검사하려면 어떻게 해야 하나요?

kubent와 같은 도구를 사용하여 사용 중단 검사를 실행합니다.

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

AKS 업그레이드가 다른 Kubernetes 플랫폼과 다른 이유는 무엇인가요?

AKS는 다음과 같은 몇 가지 고유한 이점을 제공합니다.

• AKS Automatic에서 업그레이드 부담을 줄이기 위한 관리형 운영 경로.
• Azure Traffic Manager, Azure Load Balancer 및 네트워킹과의 네이티브 Azure 통합입니다.
• 조정된 다중 클러스터 업그레이드를 위한 Azure Kubernetes Fleet Manager입니다.
• 수동 노드 관리 없이 자동 노드 이미지 패치입니다.
• 할당량, 네트워킹 및 자격 증명에 대한 기본 제공 유효성 검사입니다.
• 업그레이드 관련 문제에 대한 Azure 지원입니다.

업그레이드 경로 선택

이 문서에서는 기술 기반을 제공했습니다. 이제 시나리오 기반 경로를 선택합니다.

실행할 준비가 되셨나요?

아직 결정 중인가요?

다음을 고려하는 안내된 의사 결정 트리에 업그레이드 시나리오 허브를 사용합니다.

• 가동 중지 시간 허용 오차
• 환경 복잡성
• 위험 프로필
• 타임라인 제약 조건

최종 권장 사항

• 대부분의 프로덕션 워크로드에 AKS 자동 을 사용합니다.
• 업그레이드를 시작하기 전에 AKS 패치 및 업그레이드 지침을 검토하여 모범 사례 및 계획 팁을 확인하세요.
• 항상 API 호환성이 손상되는 변경 내용을 확인하고 대상 Kubernetes 버전과의 워크로드 호환성을 확인합니다.
• 스테이징 환경에서 maxSurge, maxUnavailable, PDB와 같은 업그레이드 설정을 테스트하여 프로덕션 위험을 최소화합니다.
• 프로세스 전체에서 업그레이드 이벤트 및 클러스터 상태를 모니터링합니다.