VMware용 Anthos 클러스터 업그레이드

이 페이지에서는 VMware용 Anthos 클러스터(GKE On-Prem)를 업그레이드하는 방법을 설명합니다. Anthos On-Prem API로 사용자 클러스터를 관리하고 미리보기 업그레이드 절차를 통해 Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 클러스터를 업그레이드하려는 경우 Anthos On-Prem API 클라이언트를 사용하여 사용자 클러스터 업그레이드를 참조하세요.

업그레이드 절차 개요

동일한 부 출시 버전 또는 다음 부 출시 버전에 속하는 모든 버전으로 직접 업그레이드할 수 있습니다. 예를 들어 1.13.0에서 1.13.1로 업그레이드하거나 1.12.1 에서 1.13.0으로 업그레이드할 수 있습니다.

다음 부 출시 버전에 포함되지 않는 버전으로 업그레이드하는 경우 현재 버전과 원하는 버전 사이에 각 부 출시 버전 중 하나를 통해 업그레이드해야 합니다. 예를 들어 버전 1.11.2에서 버전 1.13.0으로 업그레이드하는 경우 직접 업그레이드할 수 없습니다. 먼저 버전 1.11.2에서 버전 1.12.x로 업그레이드한 후 버전 1.13.0으로 업그레이드해야 합니다.

이 주제에서는 버전 1.12.x에서 버전 1.13.y로 업그레이드하는 방법을 설명합니다.

업그레이드 프로세스를 시작하기 전에 클러스터 업그레이드 권장사항을 검토하세요.

다음은 일반적인 업그레이드 워크플로입니다.

  1. 관리자 워크스테이션을 업그레이드 대상 버전으로 업그레이드합니다.

  2. 관리자 워크스테이션에서 사용자 클러스터를 업그레이드합니다.

  3. 모든 사용자 클러스터가 업그레이드되면 관리자 워크스테이션에서 관리자 클러스터를 업그레이드할 수 있습니다. 업그레이드에서 사용할 수 있는 기능이 필요하지 않으면 이 단계는 선택사항입니다.

비동기 사용자 클러스터 업그레이드

사용자 클러스터 업그레이드의 경우 gkectl upgrade cluster 명령어에는 두 가지 변형이 있습니다.

  • 비동기(권장)
  • 동기식

비동기 변형을 사용하면 명령어가 업그레이드를 시작한 후 완료합니다. 업그레이드 전체 기간 동안 명령어의 출력을 확인할 필요가 없습니다. 대신 gkectl list clustergkectl describe cluster를 실행하여 업그레이드 진행 상황을 주기적으로 확인할 수 있습니다.

비동기 변형을 사용하려면 명령어에 --async 플래그를 포함합니다. 자세한 내용은 사용자 클러스터 업그레이드를 참조하세요.

업그레이드 준비

관리자 워크스테이션을 만들기 전에 gkeadm create config에서 생성한 관리자 워크스테이션 구성 파일을 채웠습니다. 이 파일의 기본 이름은 admin-ws-config.yaml입니다.

또한 워크스테이션에는 정보 파일이 있습니다. 이 파일의 기본 이름은 관리자 워크스테이션의 이름과 동일합니다.

관리자 워크스테이션 구성 파일과 정보 파일을 찾습니다. 업그레이드 단계를 수행하는 데 필요합니다. 이러한 파일이 현재 디렉터리에 있고 이름이 모두 기본값이면 업그레이드 명령어를 실행할 때 이를 지정할 필요가 없습니다. 그러나 이러한 파일이 다른 디렉터리에 있거나 파일 이름이 변경된 경우에는 --config--info-file 플래그를 사용하여 이를 지정해야 합니다.

출력 정보 파일이 없으면 다시 만들 수 있습니다. 누락된 경우 정보 파일 다시 만들기를 참조하세요.

