여러 멤버 클러스터에서 Kubernetes 및 노드 이미지 업데이트

적용 대상: ✔️ 허브 클러스터를 사용하는 플릿 관리자 ✔️ 플릿 관리자

많은 수의 클러스터를 관리하는 플랫폼 관리자는 안전하고 예측 가능한 방식으로 여러 클러스터(예: 노드 OS 이미지 또는 Kubernetes 버전 업그레이드)의 업데이트를 준비하는 데 문제가 있는 경우가 많습니다. 이 문제를 해결하기 위해 Azure Kubernetes Fleet Manager를 사용하면 업데이트 실행을 사용하여 여러 클러스터에서 업데이트를 오케스트레이션할 수 있습니다.

업데이트 실행은 단계, 그룹 및 전략으로 구성되며 자동 업그레이드 프로필을 사용하여 진행 중인 정기 업데이트에 대해 수동으로, 일회성 업데이트 또는 자동으로 적용할 수 있습니다. 모든 업데이트 실행(수동 또는 자동화)은 멤버 클러스터 유지 관리 기간을 적용합니다.

업데이트 실행 이해

다음 이미지는 각각 두 개의 멤버 클러스터가 있는 두 개의 업데이트 그룹을 포함하는 두 개의 업데이트 단계를 포함하는 업그레이드 실행을 시각화합니다. 대기 기간은 첫 번째 단계와 두 번째 단계 사이에 구성됩니다.

• 업데이트 실행: 업데이트 실행은 업데이트 목표와 시퀀스로 구성된 AKS 클러스터 컬렉션에 적용되는 업데이트를 나타냅니다. 업데이트 목표는 원하는 업데이트(예: Kubernetes 버전 1.28.3으로 업그레이드)를 설명합니다. 업데이트 시퀀스는 단계 및 그룹을 사용하여 표현된 여러 멤버 클러스터에 업데이트를 적용하는 정확한 순서를 설명합니다. 지정하지 않으면 모든 멤버 클러스터가 순차적으로 하나씩 업데이트됩니다. 업데이트 실행을 중지하고 시작할 수 있습니다.
• 업데이트 스테이지: 업데이트 실행은 순차적으로 적용되는 스테이지로 나뉩니다. 예를 들어 첫 번째 업데이트 스테이지는 테스트 환경 멤버 클러스터를 업데이트하고 두 번째 업데이트 스테이지는 이후에 프로덕션 환경 멤버 클러스터를 업데이트할 수 있습니다. 후속 업데이트 스테이지의 애플리케이션 간에 지연을 위해 대기 시간을 지정할 수 있습니다.
• 업데이트 그룹: 각 업데이트 스테이지에는 업데이트할 멤버 클러스터를 선택하는 데 사용되는 하나 이상의 업데이트 그룹이 포함됩니다. 업데이트 그룹은 멤버 클러스터에 대한 업데이트 애플리케이션을 정렬하는 데도 사용됩니다. 업데이트 스테이지 내에서 업데이트는 모든 다른 업데이트 그룹에 병렬로 적용됩니다. 업데이트 그룹 내에서 멤버 클러스터는 순차적으로 업데이트됩니다. 집합의 각 멤버 클러스터는 하나의 업데이트 그룹에만 속할 수 있습니다.
• 승인 게이트(미리 보기): 각 단계 또는 그룹 전후에 구성할 수 있습니다. 승인은 업데이트 실행을 일시 중지하여 사용자 또는 사용자가 설정한 자동화가 계속 진행해도 괜찮은지 확인할 수 있도록 합니다. 사용자 또는 자동화에서 승인을 부여하면 업데이트 실행이 계속됩니다.
• 업데이트 전략: 업데이트 전략은 단계 및 그룹이 포함된 업데이트 시퀀스를 설명하고 각 실행에서 시퀀스를 반복적으로 정의하는 대신 업데이트 실행 구성을 다시 사용할 수 있도록 합니다. 업데이트 전략에는 원하는 Kubernetes 또는 노드 이미지 버전이 포함되지 않습니다.

현재 멤버 클러스터에서 지원되는 업데이트 작업은 업그레이드입니다. 선택할 수 있는 업그레이드에는 세 가지 형식이 있습니다.

• Kubernetes 컨트롤 플레인 및 노드(노드 이미지 업그레이드 포함)에 대한 Kubernetes 버전을 업그레이드합니다.
• 클러스터의 컨트롤 플레인에 대해서만 Kubernetes 버전을 업그레이드합니다.
• 노드 이미지만 업그레이드합니다.

