VMware용 Anthos 클러스터의 알려진 문제

이 페이지에는 VMware용 Anthos 클러스터에 대한 모든 알려진 문제가 나와 있습니다. 제품 버전이나 카테고리별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 원하는 필터를 선택하세요.

VMware용 Anthos 클러스터 버전을 선택하세요.

문제 카테고리를 선택하세요.

또는 해당 문제를 검색하세요.

카테고리 식별된 버전 문제 및 해결 방법
네트워킹, 운영 1.10, 1.11, 1.12, 1.13, 1.14

우선순위 클래스 누락으로 인해 제거되거나 대기 중인 Anthos Network Gateway 구성요소

kube-system의 네트워크 게이트웨이 포드에서 다음에 요약된 출력 예시와 같이 Pending 또는 Evicted 상태를 표시할 수 있습니다.


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

이러한 오류는 제거 이벤트 또는 노드 리소스로 인해 포드를 예약할 수 없음을 나타냅니다. Anthos Network Gateway 포드에는 PriorityClass가 없으므로 다른 워크로드와 같은 기본 우선순위가 있습니다. 노드에 리소스 제약이 있으면 네트워크 게이트웨이 포드가 삭제될 수 있습니다. 이 동작은 특히 ang-node DaemonSet에 좋지 않습니다. 이러한 포드는 특정 노드에 예약되어야 하며 마이그레이션할 수 없기 때문입니다.


해결 방법:

1.15 이상으로 업그레이드합니다.

단기적으로 문제를 해결하려면 PriorityClass를 수동으로 Anthos Network Gateway 구성요소에 할당합니다. VMware용 Anthos 클러스터 컨트롤러는 클러스터 업그레이드 중과 같은 조정 프로세스 중에 이러한 수동 변경사항을 덮어씁니다.

  • system-cluster-critical PriorityClass를 ang-controller-managerautoscaler 클러스터 컨트롤러 배포에 할당합니다.
  • system-node-critical PriorityClass를 ang-daemon 노드 DaemonSet에 할당합니다.
업그레이드 및 업데이트 1.12, 1.13, 1.14, 1.15.0-1.15.2

클러스터를 gcloud에 등록한 후 관리자 클러스터 업그레이드 실패

gcloud를 사용하여 비어 있지 않은 gkeConnect 섹션으로 관리자 클러스터를 등록한 후 클러스터를 업그레이드하려고 할 때 다음 오류가 표시될 수 있습니다.


failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

gke-connect 네임스페이스를 삭제합니다.


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
관리자 클러스터 이름을 가져옵니다.

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Fleet 멤버십을 삭제합니다.

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
관리자 클러스터 업그레이드를 재개합니다.

작업 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

gkectl diagnose snapshot --log-since가 클러스터 노드에서 실행되는 journalctl 명령어의 기간을 제한하지 못함

스냅샷에는 클러스터 노드에서 journalctl를 실행하여 기본적으로 수집되는 모든 로그가 포함되어 있으므로 클러스터의 스냅샷 생성 기능에는 영향을 주지 않습니다. 따라서 디버깅 정보가 누락되지 않습니다.

설치, 업그레이드 및 업데이트 1.9+, 1.10+, 1.11+, 1.12+

gkectl prepare windows 실패

MicrosoftDockerProvider가 지원 중단되었기 때문에 gkectl prepare windows가 1.13 이전 버전의 VMware용 Anthos 클러스터에 Docker를 설치하지 못합니다.


해결 방법:

이 문제를 해결하는 일반적인 방법은 VMware용 Anthos 클러스터 1.13으로 업그레이드하고 1.13 gkectl을 사용하여 Windows VM 템플릿을 만든 다음 Windows 노드 풀을 만드는 것입니다. 아래와 같이 현재 버전에서 VMware용 Anthos 클러스터 1.13으로 업그레이드하는 두 가지 옵션이 있습니다.

참고: 1.13으로 업그레이드할 필요 없이 현재 버전에서 이 문제를 해결할 수 있는 방법이 있지만, 더 많은 수동 단계가 필요합니다. 이 옵션을 고려하려면 지원팀에 문의하세요.


옵션 1: 블루/그린 업그레이드

Windows 노드 풀이 있는 VMware용 Anthos 클러스터 1.13 이상 버전을 사용하여 새 클러스터를 만들고 새 클러스터로 워크로드를 마이그레이션한 후 현재 클러스터를 해체할 수 있습니다. 최신 Anthos 마이너 버전을 사용하는 것이 좋습니다.

참고: 이렇게 하면 새 클러스터를 프로비저닝하는 데 추가 리소스가 필요하지만 기존 워크로드의 다운타임 및 중단이 줄어듭니다.


옵션 2: Windows 노드 풀을 삭제하고 VMware용 Anthos 클러스터 1.13으로 업그레이드할 때 다시 추가합니다.

참고: 이 옵션을 사용하면 클러스터가 1.13으로 업그레이드되고 Windows 노드 풀이 다시 추가될 때까지 Windows 워크로드를 실행할 수 없습니다.

  1. user-cluster.yaml 파일에서 Windows 노드 풀 구성을 삭제하여 기존 Windows 노드 풀을 삭제한 후 다음 명령어를 실행합니다.
    
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. 해당 대상 부 버전의 업그레이드 사용자 가이드에 따라 Linux 전용 관리자+사용자 클러스터를 1.12로 업그레이드합니다.
  3. (1.13으로 업그레이드하기 전에 이 단계를 수행해야 함) enableWindowsDataplaneV2: trueOnPremUserCluster CR에 구성되어 있는지 확인합니다. 그렇지 않으면 클러스터가 Docker가 설치되지 않은 새로 생성된 1.13 Windows VM 템플릿과 호환되지 않는 Windows 노드 풀에 Docker를 계속 사용합니다. 구성되지 않았거나 false로 설정된 경우, 클러스터를 업데이트하여 user-cluster.yaml에서 true로 설정하고 다음을 실행합니다.
    
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. 업그레이드 사용자 가이드에 따라 Linux 전용 관리자+사용자 클러스터를 1.13으로 업그레이드합니다.
  5. 1.13 gkectl을 사용하여 Windows VM 템플릿을 준비합니다.
    
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. user-cluster.yaml에서 OSImage 필드를 새로 만든 Windows VM 템플릿으로 설정하여 Windows 노드 풀 구성을 다시 추가합니다.
  7. 클러스터를 업데이트하여 Windows 노드 풀을 추가합니다.
    
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
설치, 업그레이드 및 업데이트 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

RootDistanceMaxSec 구성이 ubuntu 노드에 적용되지 않음

예상 구성인 20초 대신 RootDistanceMaxSec의 5초 기본값이 노드에 사용됩니다. `/var/log/startup.log`에 있는 VM에 SSH를 통해 연결하여 노드 시작 로그를 확인하면 다음 오류를 찾을 수 있습니다.


+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

5초 RootDistanceMaxSec를 사용하면 클럭 드리프트가 5초보다 큰 경우 시스템 클럭이 NTP 서버와 동기화되지 않을 수 있습니다.


해결 방법:

노드에 SSH로 연결하고 RootDistanceMaxSec를 구성합니다.


mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
업그레이드 및 업데이트 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

osImageType 필드가 비어 있어 gkectl update admin이 실패함

버전 1.13 gkectl을 사용하여 버전 1.12 관리자 클러스터를 업데이트하면 다음 오류가 표시될 수 있습니다.


Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

버전 1.13 또는 1.14 클러스터에 gkectl update admin을 사용하면 응답에 다음 메시지가 표시될 수 있습니다.


Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

gkectl 로그를 확인하면 osImageType을 빈 문자열에서 ubuntu_containerd로 설정하는 등 여러 변경 사항이 있습니다.

이러한 업데이트 오류는 버전 1.9에서 도입된 이후 관리자 클러스터 구성의 osImageType 필드의 잘못된 백필이 원인입니다.


해결 방법:

수정사항이 적용된 VMware용 Anthos 클러스터 버전으로 업그레이드합니다. 업그레이드할 수 없는 경우 Cloud Customer Care에 문의하여 이 문제를 해결하세요.

설치, 보안 1.13, 1.14, 1.15

SNI가 Controlplane V2를 사용하는 사용자 클러스터에서 작동하지 않음

Controlplane V2가 사용 설정(enableControlplaneV2: true)된 경우 authentication.sni로 사용자 클러스터의 Kubernetes API 서버에 추가 제공 인증서를 제공하는 기능이 작동하지 않습니다.


해결 방법:

VMware용 Anthos 클러스터 패치를 수정사항과 사용할 수 있을 때까지 SNI를 사용해야 하는 경우 Controlplane V2(enableControlplaneV2: false)를 사용 중지합니다.

설치 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

비공개 레지스트리 사용자 이름의 $로 인해 관리자 제어 영역 머신 시작 실패

비공개 레지스트리 사용자 이름에 $가 포함된 경우 관리자 제어 영역 머신이 시작되지 않습니다. 관리자 제어 영역 머신에서 /var/log/startup.log를 확인할 때 다음 오류가 표시됩니다.


++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

해결 방법:

$ 없이 비공개 레지스트리 사용자 이름을 사용하거나 수정사항이 적용된 VMware용 Anthos 클러스터 버전을 사용합니다.

업그레이드 및 업데이트 1.12.0-1.12.4

관리자 클러스터 업데이트 중 지원되지 않는 변경사항에 대한 거짓양성 경고

관리자 클러스터를 업데이트할 때 로그에 다음과 같은 거짓양성 경고가 표시되지만 무시하면 됩니다.


    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
업그레이드 및 업데이트 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

KSA 서명 키 순환 후 사용자 클러스터 업데이트 실패

KSA 서명 키를 순환한 후 사용자 클러스터를 업데이트하면 gkectl update가 실패하고 다음 오류 메시지가 표시될 수 있습니다.


Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


해결 방법:

KSA 서명 키 버전을 다시 1로 변경하되 최신 키 데이터는 유지합니다.
  1. 관리자 클러스터의 USER_CLUSTER_NAME 네임스페이스에서 보안 비밀을 확인하고 ksa-signing-key 보안 비밀 이름을 가져옵니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. ksa-signing-key 보안 비밀을 복사하고 복사한 보안 비밀의 이름을 service-account-cert로 지정합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
    sed 's/ name: .*/ name: service-account-cert/' | \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. 이전 ksa-signing-key 보안 비밀을 삭제합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. ksa-signing-key-rotation-stage configmap의 data.data 필드를 '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}'로 업데이트합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
    edit configmap ksa-signing-key-rotation-stage
  5. 검증 웹훅을 사용 중지하여 OnPremUserCluster 커스텀 리소스에서 버전 정보를 수정합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
    webhooks:
    - name: vonpremnodepool.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        resources:
        - onpremnodepools
    - name: vonpremusercluster.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        resources:
        - onpremuserclusters
    '
  6. OnPremUserCluster 커스텀 리소스에서 spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation 필드를 1로 업데이트합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
    edit onpremusercluster USER_CLUSTER_NAME
  7. 대상 사용자 클러스터가 준비될 때까지 기다린 후 다음을 수행하여 상태를 확인할 수 있습니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
    get onpremusercluster
  8. 사용자 클러스터의 검증 웹훅을 복원합니다.
    
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
    webhooks:
    - name: vonpremnodepool.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        - UPDATE
        resources:
        - onpremnodepools
    - name: vonpremusercluster.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        - UPDATE
        resources:
        - onpremuserclusters
    '
  9. 클러스터가 수정사항이 적용된 버전으로 업그레이드될 때까지 다른 KSA 서명 키 순환을 사용하지 마세요.
작업 1.13.1+, 1.14, 1.15

Terraform에서 사용자 클러스터를 삭제할 때 F5 BIG-IP 가상 서버가 삭제되지 않음

Terraform을 사용하여 F5 BIG-IP 부하 분산기가 있는 사용자 클러스터를 삭제할 때는 클러스터 삭제 후 F5 BIG-IP 가상 서버가 삭제되지 않습니다.


해결 방법:

F5 리소스를 삭제하려면 사용자 클러스터 F5 파티션을 삭제하는 단계를 따릅니다.

설치, 업그레이드 및 업데이트 1.13.8, 1.14.4

종류 클러스터가 docker.io에서 컨테이너 이미지를 가져옴

