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-manager 및 autoscaler 클러스터 컨트롤러 배포에 할당합니다.
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 워크로드를 실행할 수 없습니다.

user-cluster.yaml 파일에서 Windows 노드 풀 구성을 삭제하여 기존 Windows 노드 풀을 삭제한 후 다음 명령어를 실행합니다.
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
해당 대상 부 버전의 업그레이드 사용자 가이드에 따라 Linux 전용 관리자+사용자 클러스터를 1.12로 업그레이드합니다.
(1.13으로 업그레이드하기 전에 이 단계를 수행해야 함) enableWindowsDataplaneV2: true가 OnPremUserCluster CR에 구성되어 있는지 확인합니다. 그렇지 않으면 클러스터가 Docker가 설치되지 않은 새로 생성된 1.13 Windows VM 템플릿과 호환되지 않는 Windows 노드 풀에 Docker를 계속 사용합니다. 구성되지 않았거나 false로 설정된 경우, 클러스터를 업데이트하여 user-cluster.yaml에서 true로 설정하고 다음을 실행합니다.
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
업그레이드 사용자 가이드에 따라 Linux 전용 관리자+사용자 클러스터를 1.13으로 업그레이드합니다.

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

user-cluster.yaml에서 OSImage 필드를 새로 만든 Windows VM 템플릿으로 설정하여 Windows 노드 풀 구성을 다시 추가합니다.

클러스터를 업데이트하여 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로 변경하되 최신 키 데이터는 유지합니다.

관리자 클러스터의 USER_CLUSTER_NAME 네임스페이스에서 보안 비밀을 확인하고 ksa-signing-key 보안 비밀 이름을 가져옵니다.
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
```

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 -

이전 ksa-signing-key 보안 비밀을 삭제합니다.


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME

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
```

검증 웹훅을 사용 중지하여 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
'

OnPremUserCluster 커스텀 리소스에서 spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation 필드를 1로 업데이트합니다.
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
```
대상 사용자 클러스터가 준비될 때까지 기다린 후 다음을 수행하여 상태를 확인할 수 있습니다.
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get 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
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'

클러스터가 수정사항이 적용된 버전으로 업그레이드될 때까지 다른 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 이상 버전에서 만들어진 클러스터의 경우 클러스터를 만든 후 안내에 따라 관리자 클러스터 등록을 재시도합니다. 이전 버전에서 만들어진 클러스터의 경우,

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

업그레이드 및 업데이트

1.10, 1.11, 1.12, 1.13.0-1.13.1

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

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

해결 방법:

클러스터가 등록된 클러스터에 표시되는지 확인합니다. 선택 사항으로 인증을 설정한 후 클러스터에 로그인합니다. 클러스터가 여전히 등록된 경우 등록 재시도를 위한 안내를 건너뛸 수 있습니다. 1.12 이상 버전으로 업그레이드된 클러스터의 경우 클러스터를 만든 후 안내에 따라 관리자 클러스터 등록을 재시도합니다. 이전 버전으로 업그레이드된 클러스터의 경우 다음을 수행합니다.

연결-등록 SA 키 파일에 'foo: bar' 같은 가짜 키-값 쌍을 추가합니다.
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 admin`가 `StorageClass 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) 워크로드가 새로운 노드 집합에서 볼륨에 쓰기를 수행하지 못할 수 있습니다.

해결 방법:

볼륨에 쓰기를 수행할 수 없는 포드의 UID를 가져옵니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'

PersistentVolumeClaim을 사용하여 PersistentVolume 이름을 가져옵니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'

포드가 실행 중인 노드 이름을 확인합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'

SSH 또는 vSphere 웹 인터페이스를 통해 노드에 대한 Powershell 액세스 권한을 얻습니다.

환경 변수를 설정합니다.


PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID

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

디스크가 readonly인지 확인합니다.
```
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
```
결과는 True여야 합니다.

readonly을 false로 설정합니다.


PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

포드가 다시 시작되도록 삭제합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE

포드는 동일한 노드에 예약되어야 합니다. 그러나 포드가 새 노드에 예약되는 경우 새 노드에서 이전 단계를 반복해야 할 수 있습니다.

업그레이드 및 업데이트

1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

`vsphere-csi-secret`가 `gkectl update credentials vsphere --admin-cluster` 이후에 업데이트되지 않음

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

해결 방법:

vsphere-csi-secret 보안 비밀 이름을 가져옵니다.


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret

이전 단계에서 가져온 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 \
    )\"}}"

vsphere-csi-controller를 다시 시작합니다.


kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller

다음 명령어를 사용하여 출시 상태를 추적할 수 있습니다.
```
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를 수동으로 재배포

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


kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

원래의 등록 서비스 계정 키로 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 배포에서 클러스터의 기본 이미지 가져오기 보안 비밀을 추가할 수 있습니다.

기본 보안 비밀을 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 -

gke-connect-agent 배포 이름을 가져옵니다.


kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent

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 미만이 될 때까지 노드를 삭제하세요.

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

Google Cloud 콘솔의 측정항목 탐색기로 이동합니다.
측정항목 탐색기로 이동
구성 탭을 선택합니다.
측정항목 선택을 확장하고 필터 표시줄에 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+

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

외부에서 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 서버가 시작되지 않습니다. 이 경우 계속하세요.

Anthos Identity Service 및 kube-apiserver 로그를 확인합니다.

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:

클러스터의 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]"

해결 방법

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

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

Anthos Identity Service 로그에서 잘못된 토큰 컨텍스트를 확인합니다.


kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

잘못된 각 토큰 컨텍스트와 연결된 토큰 페이로드를 가져오려면 다음 명령어를 사용하여 관련된 각 서비스 계정 보안 비밀을 파싱합니다.
```
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
```
토큰을 디코딩하고 소스 포드 이름과 네임스페이스를 보려면 jwt.io의 디버거에 토큰을 복사합니다.
토큰에서 식별된 포드를 다시 시작합니다.

작업

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/30을 10.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

해결 방법:

해당하는 부 버전에 사용 가능한 최신 패치 버전의 gkectl 바이너리를 사용하여 중요 클러스터 작업 후에 관리자 클러스터 백업을 수행합니다. 예를 들어 클러스터가 1.10.2 버전을 실행하는 경우 gkectl로 관리자 클러스터 백업 및 복원에 설명된 대로 1.10.5 gkectl 바이너리를 사용하여 수동 관리자 클러스터 백업을 수행합니다.

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

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_label이 MachineTemplate.spec.template.spec.providerSpec.machineVariables에서 삭제되어 모든 MachineDeployment에서 예기치 않은 업데이트가 트리거되었습니다.

해결 방법:

해결 방법 단계 보기

모든 사용자 클러스터에서 clusterapi-controllers 복제본을 0개로 축소합니다.


kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG

각 사용자 클러스터를 하나씩 업그레이드합니다.

업그레이드 및 업데이트

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와 같은 명령어를 실행해야 합니다.

해결 방법:

컨테이너 런타임에 containerd 사용
클러스터를 최신 버전 1.10으로 업그레이드

업그레이드 및 업데이트

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가 리소스를 삭제합니다.

해결 방법:

모든 기존 PodMonitoring 커스텀 리소스(CR)를 백업합니다.
모든 클러스터를 버전 1.12로 업그레이드하고 Managed Service for Prometheus를 사용 설정합니다.
PodMonitoring CR을 다시 배포합니다.

작업

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이 삭제됩니다.

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

증상은 다음과 같습니다.

cluster-autoscaler 로그


kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler

ADMIN_CLUSTER_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

해결 방법:

해결 방법 단계 보기

관리자 클러스터에서 clusterrole 및 clusterrolebinding이 누락되었는지 확인합니다.


kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler


kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler

누락된 경우 다음 클러스터 역할 및 clusterrolebinding을 관리자 클러스터에 적용합니다. 각 사용자 클러스터의 clusterrolebinding에 서비스 계정 제목을 추가하세요.


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...

구성

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

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

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

증상은 다음과 같습니다.

cluster-health-controller 로그


kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller

ADMIN_CLUSTER_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


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"

해결 방법:

해결 방법 단계 보기

다음 yaml을 관리자 클러스터에 적용합니다.

vsphere-metrics-exporter의 경우


kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system

cluster-health-controller의 경우


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"

구성

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

해결 방법:

해결 방법 단계 보기

업데이트를 적용하려면 실패한 업데이트 after 머신을 다시 만들어야 합니다.

관리자 클러스터 업데이트의 경우 사용자 마스터 및 관리자 부가기능 노드를 다시 만들어야 합니다.

사용자 클러스터 업데이트의 경우 사용자 워커 노드를 다시 만들어야 합니다.

사용자 워커 노드 다시 만들기

옵션 1
노드 풀 업데이트의 안내를 따르고 CPU 또는 메모리를 변경하여 노드의 순차적 재생성을 트리거합니다.

옵션 2
kubectl delete를 사용하여 머신을 한 번에 하나씩 다시 만듭니다.


kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

사용자 마스터 노드 다시 만들기

옵션 1
제어 영역 크기 조절의 안내를 따라 CPU 또는 메모리를 변경하여 노드의 순차적 재생성을 트리거합니다.

옵션 2
kubectl delete를 사용하여 머신을 한 번에 하나씩 다시 만듭니다.


kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

관리자 부가기능 노드 다시 만들기

kubectl delete를 사용하여 머신을 한 번에 하나씩 다시 만듭니다.


kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

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

1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

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

ipMode.type이 static이고 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 확인을 중지합니다.

사용자 클러스터 구성 파일에 다음 필드를 추가하세요.


disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true

파일을 저장하고 다음 명령어를 실행하여 사용자 클러스터를 업데이트합니다.
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
다음을 바꿉니다.
- ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
- USER_CLUSTER_CONFIG_FILE: 사용자 클러스터 구성 파일의 경로입니다.

관리자 클러스터

수정할 OnPremAdminCluster 커스텀 리소스를 엽니다.


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system

다음 주석을 커스텀 리소스에 추가합니다.


features.onprem.cluster.gke.io/disable-node-id-verification: enabled

관리자 클러스터 제어 영역에서 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
```

수정할 Deployment Cluster API 컨트롤러를 엽니다.


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system

node-id-verification-enabled 및 node-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에서 일부 노드가 NotHealthy 및 Up 간에 전환됩니다.

해당 노드에서 실행되는 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.CheckFileExists`의 `gkectl 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로 업그레이드하는 것이 좋습니다.

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"

해결 방법:

해결 방법 단계 보기

문제를 해결하려면 다음 명령어를 실행합니다.

변경사항을 cert-manager 배포로 되돌리지 않도록 먼저 monitoring-operator를 축소합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

복제본 하나만 실행하므로 리더 선택을 중지하도록 cert-manager-cainjector 배포를 수정합니다. 단일 복제본에는 필요 없는 작업입니다.


# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

cert-manager-cainjector 배포에 대한 관련 YAML 스니펫은 다음 예시와 같아야 합니다.


...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

설치가 완료될 때까지 문제 해결을 위해 monitoring-operator 복제본을 0개로 유지합니다. 그렇지 않으면 변경사항이 되돌려집니다.

설치가 완료되고 클러스터가 작동하면 2일 차 작업을 위해 monitoring-operator를 설정합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

업그레이드할 때마다 변경사항이 되돌려집니다. 이후 버전에서 이 문제가 수정될 때까지 같은 단계를 다시 수행하여 문제를 완화합니다.

보안, 업그레이드 및 업데이트

1.10, 1.11, 1.12, 1.13

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

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

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

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

해결 방법:

해결 방법 단계 보기

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

KUBECONFIG 변수를 설정합니다.
```
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
```
ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 절대 경로로 바꿉니다.

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


kubectl --kubeconfig "${KUBECONFIG}" get secrets \
    -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
    ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key

export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \
    get nodes -o \
    jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
    --selector='node-role.kubernetes.io/master')

인증서가 만료되었는지 확인합니다.
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
```
인증서가 만료된 경우 관리자 클러스터를 업그레이드하기 전에 갱신해야 합니다.
관리자 클러스터 kubeconfig 파일도 관리자 인증서가 만료되면 만료되므로 만료 전에 이 파일을 백업해야 합니다.
1. 관리자 클러스터 kubeconfig 파일을 백업합니다.
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
  "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
```
2. kubeconfig의 client-certificate-data 및 client-key-data를 생성된 new_admin.conf 파일의 client-certificate-data 및 client-key-data로 바꿉니다.

이전 인증서를 백업합니다. 이 단계는 선택사항이지만 권장됩니다.


# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"

# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout

# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .

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


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

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


# on admin master
cd /etc/kubernetes
sudo mkdir tempdir
sudo mv manifests/*.yaml tempdir/
sleep 5
echo "remove pods"
# ensure kubelet detect those change remove those pods
# wait until the result of this command is empty
sudo docker ps | grep kube-apiserver

# ensure kubelet start those pods again
echo "start pods again"
sudo mv tempdir/*.yaml manifests/
sleep 30

# ensure kubelet start those pods again
# should show some results
sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \
    -e kube-scheduler -e etcd

# clean up
sudo rm -rf tempdir

logout

갱신된 인증서를 검증하고 kube-apiserver의 인증서를 검증해야 합니다. 인증서 만료를 확인합니다.
```
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
    "sudo kubeadm alpha certs check-expiration"
```

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


# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server

# Get the current kube-apiserver certificate

openssl s_client -showcerts -connect : \
    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    > current-kube-apiserver.crt

# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate

VMware

1.10, 1.11, 1.12, 1.13

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

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

원격 호스트에서 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-operator는 cert-manager 네임스페이스에 cert-manager를 설치합니다. 특정한 이유로 cert-manager를 직접 설치해야 하는 경우 충돌을 피하려면 다음 안내를 따르세요.

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

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

해결 방법:

업그레이드 중에 충돌 방지

보유한 cert-manager 버전을 제거합니다. 자체 리소스를 정의한 경우 백업할 수 있습니다.
업그레이드를 수행합니다.
다음 안내에 따라 자체 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 버전을 다시 설치합니다. 존재하는 경우 맞춤설정된 리소스를 복원합니다.


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-operator이 gke-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로 업그레이드할 수 없으면 다음 단계를 수행합니다.

원치 않는 청구가 있는 소스 포드 및 서비스를 찾습니다.


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

포드 또는 서비스에서 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.2/1.9.5 이상으로 업그레이드합니다.

이전 버전에서 이 문제를 해결하려면 다음 안내를 따르세요.

'stackdriver-operator'를 축소합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    scale deployment stackdriver-operator --replicas=0

USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.

수정할 gke-metrics-agent-conf ConfigMap을 엽니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    edit configmap gke-metrics-agent-conf

프로브 간격을 0.1초에서 13초로 늘립니다.


  processors:
    disk_buffer/metrics:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-metrics
      probe_interval: 13s
      retention_size_mib: 6144
  disk_buffer/self:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-self
      probe_interval: 13s
      retention_size_mib: 200
    disk_buffer/uptime:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-uptime
      probe_interval: 13s
      retention_size_mib: 200

수정 세션을 닫습니다.

gke-metrics-agent DaemonSet 버전을 1.1.0-anthos.8로 변경합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  \
  --namespace kube-system  set image daemonset/gke-metrics-agent \
  gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8

로그 기록 및 모니터링

1.10, 1.11

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

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

해결 방법:

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

다음 변경사항을 되돌리지 않으려면 stackdriver-operator를 축소합니다.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
```
USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.

수정할 gke-metrics-agent-conf ConfigMap을 엽니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf

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

수정 세션을 닫습니다.

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`

해결 방법:

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

Google Cloud Monitoring 대시보드에서 'GKE On-Prem 노드 상태'를 삭제합니다. 이 안내를 따라 'GKE On-Prem 노드 상태'를 다시 설치합니다.
Google Cloud Monitoring 대시보드에서 'GKE On-Prem 노드 사용률'을 삭제합니다. 이 안내를 따라 'GKE On-Prem 노드 사용률'을 다시 설치합니다.
Google Cloud Monitoring 대시보드에서 'GKE On-Prem vSphere vm health'를 삭제합니다. 이 안내에 따라 'GKE On-Prem vSphere vm health'를 다시 설치합니다.

이러한 지원 중단은 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를 늘립니다.

수정할 stackdriver 리소스를 엽니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver

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

변경사항을 저장하고 텍스트 편집기를 닫습니다.
변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.
```
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: ""

해결 방법:

해결 방법 단계 보기

이 오류가 발생하면 다음 단계에 따라 클러스터 등록 문제를 해결합니다. 이 문제를 해결한 후 관리자 클러스터를 업그레이드할 수 있습니다.

gkectl update admin을 실행하여 올바른 서비스 계정 키로 관리자 클러스터를 등록합니다.

OnPremAdminCluster 커스텀 리소스를 패치하기 위한 전용 서비스 계정을 만듭니다.


export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF

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

다음 명령어를 실행하여 OnPremAdminCluster 커스텀 리소스를 업데이트합니다.


export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status

--disable-upgrade-from-checkpoint 플래그를 사용하여 관리자 클러스터 업그레이드를 다시 시도합니다.
```
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
```
ADMIN_CLUSTER_CONFIG를 관리자 클러스터 구성 파일의 경로로 바꿉니다.

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에서 이러한 버전을 삭제했습니다. ESXi 및 vCenter 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)

해결 방법:

해결 방법 단계 보기

예를 들어 다음과 같이 DaemonSet 리소스를 적용합니다.


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

업그레이드 및 업데이트

1.10, 1.11, 1.12, 1.13

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

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

해결 방법:

해당 노드 풀의 머신 배포에서 cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size 및 cluster.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 오류가 발생할 수 있습니다.

해결 방법:

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

예상치 못한 동작을 방지하려면 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 파일 경로로 바꿉니다.

삭제 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

삭제 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

삭제 DaemonSet를 삭제합니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup

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 에이전트의 리소스 한도를 늘려야 합니다.

수정할 stackdriver 리소스를 엽니다.


kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver

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

변경사항을 저장하고 텍스트 편집기를 닫습니다.

변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.


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 exec 및 kubectl 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 부하 분산기 구성으로 설정된 경우 신규 사용자 클러스터를 추가하지 못할 수 있습니다.

사용자 클러스터 삭제 프로세스가 어떤 이유로든 중단되어 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:\""

해결 방법:

해결 방법 단계 보기

다음 단계를 수행합니다.

관리자 클러스터 kube-system 네임스페이스에서 monitoring-operator 배포를 축소합니다.


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0

관리자 클러스터 kube-system 네임스페이스에서 pushprox-server-rbac-proxy-config ConfigMap을 수정합니다.


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config

external-pushprox-server-auth-proxy 리스너의 principals 줄을 찾고 pushprox-client.metrics-consumers.kube-system.cluster.에서 kube-system 하위 문자열을 삭제하여 모든 사용자 클러스터의 principal_name을 수정합니다. 새 구성은 다음과 같이 표시됩니다.


permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]

관리자 클러스터에서 pushprox-server 배포를, 영향을 받는 사용자 클러스터에서 pushprox-client 배포를 다시 시작합니다.


kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client

앞의 단계를 수행하여 문제를 해결할 수 있습니다. 클러스터가 1.12.2로 업그레이드되고 나중에 문제가 해결되면 파이프라인을 다시 관리할 수 있도록 관리자 클러스터 kube-system monitoring-operator를 수직 확장합니다.
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
```

기타

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 오류로 나타납니다.

해결 방법:

해결 방법 단계 보기

이 문제를 해결하려면 cloudauditlogging 허브 특성과 상호작용하여 권한을 설정할 수 있습니다.

먼저 프로젝트에서 Anthos Cloud Audit Logging에 허용되는 기존 서비스 계정을 확인합니다.


curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

응답에 따라 다음 중 하나를 수행합니다.
- 404 Not_found 오류가 수신되었으면 이 프로젝트 ID에 허용되는 서비스 계정이 없는 것입니다. cloudauditlogging 허브 특성을 사용 설정하여 서비스 계정을 허용할 수 있습니다.
```
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- allowlistedServiceAccounts에 "code": "OK"와 함께 "lifecycleState": "ENABLED"가 포함되고 서비스 계정 목록이 포함된 특성 사양이 수신된 경우 이 프로젝트에 허용되는 기존 서비스 계정이 있는 것입니다. 클러스터에서 이 목록의 서비스 계정을 사용하거나 새 서비스 계정을 허용 목록에 추가할 수 있습니다.
```
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
```
- "code": "FAILED"와 함께 "lifecycleState": "ENABLED"가 포함된 특성 사양이 수신된 경우 권한 설정이 성공하지 않은 것입니다. 응답의 description 필드에서 문제를 해결하도록 시도하거나 현재 허용 목록을 백업하고, cloudauditlogging 허브 특성을 삭제하고, 이 섹션의 1단계에 따라 다시 사용 설정합니다. 다음 방법으로 cloudauditlogging 허브 특성을 삭제할 수 있습니다.
```
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
```

