버전 1.1. 이 버전은 Anthos 버전 지원 정책에 설명된 대로 더 이상 지원되지 않습니다. VMware용 Anthos 클러스터(GKE On-Prem)에 영향을 미치는 보안 취약점, 노출, 문제에 대한 최신 패치와 업데이트를 확인하려면 지원되는 버전으로 업그레이드하세요. 최신 버전은 여기에서 확인할 수 있습니다.

사용 가능한 버전

GKE On-Prem 업그레이드

이 주제에서는 GKE On-Prem을 업그레이드하는 방법을 설명합니다.

GKE On-Prem을 업그레이드하려면 관리자 워크스테이션을 업그레이드합니다. 그런 다음 클러스터를 업그레이드합니다.

시작하기 전에

로컬 워크스테이션 또는 노트북에서 다음 안내를 따르세요. 기존 관리 워크스테이션의 안내를 따르지 마세요.
클러스터의 현재 버전을 확인합니다.
출시 노트를 검토합니다.
버전을 검토합니다.

다음 고려사항도 검토합니다.

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

리소스	설명
관리자 클러스터	관리자 클러스터가 다운되면 다운타임을 유발한 오류의 영향을 받지 않는 한 사용자 클러스터 제어 영역과 워크로드는 사용자 클러스터에서 계속 실행됩니다.
사용자 클러스터 제어 영역	일반적으로 사용자 클러스터 제어 영역에는 뚜렷한 다운타임이 없어야 합니다. 하지만 Kubernetes API 서버로의 장기 실행 연결이 끊어져 다시 설정해야 할 수 있습니다. 이 경우 API 호출자는 연결을 설정할 때까지 다시 시도해야 합니다. 최악의 경우에는 업그레이드 중에 다운타임이 최대 1분간 발생할 수 있습니다. 참고: 사용자 클러스터 노드가 업그레이드 중에 사용자 제어 영역에 도달할 수 없으면 새 워크로드는 클러스터에 예약되지 않습니다. 기존 워크로드는 영향을 받지 않습니다.
사용자 클러스터 노드	업그레이드 시 사용자 클러스터 노드를 변경해야 하는 경우 GKE On-Prem은 노드를 롤링 방식으로 다시 만들고 이 노드에서 실행 중인 pod를 다시 예약합니다. 적절한 podDisruptionBudget과 안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다.

순차적 업그레이드

GKE On-Prem은 순차적 업그레이드를 지원합니다. 클러스터를 새 버전으로 업그레이드하려면 클러스터가 이미 최신 버전이어야 합니다.

두 버전 이상 낮은 버전에서 최신 버전으로 클러스터를 직접 업그레이드할 수 없습니다. 클러스터 버전이 두 버전 이상 낮으면 순차적으로 클러스터를 업그레이드해야 합니다.

예시

다음 버전을 사용할 수 있고 관리자 워크스테이션과 클러스터에서 가장 오래된 버전을 실행한다고 가정해 보겠습니다.

1.0.1(가장 오래된 버전)
1.0.2
1.1(최신 버전)

이 경우 1.1이 최신 버전입니다. 1.0.1에서 1.1로 업그레이드하려면 다음 단계를 따르세요.

관리자 워크스테이션을 1.0.1에서 1.0.2로 업그레이드합니다.
클러스터를 1.0.1에서 1.0.2로 업그레이드합니다.
관리자 워크스테이션을 1.0.2에서 1.1로 업그레이드합니다.
클러스터를 1.0.2에서 1.1로 업그레이드합니다.

GKE On-Prem 구성 파일 및 kubeconfig 파일 백업

관리자 워크스테이션을 업그레이드하면 Terraform은 관리자 워크스테이션 VM을 삭제하고 업그레이드된 관리자 워크스테이션으로 바꿉니다. 관리자 워크스테이션을 업그레이드하기 전에 GKE On-Prem 구성 파일과 클러스터의 kubeconfig 파일을 백업해야 합니다. 나중에 파일을 업그레이드된 관리자 워크스테이션에 복사합니다.

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