버전 1.13.8 또는 버전 1.14.4 관리자 클러스터를 만들거나 관리자 클러스터를 버전 1.13.8 또는 1.14.4로 업그레이드하면 종류 클러스터가 docker.io에서 다음 컨테이너 이미지를 가져옵니다.

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper
  • 관리자 워크스테이션에서 docker.io에 액세스할 수 없는 경우 관리자 클러스터 만들기 또는 업그레이드가 종류 클러스터를 불러오지 못합니다. 관리자 워크스테이션에서 다음 명령어를 실행하면 ErrImagePull로 대기 중인 해당 컨테이너가 표시됩니다.

    
    docker exec gkectl-control-plane kubectl get pods -A
    

    응답에는 다음과 같은 항목이 포함됩니다.

    
    ...
    kube-system         kindnet-xlhmr                             0/1
        ErrImagePull  0    3m12s
    ...
    local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
        Pending       0    3m12s
    ...
    

    이러한 컨테이너 이미지는 종류 클러스터 컨테이너 이미지에 미리 로드되어야 합니다. 하지만 v0.18.0 종류에는 미리 로드된 컨테이너 이미지 관련 문제가 있으며 실수로 인터넷에서 이미지를 가져옵니다.


    해결 방법:

    관리자 클러스터가 생성 또는 업그레이드에 대해 대기하는 동안 관리자 워크스테이션에서 다음 명령어를 실행합니다.

    
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
    
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
    
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    
    작업 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    네트워크에서 중복 GARP 요청을 필터링할 때 HA Controlplane V2 사용자 클러스터 및 관리자 클러스터에서 장애 조치 실패

    클러스터 VM이 중복 GARP(Gratuitous ARP) 요청을 필터링하는 스위치와 연결된 경우 연결 유지된 리더 선택에서 경합 상태가 발생할 수 있으며 이로 인해 일부 노드에서 잘못된 ARP 테이블 항목이 발생할 수 있습니다.

    영향을 받는 노드는 제어 영역 VIP를 ping할 수 있지만 제어 영역 VIP에 대한 TCP 연결은 타임아웃됩니다.


    해결 방법:

    영향을 받는 클러스터의 각 제어 영역 노드에서 다음 명령어를 실행합니다.
    
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
        
    업그레이드 및 업데이트 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    vCenter 인증서 순환 후 vsphere-csi-controller를 다시 시작해야 함

    vsphere-csi-controller는 vCenter 인증서 순환 후 vCenter 보안 비밀을 새로고침해야 합니다. 하지만 현재 시스템이 vsphere-csi-controller의 포드를 올바르게 다시 시작하지 않아 순환 후 vsphere-csi-controller가 비정상 종료됩니다.

    해결 방법:

    1.13 이상 버전에서 만들어진 클러스터의 경우 아래 안내에 따라 vsphere-csi-controller를 다시 시작합니다.

    
    kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    설치 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    클러스터 등록 오류 시 관리자 클러스터 생성이 실패하지 않음

    관리자 클러스터를 만드는 동안 클러스터 등록이 실패하더라도 해당 오류로 gkectl create admin 명령어가 실패하지 않고 성공할 수 있습니다. 즉, 관리자 클러스터 만들기가 Fleet에 등록하지 않고도 '성공'할 수 있습니다.

    증상을 식별하기 위해 `gkectl create admin` 로그에서 다음 오류 메시지를 찾을 수 있습니다.
    
    Failed to register admin cluster

    또한 Cloud 콘솔에서 등록된 클러스터 간에 클러스터를 찾을 수 있는지 확인할 수 있습니다.

    해결 방법:

    1.12 이상 버전에서 만들어진 클러스터의 경우 클러스터를 만든 후 안내에 따라 관리자 클러스터 등록을 재시도합니다. 이전 버전에서 만들어진 클러스터의 경우,

    1. 연결-등록 SA 키 파일에 'foo: bar' 같은 가짜 키-값 쌍을 추가합니다.
    2. gkectl update admin을 실행하여 관리자 클러스터를 다시 등록합니다.

    업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13.0-1.13.1

    관리자 클러스터 업그레이드 중에 관리자 클러스터 재등록을 건너뛸 수 있음

    관리자 클러스터 업그레이드 중에 사용자 제어 영역 노드 업그레이드가 타임아웃되면 관리자 클러스터는 업데이트된 연결 에이전트 버전에 다시 등록되지 않습니다.


    해결 방법:

    클러스터가 등록된 클러스터에 표시되는지 확인합니다. 선택 사항으로 인증을 설정한 후 클러스터에 로그인합니다. 클러스터가 여전히 등록된 경우 등록 재시도를 위한 안내를 건너뛸 수 있습니다. 1.12 이상 버전으로 업그레이드된 클러스터의 경우 클러스터를 만든 후 안내에 따라 관리자 클러스터 등록을 재시도합니다. 이전 버전으로 업그레이드된 클러스터의 경우 다음을 수행합니다.
    1. 연결-등록 SA 키 파일에 'foo: bar' 같은 가짜 키-값 쌍을 추가합니다.
    2. gkectl update admin을 실행하여 관리자 클러스터를 다시 등록합니다.

    구성 1.15.0

    vCenter.dataDisk에 대한 거짓 오류 메시지

    고가용성 관리자 클러스터의 경우 gkectl prepare에 이 거짓 오류 메시지가 표시됩니다.

    
    vCenter.dataDisk must be present in the AdminCluster spec

    해결 방법:

    이 오류 메시지는 무시해도 됩니다.

    VMware 1.15.0

    중복 VM-호스트 어피니티 규칙으로 인해 노드 풀 만들기 실패

    VM-호스트 어피니티를 사용하는 노드 풀을 만드는 동안 경합 상태로 인해 같은 이름으로 생성된 여러 VM-호스트 어피니티 규칙이 발생할 수 있습니다 이로 인해 노드 풀 생성이 실패할 수 있습니다.


    해결 방법:

    노드 풀 만들기를 진행할 수 있도록 이전 중복 규칙을 삭제합니다. 이러한 규칙의 이름은 [USER_CLUSTER_NAME]-[HASH]입니다.

    작업 1.15.0

    failed to delete the admin master node object and reboot the admin master VM 으로 인해 gkectl repair admin-master가 실패할 수 있음

    경합 상태로 인해 다음 오류와 함께 gkectl repair admin-master 명령어가 실패할 수 있습니다.

    
    Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    해결 방법:

    이 명령어는 멱등성을 갖습니다. 명령어가 성공할 때까지 안전하게 다시 실행할 수 있습니다.

    업그레이드 및 업데이트 1.15.0

    제어 영역 노드의 재생성 또는 업데이트 후 포드가 Failed 상태로 유지됨

    제어 영역 노드를 다시 만들거나 업데이트한 후에는 NodeAffinity 조건자 실패로 인해 특정 포드가 Failed 상태로 남아 있을 수 있습니다. 실패한 포드는 일반적인 클러스터 작업 또는 상태에 영향을 주지 않습니다.


    해결 방법:

    실패한 포드를 안전하게 무시하거나 수동으로 삭제할 수 있습니다.

    보안, 구성 1.15

    비공개 레지스트리 사용자 인증 정보로 인해 OnPremUserCluster가 준비되지 않음

    준비된 사용자 인증 정보 및 비공개 레지스트리를 사용하지만 비공개 레지스트리에 준비된 사용자 인증 정보가 구성되어 있지 않으면 OnPremUserCluster가 준비되지 않을 수 있으며 다음 오류 메시지가 표시될 수 있습니다.

    
    failed to check secret reference for private registry …


    해결 방법:

    준비된 사용자 인증 정보 구성의 안내에 따라 사용자 클러스터의 비공개 레지스트리 사용자 인증 정보를 준비합니다.

    업그레이드 및 업데이트 1.15.0

    gkectl upgrade adminStorageClass standard sets the parameter diskformat which is invalid for CSI Migration 와 함께 실패

    gkectl upgrade admin 중에 CSI 마이그레이션의 스토리지 프리플라이트 검사는 StorageClasses에 CSI 마이그레이션 후에 무시되는 매개변수가 없는지 확인합니다. 예를 들어 diskformat 매개변수가 있는 StorageClass가 있으면 gkectl upgrade admin은 StorageClass를 표시하고 프리플라이트 검증에 실패를 보고합니다. Anthos 1.10 이전에 생성된 관리자 클러스터에는 이 검증에 실패하는 diskformat: thin이 있는 StorageClass가 있지만 이 StorageClass는 CSI 마이그레이션 후에도 계속 작동합니다. 이러한 실패는 대신 경고로 해석해야 합니다.

    자세한 내용은 트리 내 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션의 StorageClass 매개변수 섹션을 참조하세요.


    해결 방법:

    클러스터에 CSI 마이그레이션 실행 후 매개변수가 무시된 StorageClass가 있는지 확인한 후 gkectl upgrade admin--skip-validation-cluster-health 플래그와 함께 실행합니다.

    스토리지 1.15

    Windows 파일 시스템을 사용하여 마이그레이션된 트리 내 vSphere 볼륨은 vSphere CSI 드라이버와 함께 사용할 수 없음

    특정 조건에서는 디스크를 Windows 노드에 읽기 전용으로 연결할 수 있습니다. 이렇게 연결하면 해당 볼륨이 포드 내에서 읽기 전용이 됩니다. 이 문제는 새로운 노드 집합이 이전 노드 집합을 대체하는 경우에 발생할 가능성이 높습니다(예: 클러스터 업그레이드 또는 노드 풀 업데이트). 이전에 올바르게 작동한 스테이트풀(Stateful) 워크로드가 새로운 노드 집합에서 볼륨에 쓰기를 수행하지 못할 수 있습니다.


    해결 방법:

    1. 볼륨에 쓰기를 수행할 수 없는 포드의 UID를 가져옵니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
          POD_NAME --namespace POD_NAMESPACE \
          -o=jsonpath='{.metadata.uid}{"\n"}'
    2. PersistentVolumeClaim을 사용하여 PersistentVolume 이름을 가져옵니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
          PVC_NAME --namespace POD_NAMESPACE \
          -o jsonpath='{.spec.volumeName}{"\n"}'
    3. 포드가 실행 중인 노드 이름을 확인합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
          --namespace POD_NAMESPACE \
          -o jsonpath='{.spec.nodeName}{"\n"}'
    4. SSH 또는 vSphere 웹 인터페이스를 통해 노드에 대한 Powershell 액세스 권한을 얻습니다.
    5. 환경 변수를 설정합니다.
      
      PS C:\Users\administrator> pvname=PV_NAME
      PS C:\Users\administrator> podid=POD_UID
    6. PersistentVolume과 연결된 디스크의 디스크 번호를 확인합니다.
      
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
      "C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. 디스크가 readonly인지 확인합니다.
      
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      결과는 True여야 합니다.
    8. readonlyfalse로 설정합니다.
      
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. 포드가 다시 시작되도록 삭제합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
          --namespace POD_NAMESPACE
    10. 포드는 동일한 노드에 예약되어야 합니다. 그러나 포드가 새 노드에 예약되는 경우 새 노드에서 이전 단계를 반복해야 할 수 있습니다.

    업그레이드 및 업데이트 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secretgkectl update credentials vsphere --admin-cluster 이후에 업데이트되지 않음

    클러스터 사용자 인증 정보 업데이트 후 관리자 클러스터의 vSphere 사용자 인증 정보를 업데이트하는 경우 관리자 클러스터의 kube-system 네임스페이스 아래에 vsphere-csi-secret이 여전히 이전 사용자 인증 정보를 사용하는 경우가 있습니다.


    해결 방법:

    1. vsphere-csi-secret 보안 비밀 이름을 가져옵니다.
      
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. 이전 단계에서 가져온 vsphere-csi-secret 보안 비밀의 데이터를 업데이트합니다.
      
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
        "{\"data\":{\"config\":\"$( \
          kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
            | base64 -d \
            | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
            | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
            | base64 -w 0 \
          )\"}}"
    3. vsphere-csi-controller를 다시 시작합니다.
      
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. 다음 명령어를 사용하여 출시 상태를 추적할 수 있습니다.
      
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      배포가 성공적으로 출시되면 컨트롤러에서 업데이트된 vsphere-csi-secret을 사용해야 합니다.
    업그레이드 및 업데이트 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    gkectl update cluster로 Cloud 감사 로그를 사용 설정할 때 audit-proxy 비정상 종료 루프

    --cluster-name이 비어 있기 때문에 audit-proxy 비정상 종료 루프가 발생할 수 있습니다. 이 동작은 클러스터 이름이 감사 프록시 포드/컨테이너 매니페스트에 전파되지 않는 업데이트 로직의 버그로 인해 발생합니다.


    해결 방법:

    enableControlplaneV2: true가 있는 제어 영역 v2 사용자 클러스터의 경우 SSH를 사용하여 사용자 제어 영역 머신에 연결하고 /etc/kubernetes/manifests/audit-proxy.yaml--cluster_name=USER_CLUSTER_NAME으로 업데이트합니다.

    제어 영역 v1 사용자 클러스터의 경우 kube-apiserver Statefulset에서 audit-proxy 컨테이너를 수정하여 --cluster_name=USER_CLUSTER_NAME을 추가합니다.

    
    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    업그레이드 및 업데이트 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    gkectl upgrade cluster 직후의 추가 제어 영역 재배포

    gkectl upgrade cluster 직후 제어 영역 포드가 다시 배포될 수 있습니다. gkectl list clusters의 클러스터 상태가 RUNNING에서 RECONCILING으로 변경됩니다. 사용자 클러스터에 대한 요청이 시간 초과될 수 있습니다.

    이는 제어 영역 인증서 순환이 gkectl upgrade cluster 다음에 자동으로 발생하기 때문입니다.

    이 문제는 제어 영역 v2를 사용하지 않는 사용자 클러스터에서만 발생합니다.


    해결 방법:

    클러스터 상태가 gkectl list clusters에서 다시 RUNNING으로 변경될 때까지 기다리거나 1.13.6 이상, 1.14.2 이상 또는 1.15 이상의 수정사항이 있는 버전으로 업그레이드합니다.

    업그레이드 및 업데이트 1.12.7

    잘못된 출시 버전 1.12.7-gke.19가 삭제됨

    VMware용 Anthos 클러스터 1.12.7-gke.19는 잘못된 출시 버전이므로 사용해서는 안 됩니다. 아티팩트가 Cloud Storage 버킷에서 삭제되었습니다.

    해결 방법:

    대신 1.12.7-gke.20 출시 버전을 사용하세요.

    업그레이드 및 업데이트 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    gke-connect-agent가 레지스트리 사용자 인증 정보가 업데이트된 후에도 이전 이미지를 계속 사용함

    다음 방법 중 하나를 사용하여 레지스트리 사용자 인증 정보를 업데이트하는 경우:

    • 비공개 레지스트리를 사용하지 않는 경우 gkectl update credentials componentaccess
    • 비공개 레지스트리를 사용하는 경우 gkectl update credentials privateregistry

    gke-connect-agent가 이전 이미지를 계속 사용하거나 ImagePullBackOff로 인해 gke-connect-agent 포드를 가져올 수 없는 것을 발견할 수 있습니다.

    이 문제는 VMware용 Anthos 클러스터 출시 버전 1.13.8, 1.14.4 및 이후 출시 버전에서 바로잡을 예정입니다.


    해결 방법:

    옵션 1: gke-connect-agent를 수동으로 재배포

    1. gke-connect 네임스페이스를 삭제합니다.
      
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. 원래의 등록 서비스 계정 키로 gke-connect-agent를 다시 배포합니다(키를 업데이트할 필요 없음).

      관리자 클러스터의 경우 다음과 같습니다.
      
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      사용자 클러스터의 경우 다음과 같습니다.
      
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    옵션 2: gke-connect-agent 배포에서 사용하는 이미지 가져오기 보안 비밀 regcred의 데이터를 수동으로 변경할 수 있습니다.

    
    kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    옵션 3: 다음을 수행하여 gke-connect-agent 배포에서 클러스터의 기본 이미지 가져오기 보안 비밀을 추가할 수 있습니다.

    1. 기본 보안 비밀을 gke-connect 네임스페이스에 복사합니다.
      
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. gke-connect-agent 배포 이름을 가져옵니다.
      
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. gke-connect-agent 보안 비밀에 기본 보안 비밀을 추가합니다.
      
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    설치 1.13, 1.14

    수동 LB 구성 확인 실패

    gkectl check-config를 실행하여 수동 부하 분산기로 클러스터를 만들기 전에 구성을 검증하면 다음 오류 메시지와 함께 명령어가 실패합니다.

    
     - Validation Category: Manual LB    Running validation check for "Network
    configuration"...panic: runtime error: invalid memory address or nil pointer
    dereference
    

    해결 방법:

    옵션 1: 수정사항이 포함된 패치 버전 1.13.7 및 1.14.4를 사용할 수 있습니다.

    옵션 2: 동일한 명령어를 실행하여 구성을 검증할 수 있지만 부하 분산기 유효성 검사를 건너뛸 수 있습니다.

    
    gkectl check-config --skip-validation-load-balancer
    
    작업 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    etcd 감시 부족

    etcd 버전 3.4.13 이하를 실행하는 클러스터는 감시 부족 및 비작업 리소스 감시를 경험할 수 있으며, 이로 인해 다음 문제가 발생할 수 있습니다.

    • 포드 예약이 중단됨
    • 노드를 등록할 수 없음
    • kubelet이 포드 변경사항을 관찰하지 못함

    이러한 문제로 인해 클러스터가 작동하지 않을 수 있습니다.

    이 문제는 VMware용 Anthos 클러스터 1.12.7, 1.13.6, 1.14.3 이상 버전에서 수정되었습니다. 이러한 최신 출시 버전에는 etcd 버전 3.4.21이 사용됩니다. VMware용 Anthos 클러스터의 모든 이전 버전은 이 문제의 영향을 받습니다.

    해결 방법

    즉시 업그레이드할 수 없으면 클러스터의 노드 수를 줄여서 클러스터 실패 위험을 완화할 수 있습니다. etcd_network_client_grpc_sent_bytes_total 측정항목이 300MBps 미만이 될 때까지 노드를 삭제하세요.

    측정항목 탐색기에서 이 측정항목을 보려면 다음 안내를 따르세요.

    1. Google Cloud 콘솔의 측정항목 탐색기로 이동합니다.

      측정항목 탐색기로 이동

    2. 구성 탭을 선택합니다.
    3. 측정항목 선택을 확장하고 필터 표시줄에 Kubernetes Container를 입력한 후 하위 메뉴를 사용해서 측정항목을 선택합니다.
      1. 활성 리소스 메뉴에서 Kubernetes 컨테이너를 선택합니다.
      2. 활성 측정항목 카테고리 메뉴에서 Anthos를 선택합니다.
      3. 활성 측정항목 메뉴에서 etcd_network_client_grpc_sent_bytes_total을 선택합니다.
      4. 적용을 클릭합니다.
    업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13, 1.14

    Anthos Identity Service로 인해 제어 영역 지연 시간이 발생할 수 있음

    클러스터 재시작 또는 업그레이드 시 Anthos Identity Service는 인증 웹훅을 통해 kube-apiserver에서 Anthos Identity Service로 전달되는 만료된 JWT 토큰으로 구성된 트래픽으로 인해 과부하가 발생할 수 있습니다. Anthos Identity Service는 비정상 종료 루프가 되지 않지만 응답하지 않으며 추가 요청 처리를 중지합니다. 이 문제로 인해 결국 제어 영역의 지연 시간이 길어집니다.

    이 문제는 다음 VMware용 Anthos 클러스터 출시 버전에서 수정되었습니다.

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    이 문제의 영향을 받는지 확인하려면 다음 단계를 수행하세요.

    1. 외부에서 Anthos Identity Service 엔드포인트에 연결할 수 있는지 확인합니다.
      
      curl -s -o /dev/null -w "%{http_code}" \
          -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      CLUSTER_ENDPOINT를 클러스터의 제어 영역 VIP 및 제어 영역 부하 분산기 포트로 바꿉니다(예: 172.16.20.50:443).

      이 문제의 영향을 받는 경우 명령어는 400 상태 코드를 반환합니다. 요청 시간이 초과되면 ais 포드를 다시 시작하고 curl 명령어를 다시 실행하여 문제가 해결되는지 확인하세요. 000 상태 코드가 표시되면 문제가 해결된 것입니다. 400 상태 코드가 계속 수신되면 Anthos Identity Service HTTP 서버가 시작되지 않습니다. 이 경우 계속하세요.

    2. Anthos Identity Service 및 kube-apiserver 로그를 확인합니다.
      1. Anthos Identity Service 로그를 확인합니다.
        
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
            --kubeconfig KUBECONFIG

        로그에 다음과 같은 항목이 포함된 경우 이 문제의 영향을 받는 것입니다.

        
        I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
        
      2. 클러스터의 kube-apiserver 로그를 확인합니다.

        다음 명령어에서 KUBE_APISERVER_POD는 지정된 클러스터에서 kube-apiserver 포드의 이름입니다.

        관리자 클러스터:

        
        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
            -n kube-system KUBE_APISERVER_POD kube-apiserver

        사용자 클러스터:

        
        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
            -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        kube-apiserver 로그에 다음과 같은 항목이 포함된 경우 이 문제의 영향을 받는 것입니다.

        
        E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
        E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
        

    해결 방법

    클러스터를 즉시 업그레이드하여 수정할 수 없는 경우 문제가 되는 포드를 식별하고 다시 시작하여 문제를 해결할 수 있습니다.

    1. Anthos Identity Service 세부정보 수준을 9로 높입니다.
      
      kubectl patch deployment ais -n anthos-identity-service --type=json \
          -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
          "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
          --kubeconfig KUBECONFIG
    2. Anthos Identity Service 로그에서 잘못된 토큰 컨텍스트를 확인합니다.
      
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
          --kubeconfig KUBECONFIG
    3. 잘못된 각 토큰 컨텍스트와 연결된 토큰 페이로드를 가져오려면 다음 명령어를 사용하여 관련된 각 서비스 계정 보안 비밀을 파싱합니다.
      
      kubectl -n kube-system get secret SA_SECRET \
          --kubeconfig KUBECONFIG \
          -o jsonpath='{.data.token}' | base64 --decode
      
    4. 토큰을 디코딩하고 소스 포드 이름과 네임스페이스를 보려면 jwt.io의 디버거에 토큰을 복사합니다.
    5. 토큰에서 식별된 포드를 다시 시작합니다.
    작업 1.8, 1.9, 1.10

    etcd-maintenance 포드의 메모리 사용량 증가 문제

    etcddefrag:gke_master_etcddefrag_20210211.00_p0 이미지를 사용하는 etcd 유지보수 포드가 영향을 받습니다. `etcddefrag` 컨테이너는 각 defrag 주기 중에 etcd 서버에 대한 새 연결을 열며 이전 연결은 삭제되지 않습니다.


    해결 방법:

    옵션 1: 1.8을 수정사항이 포함된 최신 패치 버전 1.11로 업그레이드

    옵션 2: 1.9.6 및 1.10.3 이전의 패치 버전을 사용하는 경우 관리자 및 사용자 클러스터의 etcd-maintenance 포드를 축소해야 합니다.

    
    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
    작업 1.9, 1.10, 1.11, 1.12, 1.13

    사용자 클러스터 제어 영역 포드의 상태 점검 누락

    클러스터 상태 컨트롤러와 gkectl diagnose cluster 명령어는 모두 네임스페이스에서 포드 상태 점검을 포함한 일련의 상태 점검을 수행합니다. 하지만 실수로 사용자 제어 영역 포드를 건너뛰기 시작합니다. 제어 영역 v2 모드를 사용하는 경우 클러스터에 영향을 주지 않습니다.


    해결 방법:

    워크로드나 클러스터 관리에는 영향을 주지 않습니다. 제어 영역 포드 상태를 확인하려면 다음 명령어를 실행하면 됩니다.

    
    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
    업그레이드 및 업데이트 1.6+, 1.7+

    1.6 및 1.7 관리자 클러스터 업그레이드가 k8s.gcr.io -> registry.k8s.io 리디렉션의 영향을 받을 수 있음

    2023년 3월 20일에 Kubernetes가 k8s.gcr.io에서 registry.k8s.io로 트래픽을 리디렉션했습니다. VMware용 Anthos 클러스터 1.6.x 및 1.7.x에서 관리자 클러스터 업그레이드는 컨테이너 이미지 k8s.gcr.io/pause:3.2를 사용합니다. 관리자 워크스테이션에 프록시를 사용할 때 프록시가 registry.k8s.io를 허용하지 않고 컨테이너 이미지 k8s.gcr.io/pause:3.2가 로컬로 캐시되지 않는 경우 컨테이너 이미지를 가져올 때 관리자 클러스터 업그레이드가 실패합니다.


    해결 방법:

    관리자 워크스테이션의 프록시 허용 목록에 registry.k8s.io를 추가합니다.

    네트워킹 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    부하 분산기 생성 시 Seesaw 검증 실패

    다음 오류 메시지와 함께 gkectl create loadbalancer가 실패합니다.

    
    - Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
    

    이는 Seesaw 그룹 파일이 이미 존재하기 때문입니다. 프리플라이트 검사는 존재하지 않는 Seesaw 부하 분산기를 검사합니다.

    해결 방법:

    이 클러스터의 기존 Seesaw 그룹 파일을 삭제합니다. 파일 이름은 관리자 클러스터의 경우 seesaw-for-gke-admin.yaml, 사용자 클러스터의 경우 seesaw-for-{CLUSTER_NAME}.yaml입니다.

    네트워킹 1.14

    conntrack 테이블 삽입 실패로 인한 애플리케이션 시간 초과

    VMware용 Anthos 클러스터 버전 1.14는 Ubuntu 또는 COS 운영체제 이미지를 사용할 때 netfilter 연결 추적(conntrack) 테이블 삽입 실패에 취약합니다. 삽입 실패로 인해 무작위 애플리케이션 시간 초과가 발생하고, conntrack 테이블에 새 항목을 위한 공간이 있는 경우에도 발생할 수 있습니다. 이러한 실패는 체인 길이를 기준으로 테이블 삽입을 제한하는 커널 5.15 이상의 변경사항으로 인해 발생합니다.

    이 문제의 영향을 받는지 확인하려면 다음 명령어를 사용하여 각 노드의 커널 내 연결 추적 시스템 통계를 확인하세요.

    
    sudo conntrack -S

    응답은 다음과 같습니다.

    
    cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
    cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
    cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
    cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
    cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
    cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
    ...
    

    응답의 chaintoolong 값이 0이 아닌 값이면 이 문제의 영향을 받습니다.

    해결 방법

    단기적인 완화 방법은 netfiler 해시 테이블(nf_conntrack_buckets)과 netfilter 연결 추적 테이블(nf_conntrack_max)의 크기를 늘리는 것입니다. 각 클러스터 노드에서 다음 명령어를 사용하여 테이블 크기를 늘립니다.

    
    sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
    sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    TABLE_SIZE를 새 크기(바이트 단위)로 바꿉니다. 기본 테이블 크기 값은 262144입니다. 노드에 있는 코어 수의 65,536배와 동일한 값을 설정하는 것이 좋습니다. 예를 들어 노드에 8개의 코어가 있으면 테이블 크기를 524288로 설정합니다.

    네트워킹 1.13.0-1.13.2

    Controlplane v2가 있는 Windows 노드에서 calico-typha 또는 anetd-operator 비정상 종료 루프

    Controlplane v2 또는 새 설치 모델을 사용하면 calico-typha 또는 anetd-operator가 Windows 노드에 예약되고 비정상 종료 루프에 노출될 수 있습니다.

    두 배포가 Windows 노드 taint를 포함한 모든 taint를 허용하도록 하기 때문입니다.


    해결 방법:

    1.13.3 이상으로 업그레이드하거나 다음 명령어를 실행하여 `calico-typha` 또는 `anetd-operator` 배포를 수정합니다.

    
        # If dataplane v2 is not used.
        kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
        # If dataplane v2 is used.
        kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
        

    다음 spec.template.spec.tolerations를 삭제합니다.

    
        - effect: NoSchedule
          operator: Exists
        - effect: NoExecute
          operator: Exists
        

    그리고 다음 톨러레이션(toleration)을 추가합니다.

    
        - key: node-role.kubernetes.io/master
          operator: Exists
        
    구성 1.14.0-1.14.2

    사용자 클러스터 비공개 레지스트리 사용자 인증 정보 파일을 로드할 수 없음

    fileRef 사용자 인증 정보를 사용하여 privateRegistry 섹션을 지정하면 사용자 클러스터를 만들지 못할 수 있습니다. 다음 메시지와 함께 프리플라이트가 실패할 수 있습니다.

    
    [FAILURE] Docker registry access: Failed to login.
    


    해결 방법:

    • 필드를 지정할 의도가 없었거나 관리자 클러스터와 동일한 비공개 레지스트리 사용자 인증 정보를 사용하려면 사용자 클러스터 구성 파일에서 privateRegistry 섹션을 삭제하거나 주석 처리하면 됩니다.
    • 사용자 클러스터에 특정 비공개 레지스트리 사용자 인증 정보를 사용하려면 다음과 같이 privateRegistry 섹션을 임시로 지정할 수 있습니다.
      
      privateRegistry:
        address: PRIVATE_REGISTRY_ADDRESS
        credentials:
          username: PRIVATE_REGISTRY_USERNAME
          password: PRIVATE_REGISTRY_PASSWORD
        caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      
      (참고: 이는 일시적인 수정에 불과하며 이러한 필드는 이미 지원 중단되었습니다. 1.14.3 이상으로 업그레이드할 때 사용자 인증 정보 파일을 사용하는 것이 좋습니다.)

    운영 1.10+

    Dataplane v2와 호환되지 않는 Anthos Service Mesh와 기타 서비스 메시

    Dataplane V2가 부하 분산을 전달받고 패킷 기반 DNAT 대신 커널 소켓을 만듭니다. 즉, 포드가 우회되고 IPTable을 사용하지 않으므로 Anthos Service Mesh가 패킷 검사를 수행할 수 없습니다.

    사이드카가 패킷 검사를 수행할 수 없으므로 Anthos Service Mesh를 사용하는 서비스에 대한 연결이 끊어지거나 잘못된 트래픽 라우팅이 발생하여 kube-proxy 없음 모드에서 이러한 문제가 나타납니다.

    이 문제는 베어메탈용 Anthos 클러스터 1.10의 모든 버전에서 발생하지만 1.10(1.10.2 이상)의 일부 최신 버전에는 해결 방법이 있습니다.


    해결 방법:

    완벽한 호환성을 위해 1.11로 업그레이드하거나 1.10.2 이상을 실행하는 경우 다음을 실행합니다.

    
        kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
        

    configmap에 bpf-lb-sock-hostns-only: true를 추가한 후 anetd daemonset를 다시 시작합니다.

    
          kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
        

    스토리지 1.12+, 1.13.3

    kube-controller-manager가 6분 후에 영구 볼륨을 강제로 분리할 수 있음

    kube-controller-manager가 6분 후 PV/PVC를 분리할 때 시간 초과되면 PV/PVC를 강제로 분리할 수 있습니다. kube-controller-manager의 자세한 로그에서 다음과 유사한 이벤트를 보여줍니다.

    
    $ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
    
    kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
    This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
    

    문제를 확인하려면 노드에 로그인하고 다음 명령어를 실행합니다.

    
    # See all the mounting points with disks
    lsblk -f
    
    # See some ext4 errors
    sudo dmesg -T
    

    kubelet 로그에는 다음과 같은 오류가 표시됩니다.

    
    Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
    the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
    

    해결 방법:

    SSH를 사용하여 영향을 받는 노드에 연결하고 노드를 재부팅합니다.

    업그레이드 및 업데이트 1.12+, 1.13+, 1.14+

    서드 파티 CSI 드라이버가 사용된 경우 클러스터 업그레이드가 중단됨

    서드 파티 CSI 드라이버를 사용하는 경우 클러스터를 업그레이드하지 못할 수 있습니다. gkectl cluster diagnose 명령어가 다음 오류를 반환할 수 있습니다.

    
    "virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
    


    해결 방법:

    --skip-validation-all 옵션을 사용하여 업그레이드를 수행합니다.

    작업 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master가 VM 하드웨어 버전을 업그레이드하지 않고 관리자 마스터 VM을 생성함

    gkectl repair admin-master를 통해 생성된 관리자 마스터 노드는 예상보다 낮은 VM 하드웨어 버전을 사용할 수 있습니다. 문제가 발생하면 gkectl diagnose cluster 보고서에서 오류를 확인할 수 있습니다.

    
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    해결 방법:

    관리자 마스터 노드를 종료하고 https://kb.vmware.com/s/article/1003746을 따라 오류 메시지에 설명된 예상 버전으로 노드를 업그레이드한 다음 노드를 시작합니다.

    운영체제 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+

    예상치 못한 종료 또는 재부팅 시 VM이 DHCP 임대를 해제하여 IP가 변경될 수 있음

    systemd v244의 systemd-networkd에는 KeepConfiguration 구성에 대한 기본 동작 변경이 있습니다. 변경 전에는 VM이 종료 또는 재부팅 시 DHCP 서버에 DHCP 임대 해제 메시지를 전송하지 않았습니다. 변경 후에는 VM에서 이러한 메시지를 전송하고 IP를 DHCP 서버로 반환합니다. 따라서 해제된 IP가 다른 VM에 재할당되거나 다른 IP가 VM에 할당되어 (vSphere 수준이 아닌 Kubernetes 수준에서) IP 충돌이 발생하거나 VM에서 IP가 변경되어 다양한 방식으로 클러스터가 손상될 수 있습니다.

    예를 들어 다음과 같은 증상이 나타날 수 있습니다.

    • vCenter UI에는 동일한 IP를 사용하는 VM이 없다고 표시되지만 kubectl get nodes -o wide에서 중복 IP가 있는 노드를 반환합니다.
      
      NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
      node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
      node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • calico-node 오류로 인해 새 노드를 시작할 수 없습니다.
      
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
      2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
      2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
      2023-01-19T22:07:08.828218856Z Calico node failed to start


    해결 방법:

    클러스터에 다음 DaemonSet를 배포하여 systemd-networkd 기본 동작 변경을 되돌립니다. 이 DaemonSet를 실행하는 VM은 종료 또는 재부팅 시 IP를 DHCP 서버에 해제하지 않습니다. IP는 임대가 만료되면 DHCP 서버에 의해 자동으로 해제됩니다.

    
          apiVersion: apps/v1
          kind: DaemonSet
          metadata:
            name: set-dhcp-on-stop
          spec:
            selector:
              matchLabels:
                name: set-dhcp-on-stop
            template:
              metadata:
                labels:
                  name: set-dhcp-on-stop
              spec:
                hostIPC: true
                hostPID: true
                hostNetwork: true
                containers:
                - name: set-dhcp-on-stop
                  image: ubuntu
                  tty: true
                  command:
                  - /bin/bash
                  - -c
                  - |
                    set -x
                    date
                    while true; do
                      export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                      grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                      if (( $? != 0 )) ; then
                        echo "Setting KeepConfiguration=dhcp-on-stop"
                        sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                        cat "${CONFIG}"
                        chroot /host systemctl restart systemd-networkd
                      else
                        echo "KeepConfiguration=dhcp-on-stop has already been set"
                      fi;
                      sleep 3600
                    done
                  volumeMounts:
                  - name: host
                    mountPath: /host
                  resources:
                    requests:
                      memory: "10Mi"
                      cpu: "5m"
                  securityContext:
                    privileged: true
                volumes:
                - name: host
                  hostPath:
                    path: /
                tolerations:
                - operator: Exists
                  effect: NoExecute
                - operator: Exists
                  effect: NoSchedule
          

    작업, 업그레이드 및 업데이트 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    관리자 클러스터가 1.11.x에서 업그레이드된 후 구성요소 액세스 서비스 계정 키가 삭제됨

    이 문제는 1.11.x에서 업그레이드된 관리자 클러스터에만 영향을 주며 1.12 이후 새로 생성된 관리자 클러스터에는 영향을 주지 않습니다.

    1.11.x 클러스터를 1.12.x로 업그레이드하면 admin-cluster-creds 보안 비밀의 component-access-sa-key 필드가 삭제되어 비어 있게 됩니다. 다음 명령어를 실행하여 확인할 수 있습니다.

    
    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    출력이 비어 있으면 키가 완전 삭제되었다는 의미입니다.

    구성요소 액세스 서비스 계정 키가 삭제되면 새 사용자 클러스터를 설치하거나 기존 사용자 클러스터를 업그레이드할 수 없습니다. 다음은 표시될 수 있는 오류 메시지입니다.

    • 느린 검증 프리플라이트 실패, 오류 메시지: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • gkectl prepare 준비 실패, 오류 메시지: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Google Cloud 콘솔 또는 gcloud CLI를 사용하여 1.13 사용자 클러스터를 업그레이드하는 경우 gkectl update admin --enable-preview-user-cluster-central-upgrade를 실행하여 플랫폼 컨트롤러를 배포하면 명령어가 "failed to download bundle to disk: dialing: unexpected end of JSON input" 메시지와 함께 실패합니다. kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml 출력의 status 필드에서 이 메시지를 확인할 수 있습니다.


    해결 방법:

    다음 명령어를 실행하여 구성요소 액세스 서비스 계정 키를 보안 비밀에 다시 수동으로 추가합니다.

    
    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

    작업 1.13.0+, 1.14.0+

    Controlplane V2가 사용 설정된 경우 클러스터 자동 확장 처리가 작동하지 않음

    Controlplane V2 또는 새 설치 모델로 만든 사용자 클러스터에서 자동 확장이 사용 설정된 노드 풀이 항상 user-cluster.yaml에 autoscaling.minReplicas를 사용합니다. 클러스터 자동 확장 처리 포드의 로그에도 비정상으로 표시됩니다.

    
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
      logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
     TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
     TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
      
    다음 명령어를 실행하면 클러스터 자동 확장 처리 포드를 찾을 수 있습니다.
    
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
       get pods | grep cluster-autoscaler
    cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s
      


    해결 방법:

    수정사항이 포함된 버전으로 업그레이드할 때까지 `gkectl 업데이트 클러스터`가 있는 모든 노드 풀에서 자동 확장을 중지합니다.

    설치 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    CIDR이 IP 블록 파일에서 허용되지 않음

    사용자가 IP 블록 파일에서 CIDR을 사용하는 경우 구성 검증이 실패하며 다음 오류가 반환됩니다.

    
    - Validation Category: Config Check
        - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
    172.16.20.12/30
      


    해결 방법:

    수정사항이 포함된 버전(1.12.5, 1.13.4, 1.14.1 이상)으로 업그레이드할 때까지 IP 블록 파일에 개별 IP를 포함합니다.

    업그레이드 및 업데이트 1.14.0-1.14.1

    admin-cluster.yaml의 OS 이미지 유형 업데이트가 사용자 제어 영역 머신이 다시 생성될 때까지 대기하지 않음

    admin-cluster.yaml에서 제어 영역 OS 이미지 유형을 업데이트할 때 해당 사용자 클러스터가 Controlplane V2를 통해 생성된 경우 gkectl 명령어가 완료될 때 사용자 제어 영역 머신의 재생성이 완료되지 않을 수 있습니다.


    해결 방법:

    업데이트가 완료되면 kubectl --kubeconfig USER_KUBECONFIG get nodes -owide를 사용하여 노드 OS 이미지 유형을 모니터링하여 사용자 제어 영역 머신의 재생성이 완료될 때까지 기다립니다. 예: Ubuntu에서 COS로 업데이트하는 경우 업데이트 명령어가 완료된 후에도 모든 제어 영역 머신이 Ubuntu에서 COS로 완전히 변경될 때까지 기다려야 합니다.

    작업 1.14.0

    Calico CNI 서비스 계정 인증 토큰 문제로 인한 포드 생성 또는 삭제 오류

    VMware용 Anthos 클러스터 1.14.0에서 Calico 문제가 발생하면 포드 생성 및 삭제가 실패하며 kubectl describe pods 출력에서 다음 오류 메시지가 반환됩니다.

    
      error getting ClusterInformation: connection is unauthorized: Unauthorized
      

    이 문제는 Calico를 사용하여 클러스터를 만들거나 1.14로 업그레이드한 후 24시간이 지나야만 관측됩니다.

    관리자 클러스터는 항상 Calico를 사용하는 반면 사용자 클러스터의 경우 user-cluster.yaml에 구성 필드 `enableDataPlaneV2`가 있습니다. 해당 필드가 `false`로 설정되었거나 지정되지 않은 경우 사용자 클러스터에 Calico가 사용됩니다.

    노드의 install-cni 컨테이너는 24시간 동안 유효한 토큰으로 kubeconfig를 만듭니다. 이 토큰은 calico-node 포드에 의해 주기적으로 갱신되어야 합니다. calico-node 포드는 노드의 kubeconfig 파일이 포함된 디렉터리에 액세스할 수 없으므로 토큰을 갱신할 수 없습니다.


    해결 방법:

    이 문제를 완화하려면 관리자 및 사용자 클러스터의 calico-node DaemonSet에 다음 패치를 적용합니다.

    
      kubectl -n kube-system get daemonset calico-node \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
        | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
        | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
    
      kubectl -n kube-system get daemonset calico-node \
        --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
        | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
        | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
      
    다음을 바꿉니다.
    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • USER_CLUSTER_CONFIG_FILE: 사용자 클러스터 구성 파일의 경로입니다.
    설치 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    CIDR을 사용할 때 IP 블록 검증 실패

    사용자가 적절한 구성을 사용하더라도 클러스터 생성이 실패합니다. 클러스터에 IP가 충분하지 않아 사용자에게 생성 실패가 표시됩니다.


    해결 방법:

    CIDR을 작은 CIDR 블록 여러 개로 분할(예: 10.0.0.0/3010.0.0.0/31, 10.0.0.2/31로)합니다. CIDR이 N+1개(N은 클러스터의 노드 수)면 충분합니다.

    작업, 업그레이드 및 업데이트 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    관리자 클러스터 백업에 상시 보안 비밀 암호화 키 및 구성이 포함되지 않음

    클러스터 백업과 함께 상시 보안 비밀 암호화 기능이 사용 설정되면 관리자 클러스터 백업에 상시 보안 비밀 암호화 기능에 필요한 암호화 키와 구성이 포함되지 않습니다. 따라서 gkectl repair admin-master --restore-from-backup을 사용하여 이 백업으로 관리자 마스터를 복구하면 다음 오류가 발생합니다.

    
    Validating admin master VM xxx ...
    Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
    Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
    Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
    Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
    Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
    Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
    

    작업, 업그레이드 및 업데이트 1.10+

    `gkectl update` 명령어를 사용하여 상시 가동 보안 비밀 암호화 기능을 사용 설정하면 새 부팅 디스크(예: gkectl repair admin-master)로 관리자 마스터 VM 다시 만들 수 없음

    클러스터 생성 시 상시 보안 비밀 암호화 기능을 사용 설정하지 않고 나중에 gkectl update 작업을 사용하여 사용 설정하면 gkectl repair admin-master가 관리자 클러스터 제어 영역 노드를 복구하지 못합니다. 클러스터를 만들 때 상시 보안 비밀 암호화 기능을 사용 설정하는 것이 좋습니다. 현재 이 문제의 완화 방법은 없습니다.

    업그레이드 및 업데이트 1.10

    첫 번째 사용자 클러스터를 1.9에서 1.10으로 업그레이드하면 다른 사용자 클러스터에 노드가 다시 생성됩니다.

    첫 번째 사용자 클러스터를 1.9에서 1.10으로 업그레이드하면 동일한 관리자 클러스터의 다른 사용자 클러스터에 노드가 다시 생성될 수 있습니다. 재생성은 순차적으로 수행됩니다.

    disk_labelMachineTemplate.spec.template.spec.providerSpec.machineVariables에서 삭제되어 모든 MachineDeployment에서 예기치 않은 업데이트가 트리거되었습니다.


    해결 방법:

    업그레이드 및 업데이트 1.10.0

    클러스터 업그레이드 후 Docker가 자주 다시 시작됨

    사용자 클러스터를 1.10.0으로 업그레이드하면 Docker가 다시 시작되는 경우가 많습니다.

    kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG를 실행하여 이 문제를 감지할 수 있습니다.

    노드 조건에 Docker가 자주 다시 시작하는지 여부가 표시됩니다. 출력 예시는 다음과 같습니다.

    
    Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
    

    근본 원인을 파악하려면 증상이 있는 노드에 SSH를 설정하고 sudo journalctl --utc -u docker 또는 sudo journalctl -x와 같은 명령어를 실행해야 합니다.


    해결 방법:

    업그레이드 및 업데이트 1.11, 1.12

    버전 1.12로 업그레이드한 후 자체 배포된 GMP 구성요소가 보존되지 않음

    VMware용 Anthos 클러스터 버전 1.12 미만을 사용하고 클러스터의 gmp-system 네임스페이스에서 Google 관리 Prometheus(GMP) 구성요소를 수동으로 설정한 경우 버전 1.12.x로 업그레이드하면 구성요소가 보존되지 않습니다.

    버전 1.12부터 gmp-system 네임스페이스 및 CRD의 GMP 구성요소를 stackdriver 객체에서 관리하며 enableGMPForApplications 플래그가 기본적으로 false로 설정됩니다. 1.12로 업그레이드하기 전에 네임스페이스에 GMP 구성요소를 수동으로 배포하면 stackdriver가 리소스를 삭제합니다.


    해결 방법:

    작업 1.11, 1.12, 1.13.0 - 1.13.1

    클러스터 스냅샷 system 시나리오에서 ClusterAPI 객체가 누락됨

    system 시나리오에서 클러스터 스냅샷의 default 네임스페이스 아래에 리소스가 포함되지 않습니다.

    하지만 이 네임스페이스 아래에 있는 Cluster API 객체 등 일부 Kubernetes 리소스에 유용한 디버깅 정보가 포함되어 있습니다. 디버깅 정보가 클러스터 스냅샷에 포함되어야 합니다.


    해결 방법:

    다음 명령어를 수동으로 실행하여 디버깅 정보를 수집할 수 있습니다.

    
    export KUBECONFIG=USER_CLUSTER_KUBECONFIG
    kubectl get clusters.cluster.k8s.io -o yaml
    kubectl get controlplanes.cluster.k8s.io -o yaml
    kubectl get machineclasses.cluster.k8s.io -o yaml
    kubectl get machinedeployments.cluster.k8s.io -o yaml
    kubectl get machines.cluster.k8s.io -o yaml
    kubectl get machinesets.cluster.k8s.io -o yaml
    kubectl get services -o yaml
    kubectl describe clusters.cluster.k8s.io
    kubectl describe controlplanes.cluster.k8s.io
    kubectl describe machineclasses.cluster.k8s.io
    kubectl describe machinedeployments.cluster.k8s.io
    kubectl describe machines.cluster.k8s.io
    kubectl describe machinesets.cluster.k8s.io
    kubectl describe services
    
    각 매개변수는 다음과 같습니다.

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

    업그레이드 및 업데이트 1.11.0~1.11.4, 1.12.0~1.12.3, 1.13.0~1.13.1

    vSAN 설정을 위한 노드 드레이닝 중에 사용자 클러스터 삭제가 중단됨

    다음 시나리오에서 사용자 클러스터를 삭제, 업데이트 또는 업그레이드할 때 노드 드레이닝이 중단될 수 있습니다.

    • 버전 1.12.x부터 관리자 클러스터가 vSAN에서 vSphere CSI 드라이버를 사용해 왔습니다.
    • 관리자 클러스터와 사용자 클러스터에 트리 내 vSphere 플러그인이 만든 PVC/PV 객체가 없습니다.

    증상을 확인하려면 아래 명령어를 실행합니다.

    
    kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
    

    다음은 위 명령어의 샘플 오류 메시지입니다.

    
    E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
    

    kubevols는 vSphere 트리 내 드라이버의 기본 디렉터리입니다. 생성된 PVC/PV 객체가 없으면 현재 구현에서 kubevols가 항상 존재한다고 가정하기 때문에 kubevols를 찾는 중에 노드 드레이닝이 중단되는 버그가 발생할 수 있습니다.


    해결 방법:

    노드가 생성된 Datastore에 kubevols 디렉터리를 만듭니다. 이는 user-cluster.yaml 또는 admin-cluster.yaml 파일의 vCenter.datastore 필드에서 정의됩니다.

    구성 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    사용자 클러스터를 삭제한 후 Cluster Autoscaler clusterrolebinding 및 clusterrole이 삭제됩니다.

    사용자 클러스터를 삭제하면 클러스터 자동 확장 처리에 해당하는 clusterroleclusterrolebinding도 삭제됩니다. 이는 클러스터 자동 확장 처리가 사용 설정된 동일한 관리자 클러스터에 있는 다른 모든 사용자 클러스터에 영향을 줍니다. 이는 동일한 관리자 클러스터 내의 모든 클러스터 자동 확장 처리 포드에 동일한 clusterrole 및 clusterrolebinding이 사용되기 때문입니다.

    증상은 다음과 같습니다.

    • cluster-autoscaler 로그
    • 
      kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
      cluster-autoscaler
      
      여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다. 다음은 표시될 수 있는 오류 메시지의 예시입니다.
      
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
      2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
      

    해결 방법:

    구성 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    사용자 클러스터 삭제 후 관리자 클러스터 cluster-health-controllervsphere-metrics-exporter가 작동하지 않음

    사용자 클러스터를 삭제하면 해당 clusterrole도 삭제되어 자동 복구 및 vsphere 측정항목 내보내기가 작동하지 않습니다.

    증상은 다음과 같습니다.

    • cluster-health-controller 로그
    • 
      kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
      cluster-health-controller
      
      여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다. 다음은 표시될 수 있는 오류 메시지의 예시입니다.
      
      error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
      
    • vsphere-metrics-exporter 로그
    • 
      kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
      vsphere-metrics-exporter
      
      여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다. 다음은 표시될 수 있는 오류 메시지의 예시입니다.
      
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
      

    해결 방법:

    구성 1.12.1-1.12.3, 1.13.0-1.13.2

    OS 이미지 검증 시 gkectl check-config 실패

    gkectl prepare를 실행하지 않고 gkectl check-config를 실패할 수 있는 알려진 문제입니다. gkectl prepare를 실행하기 전에 명령어를 실행하도록 권장하므로 혼동될 수 있습니다.

    gkectl check-config 명령어가 실패하며 다음 오류 메시지가 반환되는 증상을 보입니다.

    
    Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
    

    해결 방법:

    옵션 1: gkectl prepare을 실행하여 누락된 OS 이미지를 업로드합니다.

    옵션 2: gkectl check-config --skip-validation-os-images를 사용하여 OS 이미지 검증을 건너뜁니다.

    업그레이드 및 업데이트 1.11, 1.12, 1.13

    안티어피니티 그룹 업데이트 시 gkectl update admin/cluster 실패

    anti affinity groups 업데이트 시 gkectl update admin/cluster를 실패할 수 있는 알려진 문제입니다.

    gkectl update 명령어가 실패하며 다음 오류 메시지가 반환되는 증상을 보입니다.

    
    Waiting for machines to be re-deployed...  ERROR
    Exit with error:
    Failed to update the cluster: timed out waiting for the condition
    

    해결 방법:

    설치, 업그레이드 및 업데이트 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    구성된 호스트 이름에 마침표가 포함된 경우 노드를 등록할 수 없음

    ipMode.typestatic이고 IP 블록 파일의 구성된 호스트 이름에 마침표가 1개 이상 포함된 경우 클러스터 생성, 업그레이드, 업데이트, 노드 자동 복구 중에 노드 등록이 실패합니다. 이 경우 노드의 인증서 서명 요청(CSR)이 자동으로 승인되지 않습니다.

    노드의 대기 중인 CSR을 보려면 다음 명령어를 실행합니다.

    
    kubectl get csr -A -o wide
    

    다음 로그에서 오류 메시지를 확인합니다.

    • 관리자 클러스터에서 clusterapi-controllers 포드의 clusterapi-controller-manager 컨테이너에 대한 로그를 봅니다.
      
      kubectl logs clusterapi-controllers-POD_NAME \
          -c clusterapi-controller-manager -n kube-system \
          --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      
    • 사용자 클러스터에서 동일한 로그를 보려면 다음 명령어를 실행하세요.
      
      kubectl logs clusterapi-controllers-POD_NAME \
          -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
          --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      
      각 항목의 의미는 다음과 같습니다.
      • ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다.
      • USER_CLUSTER_NAME은 사용자 클러스터 이름입니다.
      다음은 표시될 수 있는 오류 메시지의 예시입니다. "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • 문제가 있는 노드의 kubelet 로그를 봅니다.
      
      journalctl --u kubelet
      
      다음은 표시될 수 있는 오류 메시지의 예시입니다. "Error getting node" err="node \"node-worker-vm-1\" not found"

    IP 블록 파일의 호스트 이름 필드에 도메인 이름을 지정하면 첫 번째 마침표 뒤에 오는 모든 문자가 무시됩니다. 예를 들어 호스트 이름을 bob-vm-1.bank.plc로 지정하면 VM 호스트 이름과 노드 이름이 bob-vm-1로 설정됩니다.

    노드 ID 확인이 사용 설정되었으면 CSR 승인자가 노드 이름을 머신 사양의 호스트 이름과 비교하며 이름을 조정하지 못합니다. 승인자가 CSR을 거부하고 노드가 부트스트랩에 실패합니다.


    해결 방법:

    사용자 클러스터

    다음 단계를 완료하여 노드 ID 확인을 중지합니다.

    1. 사용자 클러스터 구성 파일에 다음 필드를 추가하세요.
      
      disableNodeIDVerification: true
      disableNodeIDVerificationCSRSigning: true
      
    2. 파일을 저장하고 다음 명령어를 실행하여 사용자 클러스터를 업데이트합니다.
      
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config USER_CLUSTER_CONFIG_FILE
      
      다음을 바꿉니다.
      • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
      • USER_CLUSTER_CONFIG_FILE: 사용자 클러스터 구성 파일의 경로입니다.

    관리자 클러스터

    1. 수정할 OnPremAdminCluster 커스텀 리소스를 엽니다.
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          edit onpremadmincluster -n kube-system
      
    2. 다음 주석을 커스텀 리소스에 추가합니다.
      
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
      
    3. 관리자 클러스터 제어 영역에서 kube-controller-manager 매니페스트를 수정합니다.
      1. SSH로 관리자 클러스터 제어 영역 노드에 연결합니다.
      2. 수정할 kube-controller-manager 매니페스트를 엽니다.
        
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
        
      3. controllers 목록을 찾습니다.
        
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
        
      4. 아래와 같이 이 섹션을 업데이트합니다.
        
        --controllers=*,bootstrapsigner,tokencleaner
        
    4. 수정할 Deployment Cluster API 컨트롤러를 엽니다.
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          edit deployment clusterapi-controllers -n kube-system
      
    5. node-id-verification-enablednode-id-verification-csr-signing-enabled 값을 false로 변경합니다.
      
      --node-id-verification-enabled=false
      --node-id-verification-csr-signing-enabled=false
      
    설치, 업그레이드 및 업데이트 1.11.0~1.11.4

    비공개 레지스트리 인증서 번들로 인한 관리자 제어 영역 머신 시작 실패

    관리자 클러스터 생성/업그레이드가 다음 로그에서 계속 중단되다가 결국에는 시간 초과됩니다.

    
    Waiting for Machine gke-admin-master-xxxx to become ready...
    

    외부 클러스터 스냅샷의 Cluster API 컨트롤러 로그에 다음 로그가 포함됩니다.

    
    Invalid value 'XXXX' specified for property startup-data
    

    다음은 Cluster API 컨트롤러 로그의 파일 경로 예시입니다.

    
    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
        

    VMware has a 64k vApp property size limit. In the identified versions, the data passed via vApp property is close to the limit. When the private registry certificate contains a certificate bundle, it may cause the final data to exceed the 64k limit.


    Workaround:

    Only include the required certificates in the private registry certificate file configured in privateRegistry.caCertPath in the admin cluster config file.

    Or upgrade to a version with the fix when available.

    네트워킹 1.10, 1.11.0~1.11.3, 1.12.0~1.12.2, 1.13.0

    동시 상태 업데이트 충돌로 인해 NetworkGatewayNodes가 비정상으로 표시됨

    networkgatewaygroups.status.nodes에서 일부 노드가 NotHealthyUp 간에 전환됩니다.

    해당 노드에서 실행되는 ang-daemon 포드의 로그에 반복되는 오류가 표시됩니다.

    
    2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
    

    NotHealthy 상태일 때는 컨트롤러가 노드에 추가 유동 IP를 할당할 수 없습니다. 이로 인해 다른 노드에 부담이 가중되거나 고가용성을 위한 중복성 부족이 발생할 수 있습니다.

    그 외에는 데이터 영역 활동이 영향을 받지 않습니다.

    networkgatewaygroup 객체의 경합이 발생하면 재시도 처리의 결함으로 인해 일부 상태 업데이트가 실패합니다. 상태 업데이트가 너무 많이 실패하면 ang-controller-manager에서 노드가 하트비트 시간 제한을 넘었다고 보고 NotHealthy 노드를 표시합니다.

    이후 버전에서는 재시도 처리의 결함이 수정되었습니다.


    해결 방법:

    가능한 경우 수정된 버전으로 업그레이드하세요.

    업그레이드 및 업데이트 1.12.0~1.12.2, 1.13.0

    경합 상태로 인해 업데이트 또는 업그레이드 중에 머신 객체 삭제가 차단됨

    이전 머신 객체가 삭제될 때까지 클러스터 업그레이드 또는 업데이트가 중단될 수 있는 알려진 문제입니다. 머신 객체에서 파이널라이저를 삭제할 수 없기 때문에 발생하는 문제입니다. 이 문제는 노드 풀의 순차적 업데이트 작업에 영향을 미칩니다.

    다음 오류 메시지와 함께 gkectl 명령어가 시간 초과되는 증상을 보입니다.

    
    E0821 18:28:02.546121   61942 console.go:87] Exit with error:
    E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
    Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
    

    clusterapi-controller 포드 로그에서 이 오류는 다음과 같이 표시됩니다.

    
    $ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
        -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
        | grep "Error removing finalizer from machine object"
    [...]
    E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
    

    이 버그가 없어도 성공적인 실행을 위해 몇 분간 동일한 머신에서 오류가 반복됩니다. 대부분은 빠르게 이 과정을 거치지만, 일부 드문 경우 몇 시간 동안 경합 상태에서 중단될 수 있습니다.

    문제는 기본 VM이 vCenter에서 이미 삭제되었지만 해당 머신 객체를 삭제할 수 없으며 다른 컨트롤러가 자주 업데이트되어 파이널라이저 삭제가 중단된다는 것입니다. 이로 인해 gkectl 명령어가 시간 초과될 수 있지만 컨트롤러가 클러스터를 계속 조정하므로 결국에는 업그레이드 또는 업데이트 프로세스가 완료됩니다.


    해결 방법:

    환경 및 요구사항에 따라 이 문제의 여러 완화 옵션을 준비했습니다.

    • 옵션 1: 업그레이드가 자체적으로 완료될 때까지 기다립니다.

      환경의 분석 및 재현에 따라 업그레이드는 수동 개입 없이 자체적으로 완료될 수 있습니다. 이 옵션의 주의해야 할 점은 파이널라이저 제거가 각 머신 객체에 적용되는 데 걸리는 시간이 불확실하다는 것입니다. 운이 좋으면 즉시 적용될 수도 있고, 머신 세트 컨트롤러 조정 속도가 너무 빠르고 머신 컨트롤러가 조정 사이에서 파이널라이저를 삭제할 기회가 없을 경우에는 몇 시간이 걸릴 수 있습니다.

      다행히 이 옵션은 사용자의 조치가 필요하지 않으며 워크로드가 중단되지 않습니다. 업그레이드가 완료되는 데 시간이 더 걸릴 뿐입니다.
    • 옵션 2: 모든 이전 머신 객체에 자동 복구 주석을 적용합니다.

      머신 세트 컨트롤러가 자동 복구 주석과 삭제 타임스탬프가 0이 아닌 머신을 필터링하고 해당 머신에서 삭제 호출을 계속 수행하지 않으므로 경합 상태를 방지하는 데 도움이 됩니다.

      단점은 머신의 포드가 제거되는 대신 직접 삭제된다는 점입니다. 즉, PDB 구성을 고려하지 않아 워크로드에 다운타임이 발생할 수 있습니다.

      모든 머신 이름을 가져오는 명령어는 다음과 같습니다.
      
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      
      각 머신에 자동 복구 주석을 적용하는 명령어는 다음과 같습니다.
      
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
          machine MACHINE_NAME \
          onprem.cluster.gke.io/repair-machine=true
      

    이 문제가 발생하고 오랜 시간이 지나도 업그레이드/업데이트가 여전히 완료되지 않으면 지원팀에 연락하여 완화 방법을 문의하세요.

    설치, 업그레이드 및 업데이트 1.10.2, 1.11, 1.12, 1.13

    gkectl prepare OS 이미지 검증 프리플라이트 실패

    gkectl prepare 명령어 실패:

    
    - Validation Category: OS Images
        - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
    

    gkectl prepare의 프리플라이트 검사에 잘못된 검증이 포함되었습니다.


    해결 방법:

    추가 플래그 --skip-validation-os-images로 같은 명령어를 실행합니다.

    설치 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    https:// 또는 http:// 프리픽스가 있는 vCenter URL로 인해 클러스터 시작 오류 발생

    관리자 클러스터 생성 실패:

    
    Exit with error:
    Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
    Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
    [data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
    (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
    Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
    (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
    

    URL이 '/' 또는 ':'을 지원하지 않는 보안 비밀 키의 일부로 사용됩니다.


    해결 방법:

    관리자 클러스터 또는 사용자 클러스터 구성 yaml의 vCenter.Address 필드에서 https:// 또는 http:// 프리픽스를 삭제합니다.

    설치, 업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    util.CheckFileExistsgkectl prepare 패닉

    gkectl prepare는 다음 스택 트레이스로 패닉할 수 있습니다.

    
    panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
    
    goroutine 1 [running]:
    gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
    gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
    ...
    

    gkectl prepare가 잘못된 권한으로 비공개 레지스트리 인증서 디렉터리를 만드는 것이 문제입니다.


    해결 방법:

    이 문제를 해결하려면 관리자 워크스테이션에서 다음 명령어를 실행하세요.

    
    sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    
    업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    gkectl repair admin-master 및 재개 가능한 관리자 업그레이드가 함께 작동하지 않음

    관리자 클러스터 업그레이드 시도 실패 후 gkectl repair admin-master를 실행하지 마세요. 이렇게 하면 관리자 마스터 전원 오류 또는 VM에 액세스 불가와 같은 문제로 인해 후속 관리자 업그레이드 시도가 실패할 수 있습니다.


    해결 방법:

    이 실패 시나리오가 이미 발생했으면 지원팀에 문의하세요.

    업그레이드 및 업데이트 1.10, 1.11

    관리자 클러스터 업그레이드를 재개하면 관리자 제어 영역 VM 템플릿이 누락될 수 있음

    관리자 클러스터 업그레이드 시도가 재개된 후 관리자 제어 영역 머신이 다시 생성되지 않으면 관리자 제어 영역 VM 템플릿이 삭제됩니다. 관리자 제어 영역 VM 템플릿은 gkectl repair admin-master로 제어 영역 머신을 복구하는 데 사용되는 관리자 마스터의 템플릿입니다.


    해결 방법:

    관리자 제어 영역 VM 템플릿은 다음 관리자 클러스터 업그레이드 중에 다시 생성됩니다.

    운영체제 1.12, 1.13

    cgroup v2는 워크로드에 영향을 줄 수 있음

    버전 1.12.0에서는 Container Optimized OS(COS) 노드에 cgroup v2(통합)가 기본적으로 사용 설정됩니다. 이 경우 COS 클러스터의 워크로드가 불안정해질 수 있습니다.


    해결 방법:

    버전 1.12.1에서 cgroup v1(하이브리드)로 다시 전환했습니다. COS 노드를 사용하는 경우 출시되는 즉시 버전 1.12.1로 업그레이드하는 것이 좋습니다.

    ID 1.10, 1.11, 1.12, 1.13

    ClientConfig 커스텀 리소스

    gkectl update가 ClientConfig 커스텀 리소스에서 수행한 수동 변경사항을 되돌립니다.


    해결 방법:

    수동으로 변경한 후 항상 ClientConfig 리소스를 백업하는 것이 좋습니다.

    설치 1.10, 1.11, 1.12, 1.13

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

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

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


    해결 방법:

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

    설치 1.12

    cert-manager/ca-injector의 리더 선택 문제로 인해 사용자 클러스터 설치 실패

    apiserver/etcd가 느릴 때 crashloop의 cert-manager-cainjector로 인해 설치 장애가 발생할 수 있습니다.

    
    # These are logs from `cert-manager-cainjector`, from the command
    # `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
      cert-manager-cainjector-xxx`
    
    I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
    
    E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
      Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
    
    I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
    
    E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
    

    해결 방법:

    보안, 업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

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

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

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

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

    해결 방법:

    VMware 1.10, 1.11, 1.12, 1.13

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

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

    관련 govmomi 버그


    해결 방법:

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

    1. 이 문제는 vCenter 버전 7.0U2 이상에서 해결되었습니다.
    2. 하위 버전의 경우 호스트를 마우스 오른쪽 버튼으로 클릭한 다음 연결 > 연결 해제를 선택합니다. 그런 다음 다시 연결하세요. 그러면 VM의 포트 그룹 업데이트가 강제로 수행됩니다.
    운영체제 1.10, 1.11, 1.12, 1.13

    원격 호스트에서 SSH 연결 종료

    VMware용 Anthos 클러스터 버전 1.7.2 이상의 경우 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화됩니다.

    CIS 규칙 '5.2.16 SSH 유휴 제한 시간 간격이 구성되었는지 확인'을 충족하도록 /etc/ssh/sshd_config가 다음과 같이 설정됩니다.

    
    ClientAliveInterval 300
    ClientAliveCountMax 0
    

    이 설정의 목적은 유휴 시간 5분이 지난 후 클라이언트 세션을 종료하는 것입니다. 하지만 ClientAliveCountMax 0 값은 예기치 않은 동작을 가져옵니다. 관리자 워크스테이션 또는 클러스터 노드에서 SSH 세션을 사용하면 SSH 클라이언트가 유휴 상태가 아니더라도 SSH 연결이 끊길 수 있습니다. 예를 들어 시간이 오래 걸리는 명령어를 실행하면 다음 메시지와 함께 명령어가 종료될 수 있습니다.

    
    Connection to [IP] closed by remote host.
    Connection to [IP] closed.
    

    해결 방법:

    다음 중 원하는 방법을 선택하면 됩니다.

    • SSH 연결이 끊길 때 명령어가 종료되지 않도록 nohup를 사용합니다.
      
      nohup gkectl upgrade admin --config admin-cluster.yaml \
          --kubeconfig kubeconfig
      
    • 0이 아닌 ClientAliveCountMax 값을 사용하도록 sshd_config를 업데이트합니다. CIS 규칙에서는 3보다 작은 값을 사용하는 것을 권장합니다.
      
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
          /etc/ssh/sshd_config
      sudo systemctl restart sshd
      

    SSH 세션을 다시 연결해야 합니다.

    설치 1.10, 1.11, 1.12, 1.13

    cert-manager 설치 충돌

    1.13 버전에서 monitoring-operatorcert-manager 네임스페이스에 cert-manager를 설치합니다. 특정한 이유로 cert-manager를 직접 설치해야 하는 경우 충돌을 피하려면 다음 안내를 따르세요.

    이 작업을 각각의 클러스터에 대해 한 번만 적용하면 클러스터 업그레이드 시 변경사항이 유지됩니다.

    자체 cert-manager 설치 시 일반적인 증상 중 하나는 cert-manager 버전 또는 이미지(예: v1.7.2)가 이전 버전으로 되돌아갈 수 있다는 것입니다. 이 문제는 monitoring-operator에서 cert-manager 조정을 시도하며 그 과정에서 버전을 되돌리기 때문에 발생합니다.

    해결 방법:

    업그레이드 중에 충돌 방지

    1. 보유한 cert-manager 버전을 제거합니다. 자체 리소스를 정의한 경우 백업할 수 있습니다.
    2. 업그레이드를 수행합니다.
    3. 다음 안내에 따라 자체 cert-manager를 복원하세요.

    사용자 클러스터에서 고유한 cert-manager 복원

    • monitoring-operator 배포를 0으로 축소합니다.
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          -n USER_CLUSTER_NAME \
          scale deployment monitoring-operator --replicas=0
      
    • monitoring-operator에서 관리하는 cert-manager 배포를 0으로 축소합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n cert-manager scale deployment cert-manager --replicas=0
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n cert-manager scale deployment cert-manager-cainjector\
          --replicas=0
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n cert-manager scale deployment cert-manager-webhook --replicas=0
      
    • cert-manager 버전을 다시 설치합니다. 존재하는 경우 맞춤설정된 리소스를 복원합니다.
    • 업스트림 기본 cert-manager 설치를 사용하거나 cert-manager가 cert-manager 네임스페이스에 설치되어 있는 경우 이 단계를 건너뛸 수 있습니다. 그렇지 않으면 cert-manager에서 metrics-ca cert-manager.io/v1 인증서 및 metrics-pki.cluster.local 발급기관 리소스를 설치된 cert-manager의 클러스터 리소스 네임스페이스에 복사합니다.
      
      relevant_fields='
      {
        apiVersion: .apiVersion,
        kind: .kind,
        metadata: {
          name: .metadata.name,
          namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
        },
        spec: .spec
      }
      '
      f1=$(mktemp)
      f2=$(mktemp)
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get issuer -n cert-manager metrics-pki.cluster.local -o json \
          | jq "${relevant_fields}" > $f1
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get certificate -n cert-manager metrics-ca -o json \
          | jq "${relevant_fields}" > $f2
      kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
      kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
      

    관리자 클러스터에서 고유한 cert-manager 복원

    일반적으로 관리자 클러스터는 VMware용 Anthos 클러스터 제어 영역 워크로드만 실행하므로 관리자 클러스터에 cert-manager를 다시 설치할 필요가 없습니다. 드물지만 관리자 클러스터에 자체 cert-manager를 설치해야 하는 경우에도 다음 안내를 따라 충돌을 방지하세요. Apigee 고객이고 Apigee에 대한 cert-manager만 필요한 경우 관리자 클러스터 명령어를 실행할 필요가 없습니다.

    • monitoring-operator 배포를 0으로 확장합니다.
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          -n kube-system scale deployment monitoring-operator --replicas=0
      
    • monitoring-operator에서 관리하는 cert-manager 배포를 0으로 축소합니다.
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          -n cert-manager scale deployment cert-manager \
          --replicas=0
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
           -n cert-manager scale deployment cert-manager-cainjector \
           --replicas=0
      
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          -n cert-manager scale deployment cert-manager-webhook \
          --replicas=0
      
    • cert-manager 버전을 다시 설치합니다. 존재하는 경우 맞춤설정된 리소스를 복원합니다.
    • 업스트림 기본 cert-manager 설치를 사용하거나 cert-manager가 cert-manager 네임스페이스에 설치되어 있는 경우 이 단계를 건너뛸 수 있습니다. 그렇지 않으면 cert-manager에서 metrics-ca cert-manager.io/v1 인증서 및 metrics-pki.cluster.local 발급기관 리소스를 설치된 cert-manager의 클러스터 리소스 네임스페이스에 복사합니다.
      
      relevant_fields='
      {
        apiVersion: .apiVersion,
        kind: .kind,
        metadata: {
          name: .metadata.name,
          namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
        },
        spec: .spec
      }
      '
      f3=$(mktemp)
      f4=$(mktemp)
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
          get issuer -n cert-manager metrics-pki.cluster.local -o json \
          | jq "${relevant_fields}" > $f3
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get certificate -n cert-manager metrics-ca -o json \
          | jq "${relevant_fields}" > $f4
      kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
      kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
      
    운영체제 1.10, 1.11, 1.12, 1.13

    docker, containerd, runc 취약점 스캔의 거짓양성

    VMware용 Anthos 클러스터와 함께 제공되는 Ubuntu OS 이미지의 Docker, containerd, runc는 Ubuntu PPA를 사용하는 특수 버전으로 고정됩니다. 이렇게 하면 VMware용 Anthos 클러스터가 모든 컨테이너 런타임 변경사항을 출시 전에 검증합니다.

    하지만 다양한 CVE 스캔 도구에서 취약점 피드로 사용하는 Ubuntu CVE Tracker에 대한 특수 버전은 알려지지 않았습니다. 따라서 Docker, containerd, runc 취약점 스캔 결과에 거짓양성이 표시됩니다.

    예를 들어 CVE 스캔 결과에 다음과 같은 거짓양성이 표시될 수 있습니다. VMware용 Anthos 클러스터의 최신 패치 버전에서는 이러한 CVE가 이미 수정되었습니다.

    CVE 수정사항은 출시 노트를 참조하세요.


    해결 방법:

    Canonical에서는 이 문제를 인식하고 있으며 수정사항은 https://github.com/canonical/sec-cvescan/issues/73에서 추적됩니다.

    업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    HA가 아닌 클러스터 업그레이드 중에 관리자와 사용자 클러스터 사이의 네트워크 연결이 잠시 중지될 수 있음

    HA가 아닌 클러스터를 1.9에서 1.10으로 업그레이드하는 경우 사용자 클러스터에 대한 kubectl exec, kubectl log, 웹훅이 잠시 동안 사용 불가능한 상태인 것을 확인할 수 있습니다. 이러한 다운타임은 최대 1분까지 걸릴 수 있습니다. 이 문제는 수신되는 요청(kubectl exec, kubectl log, 웹훅)이 사용자 클러스터의 kube-apiserver에서 처리되기 때문입니다. 사용자 kube-apiserver는 Statefulset입니다. HA가 아닌 클러스터에는 Statefulset에 대해 복제본이 하나만 있습니다. 따라서 업그레이드하는 동안 새 kube-apiserver가 아직 준비되지 않은 상태에서 이전 kube-apiserver를 사용할 수 없는 경우가 존재합니다.


    해결 방법:

    이러한 다운타임은 업그레이드 프로세스 중에만 발생합니다. 업그레이드 중 다운타임을 줄이기 위해서는 HA 클러스터로 전환하는 것이 좋습니다.

    설치, 업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    클러스터 생성 또는 업그레이드 후 HA 클러스터를 진단할 때 Konnectivity 준비 검사 실패

    HA 클러스터를 생성 또는 업그레이드하는 중 클러스터 진단에서 konnectivity 준비 검사가 실패하더라도, 대부분의 경우에는 VMware용 Anthos 클러스터의 기능(kubectl exec, kubectl log, 웹훅)에 영향을 주지 않습니다. 이 문제는 불안정한 네트워킹 또는 다른 문제로 인해 일정 기간 동안 한 두 개의 konnectivity 복제본이 준비되지 않을 수 있기 때문입니다.


    해결 방법:

    konnectity는 자동으로 복구됩니다. 30분~1시간 정도 기다린 후 클러스터 진단을 다시 실행하세요.

    운영체제 1.7, 1.8, 1.9, 1.10, 1.11

    /etc/cron.daily/aide CPU 및 메모리 급증 문제

    VMware용 Anthos 클러스터 1.7.2부터 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화되었습니다.

    따라서 CIS L1 서버 규칙인 '1.4.2 파일 시스템 무결성을 정기적으로 검증'을 준수하기 위해 aide 검사를 예약하는 /etc/cron.daily/aide 크론 스크립트가 설치되었습니다.

    크론 작업은 매일 오전 6시 25분(UTC)에 실행됩니다. 파일 시스템의 파일 수에 따라 이 aide 프로세스로 인해 해당 시간에 CPU 및 메모리 사용량이 급증할 수 있습니다.


    해결 방법:

    급증이 워크로드에 영향을 주는 경우 일일 크론 작업을 중지할 수 있습니다.

    
    sudo chmod -x /etc/cron.daily/aide
    
    네트워킹 1.10, 1.11, 1.12, 1.13

    부하 분산기와 NSX-T 스테이트풀(Stateful) 분산형 방화벽 규칙의 예기치 않은 상호작용

    VMware용 Anthos 클러스터 버전 1.9 이상을 배포할 때 NSX-T 스테이트풀(Stateful) 분산 방화벽 규칙을 사용하는 환경에 Seesaw 번들 부하 분산기가 있으면 stackdriver-operatorgke-metrics-agent-conf ConfigMap을 만들지 못하고 gke-connect-agent 포드가 비정상 종료 루프에 빠집니다.

    근본적인 문제는 Seesaw가 비대칭 연결 흐름을 사용하기 때문에 스테이트풀(Stateful) NSX-T 분산형 방화벽 규칙에서 Seesaw 부하 분산기를 통한 클라이언트에서 사용자 클러스터 API 서버로의 연결을 종료하는 것입니다. NSX-T 분산형 방화벽 규칙과의 통합 문제는 Seesaw를 사용하는 모든 VMware용 Anthos 클러스터에 영향을 미칩니다. 크기가 32K 이상인 대형 Kubernetes 객체를 만들면 애플리케이션에서 비슷한 연결 문제가 발생할 수 있습니다.


    해결 방법:

    NSX-T 분산형 방화벽 규칙을 중지하거나 Seesaw VM에 스테이트리스(Stateless) 분산형 방화벽 규칙을 사용하려면 이 안내를 따르세요.

    클러스터에 수동 부하 분산기가 사용되는 경우 이 안내에 따라 백엔드 노드 장애가 감지되었을 때 클라이언트 연결을 재설정하도록 부하 분산기를 구성합니다. 이 구성을 사용하지 않으면 서버 인스턴스가 작동 중지되었을 때 Kubernetes API 서버의 클라이언트가 몇 분 동안 응답하지 않을 수 있습니다.

    로그 기록 및 모니터링 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    예기치 않은 모니터링 청구

    VMware용 Anthos 클러스터 버전 1.10 이상에서 일부 고객의 결제 페이지에 Metrics volume에 대한 요금이 예기치 않게 높게 청구되었습니다. 이 문제는 다음 두 조건이 모두 적용되는 경우에만 영향을 미칩니다.

    • 애플리케이션 모니터링이 사용 설정됨(enableStackdriverForApplications=true)
    • Managed Service for Prometheus가 사용 설정되지 않음(enableGMPForApplications)
    • 애플리케이션 포드에 prometheus.io/scrap=true 주석 포함 (Anthos Service Mesh를 설치하면 이 주석을 추가할 수도 있습니다.)

    이 문제의 영향을 받는지 확인하려면 사용자 정의 측정항목을 나열하세요. 원치 않는 측정항목에 대한 결제가 표시되면 이 문제가 적용됩니다.


    해결 방법

    이 문제의 영향을 받는 경우 클러스터를 버전 1.12로 업그레이드하고 이 문제를 해결하는 새로운 애플리케이션 모니터링 솔루션인 managed-service-for-prometheus로 전환하는 것이 좋습니다.

  • 애플리케이션 측정항목 대비 애플리케이션 로그 컬렉션을 제어하도록 플래그를 구분합니다.
  • 번들로 포함된 Google Cloud Managed Service for Prometheus
  • 버전 1.12로 업그레이드할 수 없으면 다음 단계를 수행합니다.

    1. 원치 않는 청구가 있는 소스 포드 및 서비스를 찾습니다.
      
      kubectl --kubeconfig KUBECONFIG \
        get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
      kubectl --kubeconfig KUBECONFIG get \
        services -A -o yaml | grep 'prometheus.io/scrape: "true"'
      
    2. 포드 또는 서비스에서 prometheus.io/scrap=true 주석을 삭제합니다. Anthos Service Mesh로 주석을 추가하는 경우 Prometheus 옵션 없이 Anthos Service Mesh를 구성하거나 Istio 측정항목 병합 기능을 사용 중지하는 것이 좋습니다.
    설치 1.11, 1.12, 1.13

    vSphere 데이터 디스크를 만들 때 설치 프로그램 오류

    커스텀 역할이 잘못된 권한 수준에서 연결되면 VMware용 Anthos 클러스터 설치 프로그램이 실패할 수 있습니다.

    역할 결합이 잘못되면 govc를 사용하여 vSphere 데이터 디스크 만들기가 중지되고 디스크가 0과 같은 크기로 생성됩니다. 이 문제를 해결하려면 vSphere vCenter 수준(루트)에서 커스텀 역할을 결합해야 합니다.


    해결 방법:

    DC 수준(또는 루트보다 낮은 수준)에서 커스텀 역할을 결합하려면 루트 vCenter 수준에서 사용자에게 읽기 전용 역할도 결합해야 합니다.

    역할 생성에 대한 자세한 내용은 vCenter 사용자 계정 권한을 참조하세요.

    로그 기록 및 모니터링 1.9.0~1.9.4, 1.10.0~1.10.1

    monitoring.googleapis.com에 대한 높은 네트워크 트래픽

    사용자 워크로드가 없는 새 클러스터에서도 monitoring.googleapis.com에 대해 높은 네트워크 트래픽이 확인될 수 있습니다.

    이 문제는 버전 1.10.0-1.10.1 및 버전 1.9.0-1.9.4에 영향을 미칩니다. 이 문제는 버전 1.10.2 및 1.9.5에서 해결되었습니다.


    해결 방법:

    로그 기록 및 모니터링 1.10, 1.11

    gke-metrics-agent에 CrashLoopBackOff 오류 자주 발생

    VMware용 Anthos 클러스터 버전 1.10 이상의 경우 `stackdriver` 객체에서 `enableStackdriverForApplications`가 `true` 로 설정되면 `gke-metrics-agent` DaemonSet에서 CrashLoopBackOff 오류가 자주 발생합니다.


    해결 방법:

    이 문제를 해결하려면 다음 명령어를 실행하여 애플리케이션 측정항목 수집을 중지합니다. 이러한 명령어는 애플리케이션 로그 수집을 중지하지 않습니다.

    1. 다음 변경사항을 되돌리지 않으려면 stackdriver-operator를 축소합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system scale deploy stackdriver-operator \
          --replicas=0
      
      USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.
    2. 수정할 gke-metrics-agent-conf ConfigMap을 엽니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit configmap gke-metrics-agent-conf
      
    3. services.pipelines에서 전체 metrics/app-metrics 섹션을 주석 처리합니다.
      
      services:
        pipelines:
          #metrics/app-metrics:
          #  exporters:
          #  - googlecloud/app-metrics
          #  processors:
          #  - resource
          #  - metric_to_resource
          #  - infer_resource
          #  - disk_buffer/app-metrics
          #  receivers:
          #  - prometheus/app-metrics
          metrics/metrics:
            exporters:
            - googlecloud/metrics
            processors:
            - resource
            - metric_to_resource
            - infer_resource
            - disk_buffer/metrics
            receivers:
            - prometheus/metrics
      
    4. 수정 세션을 닫습니다.
    5. gke-metrics-agent DaemonSet를 다시 시작합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system rollout restart daemonset gke-metrics-agent
      
    로그 기록 및 모니터링 1.11, 1.12, 1.13

    대시보드에서 지원 중단된 측정항목 교체

    OOTB 대시보드에서 지원 중단된 측정항목을 사용하면 일부 빈 차트가 표시됩니다. Monitoring 대시보드에서 지원 중단된 측정항목을 찾으려면 다음 명령어를 실행합니다.

    
    gcloud monitoring dashboards list > all-dashboard.json
    
    # find deprecated metrics
    cat all-dashboard.json | grep -E \
      'kube_daemonset_updated_number_scheduled\
        |kube_node_status_allocatable_cpu_cores\
        |kube_node_status_allocatable_pods\
        |kube_node_status_capacity_cpu_cores'
    

    지원 중단된 다음 측정항목은 대체 측정항목으로 마이그레이션되어야 합니다.

    지원 중단됨대체
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods
    kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods
    kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    해결 방법:

    지원 중단된 측정항목을 교체하려면 다음 안내를 따르세요.

    1. Google Cloud Monitoring 대시보드에서 'GKE On-Prem 노드 상태'를 삭제합니다. 이 안내를 따라 'GKE On-Prem 노드 상태'를 다시 설치합니다.
    2. Google Cloud Monitoring 대시보드에서 'GKE On-Prem 노드 사용률'을 삭제합니다. 이 안내를 따라 'GKE On-Prem 노드 사용률'을 다시 설치합니다.
    3. Google Cloud Monitoring 대시보드에서 'GKE On-Prem vSphere vm health'를 삭제합니다. 이 안내에 따라 'GKE On-Prem vSphere vm health'를 다시 설치합니다.
    4. 이러한 지원 중단은 Kubernetes 1.22에 필요한 kube-state-metrics 에이전트를 v1.9에서 v2.4로 업그레이드하면 발생합니다. 커스텀 대시보드나 알림 정책에서 kube_ 프리픽스가 있는 지원 중단된 모든 kube-state-metrics 측정항목을 교체할 수 있습니다.

    로그 기록 및 모니터링 1.10, 1.11, 1.12, 1.13

    Cloud Monitoring의 알 수 없는 측정항목 데이터

    VMware용 Anthos 클러스터 버전 1.10 이상의 경우 Cloud Monitoring의 클러스터 데이터에 다음과 같이 관련이 없는 요약 측정항목이 포함될 수 있습니다.

    
    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
    

    관련 없는 요약 측정항목을 포함할 수 있는 다른 측정항목 유형은 다음과 같습니다.

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    이러한 요약 유형 측정항목은 측정항목 목록에 있지만 현재 gke-metrics-agent에서 지원되지 않습니다.

    로그 기록 및 모니터링 1.10, 1.11, 1.12, 1.13

    일부 노드에서 측정항목 누락

    모든 노드가 아닌 일부 노드에서 다음 측정항목이 누락될 수 있습니다.

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    해결 방법:

    이 문제를 해결하려면 해결 방법으로 다음 단계를 수행합니다. [버전 1.9.5 이상, 1.10.2 이상, 1.11.0]: 1~4단계를 수행하여 gke-metrics-agent의 CPU를 늘립니다.

    1. 수정할 stackdriver 리소스를 엽니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit stackdriver stackdriver
      
    2. gke-metrics-agent의 CPU 요청을 10m에서 50m으로 늘리고 CPU 한도를 100m에서 200m으로 늘리려면 다음 resourceAttrOverride 섹션을 stackdriver 매니페스트에 추가합니다.
      
      spec:
        resourceAttrOverride:
          gke-metrics-agent/gke-metrics-agent:
            limits:
              cpu: 100m
              memory: 4608Mi
            requests:
              cpu: 10m
              memory: 200Mi
      
      수정된 리소스는 다음과 비슷하게 표시되어야 합니다.
      
      spec:
        anthosDistribution: on-prem
        clusterLocation: us-west1-a
        clusterName: my-cluster
        enableStackdriverForApplications: true
        gcpServiceAccountSecretName: ...
        optimizedMetrics: true
        portable: true
        projectID: my-project-191923
        proxyConfigSecretName: ...
        resourceAttrOverride:
          gke-metrics-agent/gke-metrics-agent:
            limits:
              cpu: 200m
              memory: 4608Mi
            requests:
              cpu: 50m
              memory: 200Mi
      
    3. 변경사항을 저장하고 텍스트 편집기를 닫습니다.
    4. 변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system get daemonset gke-metrics-agent -o yaml \
          | grep "cpu: 50m"
      
      수정이 적용된 경우 명령어가 cpu: 50m을 찾습니다.
    로그 기록 및 모니터링 1.11.0~1.11.2, 1.12.0

    관리자 클러스터에서 스케줄러 및 컨트롤러 관리자 측정항목 누락

    관리자 클러스터가 이 문제의 영향을 받는 경우 이는 스케줄러 및 컨트롤러 관리자 측정항목이 없는 것입니다. 예를 들어 다음 두 측정항목이 누락됩니다.

    
    # scheduler metric example
    scheduler_pending_pods
    # controller-manager metric example
    replicaset_controller_rate_limiter_use
    

    해결 방법:

    v1.11.3 이상, v1.12.1 이상 또는 v1.13 이상으로 업그레이드합니다.

    1.11.0~1.11.2, 1.12.0

    사용자 클러스터에서 스케줄러 및 컨트롤러 관리자 측정항목 누락

    사용자 클러스터가 이 문제의 영향을 받는 경우 이는 스케줄러 및 컨트롤러 관리자 측정항목이 없는 것입니다. 예를 들어 다음 두 측정항목이 누락됩니다.

    
    # scheduler metric example
    scheduler_pending_pods
    # controller-manager metric example
    replicaset_controller_rate_limiter_use
    

    해결 방법:

    이 문제는 VMware용 Anthos 클러스터 버전 1.13.0 이상에서 수정되었습니다. 수정사항이 적용된 버전으로 클러스터를 업그레이드합니다.

    설치, 업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    생성 중 관리자 클러스터 등록 실패

    1.9.x 또는 1.10.0 버전의 관리자 클러스터를 만드는 중에 관리자 클러스터를 제공된 gkeConnect 사양으로 등록하지 못하면 다음 오류가 발생합니다.

    
    Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
    

    이 관리자 클러스터를 계속 사용할 수 있지만 나중에 관리자 클러스터를 버전 1.10.y로 업그레이드하려고 하면 다음 오류가 발생합니다.

    
    failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""
    

    해결 방법:

    ID 1.10, 1.11, 1.12, 1.13

    Anthos Identity Service를 사용하면 Connect 에이전트가 예기치 않게 다시 시작될 수 있음

    Anthos Identity Service 기능을 사용하여 Anthos Identity Service ClientConfig를 관리하는 경우 Connect 에이전트가 예기치 않게 다시 시작될 수 있습니다.


    해결 방법:

    기존 클러스터에서 이 문제가 발생한 경우 다음 중 하나를 수행할 수 있습니다.

    • Anthos Identity Service(AIS)를 사용 중지합니다. AIS를 중지해도 배포된 AIS 바이너리 또는 AIS ClientConfig는 삭제되지 않습니다. AIS를 중지하려면 다음 명령어를 실행합니다.
      
      gcloud beta container hub identity-service disable \
          --project PROJECT_NAME
      
      PROJECT_NAME을 클러스터의 Fleet 호스트 프로젝트 이름으로 바꿉니다.
    • Connect 에이전트 버전을 업그레이드할 수 있도록 클러스터를 버전 1.9.3 이상 또는 버전 1.10.1 이상으로 업데이트합니다.
    네트워킹 1.10, 1.11, 1.12, 1.13

    Cisco ACI가 직접 서버 반환(DSR)에서 작동하지 않음

    Seesaw는 DSR 모드에서 실행되며 기본적으로 데이터 영역 IP 학습 때문에 Cisco ACI에서 작동하지 않습니다.


    해결 방법:

    가능한 해결 방법은 Cisco Application Policy Infrastructure Controller(APIC)에서 Seesaw IP 주소를 L4-L7 가상 IP로 추가하여 IP 학습을 중지하는 것입니다.

    Tenant(테넌트) > Application Profiles(애플리케이션 프로필) > Application EPGs(애플리케이션 EPG) 또는 uSeg EPG로 이동하여 L4-L7 가상 IP 옵션을 구성할 수 있습니다. IP 학습을 중지하지 못하면 IP 엔드포인트가 Cisco API 패브릭의 여러 위치 간에 플랩됩니다.

    VMware 1.10, 1.11, 1.12, 1.13

    vSphere 7.0 업데이트 3 문제

    최근 VMWare에서는 다음과 같은 vSphere 7.0 업데이트 3 버전의 중요 문제를 확인했습니다.

    • vSphere ESXi 7.0 업데이트 3(빌드 18644231)
    • vSphere ESXi 7.0 업데이트 3a(빌드 18825058)
    • vSphere ESXi 7.0 업데이트 3b(빌드 18905247)
    • vSphere vCenter 7.0 업데이트 3b(빌드 18901211)

    해결 방법:

    이후 VMWare에서 이러한 버전을 삭제했습니다. ESXivCenter Server를 최신 버전으로 업그레이드해야 합니다.

    운영체제 1.10, 1.11, 1.12, 1.13

    COS 노드에서 실행 중인 포드에 emptyDir 볼륨을 exec로 마운트할 수 없음

    Container-Optimized OS(COS) 이미지를 사용하는 노드에서 실행되는 포드의 경우 emptyDir 볼륨을 exec로 마운트할 수 없습니다. noexec로 마운트되며 exec user process caused: permission denied 오류가 발생합니다. 예를 들어 다음 테스트 포드를 배포하는 경우 이 오류 메시지가 표시됩니다.

    
    apiVersion: v1
    kind: Pod
    metadata:
      creationTimestamp: null
      labels:
        run: test
      name: test
    spec:
      containers:
      - args:
        - sleep
        - "5000"
        image: gcr.io/google-containers/busybox:latest
        name: test
        volumeMounts:
          - name: test-volume
            mountPath: /test-volume
        resources:
          limits:
            cpu: 200m
            memory: 512Mi
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      volumes:
        - emptyDir: {}
          name: test-volume
    

    테스트 포드에서 mount | grep test-volume을 실행하면 noexec 옵션이 표시됩니다.

    
    /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
    

    해결 방법:

    업그레이드 및 업데이트 1.10, 1.11, 1.12, 1.13

    노드 풀에서 자동 확장을 중지한 후 클러스터 노드 풀 복제본 업데이트가 작동하지 않음

    노드 풀에서 자동 확장을 사용 설정하고 중지하면 노드 풀 복제본이 업데이트되지 않습니다.


    해결 방법:

    해당 노드 풀의 머신 배포에서 cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-sizecluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size 주석을 삭제합니다.

    로그 기록 및 모니터링 1.11, 1.12, 1.13

    Windows 모니터링 대시보드에 Linux 클러스터의 데이터 표시

    버전 1.11부터 바로 사용할 수 있는 모니터링 대시보드에는 Windows 포드 상태 대시보드와 Windows 노드 상태 대시보드에 Linux 클러스터도 표시됩니다. Windows 노드와 포드 측정항목도 Linux 클러스터에 노출되기 때문입니다.

    로그 기록 및 모니터링 1.10, 1.11, 1.12

    CrashLoopBackOff 상수의 stackdriver-log-forwarder

    VMware용 Anthos 클러스터 버전 1.10, 1.11, 1.12에서 디스크에 손상된 버퍼링된 로그가 있으면 stackdriver-log-forwarder DaemonSet에 CrashLoopBackOff 오류가 발생할 수 있습니다.


    해결 방법:

    이 문제를 완화하려면 노드에서 버퍼링된 로그를 삭제해야 합니다.

    1. 예상치 못한 동작을 방지하려면 stackdriver-log-forwarder를 축소하세요.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      
      USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.
    2. 삭제 DaemonSet를 배포하여 손상된 청크를 삭제합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n kube-system -f - << EOF
      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
      EOF
      
    3. 삭제 DaemonSet가 모든 청크를 삭제했는지 확인하려면 다음 명령어를 실행하면 됩니다. 두 명령어의 출력은 클러스터의 노드 수와 동일합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
      
    4. 삭제 DaemonSet를 삭제합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        -n kube-system delete ds fluent-bit-cleanup
      
    5. stackdriver-log-forwarder를 재개합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
      
    로그 기록 및 모니터링 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    stackdriver-log-forwarder가 Cloud Logging에 로그를 전송하지 않음

    클러스터에서 Cloud Logging에 로그가 표시되지 않고 로그에 다음 오류가 표시되는 경우:

    
    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
    2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
          
    로그 입력 속도가 Logging 에이전트의 한도를 초과하여 stackdriver-log-forwarder에서 로그를 전송하지 않을 수 있습니다. 이 문제는 모든 VMware용 Anthos 클러스터 버전에서 발생합니다.

    해결 방법:

    이 문제를 완화하려면 Logging 에이전트의 리소스 한도를 늘려야 합니다.

    1. 수정할 stackdriver 리소스를 엽니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit stackdriver stackdriver
      
    2. stackdriver-log-forwarder의 CPU 요청을 늘리려면 다음 resourceAttrOverride 섹션을 stackdriver 매니페스트에 추가합니다.
      
      spec:
        resourceAttrOverride:
          stackdriver-log-forwarder/stackdriver-log-forwarder:
            limits:
              cpu: 1200m
              memory: 600Mi
            requests:
              cpu: 600m
              memory: 600Mi
      
      수정된 리소스는 다음과 비슷하게 표시되어야 합니다.
      
      spec:
        anthosDistribution: on-prem
        clusterLocation: us-west1-a
        clusterName: my-cluster
        enableStackdriverForApplications: true
        gcpServiceAccountSecretName: ...
        optimizedMetrics: true
        portable: true
        projectID: my-project-191923
        proxyConfigSecretName: ...
        resourceAttrOverride:
          stackdriver-log-forwarder/stackdriver-log-forwarder:
            limits:
              cpu: 1200m
              memory: 600Mi
            requests:
              cpu: 600m
              memory: 600Mi
      
    3. 변경사항을 저장하고 텍스트 편집기를 닫습니다.
    4. 변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.
      
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
          | grep "cpu: 1200m"
      
      수정이 적용된 경우 명령어가 cpu: 1200m을 찾습니다.
    보안 1.13

    NodeReady 후 Kubelet 서비스를 일시적으로 사용할 수 없음

    단시간 동안 노드가 준비되지만 kubelet 서버 인증서가 준비되지 않습니다. 이 수십 초 동안 kubectl execkubectl logs를 사용할 수 없습니다. 이는 새 서버 인증서 승인자가 업데이트된 유효한 노드 IP를 확인하는 데 시간이 걸리기 때문입니다.

    이 문제는 kubelet 서버 인증서에만 영향을 미치며 포드 예약에는 영향을 주지 않습니다.

    업그레이드 및 업데이트 1.12

    부분 관리자 클러스터 업그레이드가 이후 사용자 클러스터 업그레이드를 차단하지 않음

    다음과 같이 사용자 클러스터 업그레이드가 실패합니다.

    
    .LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
    

    관리자 클러스터가 완전히 업그레이드되지 않았고 상태 버전이 계속 1.10입니다. 1.12로의 사용자 클러스터 업그레이드가 프리플라이트 검사로 차단되지 않고 버전 차이 문제로 인해 실패합니다.


    해결 방법:

    먼저 관리자 클러스터를 1.11로 업그레이드한 후 사용자 클러스터를 1.12로 업그레이드합니다.

    스토리지 1.10.0~1.10.5, 1.11.0~1.11.2, 1.12.0

    Datastore에서 여유 공간이 부족하다고 잘못 보고함

    gkectl diagnose cluster 명령어 실패:

    
    Checking VSphere Datastore FreeSpace...FAILURE
        Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
    

    데이터 스토어 여유 공간의 검증을 기존 클러스터 노드 풀에 사용해서는 안 되는데 gkectl diagnose cluster에 실수로 추가되었습니다.


    해결 방법:

    오류 메시지를 무시하거나 --skip-validation-infra를 사용하여 검증을 건너뛰면 됩니다.

    작업, 네트워킹 1.11, 1.12.0~1.12.1

    관리자 클러스터가 MetalLB 부하 분산기를 사용할 때 신규 사용자 클러스터를 추가할 수 없음

    관리자 클러스터가 MetalLB 부하 분산기 구성으로 설정된 경우 신규 사용자 클러스터를 추가하지 못할 수 있습니다.

    사용자 클러스터 삭제 프로세스가 어떤 이유로든 중단되어 MatalLB ConfigMap이 무효화될 수 있습니다. 이 상태에서는 신규 사용자 클러스터를 추가할 수 없습니다.


    해결 방법:

    사용자 클러스터를 강제 삭제하면 됩니다.

    설치, 운영체제 1.10, 1.11, 1.12, 1.13

    사용자 클러스터에 Container-Optimized OS(COS) 사용 시 실패

    osImageType에서 관리자 클러스터에 cos를 사용하고 관리자 클러스터가 생성되고 사용자 클러스터는 생성되기 전에 gkectl check-config가 실행되면 실패합니다.

    
    Failed to create the test VMs: VM failed to get IP addresses on the network.
    

    사용자 클러스터 check-config에 대해 생성된 테스트 VM은 기본적으로 관리자 클러스터의 동일한 osImageType를 사용하며 현재 테스트 VM은 아직 COS와 호환되지 않습니다.


    해결 방법:

    테스트 VM을 만드는 느린 프리플라이트 검사를 방지하려면 gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast를 사용합니다.

    로그 기록 및 모니터링 1.12.0~1.12.1

    관리자 클러스터의 Grafana가 사용자 클러스터에 연결할 수 없음

    이 문제는 관리자 클러스터에서 Grafana를 사용하여 VMware용 Anthos 클러스터 버전 1.12.0 및 1.12.1에서 사용자 클러스터를 모니터링하는 고객에게 영향을 줍니다. 사용자 클러스터의 pushprox-client 인증서가 관리자 클러스터의 pushprox-server의 허용 목록과 일치하지 않기 때문입니다. 사용자 클러스터의 pushprox-client에서 다음과 같은 오류 로그를 출력하는 증상을 보입니다.

    
    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
    

    해결 방법:

    기타 1.11.3

    gkectl repair admin-master가 복구에 사용할 VM 템플릿을 제공하지 않음

    gkectl repair admin-master 명령어 실패:

    
    Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
    

    관리자 제어 영역 VM의 이름이 t, m, p 또는 l 문자로 끝나는 경우 gkectl repair admin-master는 관리자 제어 영역 VM을 복구하는 데 사용할 VM 템플릿을 가져올 수 없습니다.


    해결 방법:

    --skip-validation으로 명령어를 다시 실행하세요.

    로그 기록 및 모니터링 1.11, 1.12, 1.13, 1.14, 1.15

    권한 거부로 인한 Cloud Audit Logging 오류

    Anthos Cloud Audit Logging에는 현재 GKE Hub를 통해 사용자 클러스터에 대해서만 자동으로 수행되는 특별한 권한 설정이 필요합니다. Cloud Audit Logging에 필요한 올바른 권한이 관리자 클러스터에 포함되도록 Cloud Audit Logging에 대해 관리자 클러스터에 동일한 프로젝트 ID 및 서비스 계정을 사용하는 사용자 클러스터를 하나 이상 포함하는 것이 좋습니다.

    하지만 관리자 클러스터에서 사용자 클러스터와 다른 프로젝트 ID 또는 다른 서비스 계정이 사용되는 경우에는 관리자 클러스터의 감사 로그를 클라우드에 삽입하는 것이 실패합니다. 증상은 관리자 클러스터의 audit-proxy 포드에서 일련의 Permission Denied 오류로 나타납니다.


    해결 방법:

    작업, 보안 1.11

    gkectl diagnose 인증서 확인 실패

    워크스테이션이 사용자 클러스터 워커 노드에 액세스할 수 없으면 gkectl diagnose를 실행할 때 다음 오류가 발생합니다.

    
    Checking user cluster certificates...FAILURE
        Reason: 3 user cluster certificates error(s).
        Unhealthy Resources:
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    

    워크스테이션이 관리자 클러스터 워커 노드에 액세스할 수 없으면 gkectl diagnose를 실행할 때 다음 오류가 발생합니다.

    
    Checking admin cluster certificates...FAILURE
        Reason: 3 admin cluster certificates error(s).
        Unhealthy Resources:
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
        Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    

    해결 방법:

    이 메시지는 무시해도 안전합니다.

    운영체제 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ 때문에 관리자 워크스테이션의 디스크 공간이 가득 참

    /var/log/audit/에 감사 로그가 채워집니다. sudo du -h -d 1 /var/log/audit를 실행하면 디스크 사용량을 확인할 수 있습니다.

    관리자 워크스테이션의 특정 gkectl 명령어(예: gkectl diagnose snapshot)는 디스크 공간 사용량에 영향을 줍니다.

    Anthos v1.8부터 Ubuntu 이미지는 CIS Level 2 벤치마크로 강화됩니다. 또한 규정 준수 규칙 중 하나인 '4.1.2.2 감사 로그가 자동으로 삭제되지 않도록 확인'으로 auditd 설정 max_log_file_action = keep_logs를 보장합니다. 모든 감사 규칙이 디스크에 유지됩니다.


    해결 방법:

    네트워킹 1.10, 1.11.0~1.11.3, 1.12.0~1.12.2, 1.13.0

    NetworkGatewayGroup 유동 IP가 노드 주소와 충돌

    다음과 같은 검증 웹훅 오류로 인해 사용자가 NetworkGatewayGroup 객체를 만들거나 업데이트할 수 없습니다.

    
    [1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
    

    영향을 받는 버전에서 kubelet가 노드에 할당된 유동 IP 주소에 잘못 바인딩되고 이를 node.status.addresses에 노드 주소로 보고할 수 있습니다. 검증 웹훅에서 NetworkGatewayGroup 유동 IP 주소를 클러스터의 모든 node.status.addresses와 대조하고 이를 충돌로 간주합니다.


    해결 방법:

    NetworkGatewayGroup 객체의 생성 또는 업데이트가 실패한 동일한 클러스터에서 ANG 검증 웹훅을 일시적으로 중지하고 변경사항을 제출합니다.

    1. 마지막에 복원할 수 있도록 웹훅 구성을 저장합니다.
      
      kubectl -n kube-system get validatingwebhookconfiguration \
          ang-validating-webhook-configuration -o yaml > webhook-config.yaml
      
    2. 웹훅 구성을 수정합니다.
      
      kubectl -n kube-system edit validatingwebhookconfiguration \
          ang-validating-webhook-configuration
      
    3. 웹훅 구성 목록에서 vnetworkgatewaygroup.kb.io 항목을 삭제하고 닫아 변경사항을 적용합니다.
    4. NetworkGatewayGroup 객체를 만들거나 수정합니다.
    5. 원래 웹훅 구성을 다시 적용합니다.
      
      kubectl -n kube-system apply -f webhook-config.yaml
      
    설치, 업그레이드 및 업데이트 1.10.0~1.10.2

    관리자 클러스터 생성 또는 업그레이드 시간 초과

    관리자 클러스터 업그레이드 시도 중에 관리자 제어 영역 VM이 생성 중에 중단될 수 있습니다. 부팅 중에 관리자 제어 영역 VM이 무한 대기 루프 상태로 전환되며 /var/log/cloud-init-output.log 파일에 다음과 같은 무한 루프 오류가 표시됩니다.

    
    + echo 'waiting network configuration is applied'
    waiting network configuration is applied
    ++ get-public-ip
    +++ ip addr show dev ens192 scope global
    +++ head -n 1
    +++ grep -v 192.168.231.1
    +++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
    +++ awk '{print $2}'
    ++ echo
    + '[' -n '' ']'
    + sleep 1
    + echo 'waiting network configuration is applied'
    waiting network configuration is applied
    ++ get-public-ip
    +++ ip addr show dev ens192 scope global
    +++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
    +++ awk '{print $2}'
    +++ grep -v 192.168.231.1
    +++ head -n 1
    ++ echo
    + '[' -n '' ']'
    + sleep 1
    

    이는 VMware용 Anthos 클러스터가 시작 스크립트에서 노드 IP 주소를 가져오려고 하면 grep -v ADMIN_CONTROL_PLANE_VIP를 사용하여 NIC에도 할당할 수 있는 관리자 클러스터 제어 영역 VIP를 건너뛰기 때문입니다. 하지만 이 명령어는 제어 영역 VIP의 프리픽스가 있는 IP 주소도 건너뛰므로 시작 스크립트가 중단됩니다.

    예를 들어 관리자 클러스터 제어 영역 VIP가 192.168.1.25라고 가정합니다. 관리자 클러스터 제어 영역 VM의 IP 주소에 같은 프리픽스(예: 192.168.1.254)가 있으면 제어 영역 VM은 생성되는 동안 중단됩니다. 브로드캐스트 주소에 제어 영역 VIP와 동일한 프리픽스(예: 192.168.1.255)가 있으면 이 문제를 해결할 수도 있습니다.


    해결 방법:

    • 관리자 클러스터 생성 시간 초과의 원인이 브로드캐스트 IP 주소이면 관리자 클러스터 제어 영역 VM에서 다음 명령어를 실행합니다.
      
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      
      이렇게 하면 브로드캐스트 주소가 없는 줄이 생성되고 부팅 프로세스가 차단 해제됩니다. 시작 스크립트 차단이 해제되면 다음 명령어를 실행하여 추가된 줄을 삭제합니다.
      
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      
    • 하지만 관리자 클러스터 생성 시간 초과의 원인이 제어 영역 VM의 IP 주소이면 시작 스크립트 차단을 해제할 수 없습니다. 다른 IP 주소로 전환하고 버전 1.10.3 이상을 다시 만들거나 업그레이드합니다.
    운영체제, 업그레이드 및 업데이트 1.10.0~1.10.2

    COS 이미지를 사용하는 관리자 클러스터 상태가 관리자 클러스터 업그레이드 또는 관리자 마스터 복구 시 손실됨

    COS 이미지를 사용할 때 DataDisk를 관리자 클러스터 마스터 노드에 올바르게 마운트할 수 없고 COS 이미지를 사용하는 관리자 클러스터의 상태가 관리자 클러스터 업그레이드 또는 관리자 마스터 복구 시 손실됩니다. (COS 이미지를 사용하는 관리자 클러스터는 미리보기 기능입니다.)


    해결 방법:

    ubuntu_containerd로 설정된 osImageType을 사용하여 관리자 클러스터를 다시 만듭니다.

    osImageType을 cos로 설정하여 관리자 클러스터를 만든 후 관리자 클러스터 SSH 키와 SSH를 관리자 마스터 노드로 가져옵니다. df -h 결과에 /dev/sdb1 98G 209M 93G 1% /opt/data가 포함됩니다. 그리고 lsblk 결과에는 -sdb1 8:17 0 100G 0 part /opt/data가 포함됩니다.

    운영체제 1.10

    .local 도메인에서 DNS 조회에 실패한 systemd-resolved

    VMware용 Anthos 클러스터 버전 1.10.0에서 기본적으로 Ubuntu의 이름 변환은 127.0.0.53에서 리슨하는 로컬 systemd-resolved로 라우팅됩니다. 버전 1.10.0에서 사용된 Ubuntu 20.04 이미지에서 /etc/resolv.conf127.0.0.53 localhost DNS 스텁을 가리키는 /run/systemd/resolve/stub-resolv.conf에 심볼릭 링크로 연결되기 때문입니다.

    따라서 이름이 검색 도메인으로 지정되지 않는 한, localhost DNS 이름 변환에서 .local 서픽스가 있는 이름의 업스트림 DNS 서버(/run/systemd/resolve/resolv.conf에 지정됨) 확인을 거부합니다.

    이러한 경우 .local 이름 조회가 실패합니다. 예를 들어 노드 시작 중에 kubelet.local 서픽스가 있는 비공개 레지스트리에서 이미지를 가져오지 못합니다. .local 서픽스를 사용한 vCenter 주소 지정은 관리자 워크스테이션에서 작동하지 않습니다.


    해결 방법:

    관리자 클러스터 구성 파일과 사용자 클러스터 구성 파일에 도메인을 포함하도록 searchDomainsForDNS 필드를 지정하면 클러스터 노드에 이 문제가 발생하지 않습니다.

    현재 gkectl update에서는 searchDomainsForDNS 필드 업데이트를 아직 지원하지 않습니다.

    따라서 클러스터를 만들기 전에 이 필드를 설정하지 않았으면 /etc/resolv.conf의 심볼릭 링크를 /run/systemd/resolve/stub-resolv.conf(127.0.0.53 로컬 스텁 포함)에서 /run/systemd/resolve/resolv.conf(실제 업스트림 DNS를 가리킴)로 변경하여 노드에 SSH로 연결하고 로컬 systemd-resolved 스텁을 우회해야 합니다.

    
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
    

    관리자 워크스테이션의 경우 gkeadm에서 검색 도메인 지정을 지원하지 않으므로 이 수동 단계에서 이 문제를 해결해야 합니다.

    이 솔루션은 VM 재생성 시 유지되지 않습니다. VM을 다시 만들 때마다 이 해결 방법을 다시 적용해야 합니다.

    설치, 운영체제 1.10

    Docker 브리지 IP가 169.254.123.1/24 대신 172.17.0.1/16을 사용

    VMware용 Anthos 클러스터는 기본 172.17.0.1/16 서브넷을 예약하지 않도록 --bip=169.254.123.1/24를 사용하는 Docker 브리지 IP 주소에 대한 전용 서브넷을 지정합니다. 하지만 버전 1.10.0에서는 Ubuntu OS 이미지에 맞춤설정된 Docker 구성을 무시하도록 하는 버그가 있습니다.

    따라서 Docker는 기본 172.17.0.1/16을 브리지 IP 주소 서브넷으로 선택합니다. 이 IP 주소 범위 내에서 이미 실행 중인 워크로드가 있는 경우 IP 주소 충돌이 발생할 수 있습니다.


    해결 방법:

    이 문제를 해결하려면 dockerd의 다음 systemd 구성 파일 이름을 바꾼 후 서비스를 다시 시작해야 합니다.

    
    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
        /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
    
    sudo systemctl daemon-reload
    
    sudo systemctl restart docker
    

    Docker가 올바른 브리지 IP 주소를 선택하는지 확인합니다.

    
    ip a | grep docker0
    

    이 솔루션은 VM 재생성 시 유지되지 않습니다. VM을 다시 만들 때마다 이 해결 방법을 다시 적용해야 합니다.

    업그레이드 및 업데이트 1.11

    Stackdriver 준비에 의해 1.11로의 업그레이드가 차단됨

    VMware용 Anthos 클러스터 버전 1.11.0에서 로깅 및 모니터링과 관련된 커스텀 리소스 정의가 변경되었습니다.

    • stackdriver 커스텀 리소스의 그룹 이름이 addons.sigs.k8s.io에서 addons.gke.io로 변경되었습니다.
    • monitoringmetricsserver 커스텀 리소스의 그룹 이름이 addons.k8s.io에서 addons.gke.io로 변경되었습니다.
    • 위 리소스의 사양은 스키마와 비교하여 검증되기 시작합니다. 특히 stackdriver 커스텀 리소스의 resourceAttrOverride and storageSizeOverride 사양에 CPU, 메모리, 스토리지 크기 요청 및 한도 값에 문자열 유형이 있어야 합니다.

    그룹 이름이 Kubernetes 1.22의 CustomResourceDefinition 업데이트를 준수하도록 변경됩니다.

    영향을 받는 커스텀 리소스를 적용하거나 수정하는 추가 로직이 없는 경우 별도로 취해야 할 조치는 없습니다. VMware용 Anthos 클러스터 업그레이드 프로세스에서 영향을 받는 리소스의 마이그레이션을 처리하고 그룹 이름이 변경된 후 기존 사양을 유지합니다.

    그러나 영향을 받는 리소스를 적용하거나 수정하는 로직을 실행하는 경우 특히 주의해야 합니다. 첫째, 매니페스트 파일에서 리소스를 새 그룹 이름으로 참조해야 합니다. 예를 들면 다음과 같습니다.

    
    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
    kind: Stackdriver
    

    둘째, resourceAttrOverridestorageSizeOverride 사양 값이 문자열 유형인지 확인합니다. 예를 들면 다음과 같습니다.

    
    spec:
      resourceAttrOverride:
        stackdriver-log-forwarder/stackdriver-log-forwarder
          limits:
            cpu: 1000m # or "1"
            # cpu: 1 # integer value like this would not work
            memory: 3000Mi
    

    그렇지 않으면 적용 및 수정 내용이 반영되지 않으며 로깅 및 모니터링 구성요소에 예상치 못한 상태가 발생할 수 있습니다. 가능한 증상은 다음과 같습니다.

    • onprem-user-cluster-controller의 조정 오류 로그 예시는 다음과 같습니다.
      
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • kubectl edit stackdriver stackdriver 실패 예시는 다음과 같습니다.
      
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    위의 오류가 발생한다면 업그레이드 전부터 Stackdriver CR 사양에 이미 지원되지 않는 유형이 존재했다는 의미입니다. 이 문제를 해결하려면 이전 그룹 이름 kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver에서 Stackdriver CR을 수동으로 수정하고 다음을 수행합니다.

    1. 리소스 요청 및 한도를 문자열 유형으로 변경합니다.
    2. addons.gke.io/migrated-and-deprecated: true 주석이 있으면 삭제합니다.
    그런 다음 업그레이드 프로세스를 재개하거나 다시 시작합니다.

    운영체제 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    호스트의 정상 종료를 통해 VM이 이동될 때 COS VM에 IP가 표시되지 않음

    ESXi 서버에 오류가 있고 서버에 vCenter HA 기능이 사용 설정된 경우 오류가 발생한 ESXi 서버의 모든 VM이 vMotion 메커니즘을 트리거하고 정상적인 다른 ESXi 서버로 이동합니다. 마이그레이션된 COS VM은 IP를 잃게 됩니다.

    해결 방법:

    VM 재부팅

    추가 지원이 필요하면 Google 지원에 문의하세요.