위 명령어에서 다음을 수행합니다.

PROJECT_ID를 클러스터의 Audit Logging 프로젝트로 바꿉니다.
SERVICE_ACCOUNT_EMAIL을 클러스터의 Audit Logging 서비스 계정의 이메일 주소로 바꿉니다.

작업, 보안

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를 보장합니다. 모든 감사 규칙이 디스크에 유지됩니다.

해결 방법:

해결 방법 단계 보기

관리자 워크스테이션

관리자 워크스테이션의 경우 로그를 자동으로 순환하도록 수동으로 auditd 설정을 변경한 후 auditd 서비스를 다시 시작할 수 있습니다.


sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

위 설정을 사용하면 생성된 파일이 250개를 초과하면(각각 8M 크기) auditd 로그가 자동으로 순환됩니다.

클러스터 노드

클러스터 노드의 경우 1.11.5 이상, 1.12.4 이상, 1.13.2 이상 또는 1.14 이상으로 업그레이드합니다. 아직 해당 버전으로 업그레이드할 수 없다면 클러스터에 다음 DaemonSet를 적용합니다.


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

이 auditd 구성을 변경하면 CIS Level 2 규칙 '4.1.2.2 감사 로그가 자동으로 삭제되지 않도록 확인'을 위반하게 됩니다.

네트워킹

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 검증 웹훅을 일시적으로 중지하고 변경사항을 제출합니다.

마지막에 복원할 수 있도록 웹훅 구성을 저장합니다.


kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml

웹훅 구성을 수정합니다.


kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration

웹훅 구성 목록에서 vnetworkgatewaygroup.kb.io 항목을 삭제하고 닫아 변경사항을 적용합니다.
NetworkGatewayGroup 객체를 만들거나 수정합니다.

원래 웹훅 구성을 다시 적용합니다.


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.conf가 127.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로 변경되었습니다.
monitoring 및 metricsserver 커스텀 리소스의 그룹 이름이 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

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


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을 수동으로 수정하고 다음을 수행합니다.

리소스 요청 및 한도를 문자열 유형으로 변경합니다.
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 지원에 문의하세요.

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

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

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

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

gkectl prepare windows 실패

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

수동 LB 구성 확인 실패

etcd 감시 부족

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

해결 방법:

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

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

해결 방법 단계 보기

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

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

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

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

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

해결 방법 단계 보기

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

해결 방법 단계 보기

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

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

해결 방법 단계 보기

사용자 워커 노드 다시 만들기

사용자 마스터 노드 다시 만들기

관리자 부가기능 노드 다시 만들기

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

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

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

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

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

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

util.CheckFileExists의 gkectl prepare 패닉

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

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

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

ClientConfig 커스텀 리소스

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

`gkectl prepare windows` 실패

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

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

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

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

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

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

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

`gkectl upgrade admin`가 `StorageClass standard sets the parameter diskformat which is invalid for CSI Migration` 와 함께 실패

`vsphere-csi-secret`가 `gkectl update credentials vsphere --admin-cluster` 이후에 업데이트되지 않음

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`util.CheckFileExists`의 `gkectl prepare` 패닉

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

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

`cert-manager` 설치 충돌

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

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

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

CrashLoopBackOff 상수의 `stackdriver-log-forwarder`

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

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

`gkectl diagnose` 인증서 확인 실패

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

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

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

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