네트워킹, 운영 |
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 부하 분산기가 있는 사용자 클러스터를 삭제할 때는 클러스터 삭제 후 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 중에 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 를 입력한 후 하위 메뉴를 사용해서 측정항목을 선택합니다.
- 활성 리소스 메뉴에서 Kubernetes 컨테이너를 선택합니다.
- 활성 측정항목 카테고리 메뉴에서 Anthos를 선택합니다.
- 활성 측정항목 메뉴에서
etcd_network_client_grpc_sent_bytes_total 을 선택합니다.
- 적용을 클릭합니다.
|
업그레이드 및 업데이트 |
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 클러스터 출시 버전에서 수정되었습니다.
이 문제의 영향을 받는지 확인하려면 다음 단계를 수행하세요.
- 외부에서 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.
해결 방법:
|
운영 |
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 와 같은 명령어를 실행해야 합니다.
해결 방법:
|
업그레이드 및 업데이트 |
1.11, 1.12 |
버전 1.12로 업그레이드한 후 자체 배포된 GMP 구성요소가 보존되지 않음
VMware용 Anthos 클러스터 버전 1.12 미만을 사용하고 클러스터의 gmp-system 네임스페이스에서 Google 관리 Prometheus(GMP) 구성요소를 수동으로 설정한 경우 버전 1.12.x로 업그레이드하면 구성요소가 보존되지 않습니다.
버전 1.12부터 gmp-system 네임스페이스 및 CRD의 GMP 구성요소를 stackdriver 객체에서 관리하며 enableGMPForApplications 플래그가 기본적으로 false 로 설정됩니다. 1.12로 업그레이드하기 전에 네임스페이스에 GMP 구성요소를 수동으로 배포하면 stackdriver 가 리소스를 삭제합니다.
해결 방법:
|
작업 |
1.11, 1.12, 1.13.0 - 1.13.1 |
클러스터 스냅샷 system 시나리오에서 ClusterAPI 객체가 누락됨
system 시나리오에서 클러스터 스냅샷의 default 네임스페이스 아래에 리소스가 포함되지 않습니다.
하지만 이 네임스페이스 아래에 있는 Cluster API 객체 등 일부 Kubernetes 리소스에 유용한 디버깅 정보가 포함되어 있습니다. 디버깅 정보가 클러스터 스냅샷에 포함되어야 합니다.
해결 방법:
다음 명령어를 수동으로 실행하여 디버깅 정보를 수집할 수 있습니다.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
각 매개변수는 다음과 같습니다.
여기서 USER_CLUSTER_KUBECONFIG는 사용자 클러스터의 kubeconfig 파일입니다.
|
업그레이드 및 업데이트 |
1.11.0~1.11.4, 1.12.0~1.12.3, 1.13.0~1.13.1 |
vSAN 설정을 위한 노드 드레이닝 중에 사용자 클러스터 삭제가 중단됨
다음 시나리오에서 사용자 클러스터를 삭제, 업데이트 또는 업그레이드할 때 노드 드레이닝이 중단될 수 있습니다.
- 버전 1.12.x부터 관리자 클러스터가 vSAN에서 vSphere CSI 드라이버를 사용해 왔습니다.
- 관리자 클러스터와 사용자 클러스터에 트리 내 vSphere 플러그인이 만든 PVC/PV 객체가 없습니다.
증상을 확인하려면 아래 명령어를 실행합니다.
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
다음은 위 명령어의 샘플 오류 메시지입니다.
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols 는 vSphere 트리 내 드라이버의 기본 디렉터리입니다. 생성된 PVC/PV 객체가 없으면 현재 구현에서 kubevols 가 항상 존재한다고 가정하기 때문에 kubevols 를 찾는 중에 노드 드레이닝이 중단되는 버그가 발생할 수 있습니다.
해결 방법:
노드가 생성된 Datastore에 kubevols 디렉터리를 만듭니다. 이는 user-cluster.yaml 또는 admin-cluster.yaml 파일의 vCenter.datastore 필드에서 정의됩니다.
|
구성 |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 |
사용자 클러스터를 삭제한 후 Cluster Autoscaler clusterrolebinding 및 clusterrole이 삭제됩니다.
사용자 클러스터를 삭제하면 클러스터 자동 확장 처리에 해당하는 clusterrole 및 clusterrolebinding 도 삭제됩니다. 이는 클러스터 자동 확장 처리가 사용 설정된 동일한 관리자 클러스터에 있는 다른 모든 사용자 클러스터에 영향을 줍니다. 이는 동일한 관리자 클러스터 내의 모든 클러스터 자동 확장 처리 포드에 동일한 clusterrole 및 clusterrolebinding이 사용되기 때문입니다.
증상은 다음과 같습니다.
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다.
다음은 표시될 수 있는 오류 메시지의 예시입니다.
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
해결 방법:
해결 방법 단계 보기
관리자 클러스터에서 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는 관리자 클러스터의 kubeconfig 파일입니다.
다음은 표시될 수 있는 오류 메시지의 예시입니다.
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
vsphere-metrics-exporter 로그
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일입니다.
다음은 표시될 수 있는 오류 메시지의 예시입니다.
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
해결 방법:
해결 방법 단계 보기
다음 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 매니페스트를 수정합니다.
- SSH로 관리자 클러스터 제어 영역 노드에 연결합니다.
- 수정할
kube-controller-manager 매니페스트를 엽니다.
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
controllers 목록을 찾습니다.
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- 아래와 같이 이 섹션을 업데이트합니다.
--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.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로 업그레이드하는 것이 좋습니다.
|
ID |
1.10, 1.11, 1.12, 1.13 |
ClientConfig 커스텀 리소스
gkectl update 가 ClientConfig 커스텀 리소스에서 수행한 수동 변경사항을 되돌립니다.
해결 방법:
수동으로 변경한 후 항상 ClientConfig 리소스를 백업하는 것이 좋습니다.
|
설치 |
1.10, 1.11, 1.12, 1.13 |
gkectl check-config 검증 실패: F5 BIG-IP 파티션을 찾을 수 없음
F5 BIG-IP 파티션이 존재하더라도 이를 찾을 수 없어서 검증이 실패합니다.
F5 BIG-IP API 관련 문제로 인해 검사가 실패할 수 있습니다.
해결 방법:
gkectl check-config 를 다시 실행해 보세요.
|
설치 |
1.12 |
cert-manager/ca-injector의 리더 선택 문제로 인해 사용자 클러스터 설치 실패
apiserver/etcd가 느릴 때 crashloop의 cert-manager-cainjector 로 인해 설치 장애가 발생할 수 있습니다.
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
해결 방법:
해결 방법 단계 보기
문제를 해결하려면 다음 명령어를 실행합니다.
변경사항을 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 파일도 관리자 인증서가 만료되면 만료되므로 만료 전에 이 파일을 백업해야 합니다.
- 관리자 클러스터 kubeconfig 파일을 백업합니다.
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
- kubeconfig의
client-certificate-data 및 client-key-data 를 생성된 new_admin.conf 파일의 client-certificate-data 및 client-key-data 로 바꿉니다.
- 이전 인증서를 백업합니다. 이 단계는 선택사항이지만 권장됩니다.
# 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 상태가 됩니다. 그러면 결국 노드가 자동 복구되어 새로운 노드가 생성됩니다.
관련 govmomi 버그
해결 방법:
이 해결 방법은 VMware 지원팀에서 제공합니다.
- 이 문제는 vCenter 버전 7.0U2 이상에서 해결되었습니다.
- 하위 버전의 경우 호스트를 마우스 오른쪽 버튼으로 클릭한 다음 연결 > 연결 해제를 선택합니다. 그런 다음 다시 연결하세요. 그러면 VM의 포트 그룹 업데이트가 강제로 수행됩니다.
|
운영체제 |
1.10, 1.11, 1.12, 1.13 |
원격 호스트에서 SSH 연결 종료
VMware용 Anthos 클러스터 버전 1.7.2 이상의 경우 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화됩니다.
CIS 규칙 '5.2.16 SSH 유휴 제한 시간 간격이 구성되었는지 확인'을 충족하도록 /etc/ssh/sshd_config 가 다음과 같이 설정됩니다.
ClientAliveInterval 300
ClientAliveCountMax 0
이 설정의 목적은 유휴 시간 5분이 지난 후 클라이언트 세션을 종료하는 것입니다. 하지만 ClientAliveCountMax 0 값은 예기치 않은 동작을 가져옵니다. 관리자 워크스테이션 또는 클러스터 노드에서 SSH 세션을 사용하면 SSH 클라이언트가 유휴 상태가 아니더라도 SSH 연결이 끊길 수 있습니다. 예를 들어 시간이 오래 걸리는 명령어를 실행하면 다음 메시지와 함께 명령어가 종료될 수 있습니다.
Connection to [IP] closed by remote host.
Connection to [IP] closed.
해결 방법:
다음 중 원하는 방법을 선택하면 됩니다.
SSH 세션을 다시 연결해야 합니다.
|
설치 |
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 버전을 다시 설치합니다.
존재하는 경우 맞춤설정된 리소스를 복원합니다.
- 업스트림 기본 cert-manager 설치를 사용하거나 cert-manager가
cert-manager 네임스페이스에 설치되어 있는 경우 이 단계를 건너뛸 수 있습니다.
그렇지 않으면 cert-manager 에서 metrics-ca cert-manager.io/v1 인증서 및 metrics-pki.cluster.local 발급기관 리소스를 설치된 cert-manager의 클러스터 리소스 네임스페이스에 복사합니다.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
|
운영체제 |
1.10, 1.11, 1.12, 1.13 |
docker, containerd, runc 취약점 스캔의 거짓양성
VMware용 Anthos 클러스터와 함께 제공되는 Ubuntu OS 이미지의 Docker, containerd, runc는 Ubuntu PPA를 사용하는 특수 버전으로 고정됩니다. 이렇게 하면 VMware용 Anthos 클러스터가 모든 컨테이너 런타임 변경사항을 출시 전에 검증합니다.
하지만 다양한 CVE 스캔 도구에서 취약점 피드로 사용하는 Ubuntu CVE Tracker에 대한 특수 버전은 알려지지 않았습니다. 따라서 Docker, containerd, runc 취약점 스캔 결과에 거짓양성이 표시됩니다.
예를 들어 CVE 스캔 결과에 다음과 같은 거짓양성이 표시될 수 있습니다. VMware용 Anthos 클러스터의 최신 패치 버전에서는 이러한 CVE가 이미 수정되었습니다.
CVE 수정사항은 출시 노트를 참조하세요.
해결 방법:
Canonical에서는 이 문제를 인식하고 있으며 수정사항은 https://github.com/canonical/sec-cvescan/issues/73에서 추적됩니다.
|
업그레이드 및 업데이트 |
1.10, 1.11, 1.12, 1.13 |
HA가 아닌 클러스터 업그레이드 중에 관리자와 사용자 클러스터 사이의 네트워크 연결이 잠시 중지될 수 있음
HA가 아닌 클러스터를 1.9에서 1.10으로 업그레이드하는 경우 사용자 클러스터에 대한 kubectl exec , kubectl log , 웹훅이 잠시 동안 사용 불가능한 상태인 것을 확인할 수 있습니다. 이러한 다운타임은 최대 1분까지 걸릴 수 있습니다. 이 문제는 수신되는 요청(kubectl exec, kubectl log, 웹훅)이 사용자 클러스터의 kube-apiserver에서 처리되기 때문입니다. 사용자 kube-apiserver는 Statefulset입니다. HA가 아닌 클러스터에는 Statefulset에 대해 복제본이 하나만 있습니다. 따라서 업그레이드하는 동안 새 kube-apiserver가 아직 준비되지 않은 상태에서 이전 kube-apiserver를 사용할 수 없는 경우가 존재합니다.
해결 방법:
이러한 다운타임은 업그레이드 프로세스 중에만 발생합니다. 업그레이드 중 다운타임을 줄이기 위해서는 HA 클러스터로 전환하는 것이 좋습니다.
|
설치, 업그레이드 및 업데이트 |
1.10, 1.11, 1.12, 1.13 |
클러스터 생성 또는 업그레이드 후 HA 클러스터를 진단할 때 Konnectivity 준비 검사 실패
HA 클러스터를 생성 또는 업그레이드하는 중 클러스터 진단에서 konnectivity 준비 검사가 실패하더라도, 대부분의 경우에는 VMware용 Anthos 클러스터의 기능(kubectl exec, kubectl log, 웹훅)에 영향을 주지 않습니다. 이 문제는 불안정한 네트워킹 또는 다른 문제로 인해 일정 기간 동안 한 두 개의 konnectivity 복제본이 준비되지 않을 수 있기 때문입니다.
해결 방법:
konnectity는 자동으로 복구됩니다. 30분~1시간 정도 기다린 후 클러스터 진단을 다시 실행하세요.
|
운영체제 |
1.7, 1.8, 1.9, 1.10, 1.11 |
/etc/cron.daily/aide CPU 및 메모리 급증 문제
VMware용 Anthos 클러스터 1.7.2부터 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화되었습니다.
따라서 CIS L1 서버 규칙인 '1.4.2 파일 시스템 무결성을 정기적으로 검증'을 준수하기 위해 aide 검사를 예약하는 /etc/cron.daily/aide 크론 스크립트가 설치되었습니다.
크론 작업은 매일 오전 6시 25분(UTC)에 실행됩니다. 파일 시스템의 파일 수에 따라 이 aide 프로세스로 인해 해당 시간에 CPU 및 메모리 사용량이 급증할 수 있습니다.
해결 방법:
급증이 워크로드에 영향을 주는 경우 일일 크론 작업을 중지할 수 있습니다.
sudo chmod -x /etc/cron.daily/aide
|
네트워킹 |
1.10, 1.11, 1.12, 1.13 |
부하 분산기와 NSX-T 스테이트풀(Stateful) 분산형 방화벽 규칙의 예기치 않은 상호작용
VMware용 Anthos 클러스터 버전 1.9 이상을 배포할 때 NSX-T 스테이트풀(Stateful) 분산 방화벽 규칙을 사용하는 환경에 Seesaw 번들 부하 분산기가 있으면 stackdriver-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를 관리자 클러스터 구성 파일의 경로로 바꿉니다.
|
ID |
1.10, 1.11, 1.12, 1.13 |
Anthos Identity Service를 사용하면 Connect 에이전트가 예기치 않게 다시 시작될 수 있음
Anthos Identity Service 기능을 사용하여 Anthos Identity Service ClientConfig를 관리하는 경우 Connect 에이전트가 예기치 않게 다시 시작될 수 있습니다.
해결 방법:
기존 클러스터에서 이 문제가 발생한 경우 다음 중 하나를 수행할 수 있습니다.
|
네트워킹 |
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
위 명령어에서 다음을 수행합니다.
|
작업, 보안 |
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 )가 있으면 이 문제를 해결할 수도 있습니다.
해결 방법:
|
운영체제, 업그레이드 및 업데이트 |
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 재부팅
|