Azure Operator Nexus Kubernetes 클러스터 업그레이드

아티클
08/16/2024

이 문서에서는 Operator Nexus Kubernetes 클러스터를 업그레이드하여 최신 기능 및 보안 업데이트를 가져오는 방법에 대해 알아봅니다. Kubernetes 클러스터 수명 주기 중 일부에는 최신 Kubernetes 버전으로 정기적으로 업그레이드하는 작업이 포함됩니다. 최신 보안 릴리스를 적용하거나 업그레이드하여 최신 기능을 받는 것은 중요합니다. 이 문서에서는 Kubernetes 클러스터에 대한 업그레이드를 확인, 구성, 적용하는 방법을 보여 줍니다.

제한 사항

클러스터 기본 업그레이드 프로세스는 스케일 아웃 방식입니다. 즉, 하나 이상의 추가 노드(또는 최대 서지에 구성된 노드 수)가 추가됩니다. 사용 가능한 용량이 충분하지 않으면 업그레이드에 실패합니다.
새 Kubernetes 버전을 사용할 수 있게 되면 테넌트 클러스터는 자동 업그레이드를 거치지 않습니다. 클러스터의 모든 네트워크 함수가 새 Kubernetes 버전을 지원할 준비가 되었을 때 업그레이드를 시작해야 합니다. 자세한 내용은 클러스터 업그레이드를 참조하세요.
Operator Nexus는 클러스터 전체 업그레이드를 제공하여 모든 노드 풀에서 일관성을 보장합니다. 단일 노드 풀 업그레이드는 지원되지 않습니다. 또한 노드 이미지는 새 버전을 사용할 수 있을 때 클러스터 업그레이드의 일부로 업그레이드됩니다.
에이전트 노드에 대한 사용자 지정은 클러스터 업그레이드 중에 손실됩니다. 이러한 사용자 지정 항목을 업그레이드 후에도 유지하려면 노드 구성을 수동으로 변경하는 대신 DaemonSet에 해당 항목을 배치하는 것이 좋습니다.
코어 추가 기능 구성에 대한 수정 사항은 클러스터 업그레이드 프로세스의 일부로 기본 추가 기능 구성으로 복원됩니다. 잠재적인 업그레이드 실패를 방지하기 위해 추가 기능 구성(예: Calico 등)을 사용자 지정하지 마세요. 추가 기능 구성 복원에 문제가 발생하면 업그레이드 오류가 발생할 수 있습니다.
Operator Nexus Kubernetes 클러스터를 업그레이드하는 경우 Kubernetes 부 버전은 건너뛸 수 없습니다. 모든 업그레이드는 주 버전 번호별로 순차적으로 수행해야 합니다. 예를 들어 1.14.x ->1.15.x or 1.15.x ->1.16.x 업그레이드는 가능하지만, 1.14.x ->1.16.x 업그레이드는 가능하지 않습니다. 버전이 둘 이상의 주 버전에 뒤처진 경우 여러 순차적 업그레이드를 수행해야 합니다.
최대 서지 값 및/또는 최대 사용할 수 없는 값의 최댓값은 클러스터를 만드는 동안 설정해야 합니다. 클러스터가 만들어진 후에는 이러한 값을 변경할 수 없습니다. 자세한 내용은 upgradeSettingsAzure Operator Nexus Kubernetes 클러스터 만들기를 참조하세요.

필수 조건

Azure 구독의 리소스 그룹에 배포된 Azure Operator Nexus Kubernetes 클러스터
Azure CLI를 사용하는 경우 이 문서에서는 최신 Azure CLI 버전을 실행해야 합니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.
최소 필수 networkcloud az-cli 확장 버전: 2.0.b3
버전 번들 개념을 이해합니다. 자세한 내용은 Nexus Kubernetes 버전 번들을 참조하세요.

사용 가능한 업그레이드 확인

다음 단계를 사용하여 클러스터에 사용할 수 있는 Kubernetes 릴리스를 확인합니다.

Azure CLI 사용

다음 Azure CLI 명령은 클러스터에 사용 가능한 업그레이드를 반환합니다.

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

샘플 출력:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Azure Portal 사용

Azure Portal에 로그인합니다.
Operator Nexus Kubernetes 클러스터로 이동합니다.
개요 아래에서 사용 가능한 업그레이드 탭을 선택합니다.

업그레이드 이후 버전 선택

