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

아티클
01/05/2024

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

업데이트의 배경 및 유형

AKS에 대한 업데이트에는 세 가지 유형이 있으며, 각 업데이트는 다음에 빌드됩니다.

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

업데이트 형식

노드 OS 보안 패치(Linux에만 해당). Linux 노드의 경우 정식 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 클러스터의 원활한 작동을 보장하려면 다음 모범 사례를 따르세요.

Pod 중단 예산(PDB)을 정의합니다. 배포에 대한 Pod 중단 예산을 설정하는 것이 중요합니다. PDB는 중단 이벤트 중에 지속적인 기능을 보장하기 위해 사용 가능한 애플리케이션 복제본(replica) 최소 수를 적용합니다. 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% 서지는 중단에 민감한 워크로드에 권장되는 최대값입니다. 자세한 내용은 AKS에 대한 업그레이드 옵션을 참조 하세요.
노드 드레이닝 시간 제한을 조정합니다.노드 드레이닝 시간 제한 은 업데이트 중인 노드에서 Pod를 다시 예약하는 동안 클러스터가 대기하는 최대 시간을 지정합니다. 기본값은 30분입니다. Pod 일정을 조정하는 데 어려움을 겪는 워크로드의 경우 이 기본값을 조정하는 것이 도움이 될 수 있습니다.
유지 관리 기간을 계획하고 예약합니다. 업그레이드 프로세스는 Kubernetes 클러스터의 전반적인 성능에 영향을 줄 수 있습니다. 사용량이 가장 많은 기간을 벗어나는 현재 위치 업그레이드 프로세스를 예약하고 클러스터 성능을 모니터링하여 특히 업데이트 프로세스 중에 적절한 크기 조정을 보장합니다.
클러스터의 다른 종속성을 확인합니다. Kubernetes 운영자는 KEDA 스칼라, Dapr 및 서비스 메시와 같은 작업의 일부로 Kubernetes 클러스터에 다른 도구를 배포하는 경우가 많습니다. 업그레이드 프로세스를 계획할 때 대상 버전과의 호환성을 보장하기 위해 사용 중인 모든 구성 요소에 대한 릴리스 정보를 검사.

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

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

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

업데이트된 이미지가 있는 노드가 노드 풀에 추가됩니다. 한 번에 추가된 노드 수는 서지 값에 의해 제어됩니다.
기존 노드 중 하나가 코드되고드레이닝됩니다. 코드 조정은 노드가 Pod를 예약하지 않도록 합니다. 드레이닝하면 해당 Pod가 제거되고 다른 노드로 예약됩니다.
노드가 완전히 드레이닝되면 노드 풀에서 제거됩니다. 서지에 의해 추가된 업데이트된 노드가 해당 노드를 대체합니다.
이 프로세스는 노드 풀에서 업데이트해야 하는 각 노드에 대해 반복됩니다.

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

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

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

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

None. 업데이트가 자동으로 적용되지 않습니다.
Unmanaged. Ubuntu 및 Azure Linux 업데이트는 야간에 OS에 의해 적용됩니다. 다시 부팅은 별도로 관리해야 합니다.
SecurityPatch. 야간 보안 패치는 OS 이미지 업데이트로 배포됩니다.
NodeImage. 매주 AKS 패치와 야간 보안 패치가 결합됩니다.

업데이트 채널을 선택하는 Unmanaged 경우 kured와 같은 도구를 사용하여 다시 부팅 프로세스를 관리해야 합니다. 업데이트 채널을 선택하는 SecurityPatch 경우 업데이트를 야간만큼 자주 적용할 수 있습니다. 이 패치 수준을 사용하려면 리소스 그룹에 VHD를 저장해야 하며, 이로 인해 명목 요금이 발생합니다. 또한 구성을 구성과 NodeImage 결합하여 SecurityPatch 전체 노드 패치 프로세스를 사용하도록 설정해야 합니다.

가장 좋은 방법은 업데이트 채널을 사용하고 NodeImage 클러스터가 사용량이 가장 많은 aksManagedNodeOSUpgradeSchedule 기간을 벗어나는 시간으로 기본 테넌트 창을 구성하는 것입니다. 클러스터 기본 테넌트 창을 구성하는 데 사용할 수 있는 특성에 대한 기본 테넌트 창 만들기를 참조하세요. 주요 특성은 다음과 같습니다.

name. 노드 OS 업데이트에 사용합니다 aksManagedNodeOSUpgradeSchedule .
utcOffset. 표준 시간대를 구성합니다.
startTime. 기본 테넌트 창의 시작 시간을 설정합니다.
dayofWeek. 창의 요일을 설정합니다. 예: Saturday.
schedule. 창의 빈도를 설정합니다. 업데이트의 weekly경우 NodeImage .
durationHours. 이 특성을 최소 4시간으로 설정합니다.

다음은 매주 기본 테넌트 기간을 토요일 동부 표준시 오후 8시로 설정하는 예제입니다.

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utcOffset -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 기본 테넌스는 구성된 창 내에서 발생하지만 기본 테넌트의 시간은 보장되지 않습니다.

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) 및 이전 부 버전 2개에 대한 전체 지원이 제공됩니다. 세 번째 이전 부 버전에 대해 제한된 플랫폼 지원이 제공됩니다. 자세한 내용은 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 명왕성이며, 배포 및 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 클러스터의 모든 사용자 노드 풀을 업그레이드합니다.

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

플래그를 사용하여 az aks upgrade 명령을 --control-plane-only 실행하여 클러스터의 노드 풀이 아닌 클러스터 컨트롤 플레인만 업그레이드합니다.
```
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 워크로드 모범 사례

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

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

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

클러스터 업그레이드

업그레이드하기 전에

업그레이드 프로세스

수동 업그레이드

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

고려 사항

참가자

다음 단계

관련 참고 자료

피드백

피드백

추가 리소스