s <0x0

이 페이지에는 베어메탈용 Google Distributed Cloud (소프트웨어 전용)(이전 명칭: Google Distributed Cloud Virtual, 그 전 명칭: 베어메탈용 Anthos 클러스터)의 알려진 문제가 모두 나와 있습니다.

이 페이지는 기본 기술 인프라의 수명 주기를 관리하고, 서비스 수준 목표(SLO)가 충족되지 않았거나 애플리케이션 오류가 발생했을 때 알림과 호출에 대응하는 관리자, 설계자, 운영자를 위해 작성되었습니다. Google Cloud콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

Google Developer Program에 참여하는 경우 이 페이지를 저장하여 이 페이지와 관련된 출시 노트가 게시될 때 알림을 받으세요. 자세한 내용은 저장된 페이지를 참고하세요.

제품 버전이나 카테고리별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 필터를 선택하세요.

Google Distributed Cloud 버전을 선택합니다.

1.34 1.33 1.32 1.31 1.30 1.29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

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

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

또는 문제를 검색합니다.

카테고리	식별된 버전	문제 및 해결 방법
네트워킹, 업그레이드 및 업데이트	1.30 이상	업그레이드 중에 Istiod 포드가 준비 상태에 도달하지 못함 Google Distributed Cloud의 번들 인그레스 기능은 istiod을 사용합니다. 이 기능은 Istio로 정의된 커스텀 리소스 정의를 사용하지 않습니다. 하지만 사용된 코드는 오픈소스이므로 포드는 자체 사용 사례에 있을 수 있는 Istio 설치에 민감합니다. 클러스터에 Istio 커스텀 리소스 정의가 없으면 Istiod는 커스텀 리소스 정의를 기다리지 않고 준비된 것으로 선언합니다. 하지만 클러스터에 v1beta 커스텀 리소스 정의가 있는 경우 Istiod는 v1 커스텀 리소스 정의를 기다린 후 준비 상태를 선언합니다. 따라서 Istiod 포드가 준비 상태에 도달하지 못해 클러스터 업그레이드가 실패할 수 있습니다. 인증: 클러스터가 영향을 받았는지 확인하려면 gke-system 네임스페이스에서 Istiod 포드 상태를 확인하세요. kubectl get pods -n gke-system -l app=istiod 포드 상태가 Running이지만 준비 상태 확인이 실패하면(예: 0/1 준비) 클러스터가 영향을 받을 수 있습니다. 해결 방법: 이 문제를 해결하려면 다음 해결 방법 중 하나를 사용하세요. 클러스터에 Istio v1 커스텀 리소스 정의를 수동으로 배포합니다. 번들 인그레스 기능을 사용하지 않는 경우 사용 중지합니다.
설치, 업그레이드, 업데이트	1.30.400 이하	PreflightCheck 맞춤 리소스를 확인할 때 lifecycle-controllers-manager 비정상 종료 버전 1.30.400 이하의 클러스터는 PreflightCheck 커스텀 리소스를 검증할 때 lifecycle-controllers-manager 포드 비정상 종료가 발생할 수 있습니다. 이러한 비정상 종료로 인해 클러스터 프로비저닝 및 업그레이드가 중단됩니다. 이 문제는 PreflightCheck 리소스 유효성 검사 중에 null 포인터 역참조로 인해 발생합니다. 해결 방법: 클러스터 프로비저닝 또는 업그레이드를 진행하려면 프리플라이트 검사를 우회하세요. 클러스터 구성 파일에서 bypassPreflightCheck 필드를 true로 설정합니다. spec: bypassPreflightCheck: true 자세한 내용은 Kubernetes 리소스 적용 시 실행 전 검사 우회를 참고하세요.
작업, 재설정/삭제	1.33 이하	클러스터 복원 후 노드 문제 감지기가 시작되지 않음 bmctl restore cluster를 사용하여 클러스터를 복원하면 복원 작업이 완료된 후 노드에서 노드 문제 감지기 (NPD) systemd 서비스가 시작되지 않습니다. 영향을 받는지 확인하려면 복원 작업 후 클러스터 노드에서 systemctl is-active node-problem-detector을 실행합니다. 명령어가 inactive를 반환하면 이 문제의 영향을 받는 것입니다. 해결 방법: NPD를 복원하려면 다음을 수행하세요. 노드 문제 감지기를 사용 설정 및 중지하는 방법의 절차에 따라 NPD를 사용 중지합니다. 노드 문제 감지기를 사용 설정 및 중지하는 방법의 절차에 따라 NPD를 사용 설정합니다. NPD를 사용 중지하고 사용 설정하면 모든 노드에 NPD 서비스를 설치하는 NPD 배포자 작업이 명시적으로 트리거됩니다.
네트워킹, 운영	1.28 이하, 1.29.0~1.29.700, 1.30.0~1.30.300	컨트롤 플레인 부하 분산기 포드가 7일마다 다시 시작됨 번들로 제공되는 레이어 2 부하 분산기를 사용하는 클러스터에서는 7일마다 '연결 거부됨' 오류 또는 짧은 API 서버 사용 불가능 (약 1분)이 발생할 수 있습니다. 이 동작은 제어 영역 노드의 haproxy 및 keepalived 포드가 작업 TTL 설정으로 인해 다시 시작되기 때문에 발생합니다. 이 문제는 버전 1.29.0~1.29.700, 1.30.0~1.30.300, 1.28 이하의 클러스터에 영향을 미칩니다. 인증: 다음 단계를 완료하여 클러스터가 이 특정 문제의 영향을 받는지 확인합니다. 업데이트 작업의 이름을 찾습니다. kubectl get jobs -n kube-system | grep bm-system-cplb-update 작업의 TTL 설정을 확인합니다. kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}' JOB_NAME을 이전 단계에서 반환된 이름으로 바꿉니다. 출력이 604800 (초 단위 7일)이면 클러스터가 이 문제의 영향을 받는 것입니다. 해결 방법: 주간 재시작을 방지하려면 다음 단계를 완료하여 기존 부하 분산 장치 업데이트 작업의 ttlSecondsAfterFinished 필드를 더 큰 값으로 수동으로 패치하세요. 부하 분산기 업데이트 작업을 수정합니다. kubectl edit job JOB_NAME -n kube-system 편집기에서 ttlSecondsAfterFinished 필드를 찾아 값을 7776000 (약 90일)로 변경합니다. 변경사항을 적용하려면 저장하고 편집기를 종료합니다.
작업	1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0	cluster-operator nil 포인터 역참조로 인해 포드가 비정상 종료됨 컨트롤러에서 패닉 assignment to entry in nil map으로 인해 cluster-operator 포드가 비정상 종료되거나 비정상 종료 루프가 발생할 수 있습니다. 이 문제는 컨트롤러가 주석이 없는(nil 맵) 맞춤 리소스(예: NodePool)의 주석을 업데이트하려고 할 때 발생할 수 있습니다. 해결 방법: 비정상 종료를 방지하려면 커스텀 리소스 (예: NodePool)에 주석이 하나 이상 있는지 확인하세요. 다음 명령어를 사용하여 더미 주석을 추가할 수 있습니다. kubectl annotate nodepool NODEPOOL_NAME \ -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \ --kubeconfig=ADMIN_KUBECONFIG 다음을 바꿉니다. NODEPOOL_NAME: NodePool 커스텀 리소스의 이름입니다. CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다. ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
업그레이드 및 업데이트	1.34.0	호스트 이름 불일치로 인해 작업자 노드 업그레이드 실패 kubeadm의 회귀(kubernetes/kubeadm#3244)로 인해 작업자 노드 업그레이드가 실패합니다. 이 회귀는 Linux 호스트 이름이 해당 Kubernetes 노드의 kubernetes.io/hostname 라벨 값과 일치하지 않을 때 발생합니다. 영향을 받는 노드가 실패하는지 확인하려면 다음과 유사한 journalctl를 사용합니다. [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm 응답은 다음 예시와 같이 표시됩니다. Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found 이 예에서 journalctl 응답에 보고된 Linux 호스트 이름이 노드의 kubernetes.io/hostname 라벨과 일치하지 않아 업그레이드가 이 문제의 영향을 받음을 확인할 수 있습니다. kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \ -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}' 응답: lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos 해결 방법: 영향을 받는 노드가 업그레이드를 완료하도록 하려면 다음 예와 같이 해당 Kubernetes 노드의 kubernetes.io/hostname 라벨 값과 일치하도록 호스트 이름을 일시적으로 변경해 보세요. [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
네트워킹	1.34.0	정상적인 마이그레이션은 노드 차단 시 기존 연결을 삭제합니다. 이그레스 NAT 빠른 장애 조치를 사용 설정하면 kubectl cordon <NODE_NAME>로 게이트웨이 노드를 격리하여 기존 이그레스 연결을 유지하는 정상적인 마이그레이션을 시작합니다. 하지만 Google Distributed Cloud 소프트웨어 전용 버전 1.34.0에서는 점진적 마이그레이션 기능이 의도한 대로 작동하지 않습니다. 관리자가 빠른 장애 조치를 사용하는 버전 1.34.0 클러스터에서 활성 이그레스 게이트웨이 노드를 차단하면 차단이 계획되지 않은 노드 장애처럼 작동하여 해당 노드의 모든 기존 상태 저장 연결이 즉시 종료됩니다. 해결 방법: 이 문제에 대한 해결 방법은 없습니다.
네트워킹	1.32.0	ClusterIP 서비스 통신 실패 트래픽이 다른 노드의 백엔드 포드로 라우팅되면 ClusterIP 서비스에서 간헐적인 연결 또는 연결 실패가 발생할 수 있습니다. 이 통신 실패는 Cilium v1.15의 회귀로 인해 iptables에서 CILIUM_POST_nat 규칙이 삭제되어 발생합니다. CILIUM_POST_nat 규칙은 소스 네트워크 주소 변환 (SNAT)에 필요하며 이를 삭제하면 kube-proxy에 의한 마스커레이딩이 불안정해져 ClusterIP 서비스 통신이 실패합니다. 예를 들어 클러스터를 업그레이드하는 중에 작업이 중단되면 다음과 같은 로그 메시지가 표시될 수 있습니다. 이는 ClusterIP 서비스가 노드 풀 np1의 API 서버에 연결하려고 할 때 TLS 핸드셰이크가 시간 초과되었음을 나타냅니다. I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out 이 문제는 버전 1.32.100 이상에서 해결되었습니다. 해결 방법: 수정사항이 적용된 버전으로 업그레이드할 수 없는 경우 Cilium 이미지를 v1.15.6-anthos1.32.50 이상 버전으로 수동 업그레이드하는 것이 좋습니다. 이 업데이트는 필요한 CILIUM_POST_nat 규칙을 다시 도입하여 이 문제를 해결합니다. 참고: iptables 규칙을 수동으로 업데이트하여 누락된 NAT 규칙을 추가하여 통신을 복원할 수도 있지만 이러한 유형의 변경은 권장되지 않습니다. 이와 같은 하위 수준 구성 변경사항은 노드 재부팅이나 클러스터 업데이트를 통해 유지되지 않을 수 있습니다. Cilium 이미지를 업그레이드하려면 다음 단계를 따르세요. kube-system 네임스페이스에서 anetd DaemonSet를 수정합니다. kubectl edit ds anetd -n kube-system Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version. Example old image: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc... 새 이미지 예: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50 변경사항을 저장하고 편집기를 닫습니다.
설치, 업그레이드 및 업데이트	1.33	bmctl configure projects에서 Identity Pool does not exist 오류가 반환됨 bmctl configure projects 명령어를 사용하여 새 Google Cloud 프로젝트의 워크로드 아이덴티티 제휴를 구성하려고 하면 다음 오류 메시지와 함께 명령어가 실패합니다. Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.svc.id.goog). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id 이 오류는 projectID.svc.id.goog라는 필수 기본 워크로드 아이덴티티 풀이 새 프로젝트에서 자동으로 프로비저닝되지 않기 때문에 발생합니다. 해결 방법: 다음 단계에 따라 프로젝트에 워크로드 아이덴티티 제휴를 구성합니다. 누락된 기본 워크로드 아이덴티티 풀을 수동으로 만듭니다. gcloud iam workload-identity-pools create PROJECT_ID.svc.id.goog \ --location=global \ --project=PROJECT_ID PROJECT_ID를 프로젝트 ID로 바꿉니다. 관리자 워크스테이션에서 새로 가져온 액세스 토큰으로 GCP_ACCESS_TOKEN 환경 변수를 업데이트합니다. export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token) 기본적으로 액세스 토큰의 수명은 3,600초(1시간)입니다. 워크로드 아이덴티티 클러스터 인증을 사용하는 경우 bmctl은 토큰 만료 시간을 확인합니다. 토큰 만료가 1,800초 (30분) 이내인 경우 bmctl은 오류를 보고하고 종료됩니다. bmctl configure projects를 다시 실행합니다.
업그레이드 및 업데이트, 로깅 및 모니터링	1.29, 1.30, 1.31, 1.32	감사 로깅 플래그를 변경할 때 cal-update Ansible 플레이북이 실패함 cal-update Ansible 플레이북에는 disableCloudAuditLogging 플래그를 변경하려고 할 때 실패를 유발하는 논리적 오류가 포함되어 있습니다. 이로 인해 감사 로그를 사용 설정하거나 제대로 사용 중지할 수 없습니다. disableCloudAuditLogging이 true에서 false로 변경되면 kube-apiserver에 구성 변경사항을 적용하기 전에 스크립트가 실패하므로 감사 로그를 사용 설정할 수 없습니다. disableCloudAuditLogging이 false에서 true로 변경되면 감사 로그를 사용 중지할 수 있지만 cal-update 작업이 계속 실패하여 플레이북이 상태 확인에 도달하지 못합니다. 확인된 오류 메시지는 다음과 같습니다. The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines' 해결 방법: 이 문제에 대한 해결 방법은 없으며, 수정사항이 적용된 버전으로 클러스터를 업그레이드해야 합니다. 업그레이드할 때는 다음 단계를 따르세요. disableCloudAuditLogging을 true로 설정하여 감사 로깅을 사용 중지합니다. 패치가 제공되면 클러스터를 다음 부 버전 패치 버전 (또는 이후 버전) 중 하나로 업그레이드합니다. 이 버전에는 수정사항이 있습니다. 1.30.1200 1.31.800 1.32.400 Cloud 감사 로그를 다시 사용 설정하려면 disableCloudAuditLogging를 다시 false로 설정합니다.
업그레이드 및 업데이트	1.32+	복구 작업 후 고가용성 (HA) 관리자 클러스터 업그레이드 실패 HA 관리자 클러스터에서 gkectl repair admin-master 명령어를 실행한 후 gkectl upgrade admin 명령어를 실행하면 명령어가 실패하고 멈춥니다. gkectl repair admin-master 명령어는 복구된 머신에 machine.onprem.gke.io/managed=false 주석을 추가합니다. 이 주석으로 인해 gkectl upgrade admin 명령어를 실행할 때 cluster-api 컨트롤러가 조정 상태에서 멈춥니다. 비HA 클러스터의 업그레이드에는 이 주석을 삭제하는 피벗 로직이 포함되지만 HA 클러스터의 업그레이드에는 피벗 로직이 누락되어 있습니다. 해결 방법: 업그레이드를 시작하기 전에 관리자 클러스터의 머신 리소스에서 machine.onprem.gke.io/managed 주석을 수동으로 삭제합니다.
업그레이드, 구성	1.32.0~1.32.200	레지스트리 미러로 인해 업그레이드 실행 전 검사 실패 레지스트리 미러로 구성된 클러스터는 1.32.0 이상으로 업그레이드하는 동안 check_gcr_pass 프리플라이트 검사에 실패합니다. 이 실패는 PreflightCheck 커스텀 리소스가 구성되는 방식의 변경으로 인해 발생하며, 검사에 사용되는 클러스터 사양에서 레지스트리 미러 구성이 생략됩니다. 이 문제는 프록시 및 레지스트리 미러 구성이 있는 클러스터에서 내부 테스트 중에 발견되었습니다. 해결 방법: 이 문제의 해결 방법으로 다음 옵션 중 하나를 사용할 수 있습니다. 업그레이드를 트리거할 때 --force 플래그를 사용합니다. bmctl get config를 사용하여 현재 클러스터 구성을 가져오고 새로 생성된 이 구성 파일을 사용하여 업그레이드를 트리거합니다.
구성, 업데이트	1.15~1.30, 1.31.0~1.31.800, 1.32.0~1.32.300	클러스터 사양 변경 후 주기적 상태 점검 CronJob이 업데이트되지 않음 지정된 클러스터 버전에서는 클러스터 리소스 구성이 변경될 때 주기적 상태 점검 CronJob이 사양을 업데이트하지 않을 수 있습니다. 이러한 업데이트 실패로 인해 상태 점검이 오래되고 작업이 실패할 수 있습니다. 이 문제는 Google Distributed Cloud 버전 1.31.900, 1.32.400, 1.33.0 이상에서 해결되었습니다. 해결 방법: 버전 1.30 이하의 경우 다음 단계를 해결 방법으로 사용할 수 있습니다. 주기적인 상태 점검 사용 중지 이렇게 하면 현재 HealthCheck 리소스가 삭제됩니다. 주기적인 상태 점검을 다시 사용 설정합니다. 이렇게 하면 최신 클러스터 구성을 고려하는 새 HealthCheck 리소스가 생성됩니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	컨트롤 플레인 VIP의 무료 ARP 인터리빙 Keepalived는 고가용성을 위해 컨트롤 플레인 VIP를 한 머신에서 다른 머신으로 이동하는 데 사용됩니다. 번들로 제공되는 레이어 2 부하 분산기에서 컨트롤 플레인 VIP를 처리하는 경우 Keepalived 인스턴스의 장애 조치로 인해 MAC 주소가 다른 Gratuitous ARP가 인터리브되는 짧은 간격 (1초 미만)이 발생할 수 있습니다. 스위칭 네트워크 인프라에서는 이 인터리빙을 비정상으로 해석하여 최대 30분 동안 추가 ARP 메시지를 거부할 수 있습니다. 차단된 ARP 메시지로 인해 이 기간 동안 컨트롤 플레인 VIP를 사용할 수 없게 될 수 있습니다. Gratuitous ARP의 인터리빙은 버전 1.31 이하에서 사용되는 Keepalived 설정으로 인해 발생합니다. 특히 모든 노드가 동일한 우선순위를 사용하도록 구성되었습니다. 버전 1.32의 Keepalived 구성 변경사항은 각 Keepalived 인스턴스에 대해 서로 다른 우선순위를 구성하고 무상 ARP 수를 줄이는 클러스터 설정 controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat를 제공하여 이 문제를 해결합니다. 해결 방법: 버전 1.31 이하의 경우 Keepalived 구성 파일 /usr/local/etc/keepalived/keepalived.conf를 직접 편집하여 무료 ARP의 인터리빙을 줄일 수 있습니다. 컨트롤 플레인 부하 분산기를 실행하는 각 노드에 대해 구성 파일을 수정하여 다음 설정을 변경합니다. priority: 각 노드에 대해 고유한 priority 값을 설정합니다 (유효한 값은 1~254 사이). weight: 상태 점검이 실패할 때 Keepalived 장애 조치가 트리거되도록 weight 값을 -2에서 -253로 변경합니다.
로깅 및 모니터링	1.30, 1.31, 1.32, 1.33	kubernetes.io/anthos/custom_resurce_watchers 측정항목의 불일치 내부 정의 오류로 인해 kubernetes.io/anthos/custom_resurce_watchers 측정항목에 부정확한 데이터가 표시될 수 있습니다. 이 문제의 영향을 받는 경우 로그에 다음과 유사한 오류가 표시될 수 있습니다. One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE. 이러한 오류는 무시해도 됩니다. 이 측정항목은 중요한 시스템 알림에 사용되지 않으며 오류는 프로젝트 또는 클러스터의 기능에 영향을 미치지 않습니다.
작업	1.30, 1.31, 1.32, 1.33	스냅샷을 캡처하는 동안 클러스터 구성 파일을 파싱하지 못함 bmctl check cluster --snapshot를 실행할 때 관리자 워크스테이션에 .manifests 디렉터리가 누락되면 명령어가 실패하고 다음과 비슷한 오류가 발생합니다. Error message: failing while capturing snapshot failed to parse cluster config file failed to get CRD file 이 오류는 bmctl check cluster --snapshot 명령어에서 클러스터 구성을 검증하기 위해 .manifests 디렉터리의 커스텀 리소스 정의 파일이 필요하기 때문에 발생합니다. 이 디렉터리는 일반적으로 클러스터 설정 중에 생성됩니다. 디렉터리를 실수로 삭제하거나 다른 위치에서 bmctl를 실행하면 명령어가 스냅샷 작업을 진행할 수 없습니다. 해결 방법: 다음 방법 중 하나를 사용하여 .manifests 디렉터리를 수동으로 다시 생성하여 이 문제를 해결할 수 있습니다. bmctl check cluster 명령어를 실행합니다. bmctl check cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG 이 명령어는 초기 검사의 일환으로 명령어의 완료 여부와 관계없이 현재 작업 디렉터리에 .manifests 디렉터리를 자동으로 만듭니다. 현재 클러스터 구성 파일이 포함된 디렉터리에서 bmctl create cluster 명령어를 실행합니다. bmctl create cluster --cluster TEST_CLUSTER 이 명령어는 클러스터 구성 파일을 파싱할 수 없음과 같은 오류를 발생시킬 수 있지만 .manifests 디렉터리는 현재 작업 디렉터리에 계속 생성됩니다. 생성된 임시 디렉터리 bmctl-workspace/TEST_CLUSTER는 나중에 안전하게 삭제할 수 있습니다. 위의 해결 방법 중 하나를 수행한 후 bmctl check cluster --snapshot 명령어를 다시 시도합니다.
설치, 업그레이드 및 업데이트	1.32.0, 1.32.100	HAProxy를 사용할 수 없는 경우 컨트롤 플레인 VIP가 이동되지 않음 HAProxy 인스턴스를 호스팅하는 노드에서 제어 영역 VIP를 사용할 수 없는 경우 Keepalived 인스턴스의 nopreempt 설정으로 인해 제어 영역 VIP가 정상 HAProxy가 있는 노드로 이동하지 않습니다. 이 문제는 nopreempt 설정과 호환되지 않는 Keepalived 가상 라우터 중복 프로토콜 (VRRP) 우선순위를 자동으로 구성하는 기능과 관련이 있습니다. 해결 방법: 문제를 해결하려면 다음 단계에 따라 Keepalived 기능을 사용 중지하세요. preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" 주석을 클러스터에 추가합니다. kubectl annotate --kubeconfig ADMIN_KUBECONFIG \ -n CLUSTER_NAMESPACE \ clusters.baremetal.cluster.gke.io/CLUSTER_NAME \ preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable" 컨트롤 플레인 부하 분산기를 실행하는 노드에서 /usr/local/etc/keepalived/keepalived.conf의 nopreempt를 삭제합니다. 부하 분산기 구성에 따라 컨트롤 플레인 노드 또는 부하 분산기 노드 풀의 노드입니다. nopreempt가 삭제된 후에는 구성 파일의 변경사항을 적용하기 위해 keepalived 정적 포드를 다시 시작해야 합니다. 이렇게 하려면 각 노드에서 다음 명령어를 사용하여 keepalived 포드를 다시 시작합니다. crictl rmp -f \ $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
설치, 업그레이드 및 업데이트	1.30, 1.31, 1.32.0	폴더 abm-tools-*개가 정리되지 않음 프리플라이트 및 상태 점검 작업이 실패하면 타임스탬프가 지정된 abm-tools-* 폴더가 /usr/local/bin 아래에 남을 수 있습니다. 이 문제의 영향을 받는 경우 다음과 같은 폴더가 많이 표시될 수 있습니다. /usr/local/bin/abm-tools-preflight-20250410T114317 실패가 반복되면 디스크 사용량이 증가할 수 있습니다. 해결 방법 이 문제가 발생하면 다음 폴더를 수동으로 삭제하세요. rm -rf /usr/local/bin/abm-tools-*
네트워킹	1.28.0-1.28.200	이그레스 NAT 게이트웨이를 사용하면 부하 분산기 트래픽이 삭제됨 이그레스 NAT 게이트웨이가 사용 설정된 클러스터에서 부하 분산기가 오래된 EgressNATPolicy 커스텀 리소스에 지정된 트래픽 선택 규칙과 일치하는 백엔드를 선택하면 부하 분산기 트래픽이 삭제됩니다. 이 문제는 이그레스 정책과 일치하는 포드를 생성하고 삭제할 때 발생합니다. 포드가 삭제될 때 이그레스 정책이 제대로 정리되지 않으며 오래된 이그레스 정책으로 인해 LoadBalancer 포드가 더 이상 존재하지 않는 연결로 트래픽을 전송하려고 합니다. 이 문제는 Google Distributed Cloud 버전 1.28.300 이상에서 해결되었습니다. 해결 방법 이그레스 NAT 정책 리소스를 정리하려면 실패한 백엔드를 호스팅하는 각 노드를 다시 시작합니다.
업그레이드 및 업데이트, 재설정/삭제	1.28	머신 초기화 실패 - 교체 중에 새 컨트롤 플레인 노드가 멈춤 Google Distributed Cloud 1.28에서 컨트롤 플레인 노드를 교체 (삭제, 추가)할 때 새 노드가 클러스터에 참여하지 못할 수 있습니다. 이는 새 노드(bm-system-machine-init)를 설정하는 프로세스에서 다음 오류가 발생하기 때문입니다. Failed to add etcd member: etcdserver: unhealthy cluster 이 오류는 이전 컨트롤 플레인 노드가 삭제되고 etcd-events의 멤버십이 제대로 정리되지 않아 오래된 멤버가 남아 있을 때 발생합니다. 오래된 구성원으로 인해 새 노드가 etcd-events 클러스터에 참여할 수 없으므로 machine-init 프로세스가 실패하고 새 노드가 계속 다시 생성됩니다. 이 문제의 결과는 다음과 같습니다. 새 컨트롤 플레인 노드를 올바르게 시작할 수 없습니다. 클러스터가 RECONCILING 상태로 멈출 수 있습니다. machine-init 오류로 인해 컨트롤 플레인 노드가 지속적으로 삭제되고 다시 생성됩니다. 이 문제는 버전 1.29 이상에서 해결되었습니다. 해결 방법: 버전 1.29로 업그레이드할 수 없는 경우 다음 안내에 따라 결함이 있는 etcd-events 구성원을 클러스터에서 수동으로 정리할 수 있습니다. SSH를 사용하여 작동하는 컨트롤 플레인 노드에 액세스합니다. 다음 명령어를 실행합니다. ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member list 응답에 구성원 목록에 삭제된 노드가 포함된 경우 노드의 첫 번째 열에서 구성원 ID를 찾아 다음 명령어를 실행합니다. ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member remove MEMBER_ID MEMBER_ID을 삭제된 노드의 구성원 ID로 바꿉니다. 새 컨트롤 플레인 노드는 몇 분 후에 클러스터에 자동으로 조인됩니다.
업그레이드 및 업데이트	1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58	super-admin.conf 파일 누락으로 인한 컨트롤 플레인 업그레이드 실패 클러스터 업그레이드 중에 업그레이드 프로세스가 첫 번째 제어 영역 노드에서 실패할 수 있습니다. ansible 작업 내 오류 메시지는 super-admin.conf 파일이 누락되었음을 나타냅니다. 이 문제는 업그레이드되는 첫 번째 컨트롤 플레인 노드가 클러스터 생성 중에 프로비저닝된 첫 번째 노드가 아닐 수 있기 때문에 발생합니다. 업그레이드 프로세스에서는 업그레이드할 첫 번째 노드에 super-admin.conf 파일이 포함되어 있다고 가정합니다. 이 문제는 패치 업데이트 1.30.500-gke.127, 1.30.600-gke.69, 1.31.200-gke.59에서 해결되었습니다. 해결 방법: 이 문제를 완화하려면 실패한 노드에서 다음 단계를 실행하세요. /etc/kubernetes/admin.conf 파일을 /etc/kubernetes/super-admin.conf에 복사합니다. cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf 업그레이드 프로세스가 자동으로 재시도되며 성공적으로 진행됩니다.
업그레이드 및 업데이트	1.29.0~1.29.1100, 1.30.0~1.30.400	포드가 NoSchedule taint를 허용하는 경우 노드 드레이닝이 중단됨 NoSchedule 톨러레이션이 있는 포드는 업그레이드 중에 제거 대상으로 간주됩니다. 하지만 NoSchedule 허용으로 인해 Deployment 또는 DaemonSet 컨트롤러가 유지보수 중인 노드에 포드를 다시 예약하여 업그레이드가 지연될 수 있습니다. 이 문제의 영향을 받는지 확인하려면 다음 단계를 따르세요. anthos-cluster-operator 포드 로그를 확인하여 노드 드레인을 차단하는 포드를 식별합니다. 다음 예시 로그 스니펫에서 node-problem-detector-mgmt-ydhc2 포드는 아직 드레인되지 않았습니다. nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"} 노드 드레이닝을 차단하는 각 포드에 대해 다음 명령어를 실행하여 허용 오차를 확인합니다. kubectl get po POD_NAME -n kube-system \ -o json | jq '.spec.tolerations' POD_NAME을 노드 드레인을 차단하는 포드의 이름으로 바꿉니다. 다음 조합 중 하나가 표시됩니다. NoSchedule 효과 및 Exists 연산자를 사용한 허용 NoSchedule 효과 및 "baremetal.cluster.gke.io/maintenance" 키가 있는 톨러레이션(toleration) 빈 효과와 "baremetal.cluster.gke.io/maintenance" 키가 있는 톨러레이션 예를 들어 응답은 다음과 같습니다. { "effect": "NoSchedule", "operator": "Exists" }, 해결 방법: 다음 중 하나를 수행하여 노드의 드레이닝을 차단 해제할 수 있습니다. baremetal.cluster.gke.io/maintenance:Schedule 톨러레이션이 있고 단계적 종료가 필요하지 않은 포드에 baremetal.cluster.gke.io/maintenance:NoExecute 톨러레이션을 추가합니다. 노드 드레인 중에 제거해야 하는 포드에서 식별된 허용 오차 조합을 삭제합니다.
네트워킹	1.28, 1.29, 1.30	hostPort가 사용 설정된 포드에 대한 네트워크 호출은 동일한 노드 내에서 시작된 요청에 대해 실패합니다. hostPort가 사용 설정된 포드로의 네트워크 호출은 포드가 실행되는 동일한 노드 내에서 요청이 시작되는 경우 실패하고 패킷이 삭제됩니다. 이는 모든 클러스터 및 노드 유형에 적용됩니다. 하지만 kube-proxy 없이 생성된 클러스터는 영향을 받지 않습니다. 이 문제의 영향을 받는지 확인하세요. anetd 포드의 이름을 가져옵니다. anetd 포드는 네트워크 트래픽을 제어합니다. kubectl get pods -l k8s-app=cilium -n kube-system anetd 포드 상태를 확인합니다. kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters ANETD_POD_NAME을 클러스터에 있는 anetd 포드 중 하나의 이름으로 바꿉니다. 대답에 KubeProxyReplacement: Partial ...이 포함되어 있으면 이 문제의 영향을 받는 것입니다. 해결 방법 hostPort를 사용하는 포드로 요청을 전송하는 사용 사례가 포드가 실행되는 동일한 노드에서 있는 경우 kube-proxy 없이 클러스터를 만들 수 있습니다. 또는 portmap 컨테이너 네트워크 인터페이스 (CNI) 플러그인을 사용하도록 포드를 구성할 수 있습니다.
로깅 및 모니터링	1.29.100에서 확인되었으며 다른 버전에서도 발생할 수 있습니다.	네트워크 연결 손실 또는 잘못된 서비스 계정으로 인한 높은 디스크 I/O stackdriver-log-forwarder 포드에서 연결이 끊기거나 서비스 계정이 만료되어 이러한 로그를 logging.googleapis.com로 전송하지 못할 수 있습니다. 이로 인해 버퍼에 로그가 누적되어 디스크 I/O가 높아집니다. Cloud Logging 에이전트 (Fluent Bit)인 stackdriver-log-forwarder라는 DaemonSet은 4GB 제한이 있는 파일 시스템 기반 버퍼를 사용합니다. 버퍼가 가득 차면 에이전트가 버퍼를 순환하거나 플러시하려고 시도하므로 I/O가 높아질 수 있습니다. 확인할 사항: 서비스 계정 (SA) 키가 만료되었는지 확인합니다. 이 경우 회전하여 문제를 해결하세요. 다음 명령어를 사용하여 현재 사용 중인 서비스 계정을 확인하고 IAM에서 동일한 계정을 검증할 수 있습니다. kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode 해결 방법: 경고: 버퍼를 삭제하면 현재 버퍼에 저장된 모든 로그 (Kubernetes 노드, 포드, 컨테이너 로그 포함)가 영구적으로 손실됩니다. 버퍼 누적이 Google Cloud의 로깅 서비스에 대한 네트워크 연결 손실로 인해 발생한 경우 버퍼가 삭제되거나 버퍼가 가득 차고 에이전트가 로그를 전송할 수 없으면 이러한 로그가 영구적으로 손실됩니다. 노드 선택기를 추가하여 클러스터에서 stackdriver-log-forwarder daemonset 포드를 삭제합니다 (이렇게 하면 stackdriver-log-forwarder DaemonSet는 유지되지만 노드에서 예약이 취소됨). 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를 사용하여 노드에 연결합니다 (해당 노드에서 stackdriver-log-forwarder가 더 이상 실행되지 않는지 확인). 노드에서 rm -rf /var/log/fluent-bit-buffers/를 사용하여 모든 버퍼 파일을 삭제한 후 6단계를 따릅니다. 이러한 파일이 있는 노드가 너무 많고 이 백로그 청크가 있는 모든 노드를 정리하기 위해 스크립트를 적용하려면 다음 스크립트를 사용합니다. 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"}]'
업그레이드 및 업데이트, 작업	1.28, 1.29, 1.30.0, 1.30.100	containerd 문제로 인해 멈춘 포드로 인해 업그레이드가 차단됨 노드가 드레이닝될 때 포드가 종료되지 않고 멈출 수 있습니다. 고정된 포드는 노드를 드레인하는 업그레이드와 같은 작업을 차단할 수 있습니다. 컨테이너의 기본 기본 프로세스가 이미 성공적으로 종료되었는데도 컨테이너가 실행 중으로 표시되면 포드가 멈출 수 있습니다. 이 경우 crictl stop 명령어는 컨테이너를 중지하지도 않습니다. 이 문제의 영향을 받는지 확인하려면 다음 단계를 따르세요. 클러스터에 Terminating 상태로 멈춘 포드가 있는지 확인합니다. kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating 종료가 중단된 포드의 경우 kubectl describe를 사용하여 이벤트를 확인합니다. kubectl describe pod POD_NAME \ --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE Unhealthy 및 FailedKillPod이 모두 이유로 표시되는 다음과 같은 경고가 표시되면 이 문제의 영향을 받는 것입니다. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"] Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown 이 문제는 업스트림 containerd 문제로 인해 발생하며, 이 문제는 Google Distributed Cloud 버전 1.28.1000, 1.29.600, 1.30.200, 1.31 이상에서 수정되었습니다. 해결 방법 클러스터 작업을 차단 해제하려면 다음 단계를 따르세요. 고정된 포드를 강제 삭제합니다. kubectl delete pod POD_NAME -n POD_NAMESPACE --force 포드가 성공적으로 다시 시작되면 클러스터 작업을 다시 시도합니다.
업그레이드 및 업데이트, 작업	1.28, 1.29, 1.30.0~1.30.100	cgroups 삭제 실패로 인해 포드가 멈춰 업그레이드가 차단됨 노드가 드레이닝될 때 포드가 종료되지 않고 멈출 수 있습니다. 고정된 포드는 노드를 드레이닝하는 업그레이드와 같은 클러스터 작업을 차단할 수 있습니다. runc init 프로세스가 고정되면 포드가 멈출 수 있으며, 이로 인해 containerd가 해당 포드와 연결된 cgroups를 삭제할 수 없습니다. 이 문제의 영향을 받는지 확인하려면 다음 단계를 따르세요. 클러스터에 Terminating 상태로 멈춘 포드가 있는지 확인합니다. kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating 포드가 종료 상태로 멈춰 있는 노드에서 kubelet 로그를 확인합니다. 다음 명령어는 Failed to remove cgroup 텍스트가 포함된 로그 항목을 반환합니다. journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup" 응답에 다음과 같은 경고가 포함된 경우 이 문제의 영향을 받는 것입니다. May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... 해결 방법 runc init 프로세스를 고정 해제하고 클러스터 작업을 차단 해제하려면 다음을 실행하세요. kubelet 로그의 cgroup 경로를 사용하여 freezer.state 파일의 내용을 확인하여 cgroup이 고정되었는지 확인합니다. cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state freezer.state의 콘텐츠는 cgroup의 상태를 나타냅니다. 이전 예시 로그 항목의 경로를 사용하면 명령어는 다음과 같습니다. cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state FREEZING 또는 FROZEN 상태에 있는 cgroups의 고정을 해제합니다. echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state cgroups가 THAWED된 경우 해당 runc init 프로세스가 자동으로 종료되고 cgroups가 자동으로 삭제됩니다. 이렇게 하면 kubelet 로그에 추가 Failed to remove cgroup 경고가 표시되지 않습니다. Terminating 상태로 멈춘 포드도 정리 후 잠시 후에 자동으로 삭제됩니다. 고정된 cgroups가 정리되고 멈춘 포드가 삭제되면 클러스터 작업을 다시 시도합니다.
구성, 네트워킹	1.28.0~1.28.1000, 1.29.0~1.29.500, 1.30.0~1.30.200	임대 업데이트 실패로 인한 NodeNotReady 이벤트 확인된 Google Distributed Cloud 버전에서 kubelet이 40초 넘게 노드 리스를 업데이트하지 못하여 NodeNotReady 이벤트가 발생할 수 있습니다. 이 문제는 간헐적으로 발생하며 약 7일마다 발생합니다. 컨트롤 플레인 VIP 장애 조치는 NodeNotReady 이벤트가 발생할 때쯤 발생할 수 있습니다. 이 문제는 버전 1.28.1100, 1.29.600, 1.30.300 이상에서 해결되었습니다. 해결 방법: 이 문제를 완화하려면 다음 단계에 따라 kubelet을 구성하세요. /etc/default/kubelet를 만들고 다음 환경 변수를 추가합니다. HTTP2_READ_IDLE_TIMEOUT_SECONDS=10 HTTP2_PING_TIMEOUT_SECONDS=5 kubelet을 다시 시작합니다. systemctl restart kubelet kubelet의 새 프로세스 ID (PID)를 가져옵니다. pgrep kubelet 노드에서 kubelet을 다시 시작한 후 환경 변수가 적용되는지 확인합니다. cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS KUBELET_PID을 이전 단계의 명령어 출력으로 바꿉니다. cat 명령 출력의 마지막 몇 줄에 추가된 두 환경 변수가 표시됩니다.
업데이트	1.30	bmctl 버전 1.30.x로 사용자 클러스터를 업데이트할 때 변경할 수 없는 필드 오류 bmctl create cluster 명령을 사용하여 사용자 클러스터를 만들고 헤더에 cloudOperationsServiceAccountKeyPath 필드를 전달하면 spec.clusterOperations.serviceAccountSecret 필드가 생성된 클러스터 리소스에 추가됩니다. 이 필드는 클러스터 구성 파일에 없으며 변경할 수 없습니다. bmctl update cluster 명령어는 헤더에서 이 필드를 채우지 않으므로 bmctl update cluster 명령어와 원래 클러스터 구성 파일을 사용하여 클러스터를 업데이트하려고 하면 다음 오류가 발생합니다. [2025-01-15 16:38:46+0000] Failed to calculate diff: --- E000090: Unable to calculate diff An error occurred while calculating diff between live configuration and cluster.yaml file Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable. (A in old) (B in new) {"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1" A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090 이 문제는 1.30.x 버전의 bmctl를 사용하여 업데이트하는 경우에만 적용됩니다. 해결 방법: 해결 방법으로 업데이트하기 전에 실제 클러스터 리소스의 클러스터 구성을 가져올 수 있습니다. 배포된 클러스터 리소스를 기반으로 사용자 클러스터 구성 파일을 가져옵니다. bmctl get config --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH 가져온 커스텀 리소스는 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml이라는 YAML 파일에 기록됩니다. 이 새 구성 파일에는 업데이트 명령어가 작동하는 데 필요한 spec.clusterOperations.serviceAccountSecret이 포함되어 있습니다. 파일 이름의 TIMESTAMP는 파일이 생성된 날짜 및 시간을 나타냅니다. 기존 클러스터 구성 파일을 가져온 파일로 바꿉니다. 기존 파일의 백업을 저장합니다. 새 클러스터 구성 파일을 수정하고 bmctl update를 사용하여 사용자 클러스터를 업데이트합니다. bmctl update cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH
업그레이드, 업데이트, 보안	1.29, 1.30, 1.31	현재 인증서 파일이 심볼릭 링크가 아닌 경우 Kubelet 인증서 순환이 실패함 kubelet-client-current.pem 및 kubelet-server-current.pem이 심볼릭 링크 (symlink)가 아닌 실제 파일인 경우 Kubelet 인증서 순환이 실패합니다. 이 문제는 bmctl restore를 사용하여 백업에서 클러스터를 복원한 후에 발생할 수 있습니다. 해결 방법: 이 문제의 영향을 받는 경우 다음 단계를 해결 방법으로 사용할 수 있습니다. 현재 인증서 파일을 백업합니다. mkdir -p ~/kubelet-backup/ cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/ 필요한 경우 누적된 인증서 파일을 삭제합니다. ls | grep -E "^kubelet-server-20*" | xargs rm -rf ls | grep -E "^kubelet-client-20*" | xargs rm -rf kubelet-client-current.pem 및 kubelet-server-current.pem 파일의 이름을 바꿉니다. 타임스탬프를 사용하는 것이 일반적인 이름 변경 방식입니다. datetime=$(date +%Y-%m-%d-%H-%M-%S) mv kubelet-server-current.pem kubelet-server-${datetime}.pem mv kubelet-client-current.pem kubelet-client-${datetime}.pem 이전 명령어와 동일한 세션에서 유효한 최신 (이름이 바뀐) 인증서를 가리키는 심볼릭 링크를 만듭니다. ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem 심볼릭 링크의 권한을 777로 설정합니다. chmod 777 kubelet-server-current.pem chmod 777 kubelet-client-current.pem 인증서가 성공적으로 교체되면 백업 디렉터리를 삭제합니다. rm -rf ~/kubelet-backup/
설치, 업그레이드 및 업데이트	1.31	커스텀 리소스 생성 오류 Google Distributed Cloud 버전 1.31에서 클러스터(모든 유형) 및 워크로드와 같은 커스텀 리소스를 만들려고 하면 오류가 발생할 수 있습니다. 이 문제는 커스텀 리소스 정의의 caBundle 필드가 유효한 상태에서 잘못된 상태로 전환되는 것을 방지하는 Kubernetes 1.31에서 도입된 브레이킹 체인지로 인해 발생합니다. 변경사항에 관한 자세한 내용은 Kubernetes 1.31 변경 로그를 참조하세요. Kubernetes 1.31 이전에는 이전 Kubernetes 버전에서 API 서버가 빈 CA 번들 콘텐츠를 허용하지 않았기 때문에 caBundle 필드가 임시 값인 \n로 설정되는 경우가 많았습니다. cert-manager는 일반적으로 나중에 caBundle을 업데이트하므로 혼동을 피하기 위해 \n를 사용하는 것이 적절한 해결 방법이었습니다. caBundle가 잘못된 상태에서 올바른 상태로 한 번 패치된 경우 문제가 없어야 합니다. 그러나 커스텀 리소스 정의가 \n(또는 다른 잘못된 값)으로 다시 조정되면 다음과 같은 오류가 발생할 수 있습니다. ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block] 해결 방법 caBundle이 잘못된 값으로 설정된 커스텀 리소스 정의가 있는 경우 caBundle 필드를 완전히 삭제해도 됩니다. 이렇게 하면 문제가 해결됩니다.
설치, 업그레이드 및 업데이트	1.28, 1.29, 1.30	클러스터 업그레이드가 너무 오래 걸림 클러스터 업그레이드에서는 각 클러스터 노드가 드레이닝되고 업그레이드됩니다. 버전 1.28 이상에서 Google Distributed Cloud는 taint 기반 노드 드레이닝에서 퇴출 기반 드레이닝으로 전환되었습니다. 또한 포드 상호 종속성을 해결하기 위해 제거 기반 드레이닝은 다단계 드레이닝 순서를 따릅니다. 비우기의 각 단계에서 포드는 종료까지 20분의 유예 기간이 주어지지만 이전의 테인트 기반 비우기에는 20분의 단일 제한 시간이 있었습니다. 각 단계에서 모든 포드를 제거하는 데 20분이 필요한 경우 노드를 드레인하는 시간이 이전의 테인트 기반 드레인보다 훨씬 길어질 수 있습니다. 결과적으로 노드 드레이닝 시간이 늘어나면 클러스터 업그레이드를 완료하거나 클러스터를 유지보수 모드로 전환하는 데 걸리는 시간이 크게 늘어날 수 있습니다. 또한 강제 종료 기반 드레이닝의 제한 시간 로직에 영향을 미치는 업스트림 Kubernetes 문제도 있습니다. 이 문제로 인해 노드 드레이닝 시간이 늘어날 수도 있습니다. 해결 방법: 이 문제를 해결하려면 제거 기반 노드 드레이닝을 사용 중지하면 됩니다. 이렇게 하면 테인트 기반 드레이닝으로 되돌아갑니다. 하지만 테인트 기반 드레인은 PodDisruptionBudgets (PDB)를 따르지 않아 서비스 중단이 발생할 수 있으므로 권장되지 않습니다.
설치, 업그레이드 및 업데이트	1.16, 1.28, 1.29	오래된 실패한 프리플라이트 검사로 인해 클러스터 작업이 차단될 수 있음 클러스터 조정은 클러스터 생성 및 클러스터 업그레이드를 비롯한 대부분의 클러스터 작업의 표준 단계입니다. 클러스터 조정 중에 Google Distributed Cloud 클러스터 컨트롤러가 프리플라이트 검사를 트리거합니다. 이 실행 전 검사가 실패하면 추가 클러스터 조정이 차단됩니다. 따라서 클러스터 조정이 포함된 클러스터 작업도 차단됩니다. 이 프리플라이트 검사는 주기적으로 실행되지 않고 클러스터 조정의 일부로만 실행됩니다. 따라서 초기 프리플라이트 실패를 유발한 문제를 수정하고 주문형 프리플라이트 검사가 성공적으로 실행되더라도 이 오래된 실패한 프리플라이트 검사로 인해 클러스터 조정이 여전히 차단됩니다. 클러스터 설치 또는 업그레이드가 멈춘 경우 다음 단계에 따라 이 문제의 영향을 받는지 확인할 수 있습니다. anthos-cluster-operator 포드 로그에서 다음과 같은 항목을 확인합니다. "msg"="Preflight check not ready. Won't reconcile" 클러스터 컨트롤러에 의해 트리거된 실행 전 검사가 실패 상태인지 확인합니다. kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 다음을 바꿉니다. PREFLIGHT_CHECK_NAME: 삭제할 사전 점검의 이름입니다. 이 경우 이름은 클러스터 이름과 동일합니다. CLUSTER_NAMESPACE: 사전 점검이 실패하는 클러스터의 네임스페이스입니다. ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다. 실행 전 검사가 실패한 경우 (Status.Pass가 false인 경우) 이 문제의 영향을 받을 수 있습니다. 이 문제는 1.30 버전 및 이후 버전에서 해결되었습니다. 해결 방법 클러스터 작업을 차단 해제하려면 관리자 클러스터에서 실패한 프리플라이트 검사를 수동으로 삭제하세요. kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 오래된 실패한 프리플라이트 검사가 삭제되면 클러스터 컨트롤러가 새 프리플라이트 검사를 만들 수 있습니다.
설치, 업그레이드 및 업데이트	1.30.100, 1.30.200, 1.30.300	사용자 클러스터 생성 또는 업그레이드 작업이 성공하지 않을 수 있음 버전 1.30.100, 1.30.200 또는 1.30.300으로 사용자 클러스터를 생성하거나 기존 사용자 클러스터를 업그레이드하지 못할 수 있습니다. 이 문제는 kubectl 또는 GKE On-Prem API 클라이언트 ( Google Cloud 콘솔, gcloud CLI 또는 Terraform)를 사용자 클러스터의 생성 및 업그레이드 작업에 사용하는 경우에만 적용됩니다. 이 경우 사용자 클러스터 생성 작업이 Provisioning 상태에서 중단되고 사용자 클러스터 업그레이드가 Reconciling 상태에서 중단됩니다. 클러스터가 영향을 받는지 확인하려면 다음 단계를 따르세요. 클러스터 리소스를 가져옵니다. kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 다음을 바꿉니다. CLUSTER_NAME: 중단된 사용자 클러스터의 이름입니다. USER_CLUSTER_NAMESPACE: 사용자 클러스터 네임스페이스 이름입니다. ADMIN_KUBECONFIG: 관리 클러스터의 kubeconfig 파일 경로 CLUSTER STATE 값이 Provisioning 또는 Reconciling이면 이 문제의 영향을 받을 수 있습니다. 다음 예시 응답은 업그레이드가 멈췄음을 나타냅니다. NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling 버전이 일치하지 않는다는 것은 클러스터 업그레이드가 완료되지 않았음을 나타내기도 합니다. anthos-cluster-operator 포드의 전체 이름을 찾습니다. kubectl get pods -n kube-system -o=name \ -l baremetal.cluster.gke.io/lifecycle-controller-component=true \ --kubeconfig ADMIN_KUBECONFIG 다음 예시와 같이 출력은 anthos-cluster-operator 포드를 포함하는 포드 목록입니다. pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7 클러스터가 프로비저닝 또는 조정 중에 멈췄음을 나타내는 반복 메시지에 대해 anthos-cluster-operator 포드 로그를 스트리밍합니다. kubectl logs POD_NAME -n kube-system -f --since=15s \ --kubeconfig ADMIN_KUBECONFIG | \ grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" POD_NAME을 이전 단계의 anthos-cluster-operator 포드의 전체 이름으로 바꿉니다. 명령어가 실행되는 동안 일치하는 로그 줄이 연속으로 표시되는지 확인합니다. 이는 클러스터 작업이 멈췄음을 나타냅니다. 다음 샘플 출력은 클러스터가 조정 중에 멈췄을 때 표시되는 출력과 유사합니다. ... I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926" I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n" ... Control+C를 눌러 로그 스트리밍을 중지합니다. ConfigMapForwarder이 멈췄는지 확인합니다. kubectl get configmapforwarder metadata-image-digests-in-cluster \ -n USER_CLUSTER_NAMESPACE \ -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \ --kubeconfig ADMIN_KUBECONFIG 응답에는 ConfigMapForwarder 리소스의 이유와 메시지가 포함됩니다. ConfigMapForwarder이 정체되면 다음과 같은 출력이 표시됩니다. Reason: Stalled Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation metadata-image-digests ConfigMap이 사용자 클러스터 네임스페이스에 없는지 확인합니다. kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 다음과 같은 응답이 표시됩니다. Error from server (NotFound): configmaps "metadata-image-digests" not found 해결 방법 이 문제를 해결하려면 ConfigMap을 수동으로 업데이트하여 누락된 주석을 추가하면 됩니다. ConfigMap에 누락된 주석을 추가합니다. kubectl annotate configmap metadata-image-digests \ -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \ --kubeconfig ADMIN_KUBECONFIG 올바르게 주석이 추가되면 metadata-image-digests ConfigMap이 사용자 클러스터 네임스페이스에 자동으로 생성됩니다. ConfigMap이 사용자 클러스터 네임스페이스에 자동으로 생성되었는지 확인합니다. kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG ConfigMap이 성공적으로 생성되면 명령어 응답은 다음과 비슷합니다. NAME DATA AGE metadata-image-digests 0 7s 위의 수정사항과 확인을 통해 클러스터 작업자가 차단 해제되고 클러스터 작업이 평소와 같이 진행되는 것을 확인할 수 있습니다.
작업, 재설정/삭제	1.30.0~1.30.300, 1.29.0~1.29.700, 1.28.0~1.28.1100	루트가 아닌 사용자는 bmctl restore를 실행하여 쿼럼을 복원할 수 없음 루트가 아닌 사용자로 bmctl restore --control-plane-node를 실행하면 컨트롤 플레인 노드에서 워크스테이션 머신으로 파일을 복사하는 동안 chown 문제가 발생합니다. 해결 방법: 루트가 아닌 사용자의 경우 sudo를 사용하여 bmctl restore --control-plane-node 명령어를 실행합니다.
업그레이드	1.30.0-gke.1930	pause:3.9 이미지가 누락되어 업그레이드 상태 확인 작업이 활성 상태로 유지됨 업그레이드 중에 pause:3.9 이미지가 누락되어 upgrade-health-check 작업이 활성 상태로 유지될 수 있습니다. 이 문제는 업그레이드 성공 여부에 영향을 미치지 않습니다. 해결 방법: 다음 명령어를 사용하여 업그레이드 상태 점검 작업을 수동으로 삭제합니다. kubectl delete job upgrade-health-check-JOB_ID --cascade=true
운영체제	1.28, 1.29, 1.30	RHEL 9.2의 컨테이너 내에서 다운로드 속도가 느림 cgroup memory.max 제한을 초과하는 크기의 아티팩트 다운로드는 매우 느릴 수 있습니다. 이 문제는 Red Hat Enterprise Linux (RHEL) 9.2용 Linux 커널의 버그로 인해 발생합니다. cgroup v2가 사용 설정된 커널이 영향을 받습니다. 이 문제는 커널 버전 5.14.0-284.40.1.el_9.2 이상에서 해결되었습니다. 해결 방법: 영향을 받는 포드의 경우 다운로드된 아티팩트의 크기보다 한도가 크도록 컨테이너의 메모리 한도 설정(spec.containers[].resources.limits.memory)을 늘립니다.
업그레이드	1.28~1.29.200	networks.networking.gke.io 커스텀 리소스 정의의 충돌로 인해 클러스터 업그레이드가 실패함 베어 메탈 클러스터 업그레이드 중에 networks.networking.gke.io 커스텀 리소스 정의에 충돌이 있음을 나타내는 오류 메시지와 함께 업그레이드가 실패할 수 있습니다. 특히 이 오류는 v1alpha1이 spec.versions에 없다고 지적합니다. 이 문제는 업그레이드 프로세스 중에 커스텀 리소스 정의의 v1alpha1 버전이 v1로 이전되지 않았기 때문에 발생합니다. 해결 방법: 다음 명령어를 사용하여 영향을 받는 클러스터를 패치합니다. kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/networks.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
설치, 업그레이드 및 업데이트	1.28.0~1.28.600 및 1.29.0~1.29.200	check_inotify_max_user_instances 및 check_inotify_max_user_watches 설정에 대한 머신 프리플라이트 검사 실패 클러스터 설치 또는 업그레이드 중에 fs.inotify 커널 설정과 관련된 머신 프리플라이트 검사가 실패할 수 있습니다. 이 문제의 영향을 받는 경우 머신 실행 전 검사 로그에 다음과 같은 오류가 포함됩니다. Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. 이 문제는 fs.inotify max_user_instances 및 max_user_watches 값이 의도한 노드 머신이 아닌 컨트롤 플레인 및 부트스트랩 호스트에서 잘못 읽히기 때문에 발생합니다. 해결 방법: 이 문제를 해결하려면 모든 제어 영역 및 부트스트랩 머신에서 fs.inotify.max_user_instances 및 fs.inotify.max_user_watches을 권장 값으로 조정하세요. echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p 설치 또는 업그레이드 작업이 완료된 후 필요한 경우 이러한 값을 되돌릴 수 있습니다.
업그레이드	1.28.0 - 1.28.500	Google Cloud 연결 가능 여부 확인 오류로 인해 클러스터 업그레이드 실패 bmctl를 사용하여 클러스터를 업그레이드하면 대상 URL에 관리자 워크스테이션에서 연결할 수 있더라도 GCP reachability check failed 오류로 업그레이드가 실패할 수 있습니다. 이 문제는 bmctl 버전 1.28.0~1.28.500의 버그로 인해 발생합니다. 해결 방법: bmctl upgrade 명령어를 실행하기 전에 GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 유효한 서비스 계정 키 파일을 가리키도록 설정하세요. export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 이 방식으로 애플리케이션 기본 사용자 인증 정보 (ADC)를 설정하면 bmctl가 Google API 엔드포인트에 액세스하는 데 필요한 사용자 인증 정보를 갖게 됩니다.
구성, 설치, 업그레이드 및 업데이트, 네트워킹, 보안	1.15, 1.16, 1.28, 1.29	ipam-controller-manager가 필요한 경우 클러스터 설치 및 업그레이드 실패 ipam-controller-manager가 필요하고 클러스터가 Red Hat Enterprise Linux (RHEL) 8.9 이상 (업스트림 RHEL 변경사항에 따라 다름)에서 SELinux가 강제 모드로 실행되는 경우 클러스터 설치 및 업그레이드가 실패합니다. 이는 container-selinux 버전이 2.225.0보다 높은 경우에 특히 적용됩니다. 다음과 같은 상황에서는 클러스터에 ipam-controller-manager가 필요합니다. 클러스터가 IPv4/IPv6 이중 스택 네트워킹으로 구성되어 있습니다. 클러스터가 clusterNetwork.flatIPv4이 true로 설정된 상태로 구성되어 있습니다. 클러스터가 preview.baremetal.cluster.gke.io/multi-networking: enable 주석으로 구성되어 있습니다. ipam-controller-manager이 설치되어 있으면 클러스터 설치 및 업그레이드가 실패합니다. 해결 방법 각 컨트롤 플레인 노드에서 /etc/kubernetes 디렉터리의 기본 컨텍스트를 etc_t 유형으로 설정합니다. semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes 이 명령어는 /etc/kubernetes 디렉터리의 container-selinux 변경사항을 되돌립니다. 클러스터가 수정사항이 적용된 버전으로 업그레이드된 후 각 컨트롤 플레인 노드에서 이전 파일 컨텍스트 변경사항을 실행취소합니다. semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
업그레이드	1.28.0 - 1.28.500	Google Cloud 연결 가능 여부 확인 오류로 인해 클러스터 업그레이드 실패 bmctl를 사용하여 클러스터를 업그레이드하면 대상 URL에 관리자 워크스테이션에서 연결할 수 있더라도 GCP reachability check failed 오류로 업그레이드가 실패할 수 있습니다. 이 문제는 bmctl 버전 1.28.0~1.28.500의 버그로 인해 발생합니다. 해결 방법: bmctl upgrade 명령어를 실행하기 전에 GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 유효한 서비스 계정 키 파일을 가리키도록 설정하세요. export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 이 방식으로 애플리케이션 기본 사용자 인증 정보 (ADC)를 설정하면 bmctl가 Google API 엔드포인트에 액세스하는 데 필요한 사용자 인증 정보를 갖게 됩니다.
설치	1.29	별도의 부하 분산기 노드 풀이 있는 클러스터의 Binary Authorization 문제 클러스터를 만드는 중에 Binary Authorization 정책을 사용 설정하면 별도의 부하 분산기 노드 풀을 사용하여 클러스터를 설치하지 못할 수 있습니다. 이 문제는 GKE Identity Service 포드 및 기타 중요한 포드의 생성이 바이너리 승인 웹훅에 의해 차단되기 때문에 발생합니다. 이 문제의 영향을 받는지 확인하려면 다음 단계를 완료하세요. 실패하는 포드를 식별합니다. kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG 실패한 포드를 설명합니다. 출력에서 다음 메시지를 확인합니다. admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} 위 메시지가 표시되면 클러스터에 이 문제가 있는 것입니다. 해결 방법: 이 문제를 해결하려면 다음 단계를 완료하세요. 클러스터 생성 작업을 취소합니다. 클러스터 구성 파일에서 spec.binaryAuthorization 블록을 삭제합니다. Binary Authorization이 사용 중지된 클러스터를 만듭니다. 설치가 완료되면 기존 클러스터에 Binary Authorization 정책을 사용 설정합니다.
구성, 설치	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	SELinux가 사용 설정된 마운트 지점으로 인해 문제가 발생함 SELinux를 사용 설정하고 파일 시스템을 Kubernetes 관련 디렉터리에 마운트하면 클러스터 생성 실패, 읽을 수 없는 파일, 권한 문제와 같은 문제가 발생할 수 있습니다. 이 문제의 영향을 받는지 확인하려면 다음 명령어를 실행합니다. ls -Z /var/lib/containerd . system_u:object_r:container_var_lib_t:s0과 같은 다른 라벨이 표시되어야 하는 위치에 system_u:object_r:unlabeled_t:s0이 표시되면 영향을 받는 것입니다. 해결 방법: 최근에 디렉터리에 파일 시스템을 마운트한 경우 해당 디렉터리가 SELinux 구성으로 업데이트되었는지 확인하세요. bmctl create cluster를 실행하기 전에 각 머신에서 다음 명령어를 실행해야 합니다. restorecon -R -v /var restorecon -R -v /etc 이 일회성 수정사항은 재부팅 후에도 유지되지만 동일한 마운트 지점이 있는 새 노드가 추가될 때마다 필요합니다. 자세한 내용은 Red Hat 문서의 파일 시스템 마운트를 참고하세요.
재설정/삭제	1.29.0	네임스페이스 삭제를 시도하는 사용자 클러스터 재설정이 실패함 모든 관련 작업이 완료된 후 bmctl reset cluster -c ${USER_CLUSTER}을 실행하면 명령어가 사용자 클러스터 네임스페이스를 삭제하지 못합니다. 사용자 클러스터 네임스페이스가 Terminating 상태로 멈춰 있습니다. 결국 클러스터 재설정 시간이 초과되고 오류가 반환됩니다. 해결 방법: 네임스페이스를 삭제하고 사용자 클러스터 재설정을 완료하려면 다음 단계를 따르세요. 관리자 클러스터에서 metrics-server Pod를 삭제합니다. kubectl delete pods -l k8s-app=metrics-server \ -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH 이 경우 metrics-server 포드로 인해 클러스터 네임스페이스가 삭제되지 않습니다. 관리자 클러스터에서 사용자 클러스터 네임스페이스의 파이널라이저를 강제 삭제합니다. kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \ jq '.spec.finalizers = []' | \ kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f - 종료자가 삭제되면 클러스터 네임스페이스가 삭제되고 클러스터 재설정이 완료됩니다.
구성, 설치, 보안	1.16.0~1.16.7 및 1.28.0~1.28.400	Binary Authorization 배포에 nodeSelector가 누락됨 Google Distributed Cloud에 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, 1.30	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	Artifact Registry 엔드포인트 gcr.io 연결 문제로 인해 클러스터 작업이 차단될 수 있음 관리자 클러스터의 여러 클러스터 작업으로 부트스트랩 클러스터가 생성됩니다. 부트스트랩 클러스터를 만들기 전에 bmctl은 관리자 워크스테이션에서 Google Cloud 연결 가능성 검사를 수행합니다. Artifact 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 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는 Google Distributed Cloud 버전 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 주소를 할당하지 않음 Google Distributed Cloud는 번들 부하 분산에 MetalLB를 사용합니다. Google Distributed Cloud 출시 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 주소를 수신하지 않습니다. 이 문제는 Google Distributed Cloud 버전 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로 업그레이드한 후 포드가 분리됨 클러스터를 버전 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 이 문제는 Google Distributed Cloud 버전 1.15.0 이상에서 해결되었습니다.
설치	1.14	클러스터 생성이 machine-init 작업에서 멈춤 Google Distributed Cloud 버전 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으로 업그레이드가 실패합니다. Google Distributed Cloud 버전 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이 충족되면 포드를 삭제할 수 있습니다. Pod를 관리하는 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-events와 관련된 포드 오류로 인해 작업이 중단될 수 있습니다. 특히 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는 매개변수로 인식되지 않고 사용되지 않습니다. 대신 Google Distributed Cloud는 항상 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 구성요소에 할당합니다. Google Distributed Cloud 컨트롤러는 클러스터 업그레이드와 같은 조정 프로세스 중에 이러한 수동 변경 사항을 덮어씁니다. 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로 업그레이드할 수 없습니다. 클러스터 만들기 작업과 업그레이드 작업 중에 Google Distributed Cloud는 클러스터 이름과 버전을 포함하는 이름으로 상태 점검 리소스를 만듭니다. 버전 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 커스텀 리소스를 만들 수 없습니다. 이 규칙은 베어메탈 클러스터 버전 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 이상의 클러스터에서 해결되었습니다. 해결 방법 클러스터를 즉시 업그레이드할 수 없는 경우 이미지를 수동으로 가져올 수 있습니다. 다음 명령어는 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이 포드 변경사항을 관찰하지 못함 이러한 문제로 인해 클러스터가 작동하지 않을 수 있습니다. 이 문제는 Google Distributed Cloud 버전 1.12.9, 1.13.6, 1.14.3 및 이후 출시 버전에서 수정되었습니다. 이러한 최신 출시 버전에는 etcd 버전 3.4.21이 사용됩니다. Google Distributed Cloud의 모든 이전 버전은 이 문제의 영향을 받습니다. 해결 방법 즉시 업그레이드할 수 없으면 클러스터의 노드 수를 줄여서 클러스터 실패 위험을 완화할 수 있습니다. 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 상태가 계속 변경됨 Google Distributed Cloud 고급 네트워킹은 외부 피어가 많은 수의 경로 (약 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를 클러스터의 리더 포드로 바꿉니다. 해결 방법: 내보내기 정책을 사용하여 원격 피어에서 클러스터로 공지하는 경로 수를 줄이거나 제거합니다. 클러스터 버전 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의 실패 노드 수가 많은 클러스터를 설치하면 다음 예시와 비슷한 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"]} 해결 방법: 이 문제는 Google Distributed Cloud 버전 1.13.4 이상에서 해결되었습니다. 영향을 받는 버전을 사용해야 하는 경우 먼저 노드가 20개 미만인 클러스터를 만든 후 설치가 완료되면 클러스터 크기를 조절하여 노드를 추가하세요.
로그 기록 및 모니터링	1.10, 1.11, 1.12, 1.13.0	Edge 클러스터의 metrics-server에 대한 낮은 CPU 한도 Google Distributed Cloud Edge 클러스터에서 metrics-server의 CPU 한도가 낮으면 metrics-server가 자주 다시 시작될 수 있습니다. metrics-server가 비정상이기 때문에 수평형 포드 자동 확장 처리(HPA)가 작동하지 않습니다. metrics-server CPU 한도가 40m보다 작으면 클러스터가 영향을 받을 수 있습니다. metrics-server CPU 한도를 확인하려면 다음 파일 중 하나를 검토하세요. 클러스터 버전 1.x~1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml 클러스터 버전 1.13 이상: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml 해결 방법: 이 문제는 클러스터 버전 1.13.1 이상에서 해결되었습니다. 이 문제를 해결하려면 클러스터를 업그레이드하세요. 클러스터를 업그레이드할 수 있을 때까지의 단기적인 해결 방법은 다음과 같이 metrics-server의 CPU 한도를 수동으로 늘리는 것입니다. metrics-server-operator 축소: kubectl scale deploy metrics-server-operator --replicas=0 구성을 업데이트하고 CPU 한도를 늘립니다. 클러스터 버전 1.x~1.12: kubectl -n kube-system edit deployment metrics-server 클러스터 버전 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 이상의 메모리를 사용할 수 있습니다. 이 문제는 베어메탈용 Google Distributed Cloud 에지 프로필 클러스터에만 영향을 미칩니다. 기본 프로필 클러스터는 영향을 받지 않습니다. 해결 방법: 클러스터를 버전 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 클러스터를 버전 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, 1.30, 1.31	업로드 오류와 함께 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이 종료됨 Google Distributed Cloud 버전 1.11.0에서 클러스터 생성이 실패할 수 있습니다(이 문제는 Google Distributed Cloud 출시 버전 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이 Google Distributed Cloud 버전 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 설정이 제한적인 시스템의 장애 Google Distributed Cloud 출시 버전 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)는 Google Distributed Cloud 1.13 및 이전 버전에서 지원되지 않습니다. 그러나 버전 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, 1.30	vSphere에 설치 vSphere VM에 베어메탈 클러스터를 설치할 때 tx-udp_tnl-segmentation 및 tx-udp_tnl-csum-segmentation 플래그를 사용 중지로 설정해야 합니다. 이 플래그는 vSphere 드라이버 VMXNET3에서 수행하는 하드웨어 세분화 오프로드와 관련이 있으며 베어메탈 클러스터의 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 클러스터에서는 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 런타임을 다시 사용 설정합니다. 자세한 내용은 GDC용 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을 사용하는 경우 베어메탈용 Google Distributed Cloud에서 예상 상태를 조정하기 위해 준비되기 전에 노드를 차단 해제할 수 있습니다. 해결 방법 버전 1.12.0 이하 클러스터의 경우 유지보수 모드를 사용하여 노드를 안전하게 차단 해제하고 드레이닝합니다. 버전 1.12.1 (anthosBareMetalVersion: 1.12.1) 이상에서 kubectl cordon을 사용할 때 베어메탈용 Google Distributed Cloud는 노드를 예기치 않게 차단 해제하지 않습니다.
작업	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로 덮어씁니다. 파일을 덮어쓰면 업데이트 및 업그레이드와 같은 표준 클러스터 작업이 영향을 받는 사용자 클러스터에 실패합니다. 이 문제는 클러스터 버전 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: 클러스터의 네임스페이스 기본적으로 클러스터 네임스페이스 이름은 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 파일을 찾습니다. 클러스터를 만들면 베어메탈용 Google Distributed Cloud가 관리자 워크스테이션에 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, 1.30	루트가 아닌 로그인 사용자로 스냅샷 만들기 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	예기치 않은 모니터링 청구 클러스터 버전 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 대시보드에 영향을 미침 여러 Google Distributed Cloud 소프트웨어 전용 측정항목이 지원 중단되었으며 Google Distributed Cloud 출시 버전 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 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	간헐적 측정항목 내보내기 중단 클러스터에서 정상적이고 지속적인 측정항목 내보내기를 수행할 때 중단이 발생하거나 일부 노드에서 측정항목이 누락될 수 있습니다. 이 문제가 클러스터에 영향을 미치는 경우 최소한 다음 측정항목에서 데이터 격차가 발생할 수 있습니다. 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 클러스터는 사용자 클러스터에서 네트워킹 커스텀 리소스를 수동으로 수정할 수 있습니다. Google Distributed Cloud는 클러스터 업그레이드 중 사용자 클러스터의 커스텀 리소스를 관리자 클러스터의 커스텀 리소스와 조정합니다. 이 조정에서 사용자 클러스터의 네트워킹 커스텀 리소스에 직접 수정한 수정사항을 덮어씁니다. 네트워킹 커스텀 리소스를 관리자 클러스터에서만 수정해야 하지만 버전 1.12.x 클러스터에서는 이 요구사항을 적용하지 않습니다. BGP를 사용한 번들 부하 분산, 이그레스 NAT 게이트웨이, SR-IOV 네트워킹, BGP를 사용한 플랫 모드, 포드용 멀티 NIC와 같은 고급 네트워킹 기능을 사용하는 경우 다음 커스텀 리소스를 사용합니다. BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode 관리자 클러스터에서 이러한 커스텀 리소스를 수정하면 조정 단계에서 변경사항이 사용자 클러스터에 적용됩니다. 해결 방법 사용자 클러스터에서 이전에 멘션한 커스텀 리소스를 수정한 경우 업그레이드하기 전에 관리자 클러스터에서 해당 커스텀 리소스를 수정합니다. 이 단계는 구성 변경사항이 보존되도록 합니다. 클러스터 버전 1.13.0 이상에서는 사용자 클러스터의 네트워킹 커스텀 리소스를 직접 수정할 수 없습니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	포드 연결 실패 및 역방향 경로 필터링 Google Distributed Cloud는 노드에서 역방향 경로 필터링을 구성하여 소스 검증 (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, 1.30, 1.31, 1.32, 1.33, 1.34	부트스트랩(종류) 클러스터 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 버전에 적용되며 모든 버전의 클러스터에 영향을 미칩니다. 해결 방법 해결 방법 단계 보기 이 문제를 해결하려면 다음 명령어를 실행하여 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	클러스터 업그레이드 후 노드 문제 감지기가 기본적으로 사용 설정되지 않음 클러스터를 업그레이드하면 노드 문제 감지기가 기본적으로 사용 설정되지 않습니다. 이 문제는 출시 버전 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	주석 기반 측정항목 스크래핑이 작동하지 않음 Google Distributed Cloud 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에서 발생하는 측정항목 비용에 놀라지 않도록 이 종속 항목에 대해 알고 있어야 합니다.
로깅 및 모니터링	1.15, 1.16, 1.28.0-1.28.900, 1.29.0-1.29.400, 1.30.0, 1.30.100	권한 거부로 인한 Cloud 감사 로깅 오류 Cloud 감사 로그에는 클러스터 운영자가 GKE Hub를 통해 자동으로 수행하는 특별한 권한 설정이 필요합니다. 하지만 하나의 관리자 클러스터가 프로젝트 ID가 다른 여러 클러스터를 관리하는 경우 cluster-operator의 버그로 인해 동일한 서비스 계정이 허용 목록에 반복적으로 추가되고 크기 제한으로 인해 허용 목록 요청이 실패합니다. 이로 인해 이러한 클러스터의 일부 또는 전체에서 감사 로그가 Google Cloud에 삽입되지 않습니다. 증상은 영향을 받는 클러스터의 audit-proxy 포드에서 일련의 Permission Denied 오류로 나타납니다. 또 다른 증상은 GKE 허브를 통해 클라우드 감사 로깅 허용 목록을 확인할 때 오류 상태와 중복된 서비스 계정의 긴 목록이 표시되는 것입니다. curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging { "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging", "spec": { "cloudauditlogging": { "allowlistedServiceAccounts": [ "SERVICE-ACCOUNT-EMAIL", ... ... multiple lines of the same service account ] } }, "state": { "state": { "code": "ERROR" } } } 이 문제를 해결하려면 문제가 해결된 1.28.1000, 1.29.500 또는 1.30.200 이상으로 클러스터를 업그레이드하거나 다음 해결 방법을 적용하세요. 해결 방법 단계 보기 Cloud 감사 로깅 GKE Hub 기능을 삭제하고 다시 만들어 허용 목록 자동화를 다시 강제 트리거합니다. 다음 방법으로 cloudauditlogging 허브 특성을 삭제할 수 있습니다. curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging 다음 방법으로 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"]}}}' 위 명령어에서 다음을 수행합니다. PROJECT_ID를 클러스터의 클러스터 운영 프로젝트로 바꿉니다. SERVICE_ACCOUNT_EMAIL을 클러스터의 로깅 및 모니터링 서비스 계정의 이메일 주소로 바꿉니다.
구성	1.29 이하, 1.30.400 이하, 1.31.0의 모든 패치 버전	hosts 필드만 변경된 경우 노드의 레지스트리 미러 구성이 업데이트되지 않음 클러스터 사양에서 레지스트리 미러 엔드포인트의 containerRuntime.registryMirrors.hosts 필드를 업데이트해도 변경사항이 클러스터 노드에 자동으로 적용되지 않습니다. 이 문제는 조정 로직이 hosts 필드에만 적용된 변경사항을 감지하지 못해 노드에서 containerd 구성을 업데이트하는 머신 업데이트 작업이 트리거되지 않기 때문에 발생합니다. 인증: 레지스트리 미러의 hosts 필드만 수정하고 작업자 노드에서 containerd 구성 파일 (경로는 버전과 설정에 따라 /etc/containerd/config.toml 또는 /etc/containerd/config.d/01-containerd.conf와 같은 다른 경로일 수 있음)을 검사하여 이 문제를 확인할 수 있습니다. 파일에 미러 엔드포인트의 업데이트된 hosts 목록이 표시되지 않습니다. 해결 방법: 다음 중 하나를 선택합니다. 수정사항이 적용된 버전으로 업그레이드: 클러스터를 1.30.500-gke.126 이상, 1.31.100-gke.136 이상 또는 1.32.0으로 업그레이드합니다. NodePool 변경을 통해 업데이트 트리거: 영향을 받는 노드의 NodePool 사양을 사소하게 변경합니다. 예를 들어 임시 라벨이나 주석을 추가합니다. 이렇게 하면 레지스트리 미러 변경사항을 가져오는 머신 업데이트 프로세스가 트리거됩니다. 사소한 변경사항은 나중에 삭제할 수 있습니다.

다음 단계

추가 지원이 필요하면 Cloud Customer Care에 문의하세요. 다음을 비롯한 지원 리소스에 관한 자세한 내용은 지원 받기를 참고하세요.

• 지원 케이스를 여는 요구사항
• 문제 해결에 도움이 되는 도구(예: 환경 구성, 로그, 측정항목)
• 지원되는 구성요소