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

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

업그레이드 절차 개요

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

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

인그레스가 사용 설정된 사용자 클러스터를 버전 1.7에서 1.8로 업그레이드하는 경우 인그레스 마이그레이션을 참조하세요.

먼저 관리자 워크스테이션을 업그레이드한 후 사용자 클러스터를 업그레이드하고 마지막으로 관리자 클러스터를 업그레이드합니다. 관리자 클러스터를 현재 버전으로 유지하려면 사용자 클러스터를 업그레이드한 후 즉시 관리자 클러스터를 업그레이드할 필요가 없습니다.

  1. gkeadm 도구를 다운로드합니다. gkeadm 버전은 업그레이드 대상 버전과 동일해야 합니다.
  2. 관리자 워크스테이션을 업그레이드합니다.
  3. 관리자 워크스테이션에서 사용자 클러스터를 업그레이드합니다.
  4. 관리자 워크스테이션에서 관리자 클러스터를 업그레이드합니다.

관리자 워크스테이션, 관리자 클러스터, 사용자 클러스터가 현재 1.7.x 버전을 사용하고 있고 관리자 클러스터와 사용자 클러스터를 모두 1.8.x 버전으로 업그레이드한다고 가정해 보겠습니다. 계속 진행하기 전 테스트용으로 카나리아 클러스터를 사용해서 다음과 같은 업그레이드 경로를 따를 경우 중단 위험을 최소화할 수 있습니다.

다음은 권장 업그레이드 프로세스에 대한 간략한 개요입니다. 시작하기 전에 버전 1.7.x를 사용하는 카나리아 사용자 클러스터를 아직 만들지 않았으면 만듭니다.

  1. 카나리아 클러스터에서 버전 1.8.x를 테스트합니다.
    • 관리자 워크스테이션을 버전 1.8.x로 업그레이드합니다.
    • 뒤에 설명된 것처럼 gkectl prepare 명령어를 실행하여 업그레이드를 설정합니다.
      • 카나리아 사용자 클러스터를 버전 1.8.x로 업그레이드합니다.
  2. 버전 1.8.x에 확신이 있는 경우 모든 프로덕션 사용자 클러스터를 버전 1.8.x로 업그레이드합니다.
  3. 관리자 클러스터를 버전 1.8.x로 업그레이드합니다.

업그레이드 준비를 위해 구성 및 정보 파일 찾기

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

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

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

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

gkectl 및 클러스터가 업그레이드에 적합한 버전 수준인지 확인하고 적합한 번들을 다운로드했는지 확인합니다.

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

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 키 파일.

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

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

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

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

업그레이드하기 전에 클러스터에 사용할 수 있는 IP 주소가 충분한지 확인합니다. 각 DHCP 및 정적 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개 이상 많아야 합니다.

1.7 버전의 경우 관리자 클러스터에 IP 주소를 추가합니다.

먼저 다음 예시에 표시된 것처럼 IP 블록 파일을 수정합니다.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

그런 후 이 명령어를 실행하여 구성을 업데이트합니다.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]
  • 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 kubeconfig 파일의 경로입니다.

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

IP 주소는 삭제할 수 없고 추가만 가능합니다.

1.7 이전 버전의 경우 클러스터 객체를 직접 수정하여 추가 주소를 추가할 수 있습니다.

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

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

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

중요: 1.5.0부터는 사용자 클러스터에서 동일한 절차가 작동하지 않으며 각 클러스터에 gkectl update cluster를 사용해야 합니다.

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

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 블록 파일에 포함된 경우 netmaskgateway에 따라 해당 블록에 주소를 추가합니다.

  • 필요에 따라 해당 블록에 추가 고정 IP 주소를 최대한 많이 추가한 후 gkectl update cluster를 실행합니다.

업그레이드를 위한 번들 설치

버전을 클러스터 만들기 또는 업그레이드에 사용할 수 있게 하려면 해당 버전을 설치해야 합니다. 다음 단계에 따라 업그레이드할 버전 번호에 해당하는 TARGET_VERSION에 대한 번들을 설치합니다.

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

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

출력 예시는 다음과 같습니다.

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

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

  • gkectl 버전이 1.7보다 낮으면 새 업그레이드 흐름을 직접 사용할 수 없습니다. 원래 업그레이드 흐름에 따라 모든 클러스터를 1.6으로 업그레이드한 후 관리자 워크스테이션을 1.7로 업그레이드하여 새 업그레이드 흐름을 사용하기 시작합니다.

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

  • gkectl 버전이 TARGET_VERSION보다 낮으면 안내에 따라 관리자 워크스테이션을 TARGET_VERSION으로 업그레이드합니다.

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/

