베어메탈용 GKE 알려진 문제

Version 1.16 

• 최신
• 버전 1.16
• 이전 버전(지원되지 않음)

이 페이지에는 베어메탈용 Google Distributed Cloud Virtual에 대한 모든 알려진 문제가 나와 있습니다. 제품 버전이나 카테고리별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 필터를 선택하세요.

베어메탈용 GDCV 버전을 선택합니다.

1.29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

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

구성 설치 업그레이드 및 업데이트 작업 로깅 및 모니터링 네트워킹 보안 재설정/삭제 GDC용 VM 런타임

또는 문제를 검색합니다.

카테고리	식별된 버전	문제 및 해결 방법
구성, 설치, 보안	1.16.0~1.16.7 및 1.28.0~1.28.400	Binary Authorization 배포에 nodeSelector가 없음 베어메탈용 GKE에 Binary Authorization을 사용 설정하고 1.16.0~1.16.7 또는 1.28.0~1.28.400 버전을 사용하는 경우 기능의 포드가 예약되는 위치에서 문제가 발생할 수 있습니다. 이러한 버전에서는 Binary Authorization 배포에 nodeSelector가 없으므로 제어 영역 노드 대신 워커 노드에 기능의 포드가 예약될 수 있습니다. 그로 인해 오류가 발생하지는 않지만 의도되지 않은 동작입니다. 해결 방법: 영향을 받는 모든 클러스터에 대해 다음 단계를 완료합니다. Binary Authorization 배포 파일을 엽니다. kubectl edit -n binauthz-system deployment binauthz-module-deployment spec.template.spec 블록에 다음 nodeSelector를 추가합니다. nodeSelector: node-role.kubernetes.io/control-plane: "" 변경사항을 저장합니다. 변경사항이 저장되면 포드가 제어 영역 노드에만 다시 배포됩니다. 이 수정사항은 업그레이드할 때마다 적용해야 합니다.
업그레이드 및 업데이트	1.28.0, 1.28.100, 1.28.200, 1.28.300	클러스터를 1.28.0~1.28.300으로 업그레이드하는 경우 오류 발생 버전 1.11.0 이전에 생성된 클러스터를 버전 1.28.0~1.28.300으로 업그레이드하면 업그레이드 중에 수명 주기 컨트롤러 배포자 포드가 오류 상태가 될 수 있습니다. 이 경우 수명 주기 컨트롤러 배포자 포드의 로그에 다음과 유사한 오류 메시지가 표시됩니다. "inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions 해결 방법: 이 문제는 1.28.400 버전에서 해결되었습니다. 이 문제를 해결하려면 버전 1.28.400 이상으로 업그레이드합니다. 업그레이드할 수 없는 경우 다음 명령어를 실행하여 문제를 해결합니다. kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
로깅 및 모니터링	1.13.7, 1.14, 1.15, 1.16, 1.28	로그 탐색기에 잘못된 프로젝트 ID가 표시됨 클러스터 또는 컨테이너 로그가 로그 탐색기의 resource.labels.project_id에서 다른 프로젝트 ID로 태그되는 경우가 있습니다. 이 문제는 클러스터 구성의 clusterOperations.projectID 필드에 설정된 관측 가능성 PROJECT_ONE을 사용하도록 클러스터를 구성했지만 구성의 cloudOperationsServiceAccountKeyPath에는 PROJECT_TWO 프로젝트의 서비스 계정 키가 있을 때 발생합니다. 이러한 경우 모든 로그가 PROJECT_ONE으로 라우팅되지만 resource.labels.project_id에 PROJECT_TWO 라벨이 지정됩니다. 해결 방법: 다음 옵션 중 하나를 사용하여 문제를 해결합니다. 동일한 대상 프로젝트의 서비스 계정을 사용합니다. 서비스 계정 키 JSON 파일에서 project_id를 현재 프로젝트로 변경합니다. 로그 탐색기의 로그 필터에서 직접 project_id를 변경합니다.
네트워킹	1.29.0	BGP를 사용한 번들 부하 분산을 사용하는 클러스터의 성능 저하 BGP를 사용한 번들 부하 분산을 사용하는 버전 1.29.0 클러스터의 경우 LoadBalancer 유형의 총 서비스 수가 2,000개에 근접하면 부하 분산 성능이 저하될 수 있습니다. 성능이 저하되면 새로 생성된 서비스는 연결하는 데 시간이 오래 걸리거나 클라이언트에서 연결할 수 없습니다. 기존 서비스는 계속 작동하지만 부하 분산기 노드 손실과 같은 오류 모드가 효과적으로 처리되지 않습니다. 이러한 서비스 문제는 메모리 부족으로 인해 ang-controller-manager 배포가 종료될 때 발생합니다. 클러스터가 이 문제의 영향을 받는 경우 클러스터의 서비스에 연결할 수 없고 서비스가 정상이 아니며 ang-controller-manager 배포가 CrashLoopBackOff 상태가 됩니다. ang-controller-manager 배포를 나열할 때의 응답은 다음과 비슷합니다. ang-controller-manager-79cdd97b88-9b2rd 0/1 CrashLoopBackOff 639 (59s ago) 2d10h 10.250.210.152 vm-bgplb-centos4-n1-02 <none> <none> ang-controller-manager-79cdd97b88-r6tcl 0/1 CrashLoopBackOff 620 (4m6s ago) 2d10h 10.250.202.2 vm-bgplb-centos4-n1-11 <none> <none> 해결 방법 이 문제를 해결하려면 ang-controller-manager 배포의 메모리 리소스 한도를 100MiB로 늘리고 CPU 한도를 삭제하면 됩니다. kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG 성공적으로 변경하고 편집기를 닫으면 다음 출력이 표시됩니다. deployment.apps/ang-controller-manager edited 변경사항이 적용되었는지 확인하려면 클러스터에서 ang-controller-manager 매니페스트를 검사합니다. kubectl get deployment ang-controller-manager \ -n kube-system \ -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \ --kubeconfig ADMIN_KUBECONFIG 응답은 다음과 비슷하게 표시됩니다. NAME CPU_LIMITS MEMORY_LIMITS ang-controller-manager <none> 400Mi
설치, 업그레이드, 백업, 복원	1.28.0, 1.28.100	Container Registry 엔드포인트 gcr.io 연결 문제로 인해 클러스터 작업이 차단될 수 있음 관리자 클러스터의 여러 클러스터 작업으로 부트스트랩 클러스터가 생성됩니다. 부트스트랩 클러스터를 만들기 전에 bmctl은 관리자 워크스테이션에서 Google Cloud 연결 가능성 검사를 수행합니다. Container Registry 엔드포인트 gcr.io의 연결 문제로 인해 이 검사가 실패할 수 있으며 다음과 같은 오류 메시지가 표시될 수 있습니다. system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) 해결 방법 이 문제를 해결하려면 --ignore-validation-errors 플래그를 사용하여 작업을 다시 시도합니다.
네트워킹	1.15, 1.16	GKE Dataplane V2가 일부 스토리지 드라이버와 호환되지 않음 베어메탈용 GKE 클러스터는 일부 스토리지 제공업체와 호환되지 않는 GKE Dataplane V2를 사용합니다. NFS 볼륨 또는 포드가 중단되면 문제가 발생할 수 있습니다. 이 문제에 취약한 스토리지 드라이버가 지원하는 ReadWriteMany 볼륨을 사용하는 워크로드가 있는 경우에 특히 그렇습니다. Robin.io Portworx(sharedv4 서비스 볼륨) csi-nfs 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다. 해결 방법 이 문제의 해결책은 다음 Ubuntu 버전에서 제공됩니다. 20.04 LTS: linux-image-5.4.0-166-generic 이후의 5.4.0 커널 이미지 사용 22.04 LTS: linux-image-5.15.0-88-generic 이후의 5.15.0 커널 이미지를 사용하거나 6.5 HWE 커널을 사용합니다. 이러한 버전 중 하나를 사용하지 않는 경우 Google 지원팀에 문의하세요.
로깅 및 모니터링	1.15, 1.16, 1.28	대규모 클러스터의 kube-state-metrics OOM kube-state-metrics 와 동일한 노드에 있는 kube-state-metrics 또는 gke-metrics-agent 포드의 메모리가 부족(OOM)할 수 있습니다. 이 문제는 노드가 50개 이상이거나 Kubernetes 객체가 많은 클러스터에서 발생할 수 있습니다. 해결 방법 이 문제를 해결하려면 ksmNodePodMetricsOnly 기능 게이트를 사용하도록 stackdriver 커스텀 리소스 정의를 업데이트합니다. 이 기능 게이트는 소수의 중요한 측정항목만 노출하도록 합니다. 이 해결 방법을 사용하려면 다음 단계를 완료합니다. 사용 가능한 기능 게이트의 stackdriver 커스텀 리소스 정의를 확인합니다. kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly stackdriver 커스텀 리소스 정의를 업데이트하여 ksmNodePodMetricsOnly를 사용 설정합니다. kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
설치	1.28.0-1.28.200	iptable 누락으로 인해 RHEL 9.2에서 프리플라이트 검사 실패 Red Hat Enterprise Linux(RHEL) 9.2 운영체제에 클러스터를 설치할 때 누락된 iptables 패키지로 인해 오류가 발생할 수 있습니다. 이 오류는 프리플라이트 검사 중에 발생하고 다음과 유사한 오류 메시지를 트리거합니다. 'check_package_availability_pass': "The following packages are not available: ['iptables']" RHEL 9.2는 베어메탈용 GKE 버전 1.28에 대한 미리보기 버전입니다. 해결 방법 클러스터 리소스에서 spec.bypassPreflightCheck를 true로 설정하여 프리플라이트 검사 오류를 우회합니다.
작업	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16	대규모 MetalLB 장애 조치 속도 저하 MetalLB가 많은 서비스(10,000개 이상)를 처리하는 경우 장애 조치에 1시간 이상 걸릴 수 있습니다. MetalLB에서 비율이 제한된 큐를 사용하기 때문에 이러한 문제가 발생합니다. 규모가 큰 경우 장애 조치가 필요한 서비스에 도달하는 데 시간이 걸릴 수 있습니다. 해결 방법 클러스터를 버전 1.28 이상으로 업그레이드합니다. 업그레이드할 수 없는 경우 서비스를 수동으로 수정(예: 주석 추가)하면 서비스가 더 빠르게 장애 조치됩니다.
작업	1.16.0-1.16.6, 1.28.0-1.28.200	프록시가 사용 설정된 경우 관리자 워크스테이션에서 환경 변수를 설정해야 함 관리자 워크스테이션에 환경 변수 HTTPS_PROXY 및 NO_PROXY가 정의되어 있지 않으면 프록시 오류로 인해 bmctl check cluster가 실패할 수 있습니다. bmctl 명령어에서 다음 예시와 같이 일부 Google 서비스 호출 실패에 대한 오류 메시지를 보고합니다. [2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred: * GKERegister check failed: 2 errors occurred: * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout 해결 방법 관리자 워크스테이션에서 HTTPS_PROXY 및 NO_PROXY를 수동으로 설정합니다.
업그레이드 및 업데이트	1.28.0-gke.435	audit.log에 잘못된 소유권이 있으면 버전 1.28.0-gke.435로의 업그레이드가 실패할 수 있음 일부 경우에는 제어 영역 노드의 /var/log/apiserver/audit.log 파일에서 그룹 및 사용자 소유권이 모두 root로 설정됩니다. 이 파일 소유권 설정으로 인해 클러스터를 버전 1.16.x에서 버전 1.28.0-gke.435로 업그레이드할 때 제어 영역 노드에 대한 업그레이드 실패가 발생합니다. 이 문제는 버전 1.11 이전에 생성되고 Cloud 감사 로그가 중지된 클러스터에만 적용됩니다. Cloud 감사 로그는 기본적으로 버전 1.9 이상의 클러스터에 사용 설정됩니다. 해결 방법 클러스터를 버전 1.28.100-gke.146으로 업그레이드할 수 없는 경우 다음 단계를 사용하여 버전 1.28.0-gke.435로의 클러스터 업그레이드를 완료합니다. Cloud 감사 로그가 사용 설정된 경우 /var/log/apiserver/audit.log 파일을 삭제합니다. Cloud 감사 로그가 사용 중지된 경우 /var/log/apiserver/audit.log 소유권을 상위 디렉터리 /var/log/apiserver와 동일하게 변경합니다.
네트워킹, 업그레이드 및 업데이트	1.28.0-gke.435	MetalLB가 VIP 서비스에 IP 주소를 할당하지 않음 베어메탈용 GKE는 번들 부하 분산에 MetalLB를 사용합니다. 베어메탈용 GKE 출시 버전 1.28.0-gke.435에서 번들 MetalLB는 버전 0.13으로 업그레이드되어 IPAddressPools에 대한 CRD 지원이 제공됩니다. 하지만 ConfigMaps는 IPAddressPool에 대한 모든 이름을 허용하므로 IPAddressPool의 이름 끝에 해시를 추가하여 풀 이름을 Kubernetes와 호환되는 이름으로 변환해야 했습니다. 예를 들어 클러스터를 버전 1.28.0-gke.435로 업그레이드하면 이름이 default인 IPAddressPool이 default-qpvpd와 같은 이름으로 변환됩니다. MetalLB에서는 선택을 위해 IPPool의 특정 이름을 필요로 하므로 이름 변환 시 MetalLB에서 풀을 선택하고 IP 주소를 할당할 수 없습니다. 따라서 metallb.universe.tf/address-pool을 주석으로 사용하여 IP 주소의 주소 풀을 선택하는 서비스가 더 이상 MetalLB 컨트롤러에서 IP 주소를 수신하지 않습니다. 이 문제는 베어메탈용 GKE 버전 1.28.100-gke.146에서 해결되었습니다. 해결 방법 클러스터를 버전 1.28.100-gke.146으로 업그레이드할 수 없는 경우 다음 단계를 사용하여 문제를 해결합니다. IPAddressPool의 변환된 이름을 가져옵니다. kubectl get IPAddressPools -n kube-system 영향을 받는 서비스를 업데이트하여 metallb.universe.tf/address-pool 주석을 해시가 있는 변환된 이름으로 설정합니다. 예를 들어 IPAddressPool 이름이 default에서 default-qpvpd와 같은 이름으로 변환된 경우 서비스의 metallb.universe.tf/address-pool: default 주석을 metallb.universe.tf/address-pool: default-qpvpd로 변경합니다. 이름 변환에 사용된 해시는 확정적이므로 해결 방법은 지속됩니다.
업그레이드 및 업데이트	1.14, 1.15, 1.16, 1.28, 1.29	버전 1.14.x로 업그레이드한 후 포드가 분리됨 베어메탈용 GKE 클러스터를 버전 1.14.x로 업그레이드해도 이전 버전의 일부 리소스는 삭제되지 않습니다. 구체적으로 다음과 같은 분리된 포드 집합이 표시될 수 있습니다. capi-webhook-system/capi-controller-manager-xxx capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx 이러한 분리된 객체는 클러스터 작업에 직접 영향을 미치지 않지만 삭제하는 것이 좋습니다. 다음 명령어를 실행하여 분리된 객체를 삭제합니다. kubectl delete ns capi-webhook-system kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration 이 문제는 베어메탈용 GKE 버전 1.15.0 이상에서 해결되었습니다.
설치	1.14	클러스터 생성이 machine-init 작업에서 중단됨 베어메탈용 Google Distributed Cloud Virtual 버전 1.14.x를 설치하려고 할 때 machine-init 작업으로 인해 다음 예시 출력과 비슷한 오류가 발생할 수 있습니다. "kubeadm join" task failed due to: error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members "kubeadm reset" task failed due to: panic: runtime error: invalid memory address or nil pointer dereference 해결 방법: machine-init 작업이 실패하도록 하는 사용되지 않는 etcd 구성원을 삭제합니다. 작동하는 제어 영역 노드에서 다음 단계를 완료합니다. 기존 etcd 구성원을 나열합니다. etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member list 다음 예시 출력과 같이 상태가 unstarted인 구성원을 찾습니다. 5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false 99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false 실패한 etcd 구성원을 삭제합니다. etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member remove MEMBER_ID MEMBER_ID를 실패한 etcd 구성원의 ID로 바꿉니다. 앞의 출력 예시에서 이 ID는 bd1949bcb70e2cb5입니다. 다음 출력 예시에서는 구성원이 삭제된 것을 보여줍니다. Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
네트워킹	1.28.0	Cilium-operator에 노드 list 및 watch 권한 없음 Cilium 1.13에서 cilium-operator ClusterRole 권한이 잘못되었습니다. 노드 list 및 watch 권한이 없습니다. cilium-operator가 가비지 수집기를 시작하지 못하여 다음 문제가 발생합니다. Cilium 리소스 유출 비활성 ID가 BFP 정책 맵에서 삭제되지 않습니다. 정책 맵이 16K 제한에 도달할 수 있습니다. 새 항목을 추가할 수 없습니다. 잘못된 NetworkPolicy 적용 ID가 64K 제한에 도달할 수 있습니다. 새 포드를 만들 수 없습니다. 노드 권한이 없는 연산자가 다음과 같은 로그 메시지 예시를 보고합니다. 2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s Cilium 에이전트가 정책 맵에 항목을 삽입할 수 없을 때 다음 예시와 같은 오류 메시지를 보고합니다. level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint 해결 방법: Cilium ID를 삭제한 후 누락된 ClusterRole 권한을 연산자에 추가합니다. 기존 CiliumIdentity 객체를 삭제합니다. kubectl delete ciliumid –-all cilium-operator ClusterRole 객체를 수정합니다. kubectl edit clusterrole cilium-operator 다음 예시에 표시된 것처럼 누락된 권한을 포함하는 nodes에 대한 섹션을 추가합니다. - apiGroups: - "" resources: - nodes verbs: - get - list - watch 편집기를 저장하고 닫습니다. 연산자가 권한 변경을 동적으로 감지합니다. 연산자를 수동으로 다시 시작할 필요가 없습니다.
업그레이드 및 업데이트	1.15.0-1.15.7, 1.16.0-1.16.3	프리플라이트 검사 중에 일시적인 문제 발생 업그레이드 프리플라이트 검사 중에 실행되는 kubeadm 상태 점검 태스크 중 하나는 다음 오류 메시지와 함께 실패할 수 있습니다. [ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found 이 오류는 무시해도 안전합니다. 업그레이드를 차단하는 이 오류가 발생하면 업그레이드 명령어를 다시 실행합니다. bmctl preflightcheck 명령어를 사용하여 프리플라이트를 실행할 때 이 오류가 발견되면 이 실패로 인해 아무것도 차단되지 않습니다. 프리플라이트 검사를 다시 실행하여 정확한 프리플라이트 정보를 가져올 수 있습니다. 해결 방법: 업그레이드 명령어를 다시 실행합니다. bmctl preflightcheck 중에 오류가 발생하면 preflightcheck 명령어를 다시 실행합니다.
작업	1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0	노드를 교체하거나 삭제할 때 주기적인 네트워크 상태 점검 실패 이 문제는 노드가 교체되거나 삭제된 후 주기적으로 네트워크 상태 점검을 수행하는 클러스터에 영향을 줍니다. 클러스터에 주기적인 상태 점검이 수행되는 경우 네트워크 인벤토리 ConfigMap은 생성된 후 업데이트되지 않으므로 노드를 대체하거나 제거한 후에 정기적인 네트워크 상태 점검이 실패합니다. 해결 방법: 권장 해결 방법은 인벤토리 ConfigMap과 주기적인 네트워크 상태 점검을 삭제하는 것입니다. 클러스터 운영자는 최신 정보를 사용하여 자동으로 다시 만듭니다. 1.14.x 클러스터의 경우 다음 명령어를 실행합니다. kubectl delete configmap \ $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ CLUSTER_NAME-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 1.15.0 이상 클러스터의 경우 다음 명령어를 실행합니다. kubectl delete configmap \ $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ bm-system-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
네트워킹	1.14, 1.15, 1.16.0-1.16.2	기기 이름에 마침표가 포함된 경우 GDC용 Network Gateway에서 구성을 적용할 수 없음 네트워크 기기 이름에 마침표(.)가 포함된 경우(예:bond0.2) GDC용 Network Gateway는 변경사항을 적용하기 위해 sysctl을 실행할 때 마침표를 디렉터리의 경로로 간주합니다. GDC용 Network Gateway가 중복 주소 감지(DAD)가 사용 설정되었는지 확인하면 검사가 실패할 수 있으므로 조정되지 않습니다. 이 동작은 클러스터 버전마다 다릅니다. 1.14 및 1.15: 이 오류는 IPv6 유동 IP 주소를 사용할 때만 발생합니다. IPv6 유동 IP 주소를 사용하지 않는 경우 기기 이름에 마침표가 포함되어 있을 때 이 문제가 발생하지 않습니다. 1.16.0~1.16.2: 이 오류는 기기 이름에 마침표가 있는 경우 항상 존재합니다. 해결 방법: 클러스터를 버전 1.16.3 이상으로 업그레이드합니다. 클러스터를 업그레이드할 수 있을 때까지 문제 해결을 위해 기기 이름에서 마침표(.)를 삭제합니다.
업그레이드 및 업데이트, 네트워킹, 보안	1.16.0	seccomp가 사용 중지된 경우 1.16.0으로 업그레이드 실패 클러스터에서 seccomp가 사용 중지된 경우(spec.clusterSecurity.enableSeccomp가 false로 설정됨) 버전 1.16.0으로 업그레이드가 실패합니다. 베어메탈용 GKE 버전 1.16은 Kubernetes 버전 1.27을 사용합니다. Kubernetes 버전 1.27.0 이상에서 seccomp 프로필 설정 기능은 일반 정식 버전이며 더 이상 기능 게이트를 사용하지 않습니다. 이 Kubernetes 변경사항으로 인해 클러스터 구성에서 seccomp가 사용 중지될 경우 버전 1.16.0으로의 업그레이드가 실패합니다. 이 문제는 버전 1.16.1 이상의 클러스터에서 해결되었습니다. cluster.spec.clusterSecurity.enableSeccomp 필드가 false로 설정된 경우 버전 1.16.1 이상으로 업그레이드할 수 있습니다. spec.clusterSecurity.enableSeccomp가 설정되지 않거나 true로 설정된 클러스터는 영향을 받지 않습니다.
설치, 작업	1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1	/var/lib/containerd가 마운트될 때 재부팅 후 containerd 메타데이터가 손상될 수 있음 선택적으로 /var/lib/containerd를 마운트한 경우 재부팅 후 containerd 메타데이터가 손상될 수 있습니다. 메타데이터가 손상되면 시스템에 중요한 포드를 포함하여 포드가 실패할 수 있습니다. 이 문제의 영향을 받는지 확인하려면 /var/lib/containerd/의 /etc/fstab에 선택적 마운트가 정의되어 있고 마운트 옵션에 nofail이 있는지 확인합니다. 해결 방법: /etc/fstab에서 nofail 마운트 옵션을 삭제하거나 클러스터를 버전 1.15.6 이상으로 업그레이드합니다.
작업	1.13, 1.14, 1.15, 1.16, 1.28	클러스터에서 비활성 포드 정리 배포에서 관리되는 포드(ReplicaSet)가 Failed 상태이고 TaintToleration 상태가 표시될 수 있습니다. 이러한 포드는 클러스터 리소스를 사용하지 않지만 삭제해야 합니다. 다음 kubectl 명령어를 사용하여 삭제할 수 있는 포드를 나열할 수 있습니다. kubectl get pods –A | grep TaintToleration 다음 출력 예시는 TaintToleration 상태의 포드를 보여줍니다. kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 해결 방법: 설명된 증상을 가진 각 포드에 대해 포드가 속한 ReplicaSet를 확인합니다. ReplicaSet가 충족되었으면 포드를 삭제할 수 있습니다. 포드를 관리하는 ReplicaSet를 가져오고 ownerRef.Kind 값을 찾습니다. kubectl get pod POD_NAME -n NAMESPACE -o yaml ReplicaSet를 가져오고 status.replicas가 spec.replicas와 동일한지 확인합니다. kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml 이름이 일치하면 포드를 삭제합니다. kubectl delete pod POD_NAME -n NAMESPACE.
업그레이드	1.16.0	버전 1.16.0으로 업그레이드하면 etcd 이벤트가 중단될 수 있음 기존 클러스터를 버전 1.16.0으로 업그레이드하면 etcd 이벤트와 관련된 포드 오류로 인해 작업이 중단될 수 있습니다. 특히 TASK [etcd_events_install : Run etcdevents] 단계에서는 노드 업그레이드 작업이 실패합니다. 이 문제의 영향을 받는 경우 다음과 같은 포드 실패가 표시됩니다. kube-apiserver 포드가 다음 오류로 인해 시작되지 않습니다. connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" etcd-events 포드가 다음 오류로 인해 시작되지 않습니다. Error: error syncing endpoints with etcd: context deadline exceeded 해결 방법: 수정사항이 포함된 버전으로 클러스터를 업그레이드할 수 없으면 다음 임시 해결 방법을 사용해서 오류를 해결합니다. SSH를 사용하여 오류가 보고된 제어 영역 노드에 액세스합니다. etcd-events 매니페스트 파일 /etc/kubernetes/manifests/etcd-events.yaml을 수정하고 initial-cluster-state=existing 플래그를 삭제합니다. 매니페스트를 적용합니다. 업그레이드가 계속됩니다.
네트워킹	1.15.0-1.15.2	CoreDNS orderPolicy가 인식되지 않음 OrderPolicy는 매개변수로 인식되지 않고 사용되지 않습니다. 대신 베어메탈용 GKE는 항상 Random을 사용합니다. 이 문제는 CoreDNS 템플릿이 업데이트되지 않아서 orderPolicy가 무시되기 때문에 발생합니다. 해결 방법: CoreDNS 템플릿을 업데이트하고 수정사항을 적용합니다. 이 수정사항은 업그레이드가 수행될 때까지 지속됩니다. 기존 템플릿을 수정합니다. kubectl edit cm -n kube-system coredns-template 템플릿의 콘텐츠를 다음으로 바꿉니다. coredns-template: |- .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } {{- if .PrivateGoogleAccess }} import zones/private.Corefile {{- end }} {{- if .RestrictedGoogleAccess }} import zones/restricted.Corefile {{- end }} prometheus :9153 forward . {{ .UpstreamNameservers }} { max_concurrent 1000 {{- if ne .OrderPolicy "" }} policy {{ .OrderPolicy }} {{- end }} } cache 30 {{- if .DefaultDomainQueryLogging }} log {{- end }} loop reload loadbalance }{{ range $i, $stubdomain := .StubDomains }} {{ $stubdomain.Domain }}:53 { errors {{- if $stubdomain.QueryLogging }} log {{- end }} cache 30 forward . {{ $stubdomain.Nameservers }} { max_concurrent 1000 {{- if ne $.OrderPolicy "" }} policy {{ $.OrderPolicy }} {{- end }} } } {{- end }}
네트워킹, 운영	1.10, 1.11, 1.12, 1.13, 1.14	우선순위 클래스 누락으로 인해 제거되거나 대기 중인 GDC용 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 이러한 오류는 제거 이벤트 또는 노드 리소스로 인해 포드를 예약할 수 없음을 나타냅니다. GDC용 Network Gateway 포드에는 PriorityClass가 없으므로 다른 워크로드와 같은 기본 우선순위가 있습니다. 노드에 리소스 제약이 있으면 네트워크 게이트웨이 포드가 삭제될 수 있습니다. 이 동작은 특히 ang-node DaemonSet에 좋지 않습니다. 이러한 포드는 특정 노드에 예약되어야 하며 마이그레이션할 수 없기 때문입니다. 해결 방법: 1.15 이상으로 업그레이드합니다. 단기적으로 문제를 해결하려면 PriorityClass를 수동으로 GDC용 Network Gateway 구성요소에 할당합니다. 베어메탈용 GKE 컨트롤러는 클러스터 업그레이드와 같은 조정 프로세스 중에 이러한 수동 변경사항을 덮어씁니다. system-cluster-critical PriorityClass를 ang-controller-manager 및 autoscaler 클러스터 컨트롤러 배포에 할당합니다. system-node-critical PriorityClass를 ang-daemon 노드 DaemonSet에 할당합니다.
설치, 업그레이드 및 업데이트	1.15.0, 1.15.1, 1.15.2	클러스터 이름 길이로 인해 클러스터 생성 및 업그레이드 실패 클러스터 이름이 영문 기준으로 48자(버전 1.15.0) 또는 45자(버전 1.15.1 또는 1.15.2)를 초과하면 버전 1.15.0, 1.15.1 또는 1.15.2 클러스터를 만들 수 없거나 클러스터를 버전 1.15.0, 1.15.1 또는 1.15.2로 업그레이드할 수 없습니다. 클러스터 만들기 작업과 업그레이드 작업 중에 베어메탈용 GKE는 클러스터 이름과 버전을 포함하는 이름으로 상태 점검 리소스를 만듭니다. 버전 1.15.0 클러스터의 경우 상태 점검 리소스 이름은 CLUSTER_NAME-add-ons-CLUSTER_VER입니다. 버전 1.15.1 또는 1.15.2 클러스터의 경우 상태 점검 리소스 이름은 CLUSTER_NAME-kubernetes-CLUSTER_VER입니다. 클러스터 이름이 길면 상태 점검 리소스 이름이 라벨 이름에 대한 Kubernetes 63자 길이 제한을 초과하므로 상태 점검 리소스를 만들 수 없습니다. 상태 점검이 실패하면 클러스터 작업이 실패합니다. 이 문제의 영향을 받는지 확인하려면 kubectl describe를 사용하여 실패한 리소스를 확인합니다. kubectl describe healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 이 문제의 영향을 받는 경우 응답에 다음과 같은 ReconcileError 경고가 포함됩니다. ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred: * failed to create job for health check db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch "bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters, spec.template.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters] 해결 방법 클러스터 업그레이드 또는 생성을 차단 해제하려면 상태 점검을 우회하면 됩니다. (status: {pass: true}) 명령어를 사용하여 상태 점검 커스텀 리소스를 통과 상태로 패치합니다. kubectl patch healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG --type=merge \ --subresource status --patch 'status: {pass: true}'
업그레이드 및 업데이트	1.14, 1.15	미리보기 기능이 있는 버전 1.14.0 및 1.14.1 클러스터를 버전 1.15.x로 업그레이드할 수 없음 버전 1.14.0 및 1.14.1 클러스터에 미리보기 기능이 사용 설정된 경우 버전 1.15.x로의 업그레이드가 차단됩니다. 이는 클러스터 구성 파일에서 다음 주석으로 사용 설정된 kube-proxy 없이 클러스터를 만드는 기능과 같은 미리보기 기능에 적용됩니다. preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" 이 문제의 영향을 받는 경우 클러스터 업그레이드 중 다음과 같은 오류가 발생합니다. [2023-06-20 23:37:47+0000] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid: Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]: Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature isn't supported in 1.15.1 Anthos Bare Metal version 이 문제는 버전 1.14.2 이상의 클러스터에서 해결되었습니다. 해결 방법: 클러스터를 버전 1.15.x로 업그레이드하기 전에 버전 1.14.2 이상으로 업그레이드할 수 없는 경우 부트스트랩 클러스터를 사용하여 버전 1.15.x로 직접 업그레이드할 수 있습니다. bmctl upgrade cluster --use-bootstrap=true
작업	1.15	버전 1.15 클러스터에서는 중복된 유동 IP 주소를 허용하지 않음 GDC용 Network Gateway에서는 spec.floatingIPs에 기존 NetworkGatewayGroup 커스텀 리소스에서 이미 사용된 IP 주소를 포함하는 새로운 NetworkGatewayGroup 커스텀 리소스를 만들 수 없습니다. 이 규칙은 베어메탈용 GKE 클러스터 버전 1.15.0 이상의 웹훅에서 적용됩니다. 기존의 중복된 유동 IP 주소는 오류를 일으키지 않습니다. 웹훅에서만 중복 IP 주소가 포함된 새 NetworkGatewayGroups 커스텀 리소스의 생성을 막습니다. 웹훅 오류 메시지는 충돌하는 IP 주소와 이를 이미 사용 중인 기존 커스텀 리소스를 식별합니다. IP address exists in other gateway with name default 이그레스 NAT 게이트웨이와 같은 고급 네트워킹 기능에 대한 초기 문서에서는 중복 IP 주소에 대해 경고하지 않습니다. 처음에는 조정자에서 default라는 NetworkGatewayGroup 리소스만 인식했습니다. 이제 GDC용 Network Gateway가 시스템 네임스페이스에서 모든 NetworkGatewayGroup 커스텀 리소스를 인식합니다. 기존 NetworkGatewayGroup 커스텀 리소스는 그대로 유지됩니다. 해결 방법: 새 NetworkGatewayGroup 커스텀 리소스를 만들 때에만 오류가 발생합니다. 이 오류를 해결하려면 다음 안내를 따르세요. 다음 명령어를 사용하여 NetworkGatewayGroups 커스텀 리소스를 나열합니다. kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml 기존 NetworkGatewayGroup 커스텀 리소스를 열고 충돌하는 유동 IP 주소(spec.floatingIPs)를 삭제합니다. kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system RESOURCE_NAME 변경사항을 적용하려면 수정된 커스텀 리소스를 닫고 저장합니다.
GDC용 VM 런타임	1.13.7	비공개 레지스트리를 사용하는 1.13.7 클러스터에서 VM이 시작되지 않을 수 있음 비공개 레지스트리를 사용하는 신규 또는 업그레이드된 버전 1.13.7 클러스터에서 GDC용 VM 런타임을 사용 설정하면 노드 네트워크에 연결하거나 GPU를 사용하는 VM이 제대로 시작하지 않을 수 있습니다. 이 문제는 vm-system 네임스페이스의 일부 시스템 포드에서 이미지 가져오기 오류가 발생하기 때문에 발생합니다. 예를 들어 VM에서 노드 네트워크를 사용하는 경우 일부 포드에서 다음과 같은 이미지 가져오기 오류를 보고할 수 있습니다. macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m 이 문제는 버전 1.14.0 이상의 베어메탈용 GKE 클러스터에서 해결되었습니다. 해결 방법 클러스터를 즉시 업그레이드할 수 없는 경우 이미지를 수동으로 가져올 수 있습니다. 다음 명령어는 VM의 macvtab CNI 플러그인 이미지를 가져와 비공개 레지스트리로 내보냅니다. docker pull \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker tag \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker push \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 REG_HOST를 로컬에서 미러링하는 호스트의 도메인 이름으로 바꿉니다.
설치	1.11, 1.12	종류 클러스터에서 클러스터를 만드는 동안 gke-metric-agent 포드 시작 실패 종류 클러스터에서 클러스터를 만드는 동안 다음과 같은 이미지 가져오기 오류로 인해 gke-metrics-agent 포드를 시작할 수 없습니다. error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 또한 부트스트랩 클러스터의 containerd 로그에 다음 항목이 표시됩니다. Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 포드에 다음 '가져오기 실패' 오류가 표시됩니다. gcr.io/gke-on-prem-staging/gke-metrics-agent 해결 방법 종류 클러스터의 gke-metrics-agent 포드는 클러스터 생성 성공률과 내부 추적 및 모니터링을 용이하게 하기 위한 것이므로 오류가 발생해도 클러스터 생성 프로세스가 차단되지 않습니다. 따라서 이 오류를 무시해도 됩니다. 해결 방법 종류 클러스터의 gke-metrics-agent 포드는 클러스터 생성 성공률과 내부 추적 및 모니터링을 용이하게 하기 위한 것이므로 오류가 발생해도 클러스터 생성 프로세스가 차단되지 않습니다. 따라서 이 오류를 무시해도 됩니다.
작업, 네트워킹	1.12, 1.13, 1.14, 1.15, 1.16, 1.28	IPv6 서비스 엔드포인트에 액세스하면 CentOS 또는 RHEL에서 LoadBalancer 노드가 비정상 종료됨 이중 스택 서비스(IPv4 및 IPv6 엔드포인트가 모두 있는 서비스)에 액세스하고 IPv6 엔드포인트를 사용하면 서비스를 제공하는 LoadBalancer 노드가 비정상 종료될 수 있습니다. 이 문제는 CentOS 또는 RHEL 및 kernel-4.18.0-372.46.1.el8_6 이전 커널 버전과 함께 이중 스택 서비스를 사용하는 고객에게 영향을 줍니다. 이 문제의 영향을 받는다고 생각되면 uname -a 명령어를 사용하여 LoadBalancer 노드의 커널 버전을 확인합니다. 해결 방법: LoadBalancer 노드를 커널 버전 kernel-4.18.0-372.46.1.el8_6 이상으로 업데이트합니다. 기본적으로 CentOS 및 RHEL 버전 8.6 이상에서 이 커널 버전을 사용할 수 있습니다.
네트워킹	1.11, 1.12, 1.13, 1.14.0	노드 재부팅 후 간헐적인 연결 문제 노드를 다시 시작한 후 NodePort 또는 LoadBalancer 서비스에 간헐적인 연결 문제가 발생할 수 있습니다. 예를 들어 간헐적인 TLS 핸드셰이크 오류나 연결 재설정 오류가 있을 수 있습니다. 이 문제는 클러스터 버전 1.14.1 이상에서 해결되었습니다. 이 문제의 영향을 받는지 확인하려면 영향을 받는 서비스의 백엔드 포드가 실행 중인 노드에서 iptables 전달 규칙을 확인합니다. sudo iptables -L FORWARD iptables에 KUBE-FORWARD 규칙이 CILIUM_FORWARD 규칙 앞에 표시되면 이 문제의 영향을 받을 수 있습니다. 다음 출력 예시에서는 문제가 있는 노드를 보여줍니다. Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */ CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ 해결 방법: 잘못 구성된 노드에서 anetd 포드를 다시 시작합니다. anetd 포드를 다시 시작하면 iptables의 전달 규칙이 올바르게 구성됩니다. 다음 출력 예시에서는 이제 CILIUM_FORWARD 규칙이 KUBE-FORWARD 규칙 앞에 올바르게 구성되었음을 보여줍니다. Chain FORWARD (policy ACCEPT) target prot opt source destination CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
업그레이드 및 업데이트	1.9, 1.10	미리보기 기능에서 원래 권한과 소유자 정보를 유지하지 않음 bmctl 1.9.x를 사용하는 1.9.x 클러스터의 미리보기 기능에서 원래 권한과 소유자 정보를 유지하지 않습니다. 이 기능의 영향을 받는지 확인하려면 다음 명령어를 사용하여 백업된 파일을 추출하세요. tar -xzvf BACKUP_FILE 해결 방법 metadata.json이 있는지, bmctlVersion이 1.9.x인지 확인합니다. metadata.json이 없으면 1.10.x 클러스터로 업그레이드하고 bmctl 1.10.x를 사용하여 백업/복원합니다.
업그레이드 및 만들기	1.14.2	CreateContainerConfigError와 함께 clientconfig-operator가 대기 중 상태로 멈춤 OIDC/LDAP 구성으로 버전 1.14.2 클러스터를 업그레이드하거나 만든 경우 clientconfig-operator 포드가 대기 중 상태로 멈출 수 있습니다. 이 문제에서는 하나는 실행 중 상태이고 다른 하나는 대기 중 상태인 clientconfig-operator 포드 두 개가 존재합니다. 이 문제는 버전 1.14.2 클러스터에만 적용됩니다. 1.14.0 및 1.14.1과 같은 이전 클러스터 버전은 영향을 받지 않습니다. 이 문제는 버전 1.14.3 및 1.15.0 이상을 포함한 모든 후속 출시 버전에서 해결되었습니다. 해결 방법: 이 문제를 해결하려면 clientconfig-operator 배포를 패치하여 추가 보안 컨텍스트를 추가하고 배포가 준비되었는지 확인합니다. 다음 명령어를 사용하여 대상 클러스터에서 clientconfig-operator를 패치합니다. kubectl patch deployment clientconfig-operator -n kube-system \ -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \ --kubeconfig CLUSTER_KUBECONFIG 다음을 바꿉니다. CLUSTER_KUBECONFIG: 대상 클러스터의 kubeconfig 파일 경로입니다.
작업	1.11, 1.12, 1.13, 1.14, 1.15	번들 부하 분산이 없는 클러스터에서 인증 기관 순환 실패 번들 부하 분산이 없는 클러스터(spec.loadBalancer.mode가 manual로 설정)의 경우 bmctl update credentials certificate-authorities rotate 명령어는 응답하지 않고 x509: certificate signed by unknown authority 오류가 표시되면서 실패할 수 있습니다. 이 문제의 영향을 받는 경우 bmctl 명령어에서 응답하기 전에 다음 메시지를 출력할 수 있습니다. Signing CA completed in 3/0 control-plane nodes 이 경우 명령어가 결국 실패합니다. 제어 영역 3개가 있는 클러스터의 순환 인증 기관 로그에는 다음과 같은 항목이 포함될 수 있습니다. [2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK [2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK Signing CA completed in 0/0 control-plane nodes Signing CA completed in 1/0 control-plane nodes Signing CA completed in 2/0 control-plane nodes Signing CA completed in 3/0 control-plane nodes ... Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") 해결 방법 추가 지원이 필요하면 Google 지원팀에 문의하세요.
설치, 네트워킹	1.11, 1.12, 1.13, 1.14.0-1.14.1	이중 스택 클러스터에서 ipam-controller-manager 비정상 종료 루프 발생 이중 스택 클러스터(IPv4 및 IPv6 주소가 모두 포함된 클러스터)를 배포하면 ipam-controller-manager 포드에 비정상 종료 루프가 발생할 수 있습니다. 이 동작으로 인해 노드가 Ready 및 NotReady 상태 간에 순환하고 클러스터 설치가 실패할 수 있습니다. 이 문제는 API 서버가 고부하 상태일 때 발생할 수 있습니다. 이 문제의 영향을 받는지 확인하려면 CrashLoopBackOff 오류와 함께 ipam-controller-manager 포드가 실패하는지 확인합니다. kubectl -n kube-system get pods | grep ipam-controller-manager 다음 출력 예시는 CrashLoopBackOff 상태의 포드를 보여줍니다. ipam-controller-manager-h7xb8 0/1 CrashLoopBackOff 3 (19s ago) 2m ipam-controller-manager-vzrrf 0/1 CrashLoopBackOff 3 (19s ago) 2m1s ipam-controller-manager-z8bdw 0/1 CrashLoopBackOff 3 (31s ago) 2m2s NotReady 상태인 노드의 세부정보를 가져옵니다. kubectl describe node <node-name> | grep PodCIDRs 이 문제가 있는 클러스터에서는 다음 예시 출력에 표시된 것처럼 노드에 PodCIDR이 할당되지 않습니다. PodCIDRs: 정상 클러스터에서는 다음 예시 출력에 표시된 것처럼 모든 노드에 이중 스택 PodCIDR이 할당되어 있어야 합니다. PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 해결 방법: ipam-controller-manager 포드를 재시작하세요. kubectl -n kube-system rollout restart ds ipam-controller-manager
작업	1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14	etcd 감시 부족 etcd 버전 3.4.13 이하를 실행하는 클러스터는 감시 부족 및 비작업 리소스 감시를 경험할 수 있으며, 이로 인해 다음 문제가 발생할 수 있습니다. 포드 예약이 중단됨 노드를 등록할 수 없음 kubelet이 포드 변경사항을 관찰하지 못함 이러한 문제로 인해 클러스터가 작동하지 않을 수 있습니다. 이 문제는 베어메탈용 GDCV 버전 1.12.9, 1.13.6, 1.14.3 및 이후 출시 버전에서 해결되었습니다. 이러한 최신 출시 버전에는 etcd 버전 3.4.21이 사용됩니다. 베어메탈용 GDCV의 모든 이전 버전은 이 문제의 영향을 받습니다. 해결 방법 즉시 업그레이드할 수 없으면 클러스터의 노드 수를 줄여서 클러스터 실패 위험을 완화할 수 있습니다. etcd_network_client_grpc_sent_bytes_total 측정항목이 300MBps 미만이 될 때까지 노드를 삭제하세요. 측정항목 탐색기에서 이 측정항목을 보려면 다음 안내를 따르세요. Google Cloud 콘솔의 측정항목 탐색기로 이동합니다. 측정항목 탐색기로 이동 구성 탭을 선택합니다. 측정항목 선택을 확장하고 필터 표시줄에 Kubernetes Container를 입력한 후 하위 메뉴를 사용해서 측정항목을 선택합니다. 활성 리소스 메뉴에서 Kubernetes 컨테이너를 선택합니다. 활성 측정항목 카테고리 메뉴에서 Anthos를 선택합니다. 활성 측정항목 메뉴에서 etcd_network_client_grpc_sent_bytes_total을 선택합니다. 적용을 클릭합니다.
네트워킹	1.11.6, 1.12.3	SR-IOV 연산자의 vfio-pci 모드 '실패' 상태 SriovNetworkNodeState 객체의 syncStatus는 구성된 노드의 '실패' 값을 보고할 수 있습니다. 노드 상태를 보고 문제의 영향을 받는지 확인하려면 다음 명령어를 실행합니다. kubectl -n gke-operators get \ sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \ -o jsonpath='{.status.syncStatus}' NODE_NAME을 확인할 노드의 이름으로 바꿉니다. 해결 방법: SriovNetworkNodeState 객체 상태가 '실패'인 경우 클러스터를 버전 1.11.7 이상 또는 버전 1.12.4 이상으로 업그레이드합니다.
업그레이드 및 업데이트	1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1	일부 워커 노드가 업그레이드 후 준비 상태가 아님 업그레이드가 완료되면 일부 워커 노드의 준비 조건이 false로 설정될 수 있습니다. 노드 리소스에서 다음 예시와 비슷한 준비 조건 옆에 오류가 표시됩니다. container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized 중단된 머신에 로그인하면 머신의 CNI 구성이 비어 있습니다. sudo ls /etc/cni/net.d/ 해결 방법 노드의 anetd 포드를 삭제하여 다시 시작합니다.
업그레이드, 업데이트, 보안	1.10	cert-manager에서 여러 인증서 순환이 일치하지 않음 여러 수동 또는 자동 인증서 순환 후 anthos-cluster-operator와 같은 웹훅 포드가 cert-manager에서 발급한 새 인증서로 업데이트되지 않습니다. 클러스터 커스텀 리소스 업데이트가 실패하고 다음과 같은 오류가 발생합니다. Internal error occurred: failed calling webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "webhook-service.kube-system.svc") 이 문제는 다음 상황에서 발생할 수 있습니다. 180일 이상 된 클러스터에서 두 개의 수동 cert-manager를 인증서 순환으로 발급하고 anthos-cluster-operator를 다시 시작하지 않은 경우 90일 이상 된 클러스터에서 수동 cert-manager를 실행하고 anthos-cluster-operator를 다시 시작하지 않은 경우 해결 방법 anthos-cluster-operator를 종료하여 포드를 다시 시작합니다.
업그레이드 및 업데이트	1.14.0	사용자 클러스터 업그레이드 중에 생성된 오래된 수명 주기 컨트롤러 배포자 포드 버전 1.14.0 관리자 클러스터에서는 사용자 클러스터 업그레이드 중에 하나 이상의 오래된 수명 주기 컨트롤러 배포자 포드가 생성될 수 있습니다. 이 문제는 처음에 1.12 미만 버전에서 생성된 사용자 클러스터에 해당합니다. 의도하지 않게 생성된 포드는 업그레이드 작업을 방해하지 않지만 예기치 않은 상태로 발견될 수 있습니다. 오래된 포드는 삭제하는 것이 좋습니다. 이 문제는 출시 버전 1.14.1에서 해결되었습니다. 해결 방법: 오래된 수명 주기 컨트롤러 배포자 포드를 삭제하려면 다음 안내를 따르세요. 프리플라이트 검사 리소스를 나열합니다. kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A 출력 형식은 다음과 같습니다. NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d 여기서 ci-87a021b9dcbb31c는 클러스터 이름입니다. PASS 열의 값이 true 또는 false인 리소스를 삭제합니다. 예를 들어 앞의 샘플 출력의 리소스를 삭제하려면 다음 명령어를 사용합니다. kubectl delete preflightchecks ci-87a021b9dcbb31c \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG
네트워킹	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	수신 경로 수가 많아 BGPSession 상태가 계속 변경됨 베어메탈용 GKE 고급 네트워킹은 외부 피어가 많은 수의 경로(약 100개 이상)를 공지할 때 BGP 세션을 올바르게 관리하지 못합니다. 수신 경로가 많으면 노드 로컬 BGP 컨트롤러가 BGP 세션을 조정하는 데 너무 오래 걸려 상태를 업데이트할 수 없습니다. 상태 업데이트 또는 상태 점검이 없으면 세션이 비활성 상태로 삭제됩니다. 문제를 발견하고 나타낼 수 있는 BGP 세션의 바람직하지 않은 동작은 다음과 같습니다. 지속적인 bgpsession 삭제 및 재생성 bgpsession.status.state가 Established로 되지 않음 경로가 공지되지 않거나 공지와 철회를 반복함 LoadBalancer 서비스의 연결 문제로 인해 BGP 부하 분산 문제가 발생할 수 있습니다. 포드의 연결 문제로 인해 BGP FlatIP 문제가 발생할 수 있습니다. 원격 피어가 너무 많은 경로를 공지하여 BGP 문제가 발생했는지 확인하려면 다음 명령어를 사용하여 관련 상태와 출력을 검토합니다. 영향을 받는 클러스터에서 kubectl get bgpsessions를 사용합니다. 출력에 bgpsessions 상태가 '설정되지 않음'으로 표시되고 마지막 보고 시간이 0으로 재설정되기 전까지 약 10~12초까지 계속 집계됩니다. kubectl get bgpsessions의 출력은 영향을 받는 세션이 반복적으로 다시 생성되는 것을 나타냅니다. kubectl get bgpsessions \ -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}" 로그 메시지가 비활성 BGP 세션이 삭제되고 있음을 알려줍니다. kubectl logs ang-controller-manager-POD_NUMBER POD_NUMBER를 클러스터의 리더 포드로 바꿉니다. 해결 방법: 내보내기 정책을 사용하여 원격 피어에서 클러스터로 공지하는 경로 수를 줄이거나 제거합니다. 베어메탈용 GKE 클러스터 버전 1.14.2 이상에서는 AddOnConfiguration을 사용하여 수신된 경로를 처리하는 기능을 사용 중지할 수도 있습니다. --disable-received-routes 인수를 ang-daemon daemonset의 bgpd 컨테이너에 추가하세요.
네트워킹	1.14, 1.15, 1.16, 1.28	conntrack 테이블 삽입 실패로 인한 애플리케이션 시간 초과 커널 5.15 이상을 사용하는 Ubuntu OS에서 실행 중인 클러스터는 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.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.5	일부 버전의 bmctl을 사용하여 클러스터 백업을 복원할 수 없음 업그레이드에 실패하면 이전 버전을 복원할 수 있도록 업그레이드 전에 클러스터를 백업하는 것이 좋습니다. bmctl restore cluster 명령어에 문제가 있으면 식별된 버전을 사용하여 클러스터의 백업을 복원할 수 없습니다. 이 문제는 이전 버전의 백업을 복원하는 업그레이드와 관련이 있습니다. 클러스터가 영향을 받는 경우 bmctl restore cluster 로그에 다음 오류가 포함됩니다. Error: failed to extract image paths from profile: anthos version VERSION not supported 해결 방법: 이 문제가 해결될 때까지 클러스터 백업 및 복원의 안내에 따라 클러스터를 수동으로 백업하고 필요한 경우 수동으로 복원하는 것이 좋습니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2	인터페이스에 IP 주소가 없으면 NetworkGatewayGroup이 비정상 종료됨 NetworkGatewayGroup이 IPv4 및 IPv6 인터페이스가 모두 없는 노드에 대한 데몬을 만들지 못합니다. 이 경우 BGP LB 및 EgressNAT와 같은 기능이 실패합니다. kube-system 네임스페이스에서 실패한 ang-node 포드의 로그를 확인하면 IPv6 주소가 누락된 경우 다음 예시와 비슷한 오류가 표시됩니다. ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error": "creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""} 이전 예시에서는 ens192 인터페이스에 IPv6 주소가 없습니다. 노드에 IPv4 주소가 누락되면 유사한 ARP 오류가 표시됩니다. NetworkGatewayGroup은 링크-로컬 IP 주소에 ARP 연결 및 NDP 연결을 설정하려고 시도합니다. IP 주소가 없으면(ARP의 IPv4, NDP의 IPv6) 연결이 실패하고 데몬이 계속되지 않습니다. 이 문제는 출시 버전 1.14.3에서 해결되었습니다. 해결 방법: SSH를 사용하여 노드에 연결하고 노드 IP가 포함된 링크에 IPv4 또는 IPv6 주소를 추가합니다. 이전 로그 항목 예시에서 이 인터페이스는 ens192입니다. ip address add dev INTERFACE scope link ADDRESS 다음을 바꿉니다. INTERFACE: 노드의 인터페이스입니다(예: ens192). ADDRESS: 인터페이스에 적용할 IP 주소와 서브넷 마스크입니다.
재설정/삭제	1.10, 1.11, 1.12, 1.13.0-1.13.2	제어 영역 노드를 삭제할 때 anthos-cluster-operator의 비정상 종료 루프 Cluster.Spec에서 IP 주소를 삭제하여 제어 영역 노드를 삭제하려고 시도하면 anthos-cluster-operator가 다른 작업을 차단하는 비정상 종료 루프 상태가 됩니다. 해결 방법: 이 문제는 1.13.3 및 1.14.0 이상에서 해결되었습니다. 다른 모든 버전이 영향을 받습니다. 고정 버전 중 하나로 업그레이드 이 문제를 해결하려면 다음 명령어를 실행합니다. kubectl label baremetalmachine IP_ADDRESS \ -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply- 다음을 바꿉니다. IP_ADDRESS: 비정상 종료 루프 상태의 노드의 IP 주소입니다. CLUSTER_NAMESPACE: 클러스터 네임스페이스입니다.
설치	1.13.1, 1.13.2 및 1.13.3	토큰 불일치로 인해 대규모 클러스터에서 kubeadm join의 실패 노드 수가 많은 베어메탈용 GKE 클러스터를 설치하면 다음 예시와 비슷한 kubeadmin join 오류 메시지가 표시될 수 있습니다. TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] *** fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join --config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1, "start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n To see the stack trace of this error execute with --v=5 or higher", "stderr_lines": ["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"", "To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight] Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]} 해결 방법: 이 문제는 베어메탈용 GDCV 버전 1.13.4 이상에서 해결되었습니다. 영향을 받는 버전을 사용해야 하는 경우 먼저 노드가 20개 미만인 클러스터를 만든 후 설치가 완료되면 클러스터 크기를 조절하여 노드를 추가하세요.
로그 기록 및 모니터링	1.10, 1.11, 1.12, 1.13.0	Edge 클러스터의 metrics-server에 대한 낮은 CPU 한도 베어메탈용 GKE Edge 클러스터에서 metrics-server의 CPU 한도가 낮으면 metrics-server가 자주 다시 시작될 수 있습니다. metrics-server가 비정상이기 때문에 수평형 포드 자동 확장 처리(HPA)가 작동하지 않습니다. metrics-server CPU 한도가 40m보다 작으면 클러스터가 영향을 받을 수 있습니다. metrics-server CPU 한도를 확인하려면 다음 파일 중 하나를 검토하세요. 베어메탈용 GKE 클러스터 버전 1.x~1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml 베어메탈용 GKE 클러스터 버전 1.13 이상: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml 해결 방법: 이 문제는 베어메탈용 GKE 클러스터 버전 1.13.1 이상에서 해결되었습니다. 이 문제를 해결하려면 클러스터를 업그레이드하세요. 클러스터를 업그레이드할 수 있을 때까지의 단기적인 해결 방법은 다음과 같이 metrics-server의 CPU 한도를 수동으로 늘리는 것입니다. metrics-server-operator 축소: kubectl scale deploy metrics-server-operator --replicas=0 구성을 업데이트하고 CPU 한도를 늘립니다. 베어메탈용 GKE 클러스터 버전 1.x~1.12: kubectl -n kube-system edit deployment metrics-server 베어메탈용 GKE 클러스터 버전 1.13: kubectl -n gke-managed-metrics-server edit deployment metrics-server 다음 예시와 같이 --config-dir=/etc/config 줄을 삭제하고 CPU 한도를 늘립니다. [...] - command: - /pod_nanny # - --config-dir=/etc/config # <--- Remove this line - --container=metrics-server - --cpu=50m # <--- Increase CPU, such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true [...] metrics-server를 저장하고 닫아 변경사항을 적용합니다.
네트워킹	1.14, 1.15, 1.16	hostNetwork 포드에 직접 NodePort 연결이 작동하지 않음 백엔드 포드가 대상 NodePort와 동일한 노드에 있는 경우 NodePort 서비스를 사용해 hostNetwork로 사용 설정된 포드에 대한 연결이 실패합니다. 이 문제는 hostNetwork 포드와 함께 사용할 경우 LoadBalancer 서비스에 영향을 줍니다. 백엔드가 여러 개 있으면 산발적인 연결 실패가 발생할 수 있습니다. 이 문제는 eBPF 프로그램의 버그로 인해 발생합니다. 해결 방법: Nodeport 서비스를 사용하는 경우 백엔드 포드가 실행되는 노드를 타겟팅하지 않습니다. LoadBalancer 서비스를 사용할 때는 hostNetwork 포드가 LoadBalancer 노드에서 실행되지 않는지 확인합니다.
업그레이드 및 업데이트	1.12.3, 1.13.0	1.13.0 관리자 클러스터가 1.12.3 사용자 클러스터를 관리할 수 없음 버전 1.13.0을 실행하는 관리자 클러스터는 버전 1.12.3을 실행하는 사용자 클러스터를 관리할 수 없습니다. 버전 1.12.3 사용자 클러스터에 대한 작업이 실패합니다. 해결 방법: 관리자 클러스터를 버전 1.13.1로 업그레이드하거나 사용자 클러스터를 관리자 클러스터와 동일한 버전으로 업그레이드합니다.
업그레이드 및 업데이트	1.12	워커 노드 풀이 있는 관리자 클러스터에서 1.13.x로 업그레이드가 차단됨 버전 1.13.0 이상의 관리자 클러스터에는 워커 노드 풀이 포함될 수 없습니다. 워커 노드 풀이 있는 관리자 클러스터의 버전 1.13.0 이상으로의 업그레이드가 차단됩니다. 관리자 클러스터 업그레이드가 중단되면 bmctl-workspace 폴더 내 upgrade-cluster.log 파일에서 다음 오류를 확인하여 워커 노드 풀이 원인인지 확인할 수 있습니다. Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed. 해결 방법: 업그레이드하기 전에 모든 워커 노드 풀을 사용자 클러스터로 이동합니다. 노드 풀을 추가하고 삭제하는 방법은 클러스터의 노드 풀 관리를 참조하세요.
업그레이드 및 업데이트	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	kubectl apply를 사용하여 리소스를 업데이트할 때 오류 발생 kubectl apply를 사용하여 ClientConfig 또는 Stackdriver 커스텀 리소스와 같은 기존 리소스를 업데이트하면 컨트롤러에서 오류를 반환하거나 입력 및 계획된 변경사항을 되돌릴 수 있습니다. 예를 들어 먼저 리소스를 가져온 후 업데이트된 버전을 적용하여 다음과 같이 Stackdriver 커스텀 리소스를 수정할 수 있습니다. 기존 YAML 정의를 가져옵니다. kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다. 업데이트된 YAML 파일을 다시 적용합니다. kubectl apply -f stackdriver.yaml kubectl apply의 마지막 단계에서 문제가 발생할 수 있습니다. 해결 방법: 기존 리소스를 변경하는 데 kubectl apply를 사용하지 마세요. 대신 다음 예시와 같이 kubectl edit 또는 kubectl patch를 사용합니다. Stackdriver 커스텀 리소스를 수정합니다. kubectl edit stackdriver -n kube-system stackdriver YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다. 저장 후 편집기를 종료합니다. kubectl patch를 사용하는 다른 방법: 기존 YAML 정의를 가져옵니다. kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다. 업데이트된 YAML 파일을 다시 적용합니다. kubectl patch stackdriver stackdriver --type merge \ -n kube-system --patch-file stackdriver.yaml
로그 기록 및 모니터링	1.12, 1.13, 1.14, 1.15, 1.16	백로그 청크 손상으로 인한 stackdriver-log-forwarder 비정상 종료 루프 발생 손상된 백로그 청크를 처리하려고 하면 stackdriver-log-forwarder 비정상 종료 루프가 발생합니다. 컨테이너 로그에 표시되는 오류 예시는 다음과 같습니다. [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 이 비정상 종료 루프가 발생하면 Cloud Logging에 로그가 표시되지 않습니다. 해결 방법: 이 오류를 해결하려면 다음 단계를 완료합니다. 손상된 백로그 청크를 식별합니다. 다음 오류 메시지 예시를 검토합니다. [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 이 예시에서 var/log/fluent-bit-buffers/tail.1/에 저장된 tail.1/1-1659339894.252926599.flb 파일에 결함이 있습니다. 형식 검사에 실패한 모든 *.flb 파일을 삭제해야 합니다. stackdriver-log-forwarder의 실행 중인 포드를 종료합니다. kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다. 다음 단계로 이동하기 전에 stackdriver-log-forwarder 포드가 삭제되었는지 확인합니다. stackdriver-log-forwarder가 실행 중인 SSH를 사용하여 노드에 연결합니다. 노드에서 var/log/fluent-bit-buffers/tail.1/의 손상된 *.flb 파일을 모두 삭제합니다. 손상된 파일이 너무 많아서 스크립트를 적용해 모든 백로그 청크를 삭제하려면 다음 스크립트를 사용합니다. fluent-bit의 버퍼에서 모든 더티 데이터를 삭제하려면 DaemonSet를 배포합니다. kubectl --kubeconfig KUBECONFIG -n kube-system apply -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 KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l cleanup DaemonSet를 삭제합니다. kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup stackdriver-log-forwarder 포드를 재시작합니다. kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
네트워킹, GDC용 VM 런타임	1.14.0	클러스터에서 Dataplane V2(anetd)를 다시 시작하면 기존 VM이 포드가 아닌 네트워크에 연결할 수 없게 됨 멀티 NIC 클러스터에서 Dataplane V2(anetd)를 다시 시작하면 가상 머신이 네트워크에 연결되지 않을 수 있습니다. anetd 포드 로그에서 다음과 비슷한 오류가 관측될 수 있습니다. could not find an allocator to allocate the IP of the multi-nic endpoint 해결 방법: VM을 빠른 해결 방법으로 다시 시작할 수 있습니다. 문제가 반복되지 않도록 하려면 클러스터를 버전 1.14.1 이상으로 업그레이드합니다.
작업	1.13, 1.14.0, 1.14.1	gke-metrics-agent에 에지 프로필 클러스터에 대한 메모리 한도가 없음 클러스터의 워크로드에 따라 gke-metrics-agent에서 4,608MiB 이상의 메모리를 사용할 수 있습니다. 이 문제는 베어메탈용 GKE Edge 프로필 클러스터에만 영향을 미칩니다. 기본 프로필 클러스터는 영향을 받지 않습니다. 해결 방법: 클러스터를 버전 1.14.2 이상으로 업그레이드합니다.
설치	1.12, 1.13	경합 상태로 인해 클러스터 생성이 실패할 수 있음 kubectl을 사용하여 클러스터를 만들면 경합 상태로 인해 프리플라이트 검사가 완료되지 않을 수 있습니다. 그 결과 경우에 따라서 클러스터 생성이 실패할 수 있습니다. 프리플라이트 검사 조정자는 SecretForwarder를 만들어 기본 ssh-key 보안 비밀을 대상 네임스페이스에 복사합니다. 일반적으로 프리플라이트 검사는 소유자 참조를 활용하고 SecretForwarder가 완료되면 조정됩니다. 하지만 드물게 SecretForwarder의 소유자 참조로 인해 프리플라이트 검사에서 참조가 손실되어 프리플라이트 검사가 중단될 수 있습니다. 그에 따라 클러스터 생성이 실패합니다. 컨트롤러 기반 프리플라이트 검사를 계속 조정하려면 클러스터 운영자 포드를 삭제하거나 프리플라이트 검사 리소스를 삭제합니다. 프리플라이트 검사 리소스를 삭제하면 다른 검사 리소스가 생성되어 조정이 계속됩니다. 또는 이전 버전으로 만든 기존 클러스터를 고정 버전으로 업그레이드할 수 있습니다.
네트워킹	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15	멀티 NIC 기능으로 Whereabouts 플러그인을 사용할 때 예약된 IP 주소가 해제되지 않음 멀티 NIC 기능에서 CNI whereabouts 플러그인을 사용하고 CNI DEL 작업을 사용하여 포드의 네트워크 인터페이스를 삭제하는 경우 예약된 일부 IP 주소가 올바르게 해제되지 않을 수 있습니다. 이 문제는 CNI DEL 작업이 중단되면 발생합니다. 다음 명령어를 실행하여 포드의 사용하지 않은 IP 주소 예약을 확인할 수 있습니다. kubectl get ippools -A --kubeconfig KUBECONFIG_PATH 해결 방법: 사용하지 않는 IP 주소(ippool)를 수동으로 삭제하세요.
설치	1.10, 1.11.0, 1.11.1, 1.11.2	1.10.4 사용자 클러스터에서 노드 문제 감지기 실패 버전 1.11.0, 1.11.1 또는 1.11.2 관리자 클러스터가 1.10.x 사용자 클러스터를 관리하는 경우 버전 1.10.x 사용자 클러스터에서 노드 문제 감지기가 실패할 수 있습니다. 노드 문제 감지기가 실패하면 로그가 다음 오류 메시지로 업데이트됩니다. Error - NPD not supported for anthos baremetal version 1.10.4: anthos version 1.10.4 not supported. 해결 방법 이 문제를 해결하려면 관리자 클러스터를 1.11.3으로 업그레이드합니다.
작업	1.14	1.14 섬(island) 모드 IPv4 클러스터 노드의 포드 CIDR 마스크 크기가 24임 버전 1.14에서는 maxPodsPerNode 설정이 섬(island) 모드 클러스터에 고려되지 않으므로 노드에 포드 CIDR 마스크 크기가 24(IP 주소 256개)로 할당됩니다. 이로 인해 클러스터에서 포드 IP 주소가 예상보다 빨리 소진될 수 있습니다. 예를 들어 클러스터의 포드 CIDR 마스크 크기가 22인 경우 각 노드에 포드 CIDR 마스크가 24로 할당되며 클러스터는 최대 4개의 노드만 지원할 수 있게 됩니다. 또한 maxPodsPerNode가 129 이상으로 설정되어 있고 각 노드의 포드 CIDR에 오버헤드가 충분하지 않으면 포드가 제거가 많은 기간 동안 클러스터에서 네트워크 불안정이 발생할 수 있습니다. 이 문제는 65~128 범위를 벗어나는 maxPodsPerNode를 사용하는 섬(island) 모드 IPv4 클러스터에만 영향을 줍니다. 클러스터가 영향을 받는 경우, 사용자가 클러스터에 새 노드를 추가했는데 사용 가능한 podCIDR이 없을 때 anetd 포드가 다음 오류를 보고합니다. error="required IPv4 PodCIDR not available" 해결 방법 다음 단계를 사용하여 문제를 해결합니다. 1.14.1 이상 버전으로 업그레이드합니다. 워커 노드를 삭제한 후 다시 추가합니다. 제어 영역 노드를 삭제한 후 클러스터 다운타임을 방지하기 위해 하나씩 다시 추가합니다.
업그레이드 및 업데이트	1.14.0, 1.14.1	클러스터 업그레이드 롤백 실패 버전 1.14.0 또는 1.14.1 클러스터의 업그레이드 롤백이 실패할 수 있습니다. 클러스터를 1.14.0에서 1.14.1로 업그레이드한 후 bmctl restore cluster 명령어를 사용하여 1.14.0으로 롤백하려고 하면 다음 예시와 같은 오류가 반환될 수 있습니다. I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff. Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io" denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid: Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690), Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil), CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable 해결 방법: 클러스터 네임스페이스에서 모든 healthchecks.baremetal.cluster.gke.io 리소스를 삭제한 후 bmctl restore cluster 명령어를 다시 실행합니다. 모든 healthchecks.baremetal.cluster.gke.io 리소스 나열 kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 다음을 바꿉니다. CLUSTER_NAMESPACE: 클러스터의 네임스페이스 ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 이전 단계에서 나열한 모든 healthchecks.baremetal.cluster.gke.io 리소스를 삭제합니다. kubectl delete healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_RESOURCE_NAME \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG HEALTHCHECK_RESOURCE_NAME을 상태 확인 리소스의 이름으로 바꿉니다. bmctl restore cluster 명령어를 다시 실행합니다.
네트워킹	1.12.0	플랫 모드에서 서비스 외부 IP 주소가 작동하지 않음 flatIPv4가 true로 설정된 클러스터에서는 외부 IP 주소로 LoadBalancer 유형의 서비스에 액세스할 수 없습니다. 이 문제는 버전 1.12.1에서 해결되었습니다. 해결 방법: cilium-config ConfigMap에서 enable-415를 "true"로 설정한 후 anetd 포드를 다시 시작합니다.
업그레이드 및 업데이트	1.13.0, 1.14	1.13.0에서 1.14.x로 인플레이스 업그레이드가 완료되지 않음 bmctl 1.14.0 및 --use-bootstrap=false 플래그를 사용하여 1.13.0에서 1.14.x로 인플레이스 업그레이드를 수행하려고 하면 업그레이드가 완료되지 않습니다. preflight-check 연산자 오류로 인해 클러스터가 필요한 검사를 예약하지 않으므로 프리플라이트 검사가 완료되지 않습니다. 해결 방법: 1.14.x로 업그레이드하기 전에 먼저 1.13.1로 업그레이드합니다. 1.13.0에서 1.13.1로의 인플레이스 업그레이드가 작동합니다. 또는 --use-bootstrap=false 플래그를 사용하지 않고 1.13.0에서 1.14.x로 업그레이드합니다.
업그레이드, 업데이트, 보안	1.13 및 1.14	1.14.0으로 업그레이드된 클러스터의 마스터 taint 손실 제어 영역 노드에는 워크로드가 예약되는 것을 방지하기 위해 두 가지 특정 taint 중 하나가 필요합니다. 버전 1.13 GKE 클러스터를 버전 1.14.0으로 업그레이드하면 제어 영역 노드에서 다음과 같은 필수 taint가 손실됩니다. node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule 참고: 독립 실행형 유형 클러스터와 같은 자체 관리되는 클러스터에는 기본적으로 PreferNoSchedule taint가 사용됩니다. 이 문제로 인해 업그레이드 실패가 발생하지는 않지만 제어 영역 노드에서 실행하지 않아야 할 포드가 업그레이드 실패를 일으킬 수 있습니다. 이러한 워크로드 포드는 제어 영역 노드에 부담을 주고 클러스터 불안정을 초래할 수 있습니다. 영향을 받는지 여부 확인 제어 영역 노드를 찾아서 다음 명령어를 사용합니다. kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH 노드에서 taint 목록을 확인하려면 다음 명령어를 사용합니다. kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH 필수 taint가 어느 하나도 나열되지 않았으면 영향을 받은 것입니다. 해결 방법 영향을 받는 버전 1.14.0 클러스터의 각 제어 영역 노드에 대해 다음 단계를 수행하여 적절한 기능을 복원합니다. 이러한 단계는 node-role.kubernetes.io/master:NoSchedule taint 및 관련 포드에 적용됩니다. 제어 영역 노드에 PreferNoSchedule taint를 사용하려면 그에 따라 단계를 조정합니다. 해결 방법 단계 보기 누락된 taint를 적용합니다. kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH node-role.kubernetes.io/master:NoSchedule 톨러레이션(toleration)이 없는 포드를 찾습니다. kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq node-role.kubernetes.io/master:NoSchedule 톨러레이션(toleration)이 없는 포드를 삭제합니다. kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
작업, GDC용 VM 런타임	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	업로드 오류와 함께 VM 생성이 간헐적으로 실패 kubectl virt create vm 명령어를 사용하여 새 가상 머신(VM)을 만들면 이미지 업로드 중 간헐적으로 작업이 실패합니다. 이 문제는 Linux 및 Windows VM 모두에 적용됩니다. 오류는 다음 예시와 같습니다. PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready Uploading data to https://10.200.0.51 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s fail to upload image: unexpected return value 500, ... 해결 방법 kubectl virt create vm 명령어를 다시 시도하여 VM을 만듭니다.
업그레이드 및 업데이트, 로깅 및 모니터링	1.11	1.11 클러스터의 관리형 컬렉션 구성요소가 1.12로 업그레이드 시 보존되지 않음 관리형 컬렉션 구성요소는 Managed Service for Prometheus의 일부입니다. 버전 1.11 클러스터의 gmp-system 네임스페이스에 관리형 컬렉션 구성요소를 수동으로 배포한 경우 버전 1.12로 업그레이드하면 관련 리소스가 보존되지 않습니다. 버전 1.12.0 클러스터부터는 gmp-system 네임스페이스의 Managed Service for Prometheus 구성요소와 관련 커스텀 리소스 정의가 enableGMPForApplications 필드에서 stackdriver-operator로 관리됩니다. enableGMPForApplications 필드의 기본값은 true이므로 버전 1.12로 업그레이드하기 전에 네임스페이스에서 Managed Service for Prometheus 구성요소를 수동으로 배포한 경우 stackdriver-operator에서 리소스를 삭제합니다. 해결 방법 수동으로 관리되는 컬렉션 리소스를 보존하려면 다음 안내를 따르세요. 기존 PodMonitoring 커스텀 리소스를 모두 백업합니다. 클러스터를 버전 1.12로 업그레이드하고 Managed Service for Prometheus를 사용 설정합니다. 업그레이드된 클러스터에 PodMonitoring 커스텀 리소스를 다시 배포합니다.
업그레이드 및 업데이트	1.13	Docker 컨테이너 런타임의 일부 버전 1.12 클러스터를 버전 1.13으로 업그레이드할 수 없음 Docker 컨테이너 런타임을 사용하는 버전 1.12 클러스터에 다음 주석이 누락되었으면 이를 버전 1.13으로 업그레이드할 수 없습니다. baremetal.cluster.gke.io/allow-docker-container-runtime: "true" 이 문제의 영향을 받는 경우에는 bmctl이 bmctl-workspace 폴더 안의 upgrade-cluster.log 파일에 다음 오류를 기록합니다. Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook "vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources. Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file. 이 문제는 1.11에서 업그레이드된 버전 1.12 Docker 클러스터에서 발생할 가능성이 가장 높습니다. 이 업그레이드는 Docker 컨테이너 런타임을 유지보수하기 위한 주석이 필요하지 않습니다. 이 경우 1.13으로 업그레이드할 때 클러스터에 주석이 포함되지 않습니다. 버전 1.13부터는 containerd가 허용되는 유일한 컨테이너 런타임입니다. 해결 방법: 이 문제의 영향을 받는 경우 누락된 주석을 사용하여 클러스터 리소스를 업데이트합니다. 업그레이드가 실행되는 동안 또는 업그레이드를 취소하고 재시도하기 전에 주석을 추가할 수 있습니다.
설치	1.11	클러스터 생성이 완료되기 전에 bmctl이 종료됨 베어메탈용 GDCV 버전 1.11.0에서 클러스터 생성이 실패할 수 있습니다(이 문제는 베어메탈용 GDCV 출시 버전 1.11.1에서 해결됨). 일부 경우에 bmctl create cluster 명령어가 조기에 종료되고 다음과 같은 오류가 로그에 기록됩니다. Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster 해결 방법 실패한 작업은 아티팩트를 생성하지만 클러스터는 작동하지 않습니다. 이 문제의 영향을 받는 경우 다음 단계에 따라 아티팩트를 정리하고 클러스터를 만드세요. 해결 방법 단계 보기 클러스터 아티팩트를 삭제하고 노드 머신을 재설정하려면 다음 명령어를 실행합니다. bmctl reset -c USER_CLUSTER_NAME 클러스터 만들기 작업을 시작하려면 다음 명령어를 실행합니다. bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster 이 명령어가 실패하는 경우 --keep-bootstrap-cluster 플래그가 중요합니다. 클러스터 만들기 명령어가 성공하면 남은 단계를 건너뛸 수 있습니다. 그렇지 않으면 작업을 계속합니다. 다음 명령어를 실행하여 부트스트랩 클러스터의 버전을 가져옵니다. kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} 출력은 1.11.0이어야 합니다. 출력이 1.11.0이 아니면 1~2분 정도 기다린 후 다시 시도세요. 부트스트랩 클러스터에서 대상 클러스터로 리소스를 수동으로 이동하려면 다음 명령어를 실행합니다. bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE 부트스트랩 클러스터를 삭제하려면 다음 명령어를 실행합니다. bmctl reset bootstrap
설치, GDC용 VM 런타임	1.11, 1.12	설치 시 VM 런타임 조정 오류 보고 클러스터 생성 작업에서 다음과 유사한 오류를 보고할 수 있습니다. I0423 01:17:20.895640 3935589 logs.go:82] "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError" 해결 방법 이 오류는 무해하므로 무시해도 됩니다.
설치	1.10, 1.11, 1.12	멀티 NIC, containerd, HTTPS 프록시를 사용할 때 클러스터 생성 실패 다음 조건 조합이 있으면 클러스터 생성이 실패합니다. 클러스터는 containerd를 컨테이너 런타임으로 사용하도록 구성됩니다(클러스터 구성 파일에서 nodeConfig.containerRuntime이 베어메탈용 GDCV 버전 1.13 이상의 기본값인 containerd로 설정됨). 클러스터는 포드(클러스터 구성 파일에서 true로 설정된 clusterNetwork.multipleNetworkInterfaces)에 다중 네트워크 인터페이스인 멀티 NIC를 제공하도록 구성됩니다. 클러스터가 프록시를 사용하도록 구성됩니다(spec.proxy.url이 클러스터 구성 파일에 지정됨). 클러스터 만들기가 실패하더라도 클러스터를 만들려고 하면 이 설정이 전파됩니다. 이 프록시 설정은 HTTPS_PROXY 환경 변수 또는 containerd 구성(/etc/systemd/system/containerd.service.d/09-proxy.conf)으로 표시될 수 있습니다. 해결 방법 서비스 CIDR(clusterNetwork.services.cidrBlocks)을 모든 노드 머신의 NO_PROXY 환경 변수에 추가합니다.
설치	1.10, 1.11, 1.12	umask 설정이 제한적인 시스템의 장애 베어메탈용 GDCV 출시 버전 1.10.0에 모든 제어 영역 구성요소를 루트가 아닌 사용자로 실행하는 루트 없는 제어 영역 기능이 도입되었습니다. 모든 구성요소를 루트가 아닌 사용자로 실행하면 0077의 umask 설정이 더 제한적인 시스템에서는 설치 또는 업그레이드 실패가 발생할 수 있습니다. 해결 방법 제어 영역 노드를 재설정하고 모든 제어 영역 머신에서 umask 설정을 0022로 변경합니다. 머신이 업데이트된 후 설치를 다시 시도합니다. 또는 설치 또는 업그레이드를 진행할 수 있도록 제어 영역 머신에서 /etc/kubernetes의 디렉터리 및 파일 권한을 변경할 수 있습니다. /etc/kubernetes 및 모든 하위 디렉터리의 공개 읽기가 가능하도록 설정합니다(chmod o+rx). /etc/kubernetes 디렉터리(재귀적)에서 root 사용자가 소유한 모든 파일의 공개 읽기가 가능하도록 설정합니다(chmod o+r). 비공개 키 파일(.key)은 이미 올바른 소유권 및 권한을 사용해 생성되었으므로 변경에서 제외하세요. /usr/local/etc/haproxy/haproxy.cfg의 공개 읽기를 설정합니다. /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml의 공개 읽기를 설정합니다.
설치	1.10, 1.11, 1.12, 1.13	Control group v2 비호환성 Control group v2(cgroup v2)는 베어메탈용 GKE 클러스터 버전 1.13 및 이전 버전의 베어메탈용 GDCV에서 지원되지 않습니다. 그러나 버전 1.14에서는 cgroup v2가 미리보기 기능으로 지원됩니다. /sys/fs/cgroup/cgroup.controllers가 있으면 시스템이 cgroup v2를 사용한다는 의미입니다. 해결 방법 시스템에 cgroup v2가 사용되는 경우 클러스터를 버전 1.14로 업그레이드합니다.
설치	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	실행 전 검사 및 서비스 계정 사용자 인증 정보 관리자 또는 하이브리드 클러스터에 의해 트리거된 설치(즉, 사용자 클러스터와 같이 bmctl로 생성되지 않은 클러스터)의 경우 실행 전 검사는 Google Cloud 서비스 계정 사용자 인증 정보 또는 연결된 권한을 확인하지 않습니다.
설치	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	vSphere에 설치 vSphere VM에 베어메탈용 GKE 클러스터를 설치할 때 tx-udp_tnl-segmentation 및 tx-udp_tnl-csum-segmentation 플래그를 사용 중지로 설정해야 합니다. 이 플래그는 vSphere 드라이버 VMXNET3에서 수행하는 하드웨어 세분화 오프로드와 관련이 있으며 베어메탈용 GKE 클러스터의 GENEVE 터널과는 호환되지 않습니다. 해결 방법 각 노드에서 다음 명령어를 실행하여 이러한 플래그의 현재 값을 확인합니다. ethtool -k NET_INTFC | grep segm NET_INTFC를 노드의 IP 주소와 연결된 네트워크 인터페이스로 바꿉니다. 응답에 다음과 같은 항목이 포함되어야 합니다. ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... RHEL 8.4에서 ethtool이 이러한 플래그가 사용 설정되었음에도 사용 중지된 것으로 표시하는 경우가 있습니다. 이 플래그를 명시적으로 사용 중지하려면 다음 명령어를 사용하여 플래그를 사용으로 전환한 후에 사용 중지합니다. ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \ tx-udp_tnl-csum-segmentation on ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \ tx-udp_tnl-csum-segmentation off 이 플래그 변경사항은 재부팅 후 유지되지 않습니다. 시스템을 부팅할 때 이러한 플래그를 명시적으로 설정하도록 시작 스크립트를 구성합니다.
업그레이드 및 업데이트	1.10	bmctl에서 하위 버전 사용자 클러스터를 생성, 업데이트 또는 재설정할 수 없음 bmctl CLI는 관리자 클러스터 버전에 관계없이 하위 부 버전으로 사용자 클러스터를 생성, 업데이트 또는 재설정할 수 없습니다. 예를 들어 관리자 클러스터도 1.N.X 버전이더라도 1.N.X 버전의 bmctl을 사용하여 1.N-1.Y 버전의 사용자 클러스터를 재설정할 수 없습니다. 이 문제의 영향을 받는 경우 bmctl을 사용할 때 다음과 비슷한 로그가 표시됩니다. [2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: * cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported 해결 방법: kubectl을 사용하여 관리자 클러스터 내에서 사용자 클러스터 커스텀 리소스를 생성, 수정 또는 삭제합니다. 사용자 클러스터를 업그레이드하는 기능은 영향을 받지 않습니다.
업그레이드 및 업데이트	1.12	버전 1.12.1로의 클러스터 업그레이드가 중단될 수 있음 API 서버를 사용할 수 없어 클러스터를 버전 1.12.1로 업그레이드하는 작업이 간혹 중단됩니다. 이 문제는 모든 클러스터 유형 및 지원되는 모든 운영체제에 영향을 미칩니다. 이 문제가 발생하면 bmctl upgrade cluster 명령어는 프리플라이트 검사의 두 번째 단계를 포함하여 여러 지점에서 실패할 수 있습니다. 해결 방법 업그레이드 로그를 확인하여 이 문제의 영향을 받는지 확인할 수 있습니다. 기본적으로 업그레이드 로그는 /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP에 있습니다. upgrade-cluster.log에 다음과 같은 오류가 포함될 수 있습니다. Failed to upgrade cluster: preflight checks failed: preflight check failed 머신 로그에 다음과 같은 오류가 포함될 수 있습니다(반복되는 오류는 이 문제의 영향을 받았음을 나타냄). FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left). FAILED - RETRYING: Query CNI health endpoint (28 retries left). ... 클러스터를 버전 1.12.1로 다시 업그레이드하기 전에 HAProxy 및 Keepalived가 각 제어 영역 노드에서 실행되어야 합니다. 각 노드에서 crictl 명령줄 인터페이스를 사용하여 haproxy 및 keepalived 컨테이너가 실행 중인지 확인합니다. docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived 노드에서 HAProxy 또는 Keepalived가 실행되고 있지 않으면 노드에서 kubelet을 다시 시작합니다. systemctl restart kubelet
업그레이드 및 업데이트, GDC용 VM 런타임	1.11, 1.12	GDC용 VM 런타임이 사용 설정되었을 때 버전 1.12.0 이상으로 클러스터 업그레이드 실패 버전 1.12.0 베어메탈용 GKE 클러스터에서는 GDC용 VM 런타임 정식 버전 출시를 더욱 효과적으로 지원할 수 있도록 GDC용 VM 런타임과 관련된 모든 리소스가 vm-system 네임스페이스로 마이그레이션됩니다. 버전 1.11.x 이하 클러스터에서 GDC용 VM 런타임을 사용 설정한 경우 먼저 GDC용 VM 런타임을 중지하지 않으면 버전 1.12.0 이상으로 업그레이드할 수 없습니다. 이 문제의 영향을 받는 경우 업그레이드 작업 시 다음 오류가 보고됩니다. Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version 해결 방법 GDC용 VM 런타임을 사용 중지하려면 다음 안내를 따르세요. VMRuntime 커스텀 리소스를 수정합니다. kubectl edit vmruntime 사양에서 enabled를 false로 설정합니다. apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... 편집기에서 커스텀 리소스를 저장합니다. 클러스터 업그레이드가 완료되면 GDC용 VM 런타임을 다시 사용 설정합니다. 자세한 내용은 VM 기반 워크로드 작업을 참조하세요.
업그레이드 및 업데이트	1.10, 1.11, 1.12	error during manifests operations에서 업그레이드 중단 경우에 따라 클러스터 업그레이드가 완료되지 않고 bmctl CLI가 응답하지 않습니다. 이 문제는 잘못 업데이트된 리소스로 인해 발생할 수 있습니다. 이 문제의 영향을 받는지 확인하고 수정하려면 anthos-cluster-operator 로그를 확인하여 다음 항목과 비슷한 오류를 찾습니다. controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update 이러한 항목은 잘못 업데이트된 리소스의 증상이며, 여기서 {RESOURCE_NAME}은 문제 리소스의 이름입니다. 해결 방법 로그에 이러한 오류가 있으면 다음 단계를 완료합니다. kubectl edit를 사용하여 로그 메시지에 포함된 리소스에서 kubectl.kubernetes.io/last-applied-configuration 주석을 삭제합니다. 변경사항을 저장하고 리소스에 적용합니다. 클러스터 업그레이드를 다시 시도합니다.
업그레이드 및 업데이트	1.10, 1.11, 1.12	GDC용 Network Gateway를 사용하는 기능이 있는 클러스터의 업그레이드 차단 이그레스 NAT 게이트웨이 또는 BGP를 사용한 번들 부하 분산을 사용하는 클러스터의 경우 클러스터를 1.10.x에서 1.11.x로 업그레이드할 수 없습니다. 이 두 기능 모두 GDC용 Network Gateway를 사용합니다. 클러스터 업그레이드가 Waiting for upgrade to complete... 명령줄 메시지에서 중지되고 anthos-cluster-operator에서 다음과 같은 오류를 로깅합니다. apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... 해결 방법 주의: 다음 해결 방법은 매니페스트를 삭제하고 BGP를 사용한 번들 부하 분산에 다운타임을 30~60초 정도 발생시킵니다. BGP 세션은 삭제되고 다시 설정되며 이 기간 동안에는 LoadBalancer 서비스를 사용할 수 없습니다. anthos-cluster-operator가 매니페스트를 다시 설치하면 기능이 복원됩니다. 업그레이드 차단을 해제하려면 업그레이드하려는 클러스터에 대해 다음 명령어를 실행합니다. kubectl -n kube-system delete deployment \ ang-controller-manager-autoscaler kubectl -n kube-system delete deployment \ ang-controller-manager kubectl -n kube-system delete ds ang-node
업그레이드 및 업데이트	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	bmctl update는 유지보수 블록을 삭제하지 않습니다. bmctl update 명령어는 클러스터 리소스 구성에서 maintenanceBlocks 섹션을 삭제하거나 수정할 수 없습니다. 해결 방법 유지보수 모드에서 노드를 삭제하는 방법 등 자세한 내용은 유지보수 모드로 노드 배치를 참조하세요.
작업	1.10, 1.11, 1.12	유지보수 모드 절차를 사용하지 않는 경우 노드 차단 해제됨 버전 1.12.0 클러스터(anthosBareMetalVersion: 1.12.0) 이하를 실행하고 노드에서 수동으로 kubectl cordon을 사용하는 경우 베어메탈용 GKE에서 예상 상태를 조정하기 위해 준비되기 전에 노드를 차단 해제할 수 있습니다. 해결 방법 버전 1.12.0 이하 클러스터의 경우 유지보수 모드를 사용하여 노드를 안전하게 차단 해제하고 드레이닝합니다. 버전 1.12.1(anthosBareMetalVersion: 1.12.1) 이상에서는 kubectl cordon을 사용할 때 베어메탈용 GKE가 노드를 예기치 않게 차단 해제하지 않습니다.
작업	1.11	레지스트리 미러를 사용하는 버전 11 관리자 클러스터가 버전 1.10 클러스터를 관리할 수 없음 관리자 클러스터가 버전 1.11이고 레지스트리 미러를 사용하는 경우 이보다 낮은 부 버전의 사용자 클러스터를 관리할 수 없습니다. 이 문제는 사용자 클러스터에 대한 재설정, 업데이트, 업그레이드 작업에 영향을 줍니다. 이 문제의 영향을 받는지 확인하려면 로그에서 만들기, 업그레이드, 재생과 같은 클러스터 작업을 확인합니다. 이러한 로그는 기본적으로 bmctl-workspace/CLUSTER_NAME/ 폴더에 있습니다. 이 문제의 영향을 받는 경우 로그에 다음 오류 메시지가 포함됩니다. flag provided but not defined: -registry-mirror-host-to-endpoints
작업	1.10, 1.11	kubeconfig 보안 비밀을 덮어씀 bmctl check cluster 명령어는 사용자 클러스터에서 실행될 때 사용자 클러스터 kubeconfig 보안 비밀을 관리자 클러스터 kubeconfig로 덮어씁니다. 파일을 덮어쓰면 업데이트 및 업그레이드와 같은 표준 클러스터 작업이 영향을 받는 사용자 클러스터에 실패합니다. 이 문제는 베어메탈용 GKE 클러스터 버전 1.11.1 이하에 적용됩니다. 이 문제가 사용자 클러스터에 영향을 미치는지 확인하려면 다음 명령어를 실행하세요. kubectl --kubeconfig ADMIN_KUBECONFIG \ get secret -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME -kubeconfig \ -o json | jq -r '.data.value' | base64 -d 다음을 바꿉니다. ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 USER_CLUSTER_NAMESPACE: 클러스터의 네임스페이스 기본적으로 베어메탈용 GKE 클러스터의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다. USER_CLUSTER_NAME: 확인할 사용자 클러스터의 이름 출력의 클러스터 이름(다음 샘플 출력의 contexts.context.cluster 참조)이 관리자 클러스터 이름인 경우 지정된 사용자 클러스터가 영향을 받습니다. apiVersion: v1 clusters: - cluster: certificate-authority-data:LS0tLS1CRU...UtLS0tLQo= server: https://10.200.0.6:443 name: ci-aed78cdeca81874 contexts: - context: cluster: ci-aed78cdeca81 user: ci-aed78cdeca81-admin name: ci-aed78cdeca81-admin@ci-aed78cdeca81 current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81 kind: Config preferences: {} users: - name: ci-aed78cdeca81-admin user: client-certificate-data: LS0tLS1CRU...UtLS0tLQo= client-key-data: LS0tLS1CRU...0tLS0tCg== 해결 방법 다음 단계에서는 영향을 받는 사용자 클러스터(USER_CLUSTER_NAME)로 함수를 복원합니다. 사용자 클러스터 kubeconfig 파일을 찾습니다. 베어메탈용 GKE는 클러스터를 만들면 관리자 워크스테이션에 kubeconfig 파일을 생성합니다. 기본적으로 이 파일은 bmctl-workspace/USER_CLUSTER_NAME 디렉터리에 있습니다. kubeconfig가 올바른 사용자 클러스터 kubeconfig인지 확인하세요. kubectl get nodes \ --kubeconfig PATH_TO_GENERATED_FILE PATH_TO_GENERATED_FILE를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다. 응답으로 사용자 클러스터의 노드에 대한 세부정보가 반환됩니다. 클러스터의 머신 이름이 올바른지 확인합니다. 다음 명령어를 실행하여 관리자 클러스터에서 손상된 kubeconfig 파일을 삭제합니다. kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig 다음 명령어를 실행하여 올바른 kubeconfig 보안 비밀을 관리자 클러스터에 다시 저장합니다. kubectl create secret generic \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
작업	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	루트가 아닌 로그인 사용자로 스냅샷 만들기 containerd를 컨테이너 런타임으로 사용하는 경우 스냅샷을 루트가 아닌 사용자로 실행하려면 /usr/local/bin이 사용자의 PATH에 있어야 합니다. 그렇지 않으면 crictl: command not found 오류가 표시되면서 실패합니다. 루트 사용자로 로그인되어 있지 않으면 sudo가 스냅샷 명령어를 실행하는 데 사용됩니다. sudo PATH는 루트 프로필과 다를 수 있으며 /usr/local/bin을 포함할 수 없습니다. 해결 방법 /usr/local/bin을 포함하도록 /etc/sudoers의 secure_path를 업데이트합니다. 또는 다른 /bin 디렉터리에 crictl의 심볼릭 링크를 만듭니다.
로그 기록 및 모니터링	1.10	stackdriver-log-forwarder에 [parser:cri] invalid time format 경고 로그가 있음 컨테이너 런타임 인터페이스(CRI) 파서가 파싱 시간에 잘못된 정규 표현식을 사용하면 stackdriver-log-forwarder 포드의 로그에 다음과 같은 오류와 경고가 포함됩니다. [2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' 해결 방법: 해결 방법 단계 보기 클러스터를 버전 1.11.0 이상으로 업그레이드합니다. 클러스터를 즉시 업그레이드할 수 없는 경우 다음 단계를 수행하여 CRI 파싱 정규식을 업데이트합니다. 다음 변경 사항을 되돌리지 않으려면 stackdriver-operator를 축소합니다. kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 stackdriver-log-forwarder-config ConfigMap에서 Regex 항목을 수정합니다. kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config 수정된 리소스는 다음과 비슷하게 표시되어야 합니다. [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off 로그 전달자 포드를 다시 시작합니다. kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
로그 기록 및 모니터링	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	예기치 않은 모니터링 청구 베어메탈용 GKE 클러스터 버전 1.10~1.15의 경우 일부 고객의 결제 페이지에 Metrics volume에 대한 예기치 않은 높은 요금이 표시될 수 있습니다. 이 문제는 다음 두 조건이 모두 적용되는 경우에만 영향을 미칩니다. 애플리케이션 모니터링이 사용 설정됨(enableStackdriverForApplications=true) Managed Service for Prometheus가 사용 설정되지 않음(enableGMPForApplications) 애플리케이션 포드에 prometheus.io/scrap=true 주석 포함 이 문제의 영향을 받는지 확인하려면 사용자 정의 측정항목을 나열하세요. 원치 않는 측정항목에 대한 결제가 표시되는 경우 이 문제가 적용되는 것입니다. 해결 방법 이 문제의 영향을 받는 경우 클러스터를 버전 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 주석을 삭제합니다.
로그 기록 및 모니터링	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	metrics-server-config 수정사항이 유지되지 않음 포드 밀도가 높으면 과도한 로깅과 모니터링 오버헤드가 발생할 수 있으며, 이로 인해 측정항목 서버가 중지되고 다시 시작할 수 있습니다. metrics-server-config ConfigMap을 수정하여 측정항목 서버가 계속 실행되도록 더 많은 리소스를 할당할 수 있습니다. 그러나 조정으로 인해 metrics-server-config를 수정해도 클러스터 업데이트 또는 업그레이드 작업 중에 기본값으로 되돌아갈 수 있습니다. 측정항목 서버는 즉시 영향을 받지 않지만 다음에 다시 시작하면 되돌린 ConfigMap을 선택하고 다시 과도한 오버헤드에 취약해집니다. 해결 방법 1.11.x의 경우 ConfigMap 수정을 스크립트로 작성하고 이를 클러스터에 대한 업데이트나 업그레이드와 함께 수행할 수 있습니다. 1.12 이상의 경우 지원팀에 문의하세요.
로그 기록 및 모니터링	1.11, 1.12	지원 중단된 측정항목이 Cloud Monitoring 대시보드에 영향을 미침 여러 베어메탈용 GKE 측정항목이 지원 중단되었으며 베어메탈용 GDCV 출시 버전 1.11부터는 이러한 지원 중단된 측정항목에 대한 데이터가 더 이상 수집되지 않습니다. 알림 정책에서 이러한 측정항목을 사용하는 경우 알림 조건을 트리거하는 데이터가 없습니다. 다음 표에서는 지원 중단된 개별 측정항목과 이를 대체하는 측정항목을 보여줍니다. 지원 중단된 측정항목 대체 측정항목 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 베어메탈용 GKE 클러스터 버전 1.11 미만에서 권장되는 Anthos on baremetal node cpu usage exceeds 80 percent (critical) 알림의 정책 정의 파일에서 지원 중단된 측정항목을 사용합니다. node-cpu-usage-high.json JSON 정의 파일은 출시 버전 1.11.0 이상에서 업데이트됩니다. 해결 방법 대체 측정항목으로 마이그레이션하려면 다음 단계를 따르세요. Google Cloud 콘솔에서 Monitoring을 선택하거나 다음 버튼을 클릭합니다. Monitoring으로 이동 탐색 창에서 대시보드를 선택하고 Anthos 클러스터 노드 상태 대시보드를 삭제합니다. 샘플 라이브러리 탭을 클릭하고 Anthos 클러스터 노드 상태 대시보드를 재설치합니다. 알림 정책 만들기의 안내에 따라 업데이트된 node-cpu-usage-high.json 정책 정의 파일을 사용하여 정책을 만듭니다.
로그 기록 및 모니터링	1.10, 1.11	stackdriver-log-forwarder에 CrashloopBackOff 오류가 있음 경우에 따라 fluent-bit Logging 에이전트가 손상된 청크를 처리할 때 작업이 중단될 수 있습니다. Logging 에이전트에서 손상된 청크를 우회할 수 없으면 CrashloopBackOff 오류가 표시되면서 stackdriver-log-forwarder가 계속 비정상 종료할 수 있습니다. 이 문제가 발생한 경우 로그에 다음과 비슷한 항목이 포함됩니다. [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5 in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232 #1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523 #2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105 #3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490 #4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0 해결 방법: Stackdriver 로그 전달자의 버퍼 청크를 삭제합니다. 참고: 다음 명령어에서 KUBECONFIG를 관리자 클러스터 kubeconfig 파일 경로로 바꿉니다. 모든 stackdriver-log-forwarder 포드를 종료합니다. kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \ stackdriver-log-forwarder -p \ '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 다음 단계로 이동하기 전에 stackdriver-log-forwarder 포드가 삭제되었는지 확인합니다. 다음 DaemonSet을 배포하여 fluent-bit 버퍼에서 손상된 데이터를 삭제합니다. kubectl --kubeconfig KUBECONFIG -n kube-system apply -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 KUBECONFIG logs \ -n kube-system -l \ app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG -n \ kube-system get pods -l \ app=fluent-bit-cleanup --no-headers | wc -l 두 명령어의 출력은 클러스터에 있는 노드 수와 동일해야 합니다. cleanup DaemonSet를 삭제합니다. kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup 로그 전달자 포드를 다시 시작합니다. kubectl --kubeconfig 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, 1.16, 1.28	gke-metrics-agent 로그에서 알 수 없는 측정항목 오류 발생 gke-metrics-agent는 각 노드에서 측정항목을 수집하고 Cloud Monitoring으로 전달하는 daemonset입니다. 다음과 같은 로그가 생성될 수 있습니다. 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 이러한 오류 로그는 참조하는 측정항목이 지원되지 않고 모니터링에 중요하지 않기 때문에 무시해도 안전합니다.
로그 기록 및 모니터링	1.10, 1.11	간헐적 측정항목 내보내기 중단 베어메탈용 GKE 클러스터는 일반적이고 연속적인 측정항목 내보내기를 수행할 때 중단이 발생하거나 일부 노드에서 측정항목이 누락될 수 있습니다. 이 문제가 클러스터에 영향을 미치는 경우 최소한 다음 측정항목에서 데이터 격차가 발생할 수 있습니다. 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.11.1 이상으로 업그레이드하세요. 업그레이드할 수 없는 경우 다음 단계를 수행하여 문제를 해결하세요. 수정할 stackdriver 리소스를 엽니다. kubectl -n kube-system edit stackdriver stackdriver gke-metrics-agent의 CPU 요청을 10m에서 50m로 늘리려면 다음 resourceAttrOverride 섹션을 stackdriver 매니페스트에 추가합니다. spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi 수정된 리소스는 다음과 비슷하게 표시되어야 합니다. spec: anthosDistribution: baremetal 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: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi 변경사항을 저장하고 텍스트 편집기를 닫습니다. 변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다. kubectl -n kube-system get daemonset \ gke-metrics-agent -o yaml | grep "cpu: 50m" 수정이 적용된 경우 명령어가 cpu: 50m을 찾습니다.
네트워킹	1.10	여러 기본 게이트웨이에서 외부 엔드포인트로의 연결 중단 노드에 기본 게이트웨이가 여러 개 있으면 포드 내에서 google.com과 같은 외부 엔드포인트로의 연결이 끊어질 수 있습니다. 이 문제의 영향을 받는지 확인하려면 노드에서 다음 명령어를 실행합니다. ip route show 응답에 default 인스턴스가 여러 개 있으면 이는 영향을 받는다 점을 나타냅니다.
네트워킹	1.12	사용자 클러스터에서 네트워킹 커스텀 리소스 수정사항을 덮어씀 버전 1.12.x 베어메탈용 GKE 클러스터는 사용자 클러스터에서 네트워킹 커스텀 리소스를 수동으로 수정하는 것을 막지 않습니다. 베어메탈용 GKE는 클러스터 업그레이드 중 사용자 클러스터의 커스텀 리소스를 관리자 클러스터의 커스텀 리소스와 조정합니다. 이 조정에서 사용자 클러스터의 네트워킹 커스텀 리소스에 직접 수정한 수정사항을 덮어씁니다. 네트워킹 커스텀 리소스를 관리자 클러스터에서만 수정해야 하지만 버전 1.12.x 클러스터에서는 이 요구사항을 적용하지 않습니다. BGP를 사용한 번들 부하 분산, 이그레스 NAT 게이트웨이, SR-IOV 네트워킹, BGP를 사용한 플랫 모드, 포드용 멀티 NIC와 같은 고급 네트워킹 기능을 사용하는 경우 다음 커스텀 리소스를 사용합니다. BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode 관리자 클러스터에서 이러한 커스텀 리소스를 수정하면 조정 단계에서 변경사항이 사용자 클러스터에 적용됩니다. 해결 방법 사용자 클러스터에서 이전에 멘션한 커스텀 리소스를 수정한 경우 업그레이드하기 전에 관리자 클러스터에서 해당 커스텀 리소스를 수정합니다. 이 단계는 구성 변경사항이 보존되도록 합니다. 베어메탈용 GKE 클러스터 버전 1.13.0 이상에서는 사용자 클러스터의 네트워킹 커스텀 리소스를 직접 수정할 수 없습니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	포드 연결 실패 및 역방향 경로 필터링 베어메탈용 GKE는 노드에서 역방향 경로 필터링을 구성하여 소스 검증(net.ipv4.conf.all.rp_filter=0)을 중지합니다. rp_filter 설정이 1 또는 2로 변경되면 노드 외부 통신 제한 시간으로 인해 포드가 실패합니다. 역방향 경로 필터링은 IPv4 구성 폴더(net/ipv4/conf/all)의 rp_filter 파일로 설정됩니다. 이 값은 /etc/sysctl.d/60-gce-network-security.conf와 같은 네트워크 보안 구성 파일에 역방향 경로 필터링 설정을 저장하는 sysctl로 재정의될 수도 있습니다. 해결 방법 다음 해결 방법 중 하나를 수행하여 포드 연결을 복원할 수 있습니다. net.ipv4.conf.all.rp_filter의 값을 다시 0으로 수동 설정한 후 sudo sysctl -p를 실행하여 변경사항을 적용합니다. 또는 anetd 포드를 다시 시작하여 net.ipv4.conf.all.rp_filter를 0으로 다시 설정합니다. anetd 포드를 다시 시작하려면 다음 명령어를 사용하여 anetd 포드를 찾아 삭제하면 새 anetd 포드가 그 위치에서 시작됩니다. kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ ANETD_XYZ를 anetd 포드의 이름으로 바꿉니다. 해결 방법 중 하나를 수행한 후 각 노드에서 sysctl net.ipv4.conf.all.rp_filter를 실행하여 net.ipv4.conf.all.rp_filter 값이 0으로 설정되었는지 확인합니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	부트스트랩(종류) 클러스터 IP 주소 및 클러스터 노드 IP 주소 겹침 192.168.122.0/24 및 10.96.0.0/27은 부트스트랩(종류) 클러스터에서 사용되는 기본 포드 및 서비스 CIDR입니다. 클러스터 노드 머신 IP 주소와 겹치는 경우 실행 전 검사가 실패합니다. 해결 방법 --bootstrap-cluster-pod-cidr 및 --bootstrap-cluster-service-cidr 플래그를 bmctl에 전달하여 충돌을 피하려면 다른 값을 지정합니다.
운영체제	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	CentOS에서 클러스터 생성 또는 업그레이드 실패 2020년 12월에 CentOS 커뮤니티 및 Red Hat에서 CentOS 지원 종료를 발표했습니다. 2022년 1월 31일에 CentOS 8이 지원 종료(EOL)되었습니다. 지원 종료로 인해 yum 저장소가 CentOS에서 작동하지 않아 클러스터 생성 및 클러스터 업그레이드 작업이 실패합니다. 이는 지원되는 모든 CentOS 버전에 적용되며 베어메탈용 GKE 클러스터의 모든 버전에 영향을 미칩니다. 해결 방법 해결 방법 단계 보기 이 문제를 해결하려면 다음 명령어를 실행하여 CentOS에 보관 피드를 사용합니다. sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* 장기적인 솔루션으로 다른 지원되는 운영체제로 마이그레이션하는 것이 좋습니다.
보안	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	컨테이너에서 containerd 및 SELinux로 Dockerfile에 정의된 VOLUME에 쓸 수 없음 containerd를 컨테이너 런타임으로 사용하고 운영체제에 SELinux가 사용 설정된 경우 애플리케이션 Dockerfile에 정의된 VOLUME을 쓰지 못할 수 있습니다. 예를 들어 다음 Dockerfile로 빌드된 컨테이너는 /tmp 폴더에 쓸 수 없습니다. FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp 이 문제의 영향을 받았는지 확인하려면 문제가 있는 컨테이너를 호스팅하는 노드에서 다음 명령어를 실행합니다. ausearch -m avc 이 문제의 영향을 받는 경우 다음과 같은 denied 오류가 표시됩니다. time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc: denied { write } for pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0 해결 방법 이 문제를 해결하려면 다음 중 하나를 변경합니다. SELinux를 중지합니다. Dockerfile 내에서 VOLUME 기능을 사용하지 마세요.
업그레이드 및 업데이트	1.10, 1.11, 1.12	클러스터 업그레이드 후 노드 문제 감지기가 기본적으로 사용 설정되지 않음 베어메탈용 GKE 클러스터를 업그레이드하면 노드 문제 감지기가 기본적으로 사용 설정되지 않습니다. 이 문제는 출시 버전 1.10에서 1.12.1로 업그레이드하는 경우에 적용되며 출시 버전 1.12.2에서 해결되었습니다. 해결 방법: 노드 문제 감지기를 사용 설정하려면 다음 안내를 따르세요. node-problem-detector systemd 서비스가 노드에서 실행 중인지 확인합니다. SSH 명령어를 사용하여 노드에 연결합니다. node-problem-detector systemd 서비스가 노드에서 실행 중인지 확인합니다. systemctl is-active node-problem-detector 명령어 결과에 inactive가 표시되면 노드 문제 감지기가 노드에서 실행되지 않은 것입니다. 노드 문제 감지기를 사용 설정하려면 kubectl edit 명령어를 사용하고 node-problem-detector-config ConfigMap을 수정합니다. 자세한 내용은 노드 문제 감지기를 참조하세요.
작업	1.9, 1.10	루트가 아닌 로그인을 사용할 때 클러스터 백업이 실패함 nodeAccess.loginUser가 루트가 아닌 사용자 이름으로 설정된 경우 bmctl backup cluster 명령어가 실패합니다. 해결 방법: 이 문제는 버전 1.9.x, 1.10.0, 1.10.1에 적용되며 버전 1.10.2 이상에서는 해결되었습니다.
네트워킹	1.10, 1.11, 1.12	부하 분산기 서비스가 제어 영역 호스트 네트워크의 컨테이너에서 작동하지 않음 백엔드 포드가 제어 영역 노드에서 실행 중이고 컨테이너 사양에 hostNetwork: true 필드를 사용하는 경우 anetd에 LoadBalancer 서비스에 대해 패킷이 삭제되는 버그가 있습니다. 버전 1.13 이상에서는 이 버그가 없습니다. 해결 방법: hostNetwork 포드로 지원되는 LoadBalancer 서비스를 사용하는 경우 다 해결 방법이 도움이 될 수 있습니다. 워커 노드(제어 영역 노드 아님)에서 실행 서비스 사양의 externalTrafficPolicy: local를 사용하여 워크로드가 부하 분산기 노드에서 실행되는지 확인
업그레이드 및 업데이트	1.12, 1.13	분리된 anthos-version-$version$ 포드가 이미지를 가져오지 못함 1.12.x에서 1.13.x로 업그레이드하는 클러스터에서 ImagePullBackOff 오류와 함께 실패한 anthos-version-$version$ 포드가 관찰될 수 있습니다. 이 문제는 anthos-cluster-operator의 경합 상태가 업그레이드되었기 때문에 발생하며 일반 클러스터 기능에는 영향을 주지 않습니다. 버전 1.13 이상에는 이 버그가 없습니다. 해결 방법: kubectl delete job anthos-version-$version$ -n kube-system 으로 dynamic-version-installer의 작업을 삭제합니다.
업그레이드 및 업데이트	1.13	1.11에서 업그레이드된 1.12 클러스터를 1.13.0으로 업그레이드할 수 없음 버전 1.11에서 업그레이드된 버전 1.12 클러스터를 버전 1.13.0으로 업그레이드할 수 없습니다. 이 업그레이드 문제는 버전 1.12에서 생성된 클러스터에 적용되지 않습니다. 영향을 받는지 확인하려면 관리자 클러스터에서 upgrade-first-no* 문자열이 있는 업그레이드 작업 로그를 확인합니다. 다음 오류 메시지가 있으면 이 문제에 해당합니다. TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] ******* ... [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name. ... 해결 방법: 이 문제를 해결하려면 다음 안내를 따르세요. 관리자 워크스테이션에서 다음 명령어를 실행합니다. echo '[{ "op": "remove", "path": \ "/spec/clusterConfiguration/featureGates" }]' \ > remove-feature-gates.patch export KUBECONFIG=$ADMIN_KUBECONFIG kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \ 'kubectl patch kubeadmconfig $1 -n $0 --type json \ --patch-file remove-feature-gates.patch' 클러스터 업그레이드를 다시 시도합니다.
로깅 및 모니터링	1.16.2, 1.16.3	stackdriver-operator의 높은 CPU 사용량 stackdriver-operator에 평소보다 많은 CPU 시간이 사용되는 문제가 있습니다. 정상 CPU 사용량은 유휴 상태의 stackdriver-operator에 대해 50milliCPU(50m) 미만입니다. 원인은 stackdriver-operator가 적용하는 인증서 리소스와 cert-manager의 기대치가 서로 일치하지 않는 데 있습니다. 이러한 불일치로 인해 이러한 리소스를 업데이트할 때 cert-manager 및 stackdriver-operator 간에 경합 상태가 발생합니다. 이 문제로 인해 CPU 가용성이 제한된 클러스터의 성능이 저하될 수 있습니다. 해결 방법: 이 버그를 해결한 버전으로 업그레이드할 수 있을 때까지 다음 해결 방법을 사용하세요. 일시적으로 stackdriver-operator를 복제본 0개로 축소하려면 AddonConfiguration 커스텀 리소스를 적용합니다. kubectl scale deploy stackdriver-operator --replicas=0 이 문제를 해결하는 버전으로 업그레이드한 후 stackdriver-operator를 다시 백업합니다. kubectl scale deploy stackdriver-operator --replicas=1
로깅 및 모니터링	1.16.0, 1.16.1	주석 기반 측정항목 스크래핑이 작동하지 않음 베어메탈용 GDCV 1.16 부 출시 버전에서는 stackdriver 커스텀 리소스 사양의 enableStackdriverForApplications 필드가 지원 중단됩니다. 이 필드는 Stackdriver 커스텀 리소스에서 enableCloudLoggingForApplications 및 enableGMPForApplications라는 두 개의 필드로 대체됩니다. 워크로드 모니터링을 위해 Google Cloud Managed Service for Prometheus를 사용하는 것이 좋습니다. 이 기능을 사용 설정하려면 enableGMPForApplications 필드를 사용하세요. 워크로드에서 prometheus.io/scrape 주석으로 트리거되는 측정항목 수집을 사용하는 경우 annotationBasedApplicationMetrics 기능 게이트 플래그를 사용하여 이전 동작을 유지할 수 있습니다. 하지만 annotationBasedApplicationMetrics가 제대로 작동하지 못하게 하는 문제가 있어 애플리케이션이 Cloud Monitoring으로 측정항목을 수집하지 못하게 하는 문제가 발생합니다. 해결 방법: 이 문제를 해결하려면 클러스터를 버전 1.16.2 이상으로 업그레이드하세요. annotationBasedApplicationMetrics 기능 게이트에서 사용 설정된 주석 기반 워크로드 측정항목 수집은 prometheus.io/scrape 주석이 있는 객체의 측정항목을 수집합니다. 오픈소스 원본을 사용하는 많은 소프트웨어 시스템에서 이 주석을 사용할 수 있습니다. 이 측정항목 수집 방법을 계속 사용하는 경우 Cloud Monitoring에서 발생하는 측정항목 비용에 놀라지 않도록 이 종속 항목에 대해 알고 있어야 합니다.

추가 지원이 필요하면 Cloud Customer Care에 연락합니다.