관리자 워크스테이션을 업그레이드하면 관리자 워크스테이션의 Open Virtualization Appliance(OVA) 파일과 동일한 버전의 다음 항목이 포함됩니다.

gkectl
전체 번들

관리자 워크스테이션을 업그레이드하면 클러스터를 업그레이드합니다.

OVA 다운로드

다운로드에서 업그레이드할 버전의 관리 워크스테이션 OVA 파일을 다운로드합니다.

최신 OVA를 다운로드하려면 다음 명령어를 실행합니다.

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

OVA를 vSphere로 가져와 VM 템플릿으로 표시

다음 섹션에서는 다음을 수행합니다.

vCenter Server와 vSphere 환경의 요소를 선언하는 일부 변수를 만듭니다.
관리자 워크스테이션 OVA를 vSphere로 가져와 VM 템플릿으로 표시합니다.

`govc`용 변수 만들기

관리자 워크스테이션 OVA를 vSphere로 가져오기 전에 vCenter Server와 vSphere 환경의 요소를 선언하는 일부 govc 변수를 제공해야 합니다.

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

vSphere의 기본 리소스 풀을 사용하거나 자체 리소스 풀을 만들 수 있습니다.

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

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

[VCENTER_SERVER_ADDRESS]는 vCenter Server의 IP 주소 또는 호스트 이름입니다.
[VCENTER_SERVER_USERNAME]은 vCenter Server의 관리자 역할 또는 동등한 권한을 보유한 계정의 사용자 이름입니다.
[VCENTER_SERVER_PASSWORD]는 vCenter Server 계정의 비밀번호입니다.
[VSPHERE_DATASTORE]는 vSphere 환경에서 구성한 Datastore의 이름입니다.
[VSPHERE_DATACENTER]는 vSphere 환경에서 구성한 데이터센터의 이름입니다.
[VSPHERE_CLUSTER]는 vSphere 환경에서 구성한 클러스터의 이름입니다.
[VSPHERE_RESOURCE_POOL]은 vSphere 환경에 구성한 리소스 풀의 이름입니다.

OVA를 vSphere로 가져오기: 표준 스위치

vSphere 표준 스위치를 사용하는 경우 다음 명령어를 사용하여 OVA를 vSphere로 가져옵니다.

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

OVA를 vSphere로 가져오기: 분산 스위치

vSphere 분산 스위치를 사용하는 경우 이 명령어를 사용하여 OVA를 vSphere로 가져옵니다. 여기서 [YOUR_DISTRIBUTED_PORT_GROUP_NAME]은 분산 포트 그룹의 이름입니다.

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

새 관리 워크스테이션 VM의 Terraform 템플릿 변수 설정

관리 워크스테이션의 TFVARS 파일에서 vm_template을 업그레이드할 버전으로 설정합니다. vm_template 값은 다음과 같습니다. 여기서 [VERSION]은 OVA의 버전입니다.

gke-on-prem-admin-appliance-vsphere-[VERSION]

Terraform을 사용하여 관리 워크스테이션 업그레이드

관리 워크스테이션을 업그레이드하려면 다음 명령어를 실행합니다. 이 명령어는 현재 관리 워크스테이션 VM을 삭제하고 업그레이드된 VM으로 바꿉니다.

terraform init && terraform apply -auto-approve -input=false

관리자 워크스테이션에 연결

관리 워크스테이션에 SSH를 통해 연결

ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

프록시를 사용하는 경우 gcloud 및 gsutil 명령어를 실행할 수 있도록 프록시에 Google Cloud CLI를 구성해야 합니다. 자세한 내용은 gcloud CLI를 프록시/방화벽 뒤에서 사용할 수 있도록 구성을 참조하세요.
계정 사용자 인증 정보를 사용하여 Google Cloud에 로그인합니다.
```
gcloud auth login
```
gcloud를 Docker 사용자 인증 정보 도우미로 등록합니다. (이 명령어에 대해 자세히 알아보기)
```
gcloud auth configure-docker
```
허용 목록에 포함된 서비스 계정에 대해 비공개 키를 만듭니다.

