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

이 페이지에서는 VMware용 Anthos 클러스터(GKE On-Prem)를 업그레이드하는 방법을 설명합니다.

대상 버전

VMware용 Anthos 클러스터 버전 1.3.2부터는 동일한 부 출시 버전 또는 다음 부 출시 버전에 있는 모든 버전으로 직접 업그레이드할 수 있습니다. 예를 들어 1.3.2에서 1.3.5로 업그레이드하거나 1.5.2에서 1.6.1로 업그레이드할 수 있습니다.

현재 버전이 1.3.2 미만이면 먼저 버전 1.3.2에 도달하도록 순차적 업그레이드를 수행해야 합니다. 예를 들어 1.3.0에서 1.3.2로 업그레이드하려면 먼저 1.3.0에서 1.3.1로 업그레이드한 다음 1.3.1에서 1.3.2로 업그레이드해야 합니다.

버전 1.3.2 이상에서 다음 부 출시 버전에 포함되지 않는 버전으로 업그레이드하는 경우 현재 버전과 원하는 버전 사이에 각 부 출시 버전 중 하나를 통해 업그레이드해야 합니다. 예를 들어 버전 1.3.2에서 버전 1.6.1로 업그레이드하는 경우 직접 업그레이드할 수 없습니다. 먼저 버전 1.3.2에서 버전 1.4.x로 업그레이드해야 합니다. 여기서 x는 부 출시에 따른 패치 출시 버전을 나타냅니다. 그런 다음 버전 1.5.x로 업그레이드한 후 마지막으로 버전 1.6.1로 업그레이드할 수 있습니다.

업그레이드 절차 개요

  1. gkeadm 도구를 다운로드합니다. gkeadm 버전은 업그레이드 대상 버전과 동일해야 합니다.

  2. gkeadm을 사용하여 관리자 워크스테이션을 업그레이드합니다.

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

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

업그레이드 정책

관리자 클러스터를 업그레이드한 후 다음을 확인하세요.

  • 새로 만드는 모든 사용자 클러스터는 관리자 클러스터와 동일한 버전이어야 합니다.

  • 기존 사용자 클러스터를 업그레이드하는 경우 관리자 클러스터와 동일한 버전으로 업그레이드해야 합니다.

  • 관리자 클러스터를 다시 업그레이드하기 전에 모든 사용자 클러스터를 현재 관리자 클러스터와 동일한 버전으로 업그레이드해야 합니다.

구성 및 정보 파일 찾기

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

현재 관리자 워크스테이션을 만들 때 gkeadm으로 정보 파일을 만들었습니다. 이 파일의 기본 이름은 현재 관리자 워크스테이션의 이름과 동일합니다.

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

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

관리자 워크스테이션을 업그레이드하려면 먼저 gkeadm 도구의 새 버전을 다운로드한 후 이를 사용하여 관리자 워크스테이션의 구성을 업그레이드합니다. gkeadm 버전은 업그레이드 대상 버전과 일치해야 합니다.

gkeadm 다운로드

적절한 gkeadm 버전을 다운로드하려면 다운로드 페이지의 안내를 따르세요.

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

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

각 항목의 의미는 다음과 같습니다.

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

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

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

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

    • VMware용 Anthos 클러스터 구성 파일. 이 파일의 기본 이름은 config.yaml입니다.

    • 관리자 클러스터 및 사용자 클러스터의 kubeconfig 파일

    • vCenter Server의 루트 인증서. 이 파일에는 소유자 읽기 및 소유자 쓰기 권한이 있어야 합니다.

    • 구성요소 액세스 서비스 계정의 JSON 키 파일입니다. 이 파일에는 소유자 읽기 및 소유자 쓰기 권한이 있어야 합니다.

    • 연결-등록, 연결 에이전트, 로깅 모니터링 서비스 계정의 JSON 키 파일.

  • 새 관리자 워크스테이션을 만들고 백업된 모든 파일을 새 관리자 워크스테이션에 복사합니다.

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

노드 OS 이미지 및 Docker 이미지 업데이트

새 관리자 워크스테이션에서 다음 명령어를 실행하세요.

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

각 항목의 의미는 다음과 같습니다.

  • [ADMIN_CONFIG]는 관리자 클러스터 구성 파일의 경로입니다.

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

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

  • 필요한 경우 새 노드 OS 이미지를 vSphere 환경에 복사하고 OS 이미지를 템플릿으로 표시합니다.

  • 비공개 Docker 레지스트리를 구성한 경우 비공개 Docker 레지스트리에 업데이트된 Docker 이미지를 푸시합니다.

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

새 관리자 워크스테이션에서 이 섹션의 단계를 수행합니다.

업그레이드하기 전에 클러스터에 사용할 수 있는 IP 주소가 충분한지 확인합니다.

DHCP

관리자 클러스터를 업그레이드하면 VMware용 Anthos 클러스터가 관리자 클러스터에 임시 노드 하나를 만듭니다. 사용자 클러스터를 업그레이드하면 VMware용 Anthos 클러스터가 해당 사용자 클러스터에 임시 노드를 만듭니다. 임시 노드의 목적은 무중단 가용성을 보장하기 위함입니다. 클러스터를 업그레이드하기 전에 DHCP 서버가 임시 노드에 IP 주소를 충분하게 제공할 수 있는지 확인합니다. 자세한 내용은 관리자 및 사용자 클러스터에 필요한 IP 주소를 참조하세요.

고정 IP

관리자 클러스터를 업그레이드하면 VMware용 Anthos 클러스터가 관리자 클러스터에 임시 노드 하나를 만듭니다. 사용자 클러스터를 업그레이드하면 VMware용 Anthos 클러스터가 해당 사용자 클러스터에 임시 노드를 만듭니다. 임시 노드의 목적은 무중단 가용성을 보장하기 위함입니다. 클러스터를 업그레이드하기 전에 IP 주소가 충분하게 예약되어 있는지 확인합니다. 클러스터마다 클러스터 노드 수보다 최소 하나 이상 많게 IP 주소를 예약해야 합니다. 자세한 내용은 고정 IP 주소 구성을 참조하세요.

관리자 클러스터에서 노드 수를 확인합니다.

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.

그런 다음 관리자 클러스터용으로 예약된 주소를 확인합니다.

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

출력의 reservedAddresses 필드에서 관리자 클러스터 노드용으로 예약된 IP 주소 수를 확인할 수 있습니다. 예를 들어 다음 출력에서는 관리자 클러스터 노드용으로 예약된 IP 주소 5개를 보여줍니다.

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

예약된 IP 주소의 수는 관리자 클러스터의 노드 수보다 최소 2개 이상 많아야 합니다. 그렇지 않으면 클러스터 객체를 수정하여 주소를 추가로 예약할 수 있습니다.

수정할 클러스터 객체를 엽니다.

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

reservedAddresses에서 gateway, hostname, ip, netmask가 있는 블록을 추가합니다.

사용자 클러스터의 노드 수를 확인하려면 다음을 실행합니다.

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

여기서 [USER_CLUSTER_KUBECONFIG]는 사용자 클러스터의 kubeconfig 파일 경로입니다.

사용자 클러스터용으로 예약된 주소를 보려면 다음을 실행합니다.

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

각 항목의 의미는 다음과 같습니다.

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

  • [USER_CLUSTER_NAME]은 사용자 클러스터 이름입니다.

예약된 IP 주소의 수는 사용자 클러스터의 노드 수보다 최소 2개 이상 많아야 합니다. 그렇지 않으면 다음 단계를 수행합니다.

  • 수정할 사용자 클러스터의 IP 블록 파일을 엽니다.

  • 블록에 IP 주소를 추가하고 파일을 닫습니다.

  • 사용자 클러스터를 업데이트합니다.

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
      --config [USER_CLUSTER_CONFIG]
    

(선택사항) 새로운 vSphere 기능 사용 중지

새 VMware용 Anthos 클러스터 버전에는 특정 VMware vSphere 기능에 대한 새로운 기능이나 지원이 포함될 수 있습니다. 경우에 따라 VMware용 Anthos 클러스터 버전으로 업그레이드하면 이러한 기능이 자동으로 사용 설정됩니다. 새로운 기능은 VMware용 Anthos 클러스터의 출시 노트를 참조하세요. 새 기능은 VMware용 Anthos 클러스터 구성 파일에 표시되기도 합니다.