업그레이드할 대상 Kubernetes 버전을 지정할 수 있지만 정확한 대상 노드 이미지 버전은 지정할 수 없습니다. 사용 가능한 최신 노드 이미지 버전은 클러스터의 Azure 지역에 따라 달라질 수 있기 때문입니다(자세한 내용은 AKS 릴리스 추적기를 확인하세요).

대상 노드 이미지 버전은 기본 설정에 따라 자동으로 선택됩니다.

• Latest: 클러스터 업그레이드가 시작될 때 클러스터의 Azure 지역에서 사용할 수 있는 최신 노드 이미지를 사용합니다. 따라서 클러스터가 있는 Azure 지역과 업그레이드가 실제로 시작되는 시기에 따라 다른 이미지 버전을 사용할 수 있습니다.
• Consistent: 업데이트 실행이 시작되면 클러스터 간에 동일한 일관된 이미지 버전이 사용되도록 이 실행에서 멤버 클러스터의 Azure 지역에서 최신 일반 이미지 버전을 선택합니다.

최신 이미지 버전을 사용하고 보안 위험을 최소화하려면 Latest를 선택해야 하며, 이후 클러스터에서 사용하기 전에 이전 단계의 클러스터에서 해당 이미지를 사용하고 확인하여 안정성을 높이려면 Consistent를 선택해야 합니다.

계획된 유지 관리

업데이트 실행은 AKS(Azure Kubernetes Service) 클러스터 수준에서 설정한 계획된 유지 관리 기간을 따릅니다.

AKS 클러스터는 Kubernetes(컨트롤 플레인) 업그레이드용과 노드 이미지 업그레이드용으로 두 가지 고유한 유지 관리 기간을 지원합니다. 유지 관리 기간은 업데이트를 클러스터에 적용할 수 있지만 업데이트 트리거가 아닌 기간을 정의합니다.

Fleet Manager 업데이트 실행은 다음과 같이 AKS 유지 관리 기간을 준수합니다.

업데이트 실행은 다음 순서대로 계획된 유지 관리에 따라 클러스터 업그레이드의 우선 순위를 지정합니다.

1. 지속적인 유지 관리 기간이 열려 있는 멤버.
2. 앞으로 4시간 이내에 유지 관리 기간이 시작될 예정인 회원.
3. 유지 관리 기간이 없는 멤버.
4. 유지 관리 창이 닫힌 구성원.

실행 상태 업데이트

업데이트 실행은 다음 상태 중 하나일 수 있습니다.

• 시작되지 않음: 업데이트 실행이 시작되지 않았습니다.
• 실행 중: 적어도 하나의 멤버 클러스터에 대한 업데이트 실행이 진행 중입니다.
• 보류 중:
  • 멤버 클러스터: 멤버 클러스터는 메시지 필드에서 볼 수 있는 다음과 같은 이유로 상태에 있을 Pending 수 있습니다.
    • 유지 관리 기간이 열려 있지 않습니다. 메시지는 다음 개장 시간을 나타냅니다.
    • 대상 Kubernetes 버전은 아직 멤버의 Azure 지역에서 사용할 수 없습니다. 지역 간 릴리스 상태를 확인할 수 있도록 AKS 릴리스 추적기의 메시지 링크입니다.
    • 대상 노드 이미지 버전은 아직 멤버의 Azure 지역에서 사용할 수 없습니다. AKS 릴리스 추적기로 연결되는 메시지 링크입니다.
  • 업데이트 그룹: 그룹의 모든 멤버가 Pending이거나 시작되지 않았거나 Pending 게이트가 있는 경우 그룹은 Pending입니다. 멤버가 Pending으로 이동하면 업데이트 실행은 그룹의 다음 멤버를 업그레이드하려고 시도합니다. 만약 모든 멤버가 Pending이면, 그룹이 Pending 상태로 이동합니다. 그룹이 Pending인 경우에는, 업데이트 실행은 다음 업데이트 단계로 이동하기 전에 그룹이 완료되기를 기다립니다.
  • 업데이트 단계: 단계의 모든 업데이트 그룹이 Pending 완료되었거나 시작되지 않은 경우, 또는 단계에 Pending 게이트가 있는 경우 Pending입니다.
  • 실행: 현재 단계가 Pending 상태인 경우 실행이 Pending 상태입니다.
• 건너뛰기: 업데이트 실행의 모든 수준을 건너뛸 수 있습니다. 건너뛰기는 시스템이나 사용자가 시작할 수 있습니다.
  • 멤버 클러스터:
    • 사용자가 멤버, 그룹 또는 스테이지에 대한 업데이트를 건너뛰었다.
    • 멤버 클러스터가 이미 대상 Kubernetes 버전에 있습니다(업데이트 실행 모드가 Full 또는 ControlPlaneOnly인 경우).
    • 멤버 클러스터는 이미 대상 Kubernetes 버전이고 모든 노드 풀은 대상 노드 이미지 버전입니다.
    • 업데이트 실행에 대해 일관된 노드 이미지를 선택한 경우 노드 풀 중 하나에 대한 대상 이미지 버전을 찾을 수 없는 경우 해당 클러스터에 대한 업그레이드를 건너뜁니다. 예를 들어 업데이트 실행이 시작된 후 새 VM(Virtual Machine) SKU가 있는 새 노드 풀이 추가될 때 발생할 수 있습니다.
  • 업데이트 그룹:
    • 사용자가 그룹에 대한 업데이트를 건너뛰었다.
    • 시스템에서 모든 멤버 클러스터가 Skipped로 발견되었습니다.
  • 업데이트 단계:
    • 사용자가 스테이지에 대한 업데이트를 건너뛰었다.
    • 단계의 모든 업데이트 그룹이 시스템에 의해 Skipped으로 감지되었습니다.
  • 업데이트 실행:
    • 모든 단계가 시스템에 의해 Skipped로 발견되었습니다.
• 중지됨: 모든 수준의 업데이트 실행을 중지할 수 있습니다. 중지된 상태를 입력할 수 있는 두 가지 가능성이 있습니다.
  • 사용자가 업데이트 실행을 중지했으며, 이때 업데이트 실행이 모든 작업 추적을 중지했습니다. 업데이트 실행에 의해 작업이 이미 시작된 경우(예: 클러스터 업그레이드가 진행 중) 해당 개별 클러스터에 대해 해당 작업이 중단되지 않습니다.
  • 업데이트 실행 중에 오류가 발생하는 경우(예: 클러스터 중 하나에서 업그레이드 실패) 전체 업데이트 실행이 중지됨 상태로 전환됩니다. 업데이트 실행에서 후속 클러스터에 대한 작업은 시도되지 않습니다.
• 실패: 클러스터를 업그레이드하지 못하면 다음 작업이 수행됩니다.
  • 멤버 클러스터에서 MemberUpdateStatus를 Failed로 표시합니다.
  • 요약 오류 메시지와 함께 모든 부모 항목(그룹 -> 단계 -> 실행)을 Failed로 표시합니다.
  • 업데이트 실행이 더 이상 진행되지 않도록 중지합니다.
• 완료됨: 업데이트 실행이 성공적으로 완료되었습니다.

자동 업그레이드 프로필에 대한 이해

자동 업그레이드 프로필은 AKS에 새 Kubernetes 또는 노드 이미지 버전을 사용할 수 있게 되면 업데이트 실행을 자동으로 트리거하는 데 사용됩니다.

자동 업그레이드 프로필에서 다음을 구성할 수 있습니다.

• 클러스터에 적용되는 자동 업그레이드 형식을 결정하는 Channel(Stable, Rapid, NodeImage, TargetKubernetesVersion(미리 보기))
• 클러스터의 업그레이드 순서를 설정하는 UpdateStrategy입니다. 전략이 제공되지 않으면 클러스터가 하나씩 순차적으로 업데이트됩니다.
• NodeImageSelectionType Kubernetes 버전을 업그레이드할 때 노드 이미지를 선택하는 방법을 지정하는 (최신, 일관성)입니다.

안정적인 채널

안정 채널은 항상 부 버전 N-1의 최신 AKS 지원 Kubernetes 패치 릴리스입니다. 여기서 N 은 지원되는 최신 부 버전입니다.

예:

• 지원되는 최신 마이너 Kubernetes 버전은 1.30입니다. 1.29 마이너 범위의 모든 패치 릴리스는 안정 채널 업데이트로 고려됩니다.
• 1.31의 새로운 마이너 Kubernetes 버전이 게시되었습니다. 1.30 마이너 버전의 모든 패치 릴리스는 안정적인 채널 업데이트용으로 고려됩니다. 이전에 1.29에서 업데이트를 받은 클러스터는 1.30에 대한 최신 패치로 업데이트됩니다.

빠른 채널

Rapid 채널은 항상 AKS가 지원하는 최신 Kubernetes 마이너 릴리스입니다.