관리자 워크스테이션 업그레이드

  1. gkeadm 다운로드:

    gkeadm upgrade gkeadm --target-version TARGET_VERSION
    

    TARGET_VERSION을 업그레이드 대상 버전으로 바꿉니다.

  2. 관리자 워크스테이션 업그레이드:

    gkeadm upgrade admin-workstation --config AW_CONFIG_FILE --info-file INFO_FILE
    

    다음을 바꿉니다.

    • AW_CONFIG_FILE는 관리자 워크스테이션 구성 파일의 경로입니다. 파일이 현재 디렉터리에 있고 이름이 admin-ws-config.yaml이면 이 플래그를 생략할 수 있습니다.

    • INFO_FILE은 정보 파일의 경로입니다. 파일이 현재 디렉터리에 있으면 이 플래그를 생략할 수 있습니다. 이 파일의 기본 이름은 관리자 워크스테이션의 이름과 동일합니다.

위의 명령어는 다음 작업을 수행합니다.

  • 현재 관리자 워크스테이션의 홈 디렉터리에 있는 모든 파일을 백업합니다. 예를 들면 다음과 같습니다.

    • 관리자 클러스터 구성 파일입니다. 기본 이름은 admin-cluster.yaml입니다.
    • 사용자 클러스터 구성 파일입니다. 기본 이름은 user-cluster.yaml입니다.
    • 관리자 클러스터 및 사용자 클러스터의 kubeconfig 파일
    • vCenter Server의 루트 인증서. 이 파일에는 소유자 읽기 및 소유자 쓰기 권한이 있어야 합니다.
    • 구성요소 액세스 서비스 계정의 JSON 키 파일입니다. 이 파일에는 소유자 읽기 및 소유자 쓰기 권한이 있어야 합니다.
    • 연결-등록 및 로깅 모니터링 서비스 계정의 JSON 키 파일입니다.
  • 새 관리자 워크스테이션을 만들고 모든 백업 파일을 새 관리자 워크스테이션으로 복사합니다.

  • 이전 관리자 워크스테이션을 삭제합니다.

사용 가능한 IP 주소가 충분한지 확인

클러스터를 업그레이드하기 전에 IP 주소가 충분히 할당되었는지 확인합니다. 필요에 따라 추가 IP 주소를 할당할 수 있습니다. 필요한 IP 주소 수를 결정하려면 노드 IP 주소 관리를 참조하세요.

사용자 클러스터 업그레이드

명령줄

명령줄에서 수행할 수 있는 두 가지 유형의 사용자 클러스터 업그레이드는 다음과 같습니다.

  • 비동기식
  • 동기식

비동기 업그레이드

gkectl prepare를 실행하여 OS 이미지를 vSphere로 가져옵니다.

gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

사용자 클러스터 구성 파일에서 gkeOnPremVersion을 업그레이드 대상 버전으로 설정합니다.

관리자 워크스테이션에서 비동기 업그레이드를 시작합니다.

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async

앞의 명령어는 완료되며 업그레이드가 진행되는 동안 사용자 클러스터를 계속 사용할 수 있습니다.

업그레이드 상태를 확인하려면 다음을 실행하세요.

gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

출력에 클러스터 STATE 값이 표시됩니다. 클러스터가 업그레이드 중인 경우 STATE 값은 UPGRADING입니다. 예를 들면 다음과 같습니다.

NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.13.0-gke.1

STATE에 대해 가능한 값은 PROVISIONING, UPGRADING, DELETING ,UPDATING, RUNNING, RECONCILING, ERROR, UNKNOWN입니다.

업그레이드 진행 상태 및 클러스터 이벤트에 대한 세부정보를 확인하려면 다음을 실행합니다.

gkectl describe cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

출력에는 클러스터 상태, 조건, 이벤트가 포함된 지정된 사용자 클러스터의 OnPremUserCluster 커스텀 리소스가 표시됩니다.

Google에서는 다음을 포함하여 각 주요 업그레이드 단계의 시작과 종료에 대한 이벤트를 기록합니다.

  • ControlPlaneUpgrade
  • MasterNodeUpgrade
  • AddonsUpgrade
  • NodePoolsUpgrade

출력 예시:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

업그레이드가 완료되면 gkectl list clusterRUNNINGSTATUS가 표시됩니다.

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.13.0-gke.1