사용 가능한 업그레이드 출력은 업그레이드에 선택할 수 있는 여러 버전이 있음을 나타냅니다. 이 특정 시나리오에서 현재 클러스터는 버전 v1.25.4-3.에서 작동하므로 사용 가능한 업그레이드 옵션에는 v1.25.4-4 및 최신 패치 릴리스 v1.25.6-1.이 포함됩니다. 나아가 새로운 부 버전도 사용할 수 있습니다.

어느 사용 가능한 버전으로나 업그레이드할 수 있습니다. 그러나 사용 가능한 최신 major-minor-patch-versionbundle 버전으로 업그레이드하는 것이 권장됩니다.

참고 항목

버전에 대한 입력 형식은 major.minor.patch 또는 major.minor.patch-versionbundle입니다. 버전 입력은 사용 가능한 업그레이드 버전 중 하나여야 합니다. 예를 들어 클러스터의 현재 버전이 1.1.1-1일 경우유효한 버전 입력은 1.1.1-2 또는 1.1.1-x입니다. 1.1.1은 유효한 형식이지만 현재 버전이 이미 1.1.1이기 때문에 업데이트를 트리거하지 않습니다. 업데이트를 시작하려면 1.1.1-2 같은 버전 번들로 전체 버전을 지정할 수 있습니다. 그러나 1.1.2 및 1.2.x는 유효한 입력이며 1.1.2 또는 1.2.x에 대해 사용할 수 있는 최신 버전 번들을 사용합니다.

클러스터 업그레이드

클러스터 업그레이드 프로세스 중에 Operator Nexus는 다음 작업을 수행합니다.

지정된 Kubernetes 버전이 있는 새 컨트롤 플레인 노드를 클러스터에 추가합니다.
새 노드가 추가된 후 이전 컨트롤 플레인 노드 중 하나를 실행하여 실행 중인 워크로드가 다른 정상 컨트롤 플레인 노드로 정상적으로 이동되도록 합니다.
이전 컨트롤 플레인 노드는 드레이닝되면 제거되고 클러스터에 새 컨트롤 플레인 노드가 추가됩니다.
이 프로세스는 클러스터의 모든 컨트롤 플레인이 업그레이드될 때까지 반복됩니다.
서지를 통해 작업자 노드를 업그레이드하는 경우(기본값):
- 지정된 Kubernetes 버전을 실행하는 클러스터에 새 작업자 노드(또는 최대 서지에 구성된 노드 수만큼)를 추가합니다. 여러 에이전트 풀이 동시에 업그레이드됩니다.
- 실행 중인 애플리케이션의 중단을 최소화하기 위해 이전 작업자 노드 중 하나를 차단 및 드레이닝합니다. 최대 서지를 사용하는 경우 지정된 버퍼 노드 수만큼 많은 작업자 노드를 동시에 차단 및 드레이닝합니다.
- 이전 작업자 노드는 드레이닝되면 제거되고 새 Kubernetes 버전이 있는 새 작업자 노드가 클러스터에 추가됩니다(또는 최대 서지에 구성된 노드 수만큼).
서지 없이 작업자 노드를 업그레이드하는 경우:
- 클러스터의 각 에이전트 풀에 대해 이전 작업자 노드(또는 사용할 수 없는 최대 개수로 구성된 많은 노드)가 차단, 드레이닝 및 제거된 후, 지정된 Kubernetes 버전이 있는 새 작업자 노드로 바뀝니다. 여러 에이전트 풀이 동시에 업그레이드됩니다.
- 업그레이드하는 동안 이전 작업자 노드에서 드레이닝된 Pod를 즉시 이동할 수 있는 새 노드가 없으므로 클러스터 용량이 일시적으로 감소합니다. 충분한 용량이 없으면 Pod가 보류 중 상태로 전환될 수 있습니다. 따라서 특히 서지 없는 업그레이드 시 애플리케이션 용량 요구 사항을 충족하도록 클러스터를 설계해야 합니다.
이 프로세스는 클러스터의 모든 작업자 노드가 업그레이드될 때까지 반복됩니다.

참고 항목

OS(운영 체제) 이미지 버전과 Kubernetes 버전이 버전 번들 간에 동일하게 유지되는 경우 클러스터 업그레이드는 새 노드를 만들지 않고 이전 노드를 바꾸지 않습니다. 이는 예상된 동작입니다. 업그레이드에는 새로운 OS나 K8s 버전이 아닌, Addon 버전에 대한 업데이트만 포함될 수 있기 때문입니다. 롤링 업그레이드가 없으므로 노드에 차단 및 드레이닝이 없고, 따라서 Pod 중단이 발생하지 않습니다.

Important

