Azure Kubernetes Service 패치 및 업그레이드 지침

아티클
06/13/2024

AKS(Azure Kubernetes Service) 2일차 작업 가이드의 이 섹션에서는 AKS 작업자 노드 및 Kubernetes 버전에 대한 패치 및 업그레이드 전략을 설명합니다. 클러스터 운영자는 클러스터를 최신 상태로 유지하고 시간이 지남에 따라 Kubernetes API 변경 및 사용 중단을 모니터링하기 위한 계획이 있어야 합니다.

업데이트의 배경 및 유형

AKS에는 세 가지 유형의 업데이트가 있으며, 각 업데이트는 다음을 기반으로 빌드됩니다.

업데이트 형식	업그레이드 빈도	계획된 유지 관리 지원	지원되는 작업 방법	대상	설명서 링크
노드 OS 보안 패치	매일 밤	예	자동(매주), 수동/비관리(야간)	Node	노드 이미지 자동 업그레이드
노드 이미지 버전 업그레이드	Linux: 매주 Windows: 매월	예	자동, 수동	노드 풀	AKS 노드 이미지 업그레이드
Kubernetes 버전(클러스터) 업그레이드	분기별	예	자동, 수동	클러스터 및 노드 풀	AKS 클러스터 업그레이드

업데이트 유형

노드 OS 보안 패치(Linux만 해당). Linux 노드의 경우 Canonical Ubuntu 및 Azure Linux 모두 하루에 한 번 운영 체제 보안 패치를 사용할 수 있습니다. Microsoft는 노드 이미지에 대한 주간 업데이트에서 이러한 패치를 테스트하고 번들로 묶습니다.
노드 이미지에 대한 주간 업데이트입니다. AKS는 노드 이미지에 대한 주간 업데이트를 제공합니다. 이러한 업데이트에는 최신 OS 및 AKS 보안 패치, 버그 수정 및 개선 사항이 포함됩니다. 노드 업데이트는 Kubernetes 버전을 변경하지 않습니다. 버전은 Linux의 경우 날짜(예: 202311.07.0)로, Windows의 경우 Windows Server OS 빌드 및 날짜(예: 20348.2113.231115)로 형식이 지정됩니다. 자세한 내용은 AKS 릴리스 상태를 참조하세요.
분기별 Kubernetes 릴리스. AKS는 Kubernetes 릴리스에 대해 분기별 업데이트를 제공합니다. 이러한 업데이트를 통해 AKS 사용자는 최신 Kubernetes 기능 및 향상된 기능을 활용할 수 있습니다. 여기에는 보안 패치 및 노드 이미지 업데이트가 포함됩니다. 자세한 내용은 AKS에서 지원되는 Kubernetes 버전을 참조하세요.

업그레이드 전 고려 사항

전체 클러스터 영향

현재 위치 업그레이드(노드 및 클러스터 모두)는 진행 중인 동안 Kubernetes 환경의 성능에 영향을 미칩니다. Pod 중단 예산의 적절한 구성, 노드 서지 구성 및 적절한 계획을 통해 이러한 영향을 최소화할 수 있습니다.
현재 위치에서 업그레이드하는 대신 블루/그린 업데이트 전략을 사용하면 클러스터 성능에 영향을 미치지 않지만 비용과 복잡성이 증가합니다.
업그레이드 및 패치 전략에 관계없이 클러스터에 대한 강력한 테스트 및 유효성 검사 프로세스가 있어야 합니다. 먼저 하위 환경을 패치 및 업그레이드하고 유지 관리 후 유효성 검사를 수행하여 클러스터, 노드, 배포 및 애플리케이션 상태를 확인합니다.

AKS 워크로드 모범 사례

유지 관리 중에 AKS 클러스터의 원활한 작업을 보장하려면 다음 모범 사례를 따릅니다.