또한 업그레이드가 완료되면 gkectl describe clusterStatusLastGKEOnPremVersion 필드가 표시됩니다. 예를 들면 다음과 같습니다.

Status:
Cluster State:  RUNNING
LastGKEOnOremVersion:  1.12.0-gke.0

비동기 업그레이드 문제 해결

비동기 업그레이드의 경우 제한 시간은 클러스터의 노드 수를 기반으로 합니다. 업그레이드가 제한 시간보다 오래 걸리면 클러스터 상태가 UPGRADING에서 ERROR로 변경되고 업그레이드 작업이 시간 초과되었다는 이벤트가 표시됩니다. 여기서 ERROR 상태는 업그레이드가 예상보다 오래 걸리지만 종료되지 않았음을 의미합니다. 컨트롤러는 조정을 계속하고 작업을 계속 재시도합니다.

일반적으로 시간 초과는 PodDisruptionBudget(PDB)으로 인한 교착 상태의 결과입니다. 이 경우 포드를 이전 노드에서 제거할 수 없고 이전 노드는 드레이닝할 수 없습니다. 포드 제거가 10분 이상 걸릴 경우 OnPremUserCluster 객체에 이벤트를 기록합니다. gkectl describe cluster를 실행하여 이벤트를 캡처할 수 있습니다. 그런 다음 PDB를 조정하여 노드가 드레이닝되도록 할 수 있습니다. 그러면 업그레이드가 진행되고 완료됩니다.

예시 이벤트:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

또한 업그레이드가 차단되거나 업그레이드에 실패했을 때 gkectl diagnose를 실행하여 일반적인 클러스터 문제를 확인할 수 있습니다. 결과에 따라 수동으로 해결할지 아니면 Anthos 지원팀에 문의하여 추가 지원을 받을지 결정할 수 있습니다.

동기식 업그레이드

gkectl upgrade 명령어는 실행 전 검사를 실행합니다. 실행 전 검사가 실패하면 명령어가 차단됩니다. 실패를 바로잡거나 --skip-preflight-check-blocking 플래그를 사용해야 합니다. 심각한 실패가 없다고 확신하는 경우에만 실행 전 검사를 건너뛰어야 합니다.

관리자 워크스테이션에서 다음 단계를 진행합니다.

  1. gkectl prepare를 실행하여 OS 이미지를 vSphere로 가져옵니다.

    gkectl prepare \
     --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
     --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
  2. 사용자 클러스터 구성 파일에서 gkeOnPremVersion을 업그레이드 대상 버전으로 설정합니다.

  3. 클러스터를 업그레이드합니다.

    gkectl upgrade cluster \
     --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG_FILE
    

콘솔

콘솔을 사용하여 Anthos On-Prem API로 관리하는 사용자 클러스터를 업그레이드하지만 미리보기 업그레이드 절차를 사용해 사용자 클러스터를 업그레이드하지 않으려면 다음 단계를 수행합니다.

  1. 관리자 워크스테이션에서 다음 명령어를 실행합니다.

    gkectl prepare \
        --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
        --upgrade-platform
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터 kubeconfig 파일의 경로입니다.

    이 명령어는 관리자 클러스터에 번들을 다운로드 및 설치하고 사용자 클러스터를 관리하는 구성요소의 새 버전을 배포합니다. 이 명령어를 사용하면 콘솔에서 사용자 클러스터를 업그레이드할 수 있습니다.

  2. Google Cloud 콘솔에서 Anthos 클러스터 페이지로 이동합니다.

    Anthos 클러스터 페이지로 이동

  3. 사용자 클러스터가 있는 Cloud 프로젝트를 선택합니다.

  4. 클러스터 목록에서 업그레이드할 클러스터를 클릭합니다.

  5. 세부정보 패널에서 유형vm Anthos(VMware)이면 다음 단계를 수행하여 Google Cloud 콘솔을 사용해 클러스터를 삭제합니다.

    1. 세부정보 패널에서 추가 세부정보를 클릭합니다.

    2. 클러스터 기본사항 섹션에서 업그레이드를 클릭합니다.

    3. VMware용 Anthos 클러스터 버전 목록에서 업그레이드할 버전을 선택합니다.

    4. 업그레이드를 클릭합니다.

    유형외부이면 클러스터가 gkectl을 사용하여 생성되었음을 나타냅니다. 이 경우 명령줄 탭의 단계를 수행하여 클러스터를 업그레이드합니다.

업그레이드 재개

사용자 클러스터 업그레이드가 중단되면 --skip-validation-all 플래그로 동일한 업그레이드 명령어를 실행하여 사용자 클러스터 업그레이드를 재개할 수 있습니다.

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

관리자 클러스터 업그레이드

시작하기 전에 다음 사항을 확인하세요.

  • 인증서가 최신 상태인지 확인하고 필요한 경우 갱신합니다.

  • 버전 1.13 이상으로 업그레이드하는 경우 먼저 관리자 클러스터 구성 파일의 gkeConnect 섹션을 작성하여 관리자 클러스터를 등록해야 합니다. 구성 파일 변경사항을 사용하여 update 명령어를 실행합니다.

새 관리자 워크스테이션에서 이 섹션의 단계를 수행합니다. gkectl 및 클러스터가 업그레이드에 적합한 버전 수준인지 확인하고 적합한 번들을 다운로드했는지 확인합니다.

  1. 관리자 클러스터 구성 파일bundlepath 필드가 업그레이드할 번들의 경로와 일치하는지 확인합니다.

    관리자 클러스터 구성 파일의 필드에 다른 변경사항을 적용하는 경우 이러한 변경사항은 업그레이드 중에 무시됩니다. 이러한 변경사항을 적용하려면 먼저 클러스터를 업그레이드한 다음 구성 파일 변경사항과 함께 업데이트 명령어를 실행하여 클러스터에 변경사항을 적용해야 합니다.

  2. 다음 명령어를 실행합니다.

    gkectl upgrade admin \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
        --config ADMIN_CLUSTER_CONFIG_FILE \
        FLAGS
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터의 kubeconfig 파일입니다.

    • ADMIN_CLUSTER_CONFIG_FILE은 새 관리자 워크스테이션의 VMware용 Anthos 클러스터 관리자 클러스터 구성 파일입니다.

    • FLAGS플래그의 선택적 집합입니다. 예를 들어 --skip-validation-infra 플래그를 포함하면 vSphere 인프라 확인을 건너뛸 수 있습니다.

전체 번들을 다운로드하고 gkectl preparegkectl upgrade admin 명령어를 성공적으로 실행한 경우 이제 관리자 워크스테이션의 디스크 공간을 절약하기 위해 전체 번들을 삭제해야 합니다. 다음 명령어를 사용하세요.

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

관리자 클러스터 업그레이드 재개

관리자 클러스터 업그레이드가 중단되거나 실패하는 경우 관리자 클러스터 체크포인트에 중단 전 상태를 복원하는 데 필요한 상태가 포함되어 있으면 업그레이드를 재개할 수 있습니다.

경고: 업그레이드 시도 실패 후 gkectl repair admin-master로 관리 마스터를 복구하지 마세요. 이로 인해 관리자 클러스터가 좋지 않은 상태가 됩니다.

다음 단계를 따르세요.

  1. 초기 업그레이드 시도를 시작하기 전에 관리자 제어 영역이 정상인지 확인합니다. 클러스터 문제 진단을 참조하세요. 이 주제의 설명대로 관리자 클러스터에 gkectl diagnose cluster 명령어를 실행합니다.

  2. 초기 업그레이드 시도 전에 관리자 제어 영역이 비정상인 경우 gkectl repair admin-master 명령어로 관리자 제어 영역을 복구합니다.

  3. 업그레이드가 중단되거나 실패한 후 업그레이드 명령어를 다시 실행하는 경우 이전 업그레이드 시도와 동일한 번들 및 대상 버전을 사용하세요.

업그레이드 명령어를 다시 실행하면 재개된 업그레이드가 체크포인트에서 관리자 클러스터 상태를 다시 만들고 전체 업그레이드를 다시 실행합니다. 1.12.0부터 관리자 제어 영역이 비정상이면 업그레이드 프로세스가 업그레이드 진행 전 소스 버전에서 관리자 클러스터를 복원하려고 시도하지 않고 대상 버전으로 직접 업그레이드합니다.

관리자 클러스터 체크포인트가 사용 가능한 경우 업그레이드가 실패하거나 종료된 시점부터 업그레이드가 다시 시작됩니다. 체크포인트를 사용할 수 없는 경우 업그레이드는 관리자 제어 영역에 의존합니다. 따라서 업그레이드를 진행하려면 관리자 제어 영역이 정상 상태여야 합니다. 업그레이드가 성공하면 체크포인트가 다시 생성됩니다.

관리자 클러스터 업그레이드 중에 gkectl가 예기치 않게 종료되면 종류 클러스터가 삭제되지 않습니다. 업그레이드를 재개하기 위해 업그레이드 명령어를 다시 실행하기 전에 종류 클러스터를 삭제합니다.

docker stop gkectl-control-plane && docker rm gkectl-control-plane

종류 클러스터를 삭제한 후 업그레이드 명령어를 다시 실행합니다.

업그레이드 후 관리자 워크스테이션 롤백

관리자 워크스테이션을 업그레이드 전에 사용된 버전으로 롤백할 수 있습니다.

업그레이드하는 동안 gkeadm은 출력 정보 파일에 업그레이드되기 전 버전을 기록합니다. 롤백하는 동안 gkeadm은 나열된 버전을 사용하여 이전 파일을 다운로드합니다.

관리자 워크스테이션을 이전 버전으로 롤백하려면 다음 안내를 따르세요.

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

관리자 워크스테이션 구성 파일이 기본 admin-ws-config.yaml인 경우 --config=AW_CONFIG_FILE을 생략할 수 있습니다. 그렇지 않으면 AW_CONFIG_FILE을 관리자 워크스테이션 구성 파일의 경로로 바꿉니다.

롤백 명령어는 다음 단계를 수행합니다.

  1. gkeadm의 롤백 버전을 다운로드합니다.
  2. 현재 관리자 워크스테이션의 홈 디렉터리를 백업합니다.
  3. gkeadm의 롤백 버전을 사용하여 새 관리자 워크스테이션을 만듭니다.
  4. 기존 관리자 워크스테이션을 삭제합니다.

업그레이드를 위해 번들을 다른 버전으로 설치

워크스테이션을 업그레이드하면 해당 버전의 번들이 설치되어 클러스터를 업그레이드할 수 있습니다. 다른 버전을 원하는 경우 다음 단계를 수행하여 업그레이드하려는 버전인 TARGET_VERSION 번들을 설치합니다.

  1. 현재 gkectl 및 클러스터 버전을 확인하려면 다음 명령어를 실행합니다. 자세한 내용을 보려면 --details/-d 플래그를 사용합니다.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
    

    출력에서 클러스터 버전에 대한 정보를 제공합니다.

  2. 출력에 따라 다음 문제를 확인하고 필요에 따라 이를 수정합니다.

    • 현재 관리자 클러스터 버전이 TARGET_VERSION보다 낮은 부 버전 두 개 이상이면 모든 클러스터를 TARGET_VERSION보다 낮은 부 버전 하나로 업그레이드합니다.

    • gkectl 버전이 1.11보다 낮고 1.12.x로 업그레이드하려면 업그레이드를 여러 번 수행해야 합니다. 1.11.x에 도달할 때까지 한 번에 부 버전 하나를 업그레이드한 후 이 주제의 안내를 따라 진행합니다.

    • gkectl 버전이 TARGET_VERSION보다 낮은 경우 TARGET_VERSION으로 관리자 워크스테이션을 업그레이드합니다.

  3. gkectl 및 클러스터 버전이 업그레이드에 적합한 것으로 확인되었으면 번들을 다운로드합니다.

    번들 tarball이 관리자 워크스테이션에 이미 있는지 확인합니다.

    stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

    관리자 워크스테이션에 번들이 없으면 이를 다운로드합니다.

    gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
    

  4. 번들을 설치합니다.

    gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    ADMIN_CLUSTER_KUBECONFIG를 kubeconfig 파일의 경로로 바꿉니다. 파일이 현재 디렉터리에 있고 이름이 kubeconfig이면 이 플래그를 생략할 수 있습니다.

  5. 사용 가능한 클러스터 버전을 나열하고 대상 버전이 사용 가능한 사용자 클러스터 버전에 포함되었는지 확인합니다.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

