버전 1.7. 이 버전은 Anthos 버전 지원 정책에 설명된 대로 지원되며 VMware용 Anthos 클러스터(GKE On-Prem)에 영향을 미치는 보안 취약점, 노출, 문제에 대한 최신 패치와 업데이트를 제공합니다. 자세한 내용은 출시 노트를 참조하세요. 이 버전은 최신 버전이 아닙니다.

알려진 문제

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

ClientConfig 커스텀 리소스

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

kubectl describe CSINode, gkectl diagnose snapshot

간혹 nil 포인터 필드 역참조에 대한 OSS Kubernetes 문제로 인해 kubectl describe CSINodegkectl 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)을 사용하는 워크로드에 중단이나 다운타임이 발생할 수 있습니다.

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

Istio 구성 요소에 대한 PodDisruptionBudget 설정에 따라 Anthos Service Mesh 또는 OSS Istio가 클러스터에 설치되어 있으면 사용자 노드가 제어 영역 버전으로 업그레이드되지 않을 수 있습니다. 이러한 실패를 방지하려면 업그레이드하기 전에 istio-system 네임스페이스의 구성요소에 수평형 Pod 자동 확장 minReplicas 설정을 1에서 2로 늘리는 것이 좋습니다. 이렇게 하면 항상 ASM 제어 영역의 인스턴스가 실행됩니다.

Anthos Service Mesh 1.5 이상 또는 OSS Istio 1.5 이상인 경우:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Anthos Service Mesh 1.4.x 또는 OSS Istio 1.4.x 이상인 경우:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

로그 전달자가 OAuth 2.0 요청을 과도하게 수행함

VMware용 Anthos 클러스터 버전 1.7.1에서는 로그 전달자가 OAuth 2.0 요청을 과도하게 수행하여 메모리를 소비하는 경우가 발생할 수 있습니다. 다음은 stackdriver-operator 버전을 다운그레이드하고, 디스크를 삭제하고, 로그 전달자를 다시 시작하는 해결 방법입니다.

0단계: 필요에 따라 비공개 레지스트리에 이미지 다운로드

비공개 레지스트리를 사용하는 경우 계속하기 전 다음 단계에 따라 비공개 레지스트리에 이미지를 다운로드합니다. 비공개 레지스트리를 사용하지 않는 경우 이 단계를 생략합니다.

PRIVATE_REGISTRY_HOST를 비공개 Docker 레지스트리의 호스트 이름 또는 IP 주소로 바꿉니다.

stackdriver-operator

docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440

docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \
    PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

fluent-bit

docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3

docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \
    PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

prometheus

docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0

docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \
    PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

1단계: stackdriver-operator 버전 다운그레이드

  • 다음 명령어를 실행하여 stackdriver-operator 버전을 다운그레이드합니다.
kubectl  --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'

2단계: 로그 전달자에 대해 디스크 버퍼 삭제

  • 클러스터에서 DaemonSet를 배포하여 버퍼를 삭제합니다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
  • 디스크 버퍼가 삭제되었는지 확인합니다.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

출력에 클러스터에 있는 노드 수가 표시됩니다.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

출력에 클러스터에 있는 노드 수가 표시됩니다.

  • cleanup DaemonSet를 삭제합니다.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

3단계: 로그 전달자 다시 시작

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder

로그 및 측정항목이 stackdriver.projectID로 지정된 프로젝트로 전송되지 않음

VMware용 Anthos 클러스터 1.7에서는 클러스터 구성 파일의 stackdriver.serviceAccountKeyPath 필드에 지정된 서비스 계정의 상위 프로젝트로 로그가 전송됩니다. stackdriver.projectID 값은 무시됩니다. 이 문제는 이후 출시 버전에서 해결될 예정입니다.

