베어메탈용 Anthos 클러스터의 알려진 문제

Version 1.14 (latest)

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

베어메탈용 Anthos 클러스터 버전을 선택하세요. 1.14 1.13 1.12 1.11 1.10

문제 카테고리를 선택하세요. 구성 설치 업그레이드 및 업데이트 작업 로그 기록 및 모니터링 네트워킹 보안 재설정/삭제 Anthos VM 런타임

또는 문제를 검색합니다.

카테고리	식별된 버전	문제 및 해결 방법
업그레이드 및 업데이트	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	수신 경로 수가 많아 BGPSession 상태가 계속 변경됨 베어메탈용 Anthos 클러스터 고급 네트워킹은 외부 피어가 많은 수의 경로(약 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를 클러스터의 리더 포드로 바꿉니다. 해결 방법: 내보내기 정책을 사용하여 원격 피어에서 클러스터로 공지하는 경로 수를 줄이거나 제거합니다. 베어메탈용 Anthos 클러스터 버전 1.14.2 이상에서는 AddOnConfiguration을 사용하여 수신된 경로를 처리하는 기능을 사용 중지할 수도 있습니다. --disable-received-routes 인수를 ang-daemon daemonset의 bgpd 컨테이너에 추가하세요.
네트워킹	1.14	conntrack 테이블 삽입 실패로 인한 애플리케이션 시간 초과 커널 5.15 이상을 사용하는 Ubuntu OS에서 실행되는 버전 1.14 클러스터는 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	인터페이스에 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) 연결이 실패하고 데몬이 계속되지 않습니다. 해결 방법: 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의 실패 노드 수가 많은 베어메탈용 Anthos 클러스터를 설치하면 다음 예시와 비슷한 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"]} 해결 방법: 이 문제는 베어메탈용 Anthos 클러스터 버전 1.13.4 이상에서 해결되었습니다. 영향을 받는 버전을 사용해야 하는 경우 먼저 노드가 20개 미만인 클러스터를 만든 후 설치가 완료되면 클러스터 크기를 조절하여 노드를 추가하세요.
로그 기록 및 모니터링	1.10, 1.11, 1.12, 1.13.0	Edge 클러스터의 metrics-server에 대한 낮은 CPU 한도 베어메탈용 Anthos 클러스터 Edge 클러스터에서 metrics-server의 CPU 한도가 낮으면 metrics-server가 자주 다시 시작될 수 있습니다. metrics-server가 비정상이기 때문에 수평형 포드 자동 확장 처리(HPA)가 작동하지 않습니다. metrics-server CPU 한도가 40m보다 작으면 클러스터가 영향을 받을 수 있습니다. metrics-server CPU 한도를 확인하려면 다음 파일 중 하나를 검토하세요. 베어메탈용 Anthos 클러스터 버전 1.x-1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml 베어메탈용 Anthos 클러스터 버전 Anthos 1.13 이상: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml 해결 방법: 이 문제는 베어메탈용 Anthos 클러스터 버전 1.13.1 이상에서 해결되었습니다. 이 문제를 해결하려면 클러스터를 업그레이드하세요. 클러스터를 업그레이드할 수 있을 때까지의 단기적인 해결 방법은 다음과 같이 metrics-server의 CPU 한도를 수동으로 늘리는 것입니다. metrics-server-operator 축소: kubectl scale deploy metrics-server-operator --replicas=0 구성을 업데이트하고 CPU 한도를 늘립니다. 베어메탈용 Anthos 클러스터 버전 1.x-1.12: kubectl -n kube-system edit deployment metrics-server 베어메탈용 Anthos 클러스터 버전 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><--- CPU, [...] Increase 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	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.10, 1.11, 1.12, 1.13, 1.14	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	백로그 청크 손상으로 인한 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"}]'
네트워킹, Anthos 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을 빠른 해결 방법으로 다시 시작할 수 있습니다. 문제가 반복되지 않도록 하려면 베어메탈용 Anthos 클러스터 1.14.1 이상으로 업그레이드합니다.
작업	1.13, 1.14.0, 1.14.1	gke-metrics-agent에 에지 프로필 클러스터에 대한 메모리 한도가 없음 클러스터의 워크로드에 따라 gke-metrics-agent에서 4,608MiB 이상의 메모리를 사용할 수 있습니다. 이 문제는 베어메탈용 Anthos 클러스터 에지 프로필 클러스터에만 영향을 미칩니다. 기본 프로필 클러스터는 영향을 받지 않습니다. 해결 방법: 클러스터를 버전 1.14.2 이상으로 업그레이드합니다.
설치	1.12, 1.13	경합 상태로 인해 클러스터 생성이 실패할 수 있음 kubectl을 사용하여 클러스터를 생성하면 경합 상태로 인해 실행 전 검사가 완료되지 않을 수 있습니다. 그 결과 경우에 따라서 클러스터 생성이 실패할 수 있습니다. 실행 전 검사 조정자는 SecretForwarder를 만들어 기본 ssh-key 보안 비밀을 대상 네임스페이스에 복사합니다. 일반적으로 실행 전 검사는 소유자 참조를 활용하고 SecretForwarder가 완료되면 조정됩니다. 하지만 드물게 SecretForwarder의 소유자 참조로 인해 실행 전 검사에서 참조가 손실되어 실행 전 검사가 중단될 수 있습니다. 그에 따라 클러스터 생성이 실패합니다. 컨트롤러 기반 실행 전 검사에 대한 조정을 계속하려면 클러스터 운영자 포드를 삭제하거나 실행 전 검사 리소스를 삭제하세요. 실행 전 검사 리소스를 삭제하면 다른 검사 리소스가 생성되어 조정이 계속됩니다. 또는 이전 버전으로 만든 기존 클러스터를 고정 버전으로 업그레이드할 수 있습니다.
설치	1.10, 1.11.0, 1.11.1, 1.11.2	1.10.4 사용자 클러스터에서 노드 문제 감지기 실패 베어메탈용 Anthos 클러스터 1.11.0, 1.11.1 또는 1.11.2 관리자 클러스터가 1.10.x 사용자 클러스터를 관리하는 경우 베어메탈용 Anthos 클러스터 사용자 클러스터 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	클러스터 업그레이드 롤백 실패 베어메탈용 Anthos 클러스터 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 Anthos 클러스터를 버전 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
작업, Anthos VM 런타임	1.11, 1.12, 1.13, 1.14	업로드 오류와 함께 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 Anthos 클러스터의 gmp-system 네임스페이스에 관리형 컬렉션 구성요소를 수동으로 배포한 경우 버전 1.12로 업그레이드하면 관련 리소스가 보존되지 않습니다. 베어메탈용 Anthos 클러스터 버전 1.12.0부터는 gmp-system 네임스페이스의 Managed Service for Prometheus 구성요소 및 관련 커스텀 리소스 정의가 stackdriver-operator에 의해 enableGMPForApplications 필드로 관리됩니다. 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이 종료됨 베어메탈용 Anthos 클러스터 버전 1.11.0에서 클러스터 만들기가 실패할 수 있습니다(이 문제는 베어메탈용 Anthos 클러스터 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
설치, Anthos 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이 베어메탈용 Anthos 클러스터 1.14의 기본값인 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 설정이 제한적인 시스템의 장애 베어메탈용 Anthos 클러스터 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)는 베어메탈용 Anthos 클러스터 1.13 및 이전 버전에서 지원되지 않습니다. 그러나 버전 1.14에서는 cgroup v2가 미리보기 기능으로 지원됩니다. /sys/fs/cgroup/cgroup.controllers가 있으면 시스템이 cgroup v2를 사용한다는 의미입니다. 해결 방법 시스템에 cgroup v2가 사용되는 경우 베어메탈용 Anthos 클러스터 버전 1.14로 업그레이드하세요.
설치	1.10, 1.11, 1.12, 1.13, 1.14	실행 전 검사 및 서비스 계정 사용자 인증 정보 관리자 또는 하이브리드 클러스터에 의해 트리거된 설치(즉, 사용자 클러스터와 같이 bmctl로 생성되지 않은 클러스터)의 경우 실행 전 검사는 Google Cloud 서비스 계정 사용자 인증 정보 또는 연결된 권한을 확인하지 않습니다.
설치	1.10, 1.11, 1.12, 1.13, 1.14	애플리케이션 기본 사용자 인증 정보 및 bmctl bmctl은 global로 설정되지 않은 경우 애플리케이션 기본 사용자 인증 정보(ADC)를 사용하여 cluster spec에서 클러스터 작업의 위치 값을 검사합니다. 해결 방법 ADC가 작동하려면 GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 서비스 계정 사용자 인증 정보 파일을 가리키거나 gcloud auth application-default login을 실행해야 합니다.
설치	1.10, 1.11, 1.12, 1.13, 1.14	Docker 서비스 클러스터 노드 머신에서 Docker 실행 파일이 PATH 환경 변수에 있지만 Docker 서비스가 활성 상태가 아닌 경우 실행 전 검사가 실패하고 Docker service is not active가 보고됩니다. 해결 방법 Docker를 삭제하거나 Docker 서비스를 사용 설정합니다.
설치	1.10, 1.11, 1.12, 1.13, 1.14	vSphere에 설치 vSphere VM에 베어메탈용 Anthos 클러스터를 설치할 때 tx-udp_tnl-segmentation 및 tx-udp_tnl-csum-segmentation 플래그를 사용 중지로 설정해야 합니다. 이 플래그는 vSphere 드라이버 VMXNET3에서 수행하는 하드웨어 세분화 오프로드와 관련이 있으며 베어메탈용 Anthos 클러스터의 GENEVE 터널과는 호환되지 않습니다. 해결 방법 각 노드에서 다음 명령어를 실행하여 이러한 플래그의 현재 값을 확인합니다. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... NET_INTFC를 노드의 IP 주소와 연결된 네트워크 인터페이스로 바꿉니다. 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 is not 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
업그레이드 및 업데이트, Anthos VM 런타임	1.11, 1.12	Anthos VM 런타임이 사용 설정되었을 때 버전 1.12.0 이상으로 클러스터 업그레이드 실패 베어메탈용 Anthos 클러스터 출시 버전 1.12.0에서는 Anthos VM 런타임 GA 출시 버전을 더욱 효과적으로 지원할 수 있도록 Anthos VM 런타임과 관련된 모든 리소스가 vm-system 네임스페이스로 마이그레이션됩니다. 버전 1.11.x 이하 클러스터에서 Anthos VM 런타임을 사용 설정한 경우 먼저 Anthos VM 런타임을 중지하지 않으면 버전 1.12.0 이상으로 업그레이드할 수 없습니다. 이 문제의 영향을 받는 경우 업그레이드 작업 시 다음 오류가 보고됩니다. Failed to upgrade cluster: cluster is not 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 해결 방법 Anthos VM 런타임을 사용 중지하려면 다음 안내를 따르세요. VMRuntime 커스텀 리소스를 수정합니다. kubectl edit vmruntime 사양에서 enabled를 false로 설정합니다. apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... 편집기에서 커스텀 리소스를 저장합니다. 클러스터 업그레이드가 완료되면 Anthos VM 런타임을 다시 사용 설정합니다. 자세한 내용은 VM 기반 워크로드 작업을 참조하세요.
업그레이드 및 업데이트	1.10, 1.11, 1.12	error during manifests operations에서 업그레이드 중단 경우에 따라 클러스터 업그레이드가 완료되지 않고 bmctl CLI가 응답하지 않습니다. 이 문제는 잘못 업데이트된 리소스로 인해 발생할 수 있습니다. 이 문제의 영향을 받는지 확인하고 수정하려면 anthos-cluster-operator 로그를 확인하여 다음 항목과 비슷한 오류를 찾습니다. controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update 이러한 항목은 잘못 업데이트된 리소스의 증상이며, 여기서 {RESOURCE_NAME}은 문제 리소스의 이름입니다. 해결 방법 로그에 이러한 오류가 있으면 다음 단계를 완료합니다. kubectl edit를 사용하여 로그 메시지에 포함된 리소스에서 kubectl.kubernetes.io/last-applied-configuration 주석을 삭제합니다. 변경사항을 저장하고 리소스에 적용합니다. 클러스터 업그레이드를 다시 시도합니다.
업그레이드 및 업데이트	1.10, 1.11, 1.12	Anthos Network Gateway를 사용하는 기능이 있는 클러스터의 업그레이드 차단 이그레스 NAT 게이트웨이 또는 BGP를 사용한 번들 부하 분산을 사용하는 클러스터의 경우 1.10.x에서 1.11.x로의 클러스터 업그레이드가 실패합니다. 이 두 기능 모두 Anthos 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	bmctl update는 유지보수 블록을 삭제하지 않습니다. bmctl update 명령어는 클러스터 리소스 구성에서 maintenanceBlocks 섹션을 삭제하거나 수정할 수 없습니다. 해결 방법 유지보수 모드에서 노드를 삭제하는 방법 등 자세한 내용은 유지보수 모드로 노드 배치를 참조하세요.
업그레이드 및 업데이트	1.10, 1.11, 1.12, 1.13, 1.14	노드가 오프라인 상태일 때 노드 드레이닝을 시작할 수 없음 노드가 베어메탈용 Anthos 클러스터에서 벗어나면 노드의 드레이닝 프로세스가 시작되지 않습니다. 예를 들어 클러스터 업그레이드 프로세스 중에 노드가 오프라인 상태가 되면 업그레이드가 응답하지 않을 수 있습니다. 이러한 경우는 드뭅니다. 해결 방법 이 문제 발생 가능성을 최소화하려면 업그레이드를 시작하기 전에 노드가 올바르게 작동하는지 확인합니다.
업그레이드 및 업데이트	1.12	containerd 1.5.13에는 libseccomp 2.5 이상이 필요함 베어메탈용 Anthos 클러스터 1.12.1은 containerd 버전 1.5.13과 함께 제공되며 이 containerd 버전에는 libseccomp 버전 2.5 이상이 필요합니다. 시스템에 libseccomp 버전 2.5 이상이 설치되어 있지 않으면 기존 클러스터를 버전 1.12.1로 업그레이드하기 전에 업데이트합니다. 그렇지 않으면 cplb-update 포드에서 부하 분산기 노드의 오류가 다음과 같이 표시될 수 있습니다. runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond 해결 방법 Ubuntu에 최신 버전의 libseccomp를 설치하려면 다음 명령어를 실행하세요. sudo apt-get install libseccomp-dev CentOS 또는 RHEL에서 최신 버전의 libseccomp를 설치하려면 다음 명령어를 실행하세요. sudo dnf -y install libseccomp-devel
작업	1.10, 1.11, 1.12	유지보수 모드 절차를 사용하지 않는 경우 노드 차단 해제됨 베어메탈용 Anthos 클러스터 버전 1.12.0(anthosBareMetalVersion: 1.12.0) 이하를 실행하거나 노드에서 수동으로 kubectl cordon을 사용하는 경우 베어메탈용 Anthos 클러스터는 예상 상태를 조정하기 위해 준비되기 전에 노드를 차단 해제할 수 있습니다. 해결 방법 베어메탈용 Anthos 클러스터 버전 1.12.0 이하의 경우 유지보수 모드를 사용하여 노드를 안전하게 차단하고 드레이닝합니다. 버전 1.12.1(anthosBareMetalVersion: 1.12.1) 이상에서 kubectl cordon을 사용할 때 베어메탈용 Anthos 클러스터는 노드를 예기치 않게 차단 해제하지 않습니다.
작업	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로 덮어씁니다. 파일을 덮어쓰면 업데이트 및 업그레이드와 같은 표준 클러스터 작업이 영향을 받는 사용자 클러스터에 실패합니다. 이 문제는 베어메탈용 Anthos 클러스터 버전 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: 클러스터의 네임스페이스 기본적으로 베어메탈용 Anthos 클러스터의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다. USER_CLUSTER_NAME: 확인할 사용자 클러스터의 이름 출력의 클러스터 이름(다음 샘플 출력의 contexts.context.cluster 참조)이 관리자 클러스터 이름인 경우 지정된 사용자 클러스터가 영향을 받습니다. user-cluster-kubeconfig -o json | \ jq -r '.data.value' | base64 -d 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 파일을 찾습니다. 클러스터를 만들면 베어메탈용 Anthos 클러스터가 관리자 워크스테이션에 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	루트가 아닌 로그인 사용자로 스냅샷 만들기 containerd를 컨테이너 런타임으로 사용하는 경우 스냅샷을 루트가 아닌 사용자로 실행하려면 /usr/local/bin이 사용자의 PATH에 있어야 합니다. 그렇지 않으면 crictl: command not found 오류와 함께 실패합니다. 루트 사용자로 로그인되어 있지 않으면 sudo가 스냅샷 명령어를 실행하는 데 사용됩니다. sudo PATH는 루트 프로필과 다를 수 있으며 /usr/local/bin을 포함할 수 없습니다. 해결 방법 /usr/local/bin을 포함하도록 /etc/sudoers의 secure_path를 업데이트합니다. 또는 다른 /bin 디렉터리에 crictl의 기호화된 링크를 만듭니다.
작업, Anthos VM 런타임	1.10, 1.11, 1.12, 1.13, 1.14	Anthos VM 런타임 - 포드를 다시 시작하면 포드의 VM에서 IP 주소를 변경하거나 IP 주소가 손실됩니다. VM의 IP 주소를 변경해도 Kubernetes 서비스로 노출된 VM 애플리케이션의 연결 가능성은 영향을 받지 않습니다. 해결 방법 IP 주소가 손실되면 VM에서 dhclient를 실행하여 VM의 IP 주소를 가져와야 합니다.
로그 기록 및 모니터링	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' 해결 방법: 해결 방법 단계 보기 베어메탈용 Anthos 클러스터를 버전 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 ^(?[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})) (?stdout|stderr) (?[^ ]*) (?.*)$ 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	예기치 않은 모니터링 청구 베어메탈용 Anthos 클러스터 버전 1.10 이상의 경우 일부 고객이 결제 페이지에서 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	metrics-server-config 수정사항이 유지되지 않음 포드 밀도가 높으면 과도한 로깅 및 모니터링 오버헤드가 발생할 수 있으며, 이로 인해 측정항목 서버가 중지되고 재시작될 수 있습니다. metrics-server-config ConfigMap을 수정하여 측정항목 서버를 계속 실행하도록 더 많은 리소스를 할당해 보세요. 그러나 조정으로 인해 metrics-server-config를 수정해도 클러스터 업데이트 또는 업그레이드 작업 중에 기본값으로 되돌아갈 수 있습니다. 측정항목 서버는 즉시 영향을 받지 않지만, 다음에 다시 시작되면 되돌린 ConfigMap을 선택하고 다시 과도한 오버헤드에 취약해집니다. 해결 방법 1.11.x의 경우 ConfigMap 수정을 스크립트로 작성하고 이를 클러스터에 대한 업데이트 또는 업그레이드와 함께 수행하면 됩니다. 1.12 이상의 경우 지원팀에 문의하세요.
로그 기록 및 모니터링	1.11, 1.12	지원 중단된 측정항목이 Cloud Monitoring 대시보드에 영향을 미침 여러 Anthos 측정항목이 지원 중단되었으며 베어메탈용 Anthos 클러스터 출시 버전 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 클러스터에서 권장되는 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	Cloud Monitoring의 알 수 없는 측정항목 데이터 버전 1.10.x 클러스터의 Cloud Monitoring 데이터에는 다음과 같은 관련 없는 요약 측정항목 항목이 포함될 수 있습니다. Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile 관련 없는 요약 측정항목을 포함할 수 있는 다른 측정항목 유형은 다음과 같습니다. apiserver_admission_step_admission_duration_seconds_summary go_gc_duration_seconds scheduler_scheduling_duration_seconds gkeconnect_http_request_duration_seconds_summary alertmanager_nflog_snapshot_duration_seconds_summary 이러한 요약 유형 측정항목은 측정항목 목록에 있지만 현재 gke-metrics-agent에서 지원되지 않습니다.
로그 기록 및 모니터링	1.10, 1.11	간헐적 측정항목 내보내기 중단 베어메탈용 Anthos 클러스터는 일반적이고 연속적인 측정항목 내보내기를 수행할 때 중단이 발생하거나 일부 노드에서 측정항목이 누락될 수 있습니다. 이 문제가 클러스터에 영향을 미치는 경우 최소한 다음 측정항목에서 데이터 격차가 발생할 수 있습니다. 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	사용자 클러스터에서 네트워킹 커스텀 리소스 수정사항을 덮어씀 베어메탈용 Anthos 클러스터 버전 1.12.x는 사용자 클러스터에서 네트워킹 커스텀 리소스를 수동으로 수정할 수 있습니다. 베어메탈용 Anthos 클러스터는 클러스터 업그레이드 중 사용자 클러스터의 커스텀 리소스를 관리자 클러스터의 커스텀 리소스와 조정합니다. 이 조정에서 사용자 클러스터의 네트워킹 커스텀 리소스에 직접 수정한 수정사항을 덮어씁니다. 네트워킹 커스텀 리소스를 관리자 클러스터에서만 수정해야 하지만 베어메탈용 Anthos 클러스터 버전 1.12.x에서는 이 요구사항을 적용하지 않습니다. BGP를 사용한 번들 부하 분산, 이그레스 NAT 게이트웨이, SR-IOV 네트워킹, BGP를 사용한 플랫 모드, 포드용 멀티 NIC와 같은 고급 네트워킹 기능을 사용하는 경우 다음 커스텀 리소스를 사용합니다. BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode 관리자 클러스터에서 이러한 커스텀 리소스를 수정하면 조정 단계에서 변경사항이 사용자 클러스터에 적용됩니다. 해결 방법 사용자 클러스터에서 이전에 멘션한 커스텀 리소스를 수정한 경우 업그레이드하기 전에 관리자 클러스터에서 해당 커스텀 리소스를 수정합니다. 이 단계는 구성 변경사항이 보존되도록 합니다. 베어메탈용 Anthos 클러스터 버전 1.13.0 이상에서는 사용자 클러스터의 네트워킹 커스텀 리소스를 직접 수정할 수 없습니다.
네트워킹	1.11, 1.12, 1.13, 1.14	너무 많은 동시 연결로 인한 NAT 오류 클러스터의 특정 노드에 대해 노드 IP 주소는 클러스터 외부의 주소로 라우팅된 패킷에 대해 네트워크 주소 변환(NAT)을 제공합니다. 마찬가지로 인바운드 패킷이 번들 부하 분산(spec.loadBalancer.mode: bundled)을 사용하도록 구성된 부하 분산 노드에 진입할 때 소스 네트워크 주소 변환(SNAT)은 패킷을 IP 노드 주소로 라우팅하며 그런 다음에 패킷이 백엔드 포드로 전달됩니다. 베어메탈용 Anthos 클러스터에 사용되는 NAT의 포트 범위는 32768–65535입니다. 이 범위에 따라 해당 노드에서 프로토콜별 병렬 연결 수가 32,767로 제한됩니다. 각 연결에는 conntrack 테이블의 항목이 필요합니다. 단기 지속 연결이 너무 많으면 conntrack 테이블에 NAT용 포트가 부족해집니다. 가비지 수집기가 오래된 항목을 삭제하지만 삭제가 즉각적이지 않습니다. 노드 연결 수가 32,767에 근접하면 NAT가 필요한 연결에서 패킷 손실이 보이기 시작합니다. 문제가 있는 노드의 anetd 포드에서 다음 명령어를 실행하여 이 문제를 식별할 수 있습니다. kubectl -n kube-system anetd-XXX -- hubble observe \ --from-ip $IP --to-ip $IP -f 다음 형식의 오류가 표시됩니다. No mapping for NAT masquerade DROPPED 해결 방법 트래픽을 다른 노드에 재배포합니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14	번들 레이어 2 부하 분산이 있는 클라이언트 소스 IP 외부 트래픽 정책을 Local로 설정하면 번들 레이어 2 부하 분산에 라우팅 오류(예: No route to host)가 발생할 수 있습니다. 외부 트래픽 정책은 기본적으로 Cluster(externalTrafficPolicy: Cluster)로 설정됩니다. 이 설정을 사용하면 Kubernetes가 클러스터 전체의 트래픽을 처리합니다. LoadBalancer 또는 NodePort 유형의 서비스는 externalTrafficPolicy: Local를 사용하여 클라이언트 소스 IP 주소를 보존할 수 있습니다. 그러나 이 설정을 사용하면 Kubernetes가 노드 로컬 트래픽만 처리합니다. 해결 방법 클라이언트 소스 IP 주소를 보존하려는 경우 서비스 IP에 도달할 수 있도록 추가 구성이 필요할 수 있습니다. 구성에 대한 자세한 내용은 번들 부하 분산 구성의 클라이언트 소스 IP 주소 유지를 참조하세요.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14	firewalld를 수정하면 Cilium iptable 정책 체인이 삭제됩니다. CentOS 또는 Red Had Enterprise Linux(RHEL)에서 사용 설정된 firewalld로 베어메탈용 Anthos 클러스터를 실행할 때 firewalld를 변경하면 호스트 네트워크에서 Cilium iptables 체인이 삭제될 수 있습니다. iptables 체인은 anetd 포드 시작 시 추가됩니다. Cilium iptables 체인이 손실되면 노드의 포드에서 노드 외부의 네트워크 연결이 끊어집니다. iptables 체인을 삭제하는 firewalld의 변경사항에는 다음이 포함되지만 이에 국한되지 않습니다. systemctl를 사용하여 firewalld 다시 시작 명령줄 클라이언트(firewall-cmd --reload)로 firewalld 새로고침 해결 방법 노드에서 anetd를 다시 시작합니다. 다음 명령어로 anetd 포드를 찾아 삭제하고 anetd를 다시 시작합니다. kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ ANETD_XYZ를 anetd 포드의 이름으로 바꿉니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14	중복된 egressSourceIP 주소 이그레스 NAT 게이트웨이 기능 미리보기를 사용하는 경우 다른 EgressNATPolicy 객체에 이미 사용되는 egressSourceIP 주소를 지정하는 트래픽 선택 규칙을 설정할 수 있습니다. 이렇게 하면 이그레스 트래픽 라우팅이 충돌합니다. 해결 방법 개발팀과 협력하여 EgressNATPolicy 커스텀 리소스에 egressSourceIP 주소를 지정하기 전에 사용 가능한 유동 IP 주소를 결정합니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14	포드 연결 실패 및 역방향 경로 필터링 베어메탈용 Anthos 클러스터는 노드에서 역방향 경로 필터링을 구성하여 소스 유효성 검사(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으로 수동 설정하거나 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 포드의 이름으로 바꿉니다.
네트워킹	1.10, 1.11, 1.12, 1.13, 1.14	부트스트랩(종류) 클러스터 IP 주소 및 클러스터 노드 IP 주소 겹침 192.168.122.0/24 및 10.96.0.0/27은 부트스트랩(종류) 클러스터에서 사용되는 기본 포드 및 서비스 CIDR입니다. 클러스터 노드 머신 IP 주소와 겹치는 경우 실행 전 검사가 실패합니다. 해결 방법 --bootstrap-cluster-pod-cidr 및 --bootstrap-cluster-service-cidr 플래그를 bmctl에 전달하여 충돌을 피하려면 다른 값을 지정합니다.
운영체제	1.11	GA 커널에서 Ubuntu 18.04.6과 호환되지 않음 베어메탈용 Anthos 클러스터 버전 1.11.0 및 1.11.1은 GA 커널의 Ubuntu 18.04.6과 호환되지 않습니다(4.15.0-144-generic부터 4.15.0-176-generic까지). 비호환성으로 인해 네트워킹 에이전트가 클러스터 네트워크를 구성할 수 없으며 anetd 로그에서 'BPF 프로그램이 너무 큽니다' 오류가 표시됩니다. 포드 이벤트 로그에서 networkPlugin cni failed to set up pod 오류가 표시된 ContainerCreating 상태로 멈춘 포드를 확인할 수 있습니다. 이 문제는 Ubuntu 하드웨어 사용 설정(HWE) 커널에는 적용되지 않습니다. 해결 방법 HWE 커널 가져오기를 수행하고 Ubuntu 18.04에 지원되는 최신 HWE 버전으로 업그레이드하는 것이 좋습니다.
운영체제	1.10, 1.11, 1.12, 1.13, 1.14	CentOS에서 클러스터 생성 또는 업그레이드 실패 2020년 12월에 CentOS 커뮤니티 및 Red Hat에서 CentOS 지원 종료를 발표했습니다. 2022년 1월 31일에 CentOS 8이 지원 종료(EOL)되었습니다. 지원 종료로 인해 yum 저장소가 CentOS에서 작동하지 않아 클러스터 생성 및 클러스터 업그레이드 작업이 실패합니다. 이는 지원되는 모든 CentOS 버전에 적용되며 베어메탈용 Anthos 클러스터의 모든 버전에 영향을 미칩니다. 해결 방법 해결 방법 단계 보기 이 문제를 해결하려면 다음 명령어를 실행하여 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	운영체제 엔드포인트 제한사항 RHEL 및 CentOS에서는 클러스터 수준 제한이 100,000개의 엔드포인트로 제한됩니다. Kubernetes 서비스 서비스 2개가 동일한 포드 집합을 참조하는 경우 별도의 엔드포인트 집합 2개로 계산됩니다. RHEL 및 CentOS의 기본 nftable 구현으로 인해 이러한 제한이 발생합니다. 베어메탈용 Anthos 클러스터에 내재된 제한이 아닙니다.
보안	1.10, 1.11, 1.12, 1.13, 1.14	컨테이너에서 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.13, 1.14	포드 생성 중 SELinux 오류 SELinux에서 컨테이너 런타임이 tmpfs 마운트에 라벨을 설정하지 못하게 하면 포드 생성에 실패하는 경우가 있습니다. 실패하는 경우는 드물지만 SELinux가 Enforcing 모드이고 일부 커널에 있을 때 이러한 오류가 발생할 수 있습니다. SELinux가 포드 생성 실패의 원인인지 확인하려면 다음 명령어를 사용하여 kubelet 로그의 오류를 확인합니다. journalctl -u kubelet SELinux로 인해 포드 생성이 실패한 것이라면 명령어 응답에 다음과 유사한 오류가 포함됩니다. error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied 이 문제가 SELinux 시행과 관련이 있는지 확인하려면 다음 명령어를 실행하세요. ausearch -m avc 이 명령어는 감사 로그에서 액세스 벡터 캐시(AVC) 권한 오류를 검색합니다. 다음 샘플 응답의 avc: denied에서 포드 생성 실패가 SELinux 시행과 관련이 있음을 확인합니다. type=AVC msg=audit(1627410995.808:9534): avc: denied { associate } for pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492 scontext=system_u:object_r: container_file_t:s0:c61,c201 tcontext=system_u: object_r:locale_t:s0 tclass=filesystem permissive=0 SELinux에서 포드 생성 문제의 근본 원인은 다음 Linux 이미지에서 발견된 커널 버그입니다. Red Hat Enterprise Linux(RHEL) 8.3 이전 출시 버전 CentOS 8.3 이전 출시 버전 해결 방법 머신을 재부팅하면 문제를 복구하는 데 도움이 됩니다. 포드 생성 오류가 발생하지 않도록 하려면 RHEL 8.3 이상 또는 CentOS 8.3 이상을 사용합니다. 이러한 버전에서 커널 버그가 수정되었기 때문입니다.
재설정/삭제	1.10, 1.11, 1.12	네임스페이스 삭제 네임스페이스를 삭제하면 머신을 재설정하기 위한 작업을 포함하여 해당 네임스페이스에 새 리소스가 생성되지 않습니다. 해결 방법 사용자 클러스터를 삭제할 때는 먼저 클러스터 객체를 삭제한 후 네임스페이스를 삭제해야 합니다. 그렇지 않으면 머신 재설정 작업을 생성할 수 없으며 삭제 프로세스는 머신 삭제 단계를 건너뜁니다.
재설정/삭제	1.10, 1.11, 1.12, 1.13, 1.14	containerd 서비스 bmctl reset 명령어는 containerd 구성 파일 또는 바이너리를 삭제하지 않습니다. containerd systemd 서비스는 계속 실행 중인 상태입니다. 이 명령어는 노드에 예약된 포드를 실행하는 컨테이너를 삭제합니다.
업그레이드 및 업데이트	1.10, 1.11, 1.12	클러스터 업그레이드 후 노드 문제 감지기가 기본적으로 사용 설정되지 않음 베어메탈용 Anthos 클러스터를 업그레이드하면 노드 문제 감지기가 기본적으로 사용 설정되지 않습니다. 이 문제는 출시 버전 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 명령어가 실패합니다. 해결 방법: 이 문제는 베어메탈용 Anthos 클러스터 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.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 is not 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' 클러스터 업그레이드를 다시 시도합니다.

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