이제 대상 버전으로 사용자 클러스터를 만들거나 사용자 클러스터를 대상 버전으로 업그레이드할 수 있습니다.

업그레이드 프로세스 문제 해결

권장 업그레이드 프로세스를 따를 때 문제가 발생하면 이러한 권장사항에 따라 문제를 해결합니다. 이러한 제안사항에서는 버전 1.11.x 설정으로 시작했고 권장 업그레이드 프로세스를 진행한다고 가정합니다.

참조: 클러스터 생성 및 업그레이드 문제 해결

사용자 클러스터 업그레이드 문제 해결

사용자 클러스터를 업그레이드할 때 업그레이드 버전에 문제가 있다고 가정해 보겠습니다. Google 지원을 통해 예정된 패치 출시 버전에서 문제가 해결될 것을 확인합니다. 이 경우 다음을 수행하면 됩니다.

  1. 프로덕션에 현재 버전을 계속 사용합니다.
  2. 패치 버전이 출시될 때 비프로덕션 클러스터에서 패치 출시 버전을 테스트합니다.
  3. 확신이 들면 모든 프로덕션 사용자 클러스터를 패치 출시 버전으로 업그레이드합니다.
  4. 관리자 클러스터를 패치 출시 버전으로 업그레이드합니다.

관리자 클러스터 업그레이드 문제 해결

관리자 클러스터를 업그레이드할 때 문제가 발생하면 Google 지원에 연락하여 관리자 클러스터 문제를 해결해야 합니다.

그러는 동안 새 업그레이드 흐름에서 관리자 클러스터 업그레이드로 방해되지 않고 새 사용자 클러스터 기능을 계속 활용할 수 있습니다. 따라서 원하는 경우 관리자 클러스터의 업그레이드 빈도를 줄일 수 있습니다. 업그레이드 프로세스는 다음과 같이 진행될 수 있습니다.

  1. 프로덕션 사용자 클러스터를 1.12.x로 업그레이드합니다.
  2. 관리자 클러스터를 이전 버전으로 유지하고 보안 패치를 계속 수신합니다.
  3. 테스트 환경에서 관리자 클러스터 1.11.x에서 1.12.x로 업그레이드를 테스트하고 문제가 있으면 문제를 보고합니다.
  4. 1.12.x 패치 출시 버전으로 문제가 해결되면 원하는 경우 프로덕션 관리자 클러스터를 이 패치 출시 버전으로 업그레이드할 수 있습니다.

최신 버전의 알려진 문제

버전 1.7 이상에서 업그레이드하는 경우 다음과 같은 알려진 문제가 업그레이드에 영향을 미칠 수 있습니다.

참조: 알려진 문제

데이터 디스크가 거의 가득 찬 경우 관리 워크스테이션 업그레이드가 실패할 수 있음

gkectl upgrade admin-workstation 명령어로 관리자 워크스테이션을 업그레이드하는 경우, 시스템이 새 관리자 워크스테이션으로 업그레이드하는 동안 현재 관리자 워크스테이션을 로컬로 백업하려고 시도하므로 데이터 디스크가 거의 가득 차면 업그레이드가 실패할 수 있습니다. 데이터 디스크의 충분한 공간을 확보할 수 없는 경우 추가 플래그 --backup-to-local=false와 함께 gkectl upgrade admin-workstation 명령어를 사용하여 현재 관리자 워크스테이션의 로컬 백업을 만들지 않도록 합니다.

PodDisruptionBudget으로 워크로드 중단

현재는 클러스터를 업그레이드하면 PodDisruptionBudget(PDB)을 사용하는 워크로드에 장애 또는 다운타임이 발생할 수 있습니다.