번들을 설치합니다.

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

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

  • 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 kubeconfig 파일의 경로입니다. 파일이 현재 디렉터리에 있고 이름이 kubeconfig이면 이 플래그를 생략할 수 있습니다.

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

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

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

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

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

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

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

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

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

업그레이드 재개

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

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

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

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

업그레이드 대상 버전은 gkectl 버전보다 높지 않아야 하고 gkectl 버전보다 부 버전이 하나만 낮아야 합니다. 따라서 gkectl 버전이 1.7인 경우에 가능한 업그레이드 대상 버전은 1.6.x부터 1.7까지입니다. 모든 사용자 클러스터가 해당 부 버전으로 업그레이드된 경우 관리자 클러스터는 부 버전으로만 업그레이드될 수 있습니다. 예를 들어 1.6.2 사용자 클러스터가 아직 있을 때 관리자 클러스터를 1.7 버전으로 업그레이드하려고 시도하면 오류가 발생합니다.

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

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

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 인프라 확인을 건너뛸 수 있습니다. --force-upgrade-admin 플래그를 사용하여 관리자 클러스터를 먼저 업데이트한 후 사용자 클러스터를 업데이트하는 이전 업그레이드 흐름으로 되돌립니다.

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

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

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

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

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

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

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

카나리아 클러스터를 테스트하거나 사용자 클러스터를 업그레이드할 때 1.7에서 문제가 발견되었다고 가정해보세요. Google 지원을 통해 문제가 앞으로 출시될 패치 릴리스 1.7.x에서 수정된다는 것을 확인합니다. 이 경우 다음을 수행하면 됩니다.

  1. 프로덕션에 계속 1.6.2를 사용합니다.
  2. 1.7.x 패치 출시 버전이 출시되면 이를 카나리아 클러스터에서 테스트합니다.
  3. 확신이 들면 모든 프로덕션 사용자 클러스터를 1.7.x로 업그레이드합니다.
  4. 관리자 클러스터를 1.7.x로 업그레이드합니다.

1.7을 테스트할 때 1.6.x 패치 출시 버전 관리

1.7 테스트 또는 마이그레이션을 진행하고 있지만 아직 확신할 수 없고 관리자 클러스터에는 아직 1.6.2가 사용된다고 가정해보세요. 그리고 중요 1.6.x 패치 출시 버전이 출시된 것이 확인되었습니다. 1.7을 계속 테스트하면서 이 1.6.x 패치 출시 버전을 활용할 수 있습니다. 이 업그레이드 절차를 수행합니다.

  1. 1.6.x-gke.0 번들을 설치합니다.
  2. 모든 1.6.2 프로덕션 사용자 클러스터를 1.6.x로 업그레이드합니다.
  3. 관리자 클러스터를 1.6.x로 업그레이드합니다.

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

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

그러는 동안 새 업그레이드 흐름에서 관리자 클러스터 업그레이드로 방해되지 않고 새 사용자 클러스터 기능을 계속 활용할 수 있습니다. 따라서 원하는 경우 관리자 클러스터의 업그레이드 빈도를 줄일 수 있습니다. 예를 들어 1.7 버전으로 출시된 Container-Optimized OS 노드 풀을 사용할 수 있습니다. 업그레이드 프로세스는 다음과 같이 진행될 수 있습니다.

  1. 프로덕션 사용자 클러스터를 1.7로 업그레이드합니다.
  2. 관리자 클러스터를 1.6으로 유지하고 보안 패치 수신을 계속합니다.
  3. 테스트 환경에서 1.6에서 1.7로의 관리자 클러스터 업그레이드를 테스트하고 문제가 있으면 이를 보고합니다.
  4. 1.7 패치 출시 버전으로 문제가 해결되면 필요에 따라 1.6에서 이 1.7 패치 출시 버전으로 프로덕션 관리자 클러스터를 업그레이드하도록 선택할 수 있습니다.

알려진 문제

다음은 클러스터 업그레이드에 영향을 미치는 알려진 문제입니다.

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

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

버전 1.7.0: Anthos Config Management 업데이트 변경사항