서비스 계정의 이메일 주소를 복사합니다.
```
gcloud iam service-accounts list
```
서비스 계정의 비공개 키를 만듭니다. 여기서 [KEY_FILE]은 파일에 선택한 이름입니다. 이 명령어는 파일을 현재의 작업 디렉터리에 저장합니다.
```
gcloud iam service-accounts keys create key.json \
--project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
```
각 항목의 의미는 다음과 같습니다.
- [PROJECT_ID]는 프로젝트 ID입니다.
- [KEY_FILE]은 서비스 계정의 비공개 키(예: /home/ubuntu/key.json)를 저장할 이름과 경로입니다.
- [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]은 허용 목록에 포함된 서비스 계정의 이메일 주소입니다.
허용 목록에 포함된 서비스 계정을 활성화하려면 다음을 실행합니다.
```
gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [KEY_FILE]
```

백업된 구성 및 kubeconfig 파일 복사

앞에서 GKE On-Prem 구성 파일과 클러스터의 kubeconfig 파일을 백업했습니다. 이제 이러한 파일을 업그레이드된 관리자 워크스테이션에 다시 복사해야 합니다.

클러스터 업그레이드

관리 워크스테이션을 업그레이드하고 연결하면 다음 단계를 수행합니다.

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

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

DHCP

클러스터에 DHCP 서버에서 할당한 IP 주소가 있는 경우 노드가 생성된 네트워크의 DHCP 서버에 충분한 IP 주소가 있는지 확인합니다. 사용자 클러스터에서 실행 중인 노드보다 더 많은 IP 주소가 있어야 합니다.

고정 IP

클러스터에 고정 IP 주소가 있는 경우 클러스터에 IP 주소가 충분히 할당되었는지 확인합니다.

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

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

[ADMIN_CLUSTER_KUBECONFIG]는 kubectl에 사용자 클러스터 구성을 보거나 변경하는 데 사용되는 관리자 클러스터의 kubeconfig를 사용하도록 지시합니다.
-n [USER_CLUSTER_NAME]는 kubectl에 사용자 클러스터 이름이 지정된 네임스페이스를 살펴보도록 지시합니다.
[USER_CLUSTER_NAME] -o yaml은 명령어를 실행 중인 사용자 클러스터를 kubectl에 알려줍니다. -o yaml은 사용자 클러스터의 구성을 표시합니다.

명령어 출력에서 reservedAddresses 필드를 찾습니다. 사용자 클러스터에서 실행 중인 노드보다 필드에 더 많은 IP 주소가 있어야 합니다.

reservedAddresses 필드에 주소를 더 추가해야 하는 경우 다음 단계를 수행하세요.