예:

• 지원되는 최신 부 버전은 1.30입니다. 1.30 마이너 버전 범위의 모든 패치 릴리스는 빠른 채널 업데이트를 위해 고려됩니다.
• 1.31의 새로운 마이너 Kubernetes 버전이 게시되었습니다. 1.30 이 안정 채널로 이동합니다. 이전에 1.30에서 업데이트를 수신한 클러스터는 이제 빠른 채널인 1.31에 대한 최신 패치로 업데이트됩니다.

NodeImage 채널

멤버 클러스터 노드는 보안 수정 및 버그 수정이 포함된 새로 패치된 VHD로 매주 업데이트됩니다. 새 VHD에 대한 업데이트는 유지 관리 기간 및 급증 설정에 따라 중단됩니다. 이 옵션을 선택하면 추가 VHD 비용이 발생하지 않습니다.

이 채널을 사용하면 Linux 자동 업그레이드가 기본적으로 비활성화됩니다. 노드 이미지 업그레이드는 마이너 Kubernetes 버전이 계속 지원되는 한, 사용 중단된 패치 버전을 지원합니다. 노드 이미지는 AKS에서 테스트되고 완전히 관리되며 안전한 배포 사례를 사용하여 적용됩니다.

다른 운영 체제의 노드는 해당 운영 체제에 맞게 조정된 노드 이미지 버전에 따라 업데이트됩니다.

예시:

• 클러스터에는 NodeImage가 AKSWindows-2022-containerd인 버전 20348.2582.240716의 노드가 있습니다. 새 NodeImage 버전 20348.2582.240916 이 릴리스되고 클러스터 노드가 자동으로 버전 20348.2582.240916으로 업그레이드됩니다.

TargetKubernetesVersion 채널(미리 보기)

TargetKubernetesVersion 채널을 사용하면 자동 업그레이드 프로필에 이를 지정하여 플릿을 다음 Kubernetes 부 버전으로 이동할 시기를 제어할 수 있습니다. 대상 Kubernetes 버전은 "{major}.{minor}" 형식으로 지정해야 합니다 (예: "1.33"). 플릿 자동 업그레이드는 패치를 사용할 수 있을 때 멤버 클러스터를 지정된 대상 Kubernetes 버전의 최신 패치 릴리스로 자동으로 업그레이드합니다. 자동 업그레이드 프로필의 대상 Kubernetes 버전을 업데이트할 때까지 Fleet는 다음 부 버전으로 업그레이드되지 않습니다.

예:

• TargetKubernetesVersion 채널을 사용하여 자동 업그레이드 프로필을 만들고 대상 Kubernetes 버전의 "1.30"을 지정합니다. 새 패치 버전 1.30.5가 게시되었습니다. 업데이트 실행은 1.30.5의 대상으로 자동으로 생성됩니다.
• TargetKubernetesVersion 채널을 사용하여 자동 업그레이드 프로필을 만들고, 대상 Kubernetes 버전의 "1.29"를 지정하고, 자동 업그레이드 프로필에서 LTS(LongTermSupport)를 사용하도록 설정합니다. 지원되는 최신 커뮤니티 부 버전은 "1.33"입니다. 새 패치 버전 1.29.5가 게시되었습니다. 업데이트 실행은 1.29.5의 대상으로 자동으로 생성됩니다. 참고: 생성된 업데이트 실행에 LTS를 사용하지 않는 클러스터가 포함되어 있으면 실패합니다.

소수 버전 건너뛰기 동작

자동 업그레이드는 마이너 Kubernetes 버전 차이가 두 개 이상인 경우(예: 1.28에서 1.30) 마이너 버전 간에 클러스터를 이동하지 않습니다. 관리자에게 다양한 Kubernetes 버전 집합이 있는 경우 먼저 하나 이상의 업데이트 실행을 사용하여 멤버 클러스터를 일관되게 버전이 지정된 릴리스 집합으로 가져와서 구성 Stable 되거나 Rapid 채널 업데이트를 통해 나중에 일관성이 유지되도록 하는 것이 좋습니다.

다음 단계

• 방법: Azure Kubernetes Fleet Manager 업데이트 실행을 사용하여 여러 클러스터를 업그레이드합니다.
• 방법: Azure Kubernetes Fleet Manager를 사용하여 여러 클러스터를 자동으로 업그레이드합니다.
• 방법: Azure Kubernetes Fleet Manager에 대한 업데이트 실행을 모니터링합니다.
• 다중 클러스터 업데이트 FAQ.