1.7.0 이전 버전에서는 VMware용 Anthos 클러스터에 Anthos Config Management를 설치하고 업그레이드하는 데 필요한 이미지가 포함되었습니다. 1.7.0부터 Anthos Config Management 소프트웨어가 VMware용 Anthos 클러스터 번들에 포함되지 않으므로 별도로 추가해야 합니다. 이전에 클러스터 또는 클러스터의 Anthos Config Management를 사용하고 있던 경우 조치를 취할 때까지 소프트웨어가 업그레이드되지 않습니다.

Anthos Config Management 설치에 대한 자세한 내용은 Anthos Config Management 설치를 참조하세요.

버전 1.1.0-gke.6, 1.2.0-gke.6: stackdriver.proxyconfigsecretname 필드 삭제됨

버전 1.1.0-gke.6에서 stackdriver.proxyconfigsecretname 필드가 삭제되었습니다. VMware용 Anthos 클러스터의 실행 전 검사는 필드가 구성 파일에 있으면 오류를 반환합니다.

이 문제를 해결하려면 1.2.0-gke.6으로 업그레이드하기 전에 구성 파일에서 proxyconfigsecretname 필드를 삭제합니다.

Stackdriver는 이전 버전 참조

버전 1.2.0-gke.6 이전의 알려진 문제로 인해 클러스터 업그레이드 후에 Stackdriver가 구성을 업데이트할 수 없습니다. Stackdriver는 여전히 이전 버전을 참조하므로 Stackdriver가 원격 분석 파이프라인의 최신 기능을 수신하지 못합니다. 이 문제로 인해 Google 지원에서 클러스터 문제를 해결하기가 어려워질 수 있습니다.

클러스터를 1.2.0-gke.6으로 업그레이드한 후에 관리자 클러스터와 사용자 클러스터에 다음 명령어를 실행합니다.

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

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

PodDisruptionBudget으로 워크로드 중단

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

버전 1.2.0-gke.6: 업그레이드 후 Prometheus 및 Grafana의 사용이 중지됨

사용자 클러스터에서는 업그레이드 중에 Prometheus와 Grafana의 사용이 자동으로 중지됩니다. 하지만 구성과 측정항목 데이터는 손실되지 않습니다. 관리자 클러스터에서는 Prometheus와 Grafana가 계속 사용됩니다.

자세한 내용은 VMware용 Anthos 클러스터 출시 노트를 참조하세요.

버전 1.1.2-gke.0: 삭제된 사용자 클러스터 노드는 vSAN Datastore에서 삭제되지 않음

자세한 내용은 VMware용 Anthos 클러스터 출시 노트를 참조하세요.

버전 1.1.1-gke.2: vSAN Datastore 폴더의 데이터 디스크 삭제 가능

vSAN Datastore를 사용하는 경우 VMDK를 저장할 폴더를 만들어야 합니다. 알려진 문제로 인해 파일 경로 대신 폴더의 범용 고유 식별자(UUID) 경로를 vcenter.datadisk에 제공해야 합니다. 이러한 불일치로 인해 업그레이드가 실패할 수 있습니다.

자세한 내용은 VMware용 Anthos 클러스터 출시 노트를 참조하세요.

버전 1.0.2-gke.3에서 버전 1.1.0-gke.6으로 업그레이드: OIDC 문제

OpenID Connect(OIDC)가 구성된 1.0.11, 1.0.1-gke.5, 1.0.2-gke.3 버전의 클러스터는 버전 1.1.0-gke.6으로 업그레이드될 수 없습니다. 이 문제는 버전 1.1.1-gke.2에서 해결되었습니다.

설치 중에 OIDC를 사용하여 1.0.11, 1.0.1-gke.5 또는 1.0.2-gke.3 클러스터를 구성한 경우에는 업그레이드할 수 없습니다. 대신 새 클러스터를 만들어야 합니다.

버전 1.0.11에서 버전 1.0.2-gke.3으로 업그레이드

버전 1.0.2-gke.3에는 다음 OIDC 필드(usercluster.oidc)가 도입되었습니다. 이러한 필드를 통해 Google Cloud 콘솔에서 클러스터에 로그인할 수 있습니다.

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

OIDC를 사용하려면 Google Cloud 콘솔에서 클러스터에 로그인하지 않더라도 clientsecret 필드가 필요합니다. OIDC를 사용하려면 clientsecret의 자리표시자 값을 제공해야 할 수 있습니다.

oidc:
  clientsecret: "secret"

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

추가 중단을 허용할 수 없도록 구성된 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안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다.

알려진 문제

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

문제 해결

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