수정을 위해 사용자 클러스터의 구성 파일을 엽니다.
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME] --validate=false
```
클러스터 구성은 셸의 기본 편집기에서 열립니다.
고정 IP 블록을 필요한 만큼 추가합니다. IP 블록은 gateway, hostname, ip, netmask 필드로 구성됩니다.
참고: reservedAddresses 필드에 IP 블록을 더 추가하는 것은 항상 안전하지만 사용 중인 IP 주소를 삭제하는 것은 안전하지 않습니다.

다음은 4개의 고정 IP 블록이 있는 reservedAddresses 필드를 강조표시한 예시입니다.

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

구성 파일 수정

관리자 워크스테이션 VM에서 구성 파일을 수정합니다. bundlepath 값을 설정합니다. 여기서 [VERSION]는 클러스터를 업그레이드할 GKE On-Prem 버전입니다.

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

자동으로 사용 설정된 기능 정보

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

구성 파일을 통해 새 기능 중지

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

업그레이드된 관리자 워크스테이션에서 현재 구성 파일과 다른 이름으로 새 구성 파일을 만듭니다.
```
gkectl create-config --config [CONFIG_NAME]
```
새 구성 파일과 기능의 필드를 엽니다. 파일을 닫습니다.
현재 구성 파일을 열고 해당 사양에 새 기능의 필드를 추가합니다.
필드에 false 또는 해당 값을 입력합니다.
구성 파일을 저장합니다. 클러스터 업그레이드를 진행합니다.

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

`gkectl prepare` 실행

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

gkectl prepare --config [CONFIG_FILE]

gkectl prepare 명령어는 다음 태스크를 수행합니다.

필요한 경우 새 노드 OS 이미지를 vSphere 환경에 복사하고 OS 이미지를 템플릿으로 표시합니다.
새 번들에 지정된 업데이트된 Docker 이미지를 비공개 Docker 레지스트리로 푸시합니다(구성한 경우).

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

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

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일이고 [CONFIG_FILE]은 업그레이드를 수행하는 데 사용하는 GKE On-Prem 구성 파일입니다.

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

사용자 클러스터를 업그레이드하려면 관리자 클러스터의 버전이 사용자 클러스터 업그레이드의 대상 버전보다 높아야 합니다. 관리자 클러스터 버전이 높지 않다면 사용자 클러스터를 업그레이드하기 전에 관리자 클러스터를 업그레이드하세요.

gkectl

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

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일이고 [CLUSTER_NAME]은 업그레이드하는 사용자 클러스터의 이름입니다. [CONFIG_FILE]은 업그레이드를 수행하는 데 사용하는 GKE On-Prem 구성 파일입니다.

Console

설치 중 또는 사용자 클러스터를 만든 후에 Cloud Console을 사용하여 사용자 클러스터를 등록할 수 있습니다. Cloud Console의 GKE 메뉴에서 등록된 GKE On-Prem 클러스터와 Google Kubernetes Engine 클러스터를 확인하고 로그인할 수 있습니다.

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

Cloud Console에서 GKE 메뉴로 이동합니다.

GKE On-Prem 메뉴로 이동하기
사용자 클러스터의 알림 열에서 업그레이드 사용 가능을 클릭합니다.
gkectl upgrade cluster 명령어를 복사합니다.
관리자 워크스테이션에서 gkectl upgrade cluster 명령어를 실행합니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일이고, [CLUSTER_NAME]은 업그레이드할 사용자 클러스터의 이름이고, [CONFIG_FILE]은 업그레이드를 수행하는 데 사용하는 GKE On-Prem 구성 파일입니다.

업그레이드 재개

관리자 클러스터가 성공적으로 업그레이드되었지만 사용자 클러스터 업그레이드가 중단된 경우 동일한 GKE On-Prem 구성 파일 및 관리자 클러스터 kubeconfig로 gkectl upgrade cluster를 다시 실행하여 업그레이드를 재개할 수 있습니다.

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

관리자 클러스터 업그레이드를 중단해서는 안 됩니다. 현재 관리자 클러스터 업그레이드가 항상 재개되는 것은 아닙니다. 어떤 이유로든 관리자 클러스터 업그레이드가 중단되면 지원팀에 문의해야 합니다.

알려진 문제

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

PodDisruptionBudget으로 워크로드 중단

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

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

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

수정은 버전 1.1.2를 대상으로 합니다. 업그레이드하기 전에 관리 제어 영역 노드에 대한 해결 방법으로 다음 단계를 수행하세요.

vCenter 인터페이스에서 vSAN Datastore에 있는 폴더의 UUID를 가져옵니다.
클러스터의 머신 리소스를 나열합니다. 이러한 머신은 클러스터의 노드에 해당합니다.
```
kubectl get machines -n all
```
관리 제어 영역의 머신(gke-admin-master)에서 수정을 위해 구성을 엽니다.
```
kubectl edit machine [MACHINE_NAME]
```

spec.providerSpec.value.machineVariables.data_disk_path 필드를 변경합니다. VMDK 파일의 경로를 UUID로 바꿉니다. 예를 들면 다음과 같습니다.

spec:
providerSpec:
 value:
   apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
   kind: VsphereMachineProviderConfig
   machineVariables:
     data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
     datacenter: datacenter
     datastore: datastore

파일을 저장합니다.
GKE On-Prem 구성 파일을 엽니다.
vcenter.datadisk에서 파일 경로의 폴더를 폴더의 UUID로 바꿉니다. 예를 들면 다음과 같습니다.
```
vcenter:
 ...
 datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