PDB(Pod 중단 예산)를 정의합니다. 배포에 대한 Pod 중단 예산을 설정하는 것이 중요합니다. PDB는 사용 가능한 최소 애플리케이션 복제본 수를 적용하여 중단 이벤트 중에도 지속적인 기능을 보장합니다. PDB는 유지 관리 또는 노드 오류 중에 클러스터의 안정성을 유지하는 데 도움이 됩니다.

Warning

잘못 구성된 PDB는 Kubernetes API가 롤링 노드 이미지 업그레이드에서 발생하는 필요한 차단 및 드레이닝을 방지하므로 업그레이드 프로세스를 차단할 수 있습니다. 또한 너무 많은 Pod가 동시에 이동하면 애플리케이션이 중단될 수 있습니다. PDB 구성은 이러한 위험을 완화합니다.
사용 가능한 컴퓨팅 및 네트워크 제한을 확인합니다. Azure Portal의 할당량 페이지를 통해 또는 az quota 명령을 사용하여 Azure 구독에서 사용 가능한 컴퓨팅 및 네트워크 제한을 확인합니다. 컴퓨팅 및 네트워크 리소스, 특히 노드에 대한 VM vCPU, 가상 머신 및 가상 머신 확장 집합 수를 확인합니다. 한도에 가까워지면 업그레이드하기 전에 할당량 증가를 요청합니다.
노드 서브넷에서 사용 가능한 IP 공간을 확인합니다. 업데이트하는 동안 클러스터에 추가 서지 노드가 생성되고 Pod가 이러한 노드로 이동됩니다. 노드 서브넷의 IP 주소 공간을 모니터링하여 이러한 변경 내용이 발생할 수 있는 충분한 주소 공간이 있는지 확인하는 것이 중요합니다. Kubernetes 네트워크 구성마다 IP 요구 사항이 다릅니다. 시작점으로 다음 고려 사항을 검토합니다.
- 업그레이드하는 동안 서지 값에 따라 노드 IP 수가 증가합니다. (최소 서지 값은 1입니다.)
- Azure CNI를 기반으로 하는 클러스터는 개별 Pod에 IP 주소를 할당하므로, Pod 이동을 위한 충분한 IP 공간이 있어야 합니다.
- 클러스터는 업그레이드 중에 계속 작동합니다. 노드 크기 조정을 허용할 수 있는 충분한 IP 공간이 남아 있는지 확인합니다(활성화된 경우).
여러 환경을 설정합니다. 프로덕션에 롤아웃하기 전에 변경 사항을 테스트하고 유효성을 검사할 수 있도록 개발, 준비, 프로덕션과 같은 별도의 환경을 설정하는 것이 좋습니다.
서지 업그레이드 값을 조정합니다. 기본적으로 AKS의 서지 값은 1입니다. 즉, 업그레이드 프로세스의 일부로 한 번에 하나의 추가 노드가 만들어집니다. 이 값을 늘려 AKS 업그레이드 속도를 높일 수 있습니다. 33%의 서지는 중단에 민감한 워크로드에 권장되는 최댓값입니다. 자세한 내용은 노드 서지 업그레이드 사용자 지정을 참조하세요.
노드 드레인 시간 제한을 조정합니다. 노드 드레인 시간 제한은 업데이트 중인 노드에서 Pod 재예약을 시도하는 동안 클러스터가 대기할 최대 시간을 지정합니다. 이 기본값은 30분입니다. Pod 재예약에 어려움을 겪는 워크로드의 경우 이 기본값을 조정하면 도움이 될 수 있습니다.
유지 관리 기간을 계획하고 예약합니다. 업그레이드 프로세스는 Kubernetes 클러스터의 전반적인 성능에 영향을 줄 수 있습니다. 피크 사용 기간을 피해 현재 위치 업그레이드 프로세스를 예약하고, 클러스터 성능을 모니터링하여 특히 업데이트 프로세스 중에 적절한 크기 조정을 보장합니다.
클러스터의 다른 종속성을 확인합니다. Kubernetes 운영자는 KEDA 스케일러, Dapr 및 서비스 메시와 같은 작업의 일부로 Kubernetes 클러스터에 다른 도구를 배포하는 경우가 많습니다. 업그레이드 프로세스를 계획할 때 사용 중인 구성 요소에 대한 릴리스 정보를 확인하여 대상 버전과의 호환성을 확인합니다.