새 VMware용 Anthos 클러스터 버전에서 자동으로 사용 설정되고 구성 파일에 의해 구동되는 새 기능을 사용 중지해야 하는 경우 클러스터를 업그레이드하기 전에 다음 단계를 수행합니다.

  1. 업그레이드된 관리자 워크스테이션에서 현재 구성 파일과 다른 이름으로 새 구성 파일을 만듭니다.

    gkectl create-config --config [CONFIG_NAME]
  2. 새 구성 파일을 열고 기능의 필드를 기록해 둡니다. 파일을 닫습니다.

  3. 현재 구성 파일을 열고 새 기능의 필드를 추가합니다. 필드 값을 false 또는 이에 상응하는 값으로 설정합니다.

  4. 구성 파일을 저장합니다.

클러스터를 업그레이드하기 전에 출시 노트를 검토합니다. 기존 클러스터 구성을 업그레이드한 후에는 선언적으로 변경할 수 없습니다.

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

새 관리자 워크스테이션에서 이 섹션의 단계를 수행합니다.

업그레이드 대상 버전은 gkeadm 버전과 동일해야 합니다.

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

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

각 항목의 의미는 다음과 같습니다.

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

  • 여기서 [ADMIN_CLUSTER_CONFIG_FILE]은 관리자 클러스터 구성 파일의 경로입니다.

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

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

새 관리자 워크스테이션에서 이 섹션의 단계를 수행합니다.

업그레이드 대상 버전은 gkeadm 버전과 동일해야 합니다.

gkectl

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

각 항목의 의미는 다음과 같습니다.

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

  • [USER_CLUSTER_CONFIG_FILE]는 사용자 클러스터 구성 파일의 경로입니다.

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

Console

설치 중 또는 사용자 클러스터를 만든 후에 Google Cloud 콘솔을 사용하여 사용자 클러스터를 등록할 수 있습니다. Google Cloud 콘솔에서 등록된 Anthos 클러스터와 GKE 클러스터를 보고 로그인할 수 있습니다.

사용 클러스터에 업그레이드를 사용할 수 있게 되면 Google Cloud 콘솔에 알림이 표시됩니다. 이 알림을 클릭하면 사용 가능한 버전 목록과 클러스터를 업그레이드하는 데 실행할 수 있는 gkectl 명령어가 표시됩니다.

  1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine 페이지로 이동

  2. 사용자 클러스터의 알림 열에서 업그레이드 사용 가능을 클릭합니다.

  3. gkectl upgrade cluster 명령어를 복사합니다.

  4. 관리자 워크스테이션에서 gkectl upgrade cluster 명령어를 실행합니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터 kubeconfig 파일의 경로이며 [CLUSTER_NAME]은 업그레이드 중인 사용자 클러스터의 이름입니다. [USER_CLUSTER_CONFIG_FILE]은 사용자 클러스터 구성 파일의 경로입니다.

업그레이드 재개

사용자 클러스터 업그레이드가 중단된 경우 --skip-validation-all 플래그와 함께 동일한 업그레이드 명령어를 실행하면 업그레이드가 다시 시작될 수 있습니다.

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

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

관리자 클러스터 업그레이드를 중단해서는 안 됩니다. 관리자 클러스터 업그레이드를 항상 다시 시작할 수 있는 것은 아닙니다. 이유에 관계없이 관리자 클러스터 업그레이드가 중단되면 지원팀에 도움을 요청해야 합니다.

업그레이드 후 새로운 사용자 클러스터 만들기

관리자 워크스테이션 및 관리자 클러스터를 업그레이드한 후에는 새로 만드는 모든 사용자 클러스터가 업그레이드 대상 버전과 동일해야 합니다.

VMware DRS 규칙

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

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

  • VMware DRS가 사용 설정되어 있습니다. VMware DRS에는 vSphere Enterprise Plus 라이선스 버전이 필요합니다. DRS를 사용 설정하는 방법은 클러스터에서 VMware DRS 사용 설정을 참조하세요.
  • vcenter 필드에 제공된 vSphere 사용자 계정에는 Host.Inventory.EditCluster 권한이 포함됩니다.
  • 사용 가능한 물리적 호스트가 3개 이상입니다.

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

다운타임

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

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

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

사용자 클러스터 제어 영역

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

사용자 클러스터 노드

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

알려진 문제

알려진 문제를 참조하세요.

문제 해결

클러스터 생성 및 업그레이드 문제 해결을 참조하세요.