PodDisruptionBudgets(PDB)가 한 번에 1개 이상의 Pod 복제본을 이동하도록 허용해야 합니다. 그렇지 않으면 드레이닝/제거 작업이 실패합니다. 드레이닝 작업이 실패할 경우, 애플리케이션이 중단되지 않도록 업그레이드 작업도 실패합니다. 작업 중지(예: 잘못된 PDB, 할당량 부족 등)의 원인을 수정한 후 작업을 다시 시도하세요. 작업자 노드 풀별로 드레이닝 시간 제한을 구성할 수도 있는데, 이 시간 제한 후에는 Pod가 아직 드레이닝을 완료하지 않았더라도 노드가 제거됩니다. 이렇게 하면 잘못 구성된 PDB로 인해 업그레이드가 차단되는 것을 방지할 수 있습니다. 드레이닝 시간 제한 설정은 초 단위로 구성되며 기본값은 1800입니다.

networkcloud kubernetescluster update 명령을 사용하여 클러스터를 업그레이드합니다.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

show 명령을 사용하여 업그레이드가 성공했는지 확인합니다.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

다음 예제 출력은 클러스터가 이제 v1.26.3을 실행하고 있음을 보여줍니다.

"v1.26.3"

클러스터가 정상인지 확인합니다.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

다음 예제 출력은 클러스터가 정상임을 보여줍니다.

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

노드 서지 또는 사용 불가 업그레이드 사용자 지정

기본적으로 Operator Nexus는 하나의 추가 작업자 노드를 사용하여 서지로 업그레이드를 구성합니다. 최대 서지 설정에 기본값 1을 사용하면 Operator Nexus가 기존 애플리케이션의 연결/드레인 전에 추가 노드를 만들어 이전 버전의 노드를 대체함으로써 워크로드가 중단되는 것을 최소화할 수 있습니다. 업그레이드 속도와 업그레이드가 중단되는 현상을 절충하기 위해 최대 서지 값을 노드 풀별로 맞춤 설정할 수 있습니다. 최대 서지 값을 늘리면 업그레이드 프로세스가 더 빠르게 완료됩니다. 최대 서지에 큰 값을 설정하면 업그레이드 프로세스 중에 중단이 발생할 수 있습니다.

예를 들어 최대 서지 값이 100%면 가능한 가장 빠른 업그레이드 프로세스(노드 수 두 배)를 제공하지만 노드 풀의 모든 노드가 동시에 드레이닝됩니다. 테스트 환경에 이처럼 더 높은 값을 사용하기를 원할 수도 있습니다. 프로덕션 노드 풀의 경우 33%의 max_surge 설정을 하는 것이 좋습니다.

예를 들어, 리소스가 제한된 환경에서는 서지를 통한 업그레이드가 항상 적절한 것은 아닙니다. 작업자 노드를 먼저 제거한 다음 바꾸는 방식으로 서지 없이 업그레이드를 진행할 수도 있습니다. 즉, 추가 리소스가 필요하지 않지만 Pod를 노드에 예약할 수 없는 용량 감소 기간이 발생할 수 있습니다. 이러한 형식의 업그레이드는 최대 사용 불가능 설정에 따라 노드 풀별로 제어됩니다. 기본적으로 사용할 수 없는 최대 개수는 0으로 설정됩니다. 이는 최대 0개의 노드를 사용할 수 없음을 나타냅니다. 즉, 이러한 형식의 업그레이드는 기본적으로 발생하지 않습니다.

API는 최대 서지 및 최대 사용 불가에 대해 정수 값과 백분율 값을 모두 허용합니다. 5와 같은 정수는 5개의 노드가 서지/사용 불가 상태가 될 수 있음을 나타냅니다. 50%의 값은 풀의 현재 노드 수의 절반에 해당하는 서지/사용 불가 값을 나타냅니다.

최대 서지 또는 최대 사용 불가 중 하나는 최소한 1(또는 1%)이어야 합니다. 그렇지 않으면 클러스터를 업그레이드할 수 있는 메커니즘이 없습니다. 백분율 값은 가장 가까운 노드 수로 반올림 됩니다. 최대 서지와 최대 사용 불가는 모두 최대 100%로 설정할 수 있습니다. 최대 서지 값이 업그레이드에 필요한 노드 수보다 큰 경우 업그레이드할 노드 수를 최대 서지 값으로 사용합니다.

최대 서지와 최대 사용 불가는 동시에 구성할 수 있으며, 이 경우 업그레이드는 서지와 사용 불가를 혼합하여 진행됩니다.