노드 이미지에 대한 주간 업데이트 관리

Microsoft는 약 일주일에 한 번씩 AKS 노드에 대한 새 노드 이미지를 만듭니다. 노드 이미지에는 최신 OS 보안 패치, OS 커널 업데이트, Kubernetes 보안 업데이트, kubelet과 같은 업데이트된 버전의 이진 파일 및 릴리스 정보에 나열된 구성 요소 버전 업데이트가 포함되어 있습니다.

노드 이미지가 업데이트되면 대상 노드 풀의 노드에서 차단 및 드레이닝 작업이 트리거됩니다.

업데이트된 이미지가 있는 노드가 노드 풀에 추가됩니다. 동시에 추가되는 노드 수는 서지 값에 의해 제어됩니다.
서지 값에 따라 기존 노드의 배치가 차단되고 드레이닝됩니다. 차단은 노드가 Pod를 예약하지 않도록 합니다. 드레이닝은 해당 Pod를 제거하고 다른 노드로 예약합니다.
이러한 노드가 완전히 드레이닝되면 노드 풀에서 제거됩니다. 서지에 의해 추가된 업데이트된 노드가 해당 노드를 대체합니다.
이 프로세스는 노드 풀에서 업데이트해야 하는 노드의 나머지 배치마다 반복됩니다.

클러스터 업그레이드 중에도 유사한 프로세스가 발생합니다.

자동 노드 이미지 업그레이드

일반적으로 대부분의 클러스터는 NodeImage 업데이트 채널을 사용해야 합니다. 이 채널은 매주 업데이트된 노드 이미지 VHD를 제공하며 클러스터의 유지 관리 기간에 따라 업데이트됩니다.

사용 가능한 채널에는 다음이 포함됩니다.

None. 자동으로 적용되는 업데이트가 없습니다.
Unmanaged. Ubuntu 및 Azure Linux 업데이트는 야간에 OS에 의해 적용됩니다. 다시 부팅은 별도로 관리해야 합니다. AKS는 이를 테스트하거나 이러한 주기를 제어할 수 없습니다.
SecurityPatch. AKS 테스트를 거치고, 완전히 관리되며, 안전한 배포 방법에 따라 적용되는 OS 보안 패치입니다. 여기에는 보안 업데이트만 포함되며 OS 버그 수정은 포함되지 않습니다.
NodeImage. AKS는 주별 보안 수정 사항과 버그 수정 사항이 포함된 새로 패치된 VHD로 노드를 업데이트합니다. 이는 안전한 배포 방법을 사용하여 완전히 테스트되고 배포됩니다. 현재 배포된 노드 이미지에 대한 실시간 정보는 AKS 노드 이미지 업데이트를 참조하세요.

유지 관리 기간이 설정되지 않은 기본 주기를 이해하려면 소유권 및 주기 업데이트를 참조하세요.

Unmanaged 업데이트 채널을 선택하는 경우 kured와 같은 도구를 사용하여 다시 부팅 프로세스를 관리해야 합니다. Unmanaged는 AKS에서 제공하는 안전한 배포 방법과 함께 제공되지 않으며 유지 관리 기간에는 작동하지 않습니다. SecurityPatch 업데이트 채널을 선택하는 경우 업데이트를 일주일에 한 번 정도로 자주 적용할 수 있습니다. 이 패치 수준을 사용하려면 리소스 그룹에 VHD를 저장해야 하며, 이로 인해 명목 요금이 발생합니다. 워크로드에 가장 적합한 주기에 맞춰 적절한 aksManagedNodeOSUpgradeSchedule을 설정하여 SecurityPatch가 적용되는 시기를 제어합니다. 자세한 내용은 유지 관리 기간 만들기를 참조하세요. 일반적으로 새 노드 이미지(VHD)와 함께 제공되는 버그 수정도 필요한 경우 SecurityPatch 대신 NodeImage 채널을 선택해야 합니다.

NodeImage 업데이트 채널을 사용하고 클러스터가 피크 사용 기간을 피한 시간으로 aksManagedNodeOSUpgradeSchedule 유지 관리 기간을 구성하는 것이 가장 좋습니다. 클러스터 유지 관리 기간을 구성하는 데 사용할 수 있는 특성은 유지 관리 기간 만들기를 참조하세요. 주요 특성은 다음과 같습니다.

name. 노드 OS 업데이트에 aksManagedNodeOSUpgradeSchedule을 사용합니다.
utcOffset. 표준 시간대를 구성합니다.
startTime. 유지 관리 기간의 시작 시간을 설정합니다.
dayofWeek. 기간의 요일을 설정합니다. 예들 들어 Saturday입니다.
schedule. 기간의 빈도를 설정합니다. NodeImage 업데이트의 경우 weekly를 권장합니다.
durationHours. 이 특성은 최소 4시간으로 설정합니다.

이 예에서는 주간 유지 관리 기간을 토요일 동부 표준시 오후 8시로 설정합니다.

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

더 많은 예제를 보려면 Azure CLI로 유지 관리 기간 구성 추가를 참조하세요.

이 구성은 클러스터의 코드 제공 인프라 배포의 일부로 배포하는 것이 가장 좋습니다.

Azure CLI를 사용하여 구성된 유지 관리 기간을 확인할 수 있습니다.

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

CLI를 사용하여 특정 유지 관리 기간의 세부 정보를 확인할 수도 있습니다.

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

클러스터 유지 관리 기간이 구성되지 않으면 노드 이미지 업데이트가 격주로 진행됩니다. AKS 유지 관리는 가능한 한 구성된 기간 내에 발생하지만 유지 관리 시간이 보장되는 것은 아닙니다.

Important

노드 수가 많지만 노드 서지로 구성되지 않은 노드 풀이 있는 경우, 자동 업그레이드 이벤트가 트리거되지 않을 수 있습니다. 노드 풀의 노드 이미지는 예상 총 업그레이드 시간이 24시간 이내인 동안에만 업그레이드됩니다.

이 경우 다음 중 하나를 고려할 수 있습니다.

vCPU 할당량이 거의 꽉 찼고 vCPU 할당량을 늘릴 수 없는 경우 노드를 다른 노드 풀로 분할
vCPU 할당량이 충분한 경우 예상 업그레이드 시간을 줄이기 위해 노드 서지 구성

Azure 활동 로그를 통해 또는 클러스터의 리소스 로그를 검토하여 업그레이드 이벤트의 상태를 확인할 수 있습니다.

AKS 업그레이드 이벤트를 포함하는 Azure Event Grid를 사용하여 AKS(Azure Kubernetes Service) 이벤트를 구독할 수 있습니다. 이러한 이벤트는 새 버전의 Kubernetes를 사용할 수 있을 때 알려주고 업그레이드 프로세스 중에 노드 상태 변경을 추적하는 데 도움이 됩니다.

GitHub Actions를 사용하여 주간 업데이트 프로세스를 관리할 수도 있습니다. 이 방법을 사용하면 업데이트 프로세스를 보다 세부적으로 제어할 수 있습니다.

수동 노드 업데이트 프로세스

kubectl describe nodes 명령을 사용하여 클러스터에 있는 노드의 OS 커널 버전 및 OS 이미지 버전을 확인할 수 있습니다.

kubectl describe nodes <NodeName>

예제 출력(잘림):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Azure CLI az aks nodepool list 명령을 사용하여 클러스터에 있는 노드의 노드 이미지 버전을 확인합니다.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

예제 출력:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

az aks nodepool get-upgrades를 사용하여 특정 노드 풀에 사용할 수 있는 최신 노드 이미지 버전을 확인합니다.

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

예제 출력:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

클러스터 업그레이드