문제 해결을 위해서는 로깅-모니터링 서비스 계정의 상위 프로젝트에서 로그를 확인합니다.

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

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

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

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

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

    kubectl --kubeconfig [ADMIN_CLUSTER_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 [ADMIN_CLUSTER_KUBECONFIG] get nodes -o \
    jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
    --selector='node-role.kubernetes.io/master')
    
  3. 인증서가 만료되었는지 확인합니다.

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

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

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

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

    # ssh into admin master
    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 .
    
  5. kubeadm으로 인증서를 갱신합니다.

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

  6. 관리자 마스터 노드를 다시 시작합니다.

      # 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
     
  7. 관리자 클러스터 kubeconfig 파일도 관리자 인증서가 만료되면 만료되므로 만료 전에 이 파일을 백업해야 합니다.

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

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

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

  8. 갱신된 인증서의 유효성을 검사하고 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 [ADMIN_CLUSTER_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

/etc/cron.daily/aide 스크립트가 /run의 모든 공간을 소비하여 pod에 비정상 종료 루프가 발생함

VMware용 Anthos 클러스터 1.7.2부터 시작하여 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화됩니다. . 그 결과 CIS L1 서버 규칙 "1.4.2 파일 시스템 무결성에 대한 정기 검사 확인"을 따르기 위해 aide 검사가 예약되도록 크론 스크립트 /etc/cron.daily/aide가 설치되었습니다.

이 스크립트는 /run/aide를 임시 디렉터리로 사용하여 크론 로그를 저장하고 시간 경과에 따라 /run의 모든 공간을 소비할 수 있습니다. 해결 방법은 /etc/cron.daily/aide 스크립트가 /run의 모든 공간 소비를 참조하세요.

노드에서 하나 이상의 pod 비정상 종료 루프가 발견될 경우 노드에서 df -h /run을 실행합니다. 명령어 결과에 100% 공간 사용이 표시되면 이 문제가 발생할 가능성이 높습니다.

이 문제는 이후 출시 버전에서 해결될 예정입니다. 한편 다음 두 가지 해결 방법 중 하나로 이 문제를 해결할 수 있습니다.

  1. /run/aide/cron.daily.old*에서 주기적으로 로그 파일을 삭제합니다(권장).
  2. 위의 외부 링크에 언급된 단계를 따릅니다. 참고: 이 해결방법은 노드 규정 준수 상태에 영향을 줄 수 있습니다.

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-namebundle.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-versionbundle.gke.io/component-name 라벨을 삭제합니다.

또는 1.6.4 및 1.7.3 출시 버전을 기다린 후 1.6.4 또는 1.7.3으로 바로 업그레이드해도 됩니다.

비밀번호 만료 문제로 인해 관리 워크스테이션에 로그인할 수 없음

다음 버전의 VMware용 Anthos 클러스터를 사용하는 경우 이 문제가 발생할 수 있습니다.

  • 1.7.2-gke.2
  • 1.7.3-gke.2
  • 1.8.0-gke.21
  • 1.8.0-gke.24
  • 1.8.0-gke.25
  • 1.8.1-gke.7
  • 1.8.2-gke.8

관리 워크스테이션, 클러스터 노드, Seesaw 노드를 포함하여 Anthos VM에 SSH 연결을 시도할 때 다음 오류가 발생할 수 있습니다.

WARNING: Your password has expired.

이 오류는 VM의 ubuntu 사용자 비밀번호가 만료되었기 때문에 발생합니다. VM에 로그인하기 전에 사용자 비밀번호의 만료 시간을 큰 값으로 수동으로 재설정해야 합니다.

비밀번호 만료 오류 방지

위에 나열된 영향을 받는 버전을 실행 중이며 사용자 비밀번호가 아직 만료되지 않은 경우 SSH 오류를 확인하기 전에 만료 시간을 연장해야 합니다.

각 Anthos VM에서 다음 명령어를 실행합니다.

sudo change -M 99999 ubuntu

비밀번호 만료 오류 완화

사용자 비밀번호가 이미 만료되어 VM에 로그인하여 만료 시간을 연장할 수 없는 경우 각 구성요소에 대해 다음 완화 단계를 수행하세요.

관리 워크스테이션

임시 VM을 사용하여 다음 단계를 수행합니다. 임시 VM으로 사용할 1.7.1-gke.4 버전을 사용하여 관리 워크스테이션을 만들 수 있습니다.

  1. 임시 VM과 관리 워크스테이션의 전원이 꺼져 있는지 확인합니다.

  2. 관리 워크스테이션의 부팅 디스크를 임시 VM에 연결합니다. 부팅 디스크는 '하드 디스크 1' 라벨이 있는 디스크입니다.

  3. 다음 명령어를 실행하여 VM 내에 부팅 디스크를 마운트합니다. dev/sdc1을 자체 부팅 디스크 식별자로 바꿉니다.

    sudo mkdir -p /mnt/boot-disk
    sudo mount /dev/sdc1 /mnt/boot-disk
    
  4. ubuntu 사용자 만료일을 99999일과 같이 큰 값으로 설정합니다.

    sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
    
  5. 임시 VM을 종료합니다.

  6. 관리 워크스테이션의 전원을 켭니다. 이제 평소와 같이 SSH를 사용할 수 있습니다.

  7. 임시 VM을 삭제합니다.

관리자 클러스터 제어 영역 VM

안내에 따라 관리자 클러스터 제어 영역 VM을 다시 만듭니다.

관리자 클러스터 부가기능 VM

관리 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.

  kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
  

이 명령어를 실행한 후 관리자 클러스터 부가기능 VM이 재생성을 완료하고 준비될 때까지 기다린 후 다음 단계를 계속 진행합니다.

사용자 클러스터 제어 영역 VM

관리 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.

usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

이 명령어를 실행한 후 사용자 클러스터 제어 영역 VM이 재생성을 완료하고 준비될 때까지 기다린 후 다음 단계를 계속 진행합니다.

사용자 클러스터 작업자 VM

관리 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.

for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done

Seesaw VM

관리 워크스테이션에서 다음 명령어를 실행하여 Seesaw VM을 다시 만듭니다. 다운타임이 발생합니다. 부하 분산기에 HA가 사용 설정된 경우 최대 다운타임은 2초입니다.

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff