알려진 문제

이 문서에서는 VMware용 Anthos 클러스터(GKE On-Prem) 버전 1.6에서 알려진 문제를 설명합니다.

ClientConfig 커스텀 리소스

gkectl update는 ClientConfig 커스텀 리소스에서 수행한 변경을 수동으로 되돌립니다. 수동으로 변경한 후 항상 ClientConfig 리소스를 백업하는 것이 좋습니다.

kubectl describe CSINode, gkectl diagnose snapshot

간혹 nil 포인터 필드 역참조에 대한 OSS Kubernetes 문제로 인해 kubectl describe CSINode 및 gkectl diagnose snapshot이 실패합니다.

OIDC 및 CA 인증서

OIDC 제공업체는 기본적으로 공통 CA를 사용하지 않습니다. CA 인증서를 명시적으로 제공해야 합니다.

관리자 클러스터를 1.5에서 1.6.0으로 업그레이드하면 OIDC 공급업체를 사용하고 사용자 클러스터 구성 파일의 authentication.oidc.capath 값이 없는 1.5 사용자 클러스터가 손상됩니다.

이 문제를 해결하려면 다음 스크립트를 실행합니다.

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"

다음을 바꿉니다.

• YOUR_OIDC_IDENTITY_PROVICER: OIDC 제공업체의 주소:

• YOUR_YOUR_USER_CLUSTER_KUBECONFIG: 사용자 클러스터 kubeconfig 파일의 경로입니다.

gkectl check-config 검사 실패: F5 BIG-IP 파티션을 찾을 수 없음

증상

F5 BIG-IP 파티션이 존재하더라도 이를 찾을 수 없어서 검사가 실패합니다.

가능한 원인

F5 BIG-IP API 관련 문제로 인해 검사가 실패할 수 있습니다.

해결 방법

gkectl check-config를 다시 실행해 보세요.

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}'

관리자 클러스터를 업그레이드하기 전에 인증서 갱신이 필요할 수 있음

관리자 클러스터 업그레이드 절차를 시작하기 전에 관리자 클러스터 인증서가 현재 유효한지 확인하고 유효하지 않은 경우 갱신해야 합니다.

참고: 업그레이드 프로세스를 시작했지만 인증서 만료 오류가 있는 경우 Google 지원팀에 문의하세요.

참고: 이 안내는 관리자 클러스터 인증서를 갱신하는 경우에만 적용됩니다.

관리자 클러스터 인증서 갱신 프로세스

1. 시작하기 전에 관리자 워크스테이션에 OpenSSL이 설치되어 있어야 합니다.

2. KUBECONFIG 변수를 설정합니다.

   KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
   

   ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 절대 경로로 바꿉니다.

3. 관리자 마스터 노드의 IP 주소와 SSH 키를 가져옵니다.

   kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \
   -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
   ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
   
   export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \
   jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   --selector='node-role.kubernetes.io/master')
   

4. 인증서가 만료되었는지 확인합니다.

   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
   "sudo kubeadm alpha certs check-expiration"
   

   인증서가 만료된 경우 관리자 클러스터를 업그레이드하기 전에 갱신해야 합니다.

5. 관리자 클러스터 kubeconfig 파일도 관리자 인증서가 만료되면 만료되므로 만료 전에 이 파일을 백업해야 합니다.

   • 관리자 클러스터 kubeconfig 파일을 백업합니다.

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
     vi "${KUBECONFIG}"
     

   • kubeconfig의 client-certificate-data 및 client-key-data를 생성된 new_admin.conf 파일의 client-certificate-data 및 client-key-data로 바꿉니다.

6. 이전 인증서를 백업합니다.

   이 단계는 선택사항이지만 권장됩니다.

   # ssh into admin master if you didn't in the previous step
   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
   
   # on admin master
   sudo tar -czvf backup.tar.gz /etc/kubernetes
   logout
   
   # on worker node
   sudo scp -i ~/.ssh/admin-cluster.key \
   ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
   

7. kubeadm으로 인증서를 갱신합니다.

    # ssh into admin master
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
    # on admin master
    sudo kubeadm alpha certs renew all
    

8. 관리자 마스터 노드에서 실행 중인 정적 포드를 다시 시작합니다.

     # on admin master
     cd /etc/kubernetes
     sudo mkdir tempdir
     sudo mv manifests/*.yaml tempdir/
     sleep 5
     echo "remove pods"
     # ensure kubelet detect those change remove those pods
     # wait until the result of this command is empty
     sudo docker ps | grep kube-apiserver
   
     # ensure kubelet start those pods again
     echo "start pods again"
     sudo mv tempdir/*.yaml manifests/
     sleep 30
     # ensure kubelet start those pods again
     # should show some results
     sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd
   
     # clean up
     sudo rm -rf tempdir
   
     logout
    

9. 관리자 클러스터 워커 노드의 인증서 갱신

   노드 인증서 만료일 확인

       kubectl get nodes -o wide
       # find the oldest node, fill NODE_IP with the internal ip of that node
       ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}"
       openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem
       logout
      

   인증서가 곧 만료되는 경우 수동 노드 복구로 노드 인증서를 갱신하세요.

10. 갱신된 인증서의 유효성을 검사하고 kube-apiserver의 인증서를 검증해야 합니다.

    • 인증서 만료를 확인합니다.

      ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
      
      "sudo kubeadm alpha certs check-expiration"
      

    • kube-apiserver의 인증서를 확인합니다.

      # Get the IP address of kube-apiserver
      cat $KUBECONFIG | grep server
      # Get the current kube-apiserver certificate
      openssl s_client -showcerts -connect : 
      
      | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  
      
      > current-kube-apiserver.crt
      # check expiration date of this cert
      openssl x509 -in current-kube-apiserver.crt -noout -enddate
      # check nodes are ready
      kubectl --kubeconfig $KUBECONFIG get nodes
      

VMware용 Anthos 클러스터 사용(Anthos Service Mesh 버전 1.7 이상)

VMware용 Anthos 클러스터(Anthos Service Mesh 버전 1.7 이상)를 사용하고 VMware용 Anthos 클러스터 버전 1.6.0~1.6.3 또는 VMware용 Anthos 클러스터 버전 1.7.0~1.7.2로 업그레이드하려면 다음 커스텀 리소스 정의(CRD)에서 bundle.gke.io/component-name 및 bundle.gke.io/component-version 라벨을 삭제해야 합니다.

• destinationrules.networking.istio.io
• envoyfilters.networking.istio.io
• serviceentries.networking.istio.io
• virtualservices.networking.istio.io

1. 다음 명령어를 실행하여 사용자 클러스터에서 CRD destinationrules.networking.istio.io를 업데이트합니다.

   kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG

2. CRD에서 bundle.gke.io/component-version 및 bundle.gke.io/component-name 라벨을 삭제합니다.

또는 1.6.4 또는 1.7.3으로 직접 업그레이드할 수 있습니다.

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

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

7.0U2 미만 버전으로 vCenter 다시 시작 또는 업그레이드

7.0U2 미만의 버전에서 vCenter가 업그레이드되거나 그 밖의 경우 다시 시작되면 vCenter의 VM 정보에 있는 네트워크 이름이 올바르지 않으며 머신이 Unavailable 상태가 됩니다. 그러면 결국 노드가 자동 복구되어 새로운 노드가 생성됩니다.

관련 govmomi 버그: https://github.com/vmware/govmomi/issues/2552

이 해결 방법은 VMware 지원팀에서 제공합니다.

1. The issue is fixed in vCenter versions 7.0U2 and above.

2. For lower versions:
Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the
VM's portgroup.