Kubernetes 커뮤니티는 약 3개월마다 Kubernetes의 부 버전을 릴리스합니다. 새 AKS 버전 및 릴리스에 대한 정보를 계속 제공하기 위해 AKS 릴리스 정보 페이지가 정기적으로 업데이트됩니다. 변경 내용 및 개선 사항에 대한 실시간 업데이트를 제공하는 GitHub AKS RSS 피드를 구독할 수도 있습니다.

AKS는 N - 2 지원 정책을 따릅니다. 즉, 최신 릴리스(N) 및 두 가지 이전 부 버전에 대한 완전한 지원이 제공됩니다. 세 번째 이전 부 버전에 대해서는 제한된 플랫폼 지원이 제공됩니다. 자세한 내용은 AKS 지원 정책을 참조하세요.

AKS 클러스터가 계속 지원되도록 하려면 지속적인 클러스터 업그레이드 프로세스를 설정해야 합니다. 이 프로세스에는 하위 환경에서 새 버전을 테스트하고 새 버전이 기본값이 되기 전에 프로덕션으로 업그레이드하는 계획이 포함됩니다. 이 방법은 업그레이드 프로세스에서 예측 가능성을 유지하고 애플리케이션 중단을 최소화할 수 있습니다. 자세한 내용은 AKS 클러스터 업그레이드를 참조하세요.

클러스터에 더 긴 업그레이드 주기가 필요한 경우 LTS(장기 지원) 옵션을 지원하는 AKS 버전을 사용합니다. LTS 옵션을 사용하도록 설정하면 Microsoft는 2년 동안 Kubernetes 버전에 대한 추가 지원을 제공하므로 업그레이드 주기를 더욱 장기적으로 제어할 수 있습니다. 자세한 내용은 AKS에서 지원되는 Kubernetes 버전을 참조하세요.

클러스터 업그레이드는 노드 업그레이드를 포함하며 유사한 차단 및 드레이닝 프로세스를 사용합니다.

업그레이드하기 전에

프로덕션 중단 위험을 최소화하려면 항상 낮은 환경에서 업그레이드하고 테스트하는 것이 가장 좋습니다. 클러스터 업그레이드에는 Kubernetes 배포에 영향을 줄 수 있는 API 변경 사항이 포함되므로 추가 테스트가 필요합니다. 다음 리소스는 업그레이드 프로세스에 도움이 될 수 있습니다.

사용되지 않는 API에 대한 AKS 통합 문서입니다. Azure Portal의 클러스터 개요 페이지에서 문제 진단 및 해결을 선택하고, 만들기, 업그레이드, 삭제 및 크기 조정 범주로 이동한 다음, Kubernetes API 사용 중단을 선택할 수 있습니다. 이렇게 하면 클러스터에서 사용 중인 더 이상 사용되지 않는 API 버전을 확인하는 통합 문서가 실행됩니다. 자세한 내용은 사용되지 않는 API 사용 제거를 참조하세요.
AKS 릴리스 정보 페이지입니다. 이 페이지에서는 새 AKS 버전 및 릴리스에 대한 포괄적인 정보를 제공합니다. 이 정보를 검토하여 최신 업데이트 및 변경 사항을 계속 파악할 수 있습니다.
Kubernetes 릴리스 정보 페이지입니다. 이 페이지에서는 최신 Kubernetes 버전에 대한 자세한 인사이트를 제공합니다. AKS 클러스터에 영향을 줄 수 있는 중요한 정보를 강조 표시한 긴급 업그레이드 노트에 특히 주의하도록 합니다.
AKS 구성 요소의 버전별 호환성이 손상되는 변경 내용입니다. 이 표는 버전별로 AKS 구성 요소의 호환성이 손상되는 변경 사항에 대한 포괄적인 개요를 제공합니다. 이 가이드를 참조하여 업그레이드 프로세스 전에 잠재적인 호환성 문제를 사전에 해결할 수 있습니다.

이러한 Microsoft 리소스 외에도 오픈 소스 도구를 사용하여 클러스터 업그레이드 프로세스를 최적화하는 것이 좋습니다. 이러한 도구 중 하나는 Fairwinds pluto이며, 배포 및 Helm 차트에서 사용되지 않는 Kubernetes API를 검색할 수 있습니다. 이러한 도구를 통해 애플리케이션이 최신 Kubernetes 버전과 호환성을 유지하도록 할 수 있습니다.

업그레이드 프로세스

클러스터에 언제 업그레이드가 필요한지 확인하려면 az aks get-upgrades를 사용하여 AKS 클러스터에 사용 가능한 업그레이드 버전 목록을 가져옵니다. 결과에서 클러스터의 대상 버전을 결정합니다.

예를 들어 다음과 같습니다.

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

예제 출력:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

노드 풀에 있는 노드의 Kubernetes 버전을 확인하여 업그레이드해야 하는 풀을 확인합니다.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

예제 출력:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

수동 업그레이드

중단을 최소화하고 AKS 클러스터에 대한 원활한 업그레이드를 보장하려면 다음 업그레이드 방법을 따릅니다.

AKS 컨트롤 플레인을 업그레이드합니다. 먼저 AKS 컨트롤 플레인을 업그레이드합니다. 이 단계에는 클러스터 관리 및 오케스트레이션을 담당하는 컨트롤 플레인 구성 요소를 업그레이드하는 작업이 포함됩니다. 먼저 컨트롤 플레인을 업그레이드하면 개별 노드 풀을 업그레이드하기 전에 호환성 및 안정성을 보장할 수 있습니다.
시스템 노드 풀을 업그레이드합니다. 컨트롤 플레인을 업그레이드한 후 AKS 클러스터에서 시스템 노드 풀을 업그레이드합니다. 노드 풀은 애플리케이션 워크로드를 실행하는 가상 머신 인스턴스로 구성됩니다. 노드 풀을 별도로 업그레이드하면 애플리케이션을 지원하는 기본 인프라를 제어하고 체계적으로 업그레이드할 수 있습니다.
사용자 노드 풀을 업그레이드합니다. 시스템 노드 풀을 업그레이드한 후 AKS 클러스터의 모든 사용자 노드 풀을 업그레이드합니다.

이 접근 방식에 따라 업그레이드 프로세스 중에 중단을 최소화하고 애플리케이션의 가용성을 유지할 수 있습니다. 세부 단계는 다음과 같습니다.

--control-plane-only 플래그를 사용하여 az aks upgrade 명령을 실행하여 클러스터의 노드 풀이 아닌 클러스터 컨트롤 플레인만 업그레이드합니다.
```
az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>
```
az aks nodepool 업그레이드를 실행하여 노드 풀을 대상 버전으로 업그레이드합니다.
```
az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>
```
노드 풀 업그레이드 중에, AKS는 업그레이드 중인 노드에서 서지 노드, 차단 및 드레이닝 Pod를 만들고 노드를 이미지로 다시 설치한 다음, Pod의 차단을 해제합니다. 그런 다음 노드 풀의 다른 노드에 대해 이 프로세스가 반복됩니다.

kubectl get events를 실행하여 업그레이드 프로세스의 상태를 확인할 수 있습니다. 클러스터 업그레이드 문제 해결에 대한 자세한 내용은 AKS 문제 해결 설명서를 참조하세요.

자동 업그레이드 릴리스 채널에 클러스터 등록

AKS는 클러스터를 최신 상태로 유지하는 자동 클러스터 업그레이드 솔루션도 제공합니다. 이 솔루션을 사용하는 경우 업그레이드 시기를 제어하기 위해 유지 관리 기간과 연결해야 합니다. 업그레이드 기간은 4시간 이상이어야 합니다. 릴리스 채널에 클러스터를 등록하면 Microsoft는 클러스터 및 해당 노드 풀의 버전 및 업그레이드 주기를 자동으로 관리합니다.

클러스터 자동 업그레이드는 다양한 릴리스 채널 옵션을 제공합니다. 권장되는 환경 및 릴리스 채널 구성은 다음과 같습니다.