노드가 업그레이드 절차를 완료하지 못함

추가 중단을 허용할 수 없도록 구성된 PodDisruptionBudget 객체가 있으면 반복된 시도 후 노드 업그레이드가 제어 영역 버전으로 업그레이드되지 않을 수 있습니다. 이러한 실패를 방지하려면 PodDisruptionBudget 구성을 지키면서 노드 드레이닝을 허용하도록 Deployment 또는 HorizontalPodAutoscaler를 확장하는 것이 좋습니다.

중단을 허용하지 않는 모든 PodDisruptionBudget 객체를 보려면 다음 안내를 따르세요.

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

부록

버전 1.1.0-gke.6에서 사용 설정된 VMware DRS 규칙 정보

버전 1.1.0-gke.6부터 VMware용 Anthos 클러스터는 사용자 클러스터 노드에 대해 VMware Distributed Resource Scheduler(DRS) 안티어피니티 규칙을 자동으로 만들어 데이터 센터에 있는 최소 3개 이상의 물리적 호스트에 분산되도록 합니다. 버전 1.1.0-gke.6부터 이 기능은 새 클러스터와 기존 클러스터에서 자동으로 사용 설정됩니다.

업그레이드하기 전에 vSphere 환경은 다음 조건을 충족해야 합니다.

  • VMware DRS가 사용 설정되어 있습니다. VMware DRS에는 vSphere Enterprise Plus 라이선스 버전이 필요합니다. DRS를 사용 설정하는 방법은 클러스터에서 VMware DRS 사용 설정을 참조하세요.

  • 사용자 인증 정보 구성 파일에 제공된 vSphere 사용자 이름에는 Host.Inventory.EditCluster 권한이 있습니다.

  • 사용 가능한 물리적 호스트가 3개 이상입니다.

vSphere 환경이 위의 조건을 충족하지 않는 경우에도 업그레이드할 수 있지만 사용자 클러스터를 1.3.x에서 1.4.x로 업그레이드하려면 안티어피니티 그룹을 사용 중지해야 합니다. 자세한 내용은 VMware용 Anthos 클러스터 출시 노트에서 알려진 문제를 참조하세요.

업그레이드 중 다운타임 정보

리소스 설명
관리자 클러스터

관리자 클러스터가 다운되면 다운타임 원인이 되는 오류의 영향을 받지 않는 한 사용자 클러스터의 제어 영역과 워크로드는 사용자 클러스터에서 계속 실행됩니다.

사용자 클러스터 제어 영역

일반적으로 사용자 클러스터 제어 영역에는 뚜렷한 다운타임이 없어야 합니다. 하지만 Kubernetes API 서버로의 장기 실행 연결이 끊어져 다시 설정해야 할 수 있습니다. 이 경우 API 호출자는 연결을 설정할 때까지 다시 시도해야 합니다. 최악의 경우에는 업그레이드 중에 다운타임이 최대 1분간 발생할 수 있습니다.

사용자 클러스터 노드

업그레이드 시 사용자 클러스터 노드를 변경해야 하는 경우 VMware용 Anthos 클러스터는 노드를 롤링 방식으로 다시 만들고 이 노드에서 실행 중인 포드를 다시 예약합니다. 적절한 podDisruptionBudget안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다.

누락된 경우 정보 파일 다시 만들기

관리자 워크스테이션의 출력 정보 파일이 누락된 경우 이 파일을 다시 만들어야 업그레이드를 진행할 수 있습니다. 이 파일은 워크스테이션을 처음 만들 때 생성되었고 업그레이드를 완료한 후에 새 정보로 업데이트되었습니다.

출력 정보 파일 형식은 다음과 같습니다.

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

다음은 샘플 출력 정보 파일입니다.

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

편집기에서 파일을 만들고 적절한 매개변수를 대체합니다. gkeadm이 실행되는 디렉터리에서 VM 이름과 동일한 파일 이름으로 파일을 저장합니다. 예를 들어 VM 이름이 admin-ws-janedoe인 경우 파일을 admin-ws-janedoe로 저장합니다.