```
클러스터 업그레이드를 진행합니다.

버전 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)가 도입되었습니다. 이러한 필드를 통해 Cloud Console에서 클러스터에 로그인할 수 있습니다.

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

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

oidc:
  clientsecret: "secret"

부록

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

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

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

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

1.1.0-gke.6으로 업그레이드하기 전 VMware DRS 중지

이 기능을 기존 사용자 클러스터에 사용하고 싶지 않은 경우, 예를 들어 이 기능을 제공할 호스트가 충분하지 않으면 사용자 클러스터를 업그레이드하기 전에 다음 단계를 수행합니다.

기존 GKE On-Prem 구성 파일을 엽니다.
usercluster 사양에서 antiaffinitygroups 문서에 설명된 대로 antiaffinitygroups 필드를 추가합니다.
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
파일을 저장합니다.
구성 파일을 사용하여 업그레이드합니다. 클러스터가 업그레이드되었지만 기능이 사용 설정되지 않았습니다.

대체 업그레이드 시나리오

이 주제에서는 GKE On-Prem를 업그레이드하는 가장 간단한 방법을 설명합니다. 아래 표에서는 대체 업그레이드 시나리오를 설명합니다. 이 시나리오에서는 gkectl 및 클러스터만 업그레이드하며 관리자 워크스테이션을 업그레이드하지 않을 것입니다.

시나리오	단계
출시 버전에는 관리 워크스테이션에 대한 보안 업데이트가 없습니다.	`gkectl`를 다운로드합니다. 번들 다운로드 이 페이지의 안내를 따르세요.

문제해결

자세한 내용은 문제 해결을 참조하세요.

새 노드가 생성되었지만 정상이 아님

증상

수동 부하 분산 모드를 사용하는 경우 새 노드가 사용자 클러스터 제어 영역에 등록되지 않습니다.

가능한 원인

노드의 부팅 프로세스를 차단하는 노드 내 인그레스 검사가 사용 설정되었을 수 있습니다.

해결 방법

검사를 중지하려면 다음을 실행하세요.

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

`gkectl`을 사용하여 클러스터 문제 진단

gkectl diagnose 명령어를 사용하여 클러스터 문제를 식별하고 클러스터 정보를 Google과 공유하세요. 클러스터 문제 진단을 참조하세요.

기본 로깅 동작

gkectl 및 gkeadm의 경우 기본 로깅 설정만 사용해도 됩니다.

기본적으로 로그 항목은 다음과 같이 저장됩니다.
- gkectl의 기본 로그 파일은 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log이며 파일은 gkectl을 실행하는 로컬 디렉터리의 logs/gkectl-$(date).log 파일과 심볼릭 링크됩니다.
- gkeadm의 경우 기본 로그 파일은 gkeadm을 실행하는 로컬 디렉터리의 logs/gkeadm-$(date).log입니다.
모든 로그 항목은 터미널에서 출력되지 않더라도 로그 파일에 저장됩니다(--alsologtostderr가 false인 경우).
-v5 세부정보 수준(기본값)에는 지원팀에 필요한 모든 로그 항목이 포함됩니다.
로그 파일에는 실행된 명령어와 실패 메시지도 포함되어 있습니다.

도움이 필요한 경우 로그 파일을 지원팀에 보내는 것이 좋습니다.

로그 파일에 기본값이 아닌 위치 지정

gkectl 로그 파일에 기본값이 아닌 위치를 지정하려면 --log_file 플래그를 사용합니다. 지정한 로그 파일은 로컬 디렉터리와 심볼릭 링크되지 않습니다.

gkeadm 로그 파일에 기본값이 아닌 위치를 지정하려면 --log_file 플래그를 사용합니다.

관리자 클러스터에서 Cluster API 로그 찾기

관리자 제어 영역이 시작된 후에 VM을 시작하지 못하는 경우 다음 안내에 따라 관리자 클러스터에서 Cluster API 컨트롤러의 로그를 검사하여 디버깅할 수 있습니다.

kube-system 네임스페이스에서 Cluster API 컨트롤러 pod의 이름을 찾습니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
pod의 로그를 엽니다. 여기서 [POD_NAME]은 pod 이름입니다. 원하는 경우 grep 또는 유사한 도구를 사용하여 오류를 검색할 수 있습니다.
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```