Environment	업그레이드 채널	설명
생산	`stable`	안정성 및 버전 완성도를 위해 프로덕션 워크로드에 안정 또는 일반 채널을 사용합니다.
스테이징, 테스트, 개발	프로덕션과 동일	테스트가 프로덕션 환경을 업그레이드할 버전을 나타내는지 확인하려면 프로덕션과 동일한 릴리스 채널을 사용합니다.
카나리아	`rapid`	최신 Kubernetes 릴리스 및 새 AKS 기능 또는 API를 테스트하려면 `rapid` 채널을 사용합니다. `rapid`의 버전이 프로덕션에 사용 중인 채널로 승격되면 출시 시간을 개선할 수 있습니다.

고려 사항

다음 표에서는 다양한 AKS 업그레이드 및 패치 시나리오의 특징을 설명합니다.

시나리오	시작한 사용자	Kubernetes 업그레이드	OS 커널 업그레이드	노드 이미지 업그레이드
보안 패치	예	아니요	예, 다시 부팅 후	예
클러스터 만들기	예	가능할 수도 있음	예, 업데이트된 노드 이미지가 업데이트된 커널을 사용하는 경우 그렇게 함	예, 새 릴리스를 사용할 수 있는 경우 기존 클러스터를 기준으로 함
컨트롤 플레인 Kubernetes 업그레이드	예	예	없음	아니요
노드 풀 Kubernetes 업그레이드	예	예	예, 업데이트된 노드 이미지가 업데이트된 커널을 사용하는 경우 그렇게 함	예, 새 릴리스를 사용할 수 있는 경우 그렇게 함
노드 풀 스케일 업	예	없음	아니요	예
노드 이미지 업그레이드	예	아니요	예, 업데이트된 노드 이미지가 업데이트된 커널을 사용하는 경우 그렇게 함	예
클러스터 자동 업그레이드	예	예	예, 업데이트된 노드 이미지가 업데이트된 커널을 사용하는 경우 그렇게 함	예, 새 릴리스를 사용할 수 있는 경우 그렇게 함

노드 이미지 업그레이드의 일부로 적용된 OS 보안 패치는 새 클러스터를 만들 때 설치하는 버전보다 이후 버전의 커널을 설치할 수 있습니다.
노드 풀 스케일 업은 현재 가상 머신 확장 집합과 연결된 모델을 사용합니다. 보안 패치가 적용되면 OS 커널이 업그레이드되고, 노드가 다시 부팅됩니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

Anthony Nevico | 수석 클라우드 솔루션 설계자

기타 기여자:

Rishabh Saha | 주요 솔루션 설계자
Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
Ali Yousefi | 클라우드 솔루션 설계자

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음을 통해 공유

Azure Kubernetes Service 패치 및 업그레이드 지침

업데이트의 배경 및 유형

업데이트 유형

업그레이드 전 고려 사항

전체 클러스터 영향

AKS 워크로드 모범 사례

노드 이미지에 대한 주간 업데이트 관리

자동 노드 이미지 업그레이드

수동 노드 업데이트 프로세스

클러스터 업그레이드

업그레이드하기 전에

업그레이드 프로세스

수동 업그레이드

자동 업그레이드 릴리스 채널에 클러스터 등록

고려 사항

참가자

다음 단계

피드백

추가 리소스

다음을 통해 공유

Azure Kubernetes Service 패치 및 업그레이드 지침

업데이트의 배경 및 유형

업데이트 유형

업그레이드 전 고려 사항

전체 클러스터 영향

AKS 워크로드 모범 사례

노드 이미지에 대한 주간 업데이트 관리

자동 노드 이미지 업그레이드

수동 노드 업데이트 프로세스

클러스터 업그레이드

업그레이드하기 전에

업그레이드 프로세스

수동 업그레이드

자동 업그레이드 릴리스 채널에 클러스터 등록

고려 사항

참가자

다음 단계

관련 참고 자료

피드백

추가 리소스