이러한 오류는 제거 이벤트 또는 노드 리소스로 인해 포드를 예약할 수 없음을 나타냅니다. Anthos Network Gateway 포드에는 PriorityClass가 없으므로 다른 워크로드와 같은 기본 우선순위가 있습니다.
노드에 리소스 제약이 있으면 네트워크 게이트웨이 포드가 삭제될 수 있습니다. 이 동작은 특히 ang-node DaemonSet에 좋지 않습니다. 이러한 포드는 특정 노드에 예약되어야 하며 마이그레이션할 수 없기 때문입니다.
해결 방법:
1.15 이상으로 업그레이드합니다.
단기적으로 문제를 해결하려면 PriorityClass를 수동으로 Anthos Network Gateway 구성요소에 할당합니다. 베어메탈용 Anthos 클러스터 컨트롤러는 클러스터 업그레이드 중과 같은 조정 프로세스 중에 이러한 수동 변경사항을 덮어씁니다.
system-cluster-critical PriorityClass를 ang-controller-manager 및 autoscaler 클러스터 컨트롤러 배포에 할당합니다.
클러스터 이름이 영문 기준으로 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로 업그레이드할 수 없습니다. 클러스터 만들기 작업과 업그레이드 작업 중에 베어메탈용 Anthos 클러스터는 클러스터 이름과 버전을 포함하는 이름으로 상태 점검 리소스를 만듭니다.
버전 1.15.0 클러스터의 경우 상태 점검 리소스 이름은 CLUSTER_NAME-add-ons-CLUSTER_VER입니다.
버전 1.15.1 또는 1.15.2 클러스터의 경우 상태 점검 리소스 이름은 CLUSTER_NAME-kubernetes-CLUSTER_VER입니다.
클러스터를 버전 1.15.x로 업그레이드하기 전에 버전 1.14.2 이상으로 업그레이드할 수 없는 경우 부트스트랩 클러스터를 사용하여 버전 1.15.x로 직접 업그레이드할 수 있습니다.
bmctlupgradecluster--use-bootstrap=true
작업
1.15
버전 1.15 클러스터에서는 중복된 유동 IP 주소를 허용하지 않음
Anthos Network Gateway로는 기존 NetworkGatewayGroup 커스텀 리소스에서 이미 사용된 spec.floatingIPs의 IP 주소가 포함된 새로운 NetworkGatewayGroup 커스텀 리소스를 만들 수 없습니다. 이 규칙은 베어메탈용 Anthos 클러스터 버전 1.15.0 이상에서 웹훅을 통해 적용됩니다. 기존의 중복된 유동 IP 주소는 오류를 일으키지 않습니다. 웹훅에서만 중복 IP 주소가 포함된 새 NetworkGatewayGroups 커스텀 리소스의 생성을 막습니다.
웹훅 오류 메시지는 충돌하는 IP 주소와 이를 이미 사용 중인 기존 커스텀 리소스를 식별합니다.
IPaddressexistsinothergatewaywithnamedefault
이그레스 NAT 게이트웨이와 같은 고급 네트워킹 기능에 대한 초기 문서에서는 중복 IP 주소에 대해 경고하지 않습니다.
처음에는 조정자에서 default라는 NetworkGatewayGroup 리소스만 인식했습니다. 이제 Anthos Network Gateway가 시스템 네임스페이스에서 모든 NetworkGatewayGroup 커스텀 리소스를 인식합니다. 기존 NetworkGatewayGroup 커스텀 리소스는 그대로 유지됩니다.
비공개 레지스트리를 사용하는 신규 또는 업그레이드된 버전 1.13.7 클러스터에서 Anthos VM 런타임을 사용 설정하면 노드 네트워크에 연결하거나 GPU를 사용하는 VM이 제대로 시작하지 않을 수 있습니다. 이 문제는 vm-system 네임스페이스의 일부 시스템 포드에서 이미지 가져오기 오류가 발생하기 때문에 발생합니다. 예를 들어 VM에서 노드 네트워크를 사용하는 경우 일부 포드에서 다음과 같은 이미지 가져오기 오류를 보고할 수 있습니다.
macvtap-4x9zp0/1Init:ImagePullBackOff070m
이 문제는 베어메탈용 Anthos 클러스터 버전 1.14.0 이상에서 해결되었습니다.
해결 방법
클러스터를 즉시 업그레이드할 수 없는 경우 이미지를 수동으로 가져올 수 있습니다. 다음 명령어는 VM의 macvtab CNI 플러그인 이미지를 가져와 비공개 레지스트리로 내보냅니다.
종류 클러스터에서 클러스터를 만드는 동안 다음과 같은 이미지 가져오기 오류로 인해 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 로그에 다음 항목이 표시됩니다.
Sep1323:54:20bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:20.378172743Z"level=infomsg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" "Sep1323:54:21bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:21.057247258Z"level=errormsg="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
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 핸드셰이크 오류나 연결 재설정 오류가 있을 수 있습니다. 이 문제는 베어메탈용 Anthos 클러스터 버전 1.14.1 이상에서 해결되었습니다.
이 문제의 영향을 받는지 확인하려면 영향을 받는 서비스의 백엔드 포드가 실행 중인 노드에서 iptables 전달 규칙을 확인합니다.
sudoiptables-LFORWARD
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-xzvfBACKUP_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 포드 두 개가 존재합니다.
이 문제는 베어메탈용 Anthos 클러스터 버전 1.14.2에만 적용됩니다. 1.14.0 및 1.14.1과 같은 이전 버전은 영향을 받지 않습니다. 이 문제는 버전 1.14.3 및 1.15.0 이상을 포함한 모든 후속 출시 버전에서 해결되었습니다.
해결 방법:
이 문제를 해결하려면 clientconfig-operator 배포를 패치하여 추가 보안 컨텍스트를 추가하고 배포가 준비되었는지 확인합니다.
다음 명령어를 사용하여 대상 클러스터에서 clientconfig-operator를 패치합니다.
번들 부하 분산이 없는 클러스터(spec.loadBalancer.mode가 manual로 설정)의 경우 bmctl update credentials certificate-authorities rotate 명령어는 응답하지 않고 x509: certificate signed by unknown authority 오류가 표시되면서 실패할 수 있습니다.
이 문제의 영향을 받는 경우 bmctl 명령어에서 응답하기 전에 다음 메시지를 출력할 수 있습니다.
SigningCAcompletedin3/0control-planenodes
이 경우 명령어가 결국 실패합니다. 제어 영역 3개가 있는 클러스터의 순환 인증 기관 로그에는 다음과 같은 항목이 포함될 수 있습니다.
이중 스택 클러스터(IPv4 및 IPv6 주소가 모두 포함된 클러스터)를 배포하면 ipam-controller-manager 포드에 비정상 종료 루프가 발생할 수 있습니다. 이 동작으로 인해 노드가 Ready 및 NotReady 상태 간에 순환하고 클러스터 설치가 실패할 수 있습니다. 이 문제는 API 서버가 고부하 상태일 때 발생할 수 있습니다.
이 문제의 영향을 받는지 확인하려면 CrashLoopBackOff 오류와 함께 ipam-controller-manager 포드가 실패하는지 확인합니다.
etcd 버전 3.4.13 이하를 실행하는 클러스터에서는 감시 부족과 비작업 리소스 감시가 발생할 수 있으며, 이로 인해 다음 문제가 발생할 수 있습니다.
포드 예약이 중단됨
노드를 등록할 수 없음
kubelet이 포드 변경사항을 관찰하지 못함
이러한 문제로 인해 클러스터가 작동하지 않을 수 있습니다.
이 문제는 베어메탈용 Anthos 클러스터 1.12.9, 1.13.6, 1.14.3 및 이후 출시 버전에서 수정되었습니다. 이러한 최신 출시 버전에는 etcd 버전 3.4.21이 사용됩니다. 베어메탈용 Anthos 클러스터의 모든 이전 버전이 이 문제의 영향을 받습니다.
해결 방법
즉시 업그레이드할 수 없으면 클러스터의 노드 수를 줄여서 클러스터 실패 위험을 완화할 수 있습니다. etcd_network_client_grpc_sent_bytes_total 측정항목이 300MBps 미만이 될 때까지 노드를 삭제합니다.
SriovNetworkNodeState 객체 상태가 '실패'인 경우 베어메탈용 Anthos 클러스터 버전 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 구성이 비어 있습니다.
sudols/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 미만 버전에서 생성된 사용자 클러스터에 해당합니다. 의도하지 않게 생성된 포드는 업그레이드 작업을 방해하지 않지만 비정상적인 상태로 발견될 수 있습니다. 오래된 포드는 삭제하는 것이 좋습니다.
베어메탈용 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의 출력은 영향을 받는 세션이 반복적으로 다시 생성되는 것을 나타냅니다.
내보내기 정책을 사용하여 원격 피어에서 클러스터로 공지하는 경로 수를 줄이거나 제거합니다.
베어메탈용 Anthos 클러스터 버전 1.14.2 이상에서는 AddOnConfiguration을 사용하여 수신된 경로를 처리하는 기능을 사용 중지할 수도 있습니다. --disable-received-routes 인수를 ang-daemon daemonset의 bgpd 컨테이너에 추가하세요.
네트워킹
1.14, 1.15
conntrack 테이블 삽입 실패로 인한 애플리케이션 시간 초과
커널 5.15 이상을 사용하는 Ubuntu OS에서 실행 중인 클러스터는 netfilter 연결 추적(conntrack) 테이블 삽입 실패에 취약합니다. conntrack 테이블에 새 항목을 위한 공간이 있는 경우에도 삽입 실패가 발생할 수 있습니다. 이러한 실패는 체인 길이를 기준으로 테이블 삽입을 제한하는 커널 5.15 이상의 변경사항으로 인해 발생합니다.
이 문제의 영향을 받는지 확인하려면 다음 명령어를 사용하여 커널 내 연결 추적 시스템 통계를 확인하세요.
업그레이드에 실패하면 이전 버전을 복원할 수 있도록 업그레이드 전에 클러스터를 백업하는 것이 좋습니다.
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입니다.
ipaddressadddevINTERFACEscopelinkADDRESS
다음을 바꿉니다.
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 이상에서 해결되었습니다. 다른 모든 버전이 영향을 받습니다. 고정 버전 중 하나로 업그레이드
노드 수가 많은 베어메탈용 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 한도를 확인하려면 다음 파일 중 하나를 검토하세요.
다음 예시와 같이 --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, 1.15
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
kubectl apply를 사용하여 리소스를 업데이트할 때 오류 발생
kubectl apply를 사용하여 ClientConfig 또는 Stackdriver 커스텀 리소스와 같은 기존 리소스를 업데이트하면 컨트롤러에서 오류를 반환하거나 입력 및 원하는 변경사항을 되돌릴 수 있습니다.
예를 들어 먼저 리소스를 가져온 후 업데이트된 버전을 적용하여 다음과 같이 Stackdriver 커스텀 리소스를 수정할 수 있습니다.
클러스터에서 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.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 주소 예약을 확인할 수 있습니다.
kubectlgetippools-A--kubeconfigKUBECONFIG_PATH
해결 방법:
사용하지 않는 IP 주소(ippool)를 수동으로 삭제하세요.
설치
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에서 노드 문제 감지기가 실패할 수 있습니다. 노드 문제 감지기가 실패하면 로그가 다음 오류 메시지로 업데이트됩니다.
1.14 섬(island) 모드 IPv4 클러스터 노드의 포드 CIDR 마스크 크기가 24임
버전 1.14에서는 maxPodsPerNode 설정이 섬(island) 모드 클러스터에 고려되지 않으므로 노드에 포드 CIDR 마스크 크기가 24(IP 주소 256개)로 할당됩니다. 이로 인해 클러스터에서 포드 IP 주소가 예상보다 빨리 소진될 수 있습니다. 예를 들어 클러스터의 포드 CIDR 마스크 크기가 22인 경우 각 노드에 포드 CIDR 마스크가 24로 할당되며 클러스터는 최대 4개의 노드만 지원할 수 있게 됩니다. 또한 maxPodsPerNode가 129 이상으로 설정되어 있고 각 노드의 포드 CIDR에 오버헤드가 충분하지 않으면 포드가 제거가 많은 기간 동안 클러스터에서 네트워크 불안정이 발생할 수 있습니다.
클러스터가 영향을 받는 경우, 사용자가 클러스터에 새 노드를 추가했는데 사용 가능한 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으로 롤백하려고 하면 다음 예시와 같은 오류가 반환될 수 있습니다.
영향을 받는 버전 1.14.0 클러스터의 각 제어 영역 노드에 대해 다음 단계를 수행하여 적절한 기능을 복원합니다. 이러한 단계는 node-role.kubernetes.io/master:NoSchedule taint 및 관련 포드에 적용됩니다. 제어 영역 노드에 PreferNoSchedule taint를 사용하려면 그에 따라 단계를 조정합니다.
관리형 컬렉션 구성요소는 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에서 리소스를 삭제합니다.
이 문제는 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 명령어가 조기에 종료되고 다음과 같은 오류가 로그에 기록됩니다.
클러스터는 포드(클러스터 구성 파일에서 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, 1.15
실행 전 검사 및 서비스 계정 사용자 인증 정보
관리자 또는 하이브리드 클러스터에 의해 트리거된 설치(즉, 사용자 클러스터와 같이 bmctl로 생성되지 않은 클러스터)의 경우 실행 전 검사는 Google Cloud 서비스 계정 사용자 인증 정보 또는 연결된 권한을 확인하지 않습니다.
ADC가 작동하려면 GOOGLE_APPLICATION_CREDENTIALS 환경 변수가 서비스 계정 사용자 인증 정보 파일을 가리키거나 gcloud auth application-default login을 실행해야 합니다.
설치
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Docker 서비스
클러스터 노드 머신에서 Docker 실행 파일이 PATH 환경 변수에 있지만 Docker 서비스가 활성 상태가 아닌 경우 실행 전 검사가 실패하고 Docker service
is not active가 보고됩니다.
해결 방법
Docker를 삭제하거나 Docker 서비스를 사용 설정합니다.
설치
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
vSphere에 설치
vSphere VM에 베어메탈용 Anthos 클러스터를 설치할 때 tx-udp_tnl-segmentation 및 tx-udp_tnl-csum-segmentation 플래그를 사용 중지로 설정해야 합니다. 이 플래그는 vSphere 드라이버 VMXNET3에서 수행하는 하드웨어 세분화 오프로드와 관련이 있으며 베어메탈용 Anthos 클러스터의 GENEVE 터널과는 호환되지 않습니다.
이 플래그 변경사항은 재부팅 후 유지되지 않습니다. 시스템을 부팅할 때 이러한 플래그를 명시적으로 설정하도록 시작 스크립트를 구성합니다.
업그레이드 및 업데이트
1.10
bmctl에서 하위 버전 사용자 클러스터를 생성, 업데이트 또는 재설정할 수 없음
bmctl CLI는 관리자 클러스터 버전에 관계없이 하위 부 버전으로 사용자 클러스터를 생성, 업데이트 또는 재설정할 수 없습니다. 예를 들어 관리자 클러스터도 1.N.X 버전이더라도 1.N.X 버전의 bmctl을 사용하여 1.N-1.Y 버전의 사용자 클러스터를 재설정할 수 없습니다.
kubectl을 사용하여 관리자 클러스터 내에서 사용자 클러스터 커스텀 리소스를 생성, 수정 또는 삭제합니다.
사용자 클러스터를 업그레이드하는 기능은 영향을 받지 않습니다.
업그레이드 및 업데이트
1.12
버전 1.12.1로의 클러스터 업그레이드가 중단될 수 있음
API 서버를 사용할 수 없어 클러스터를 버전 1.12.1로 업그레이드하는 작업이 간혹 중단됩니다. 이 문제는 모든 클러스터 유형 및 지원되는 모든 운영체제에 영향을 미칩니다. 이 문제가 발생하면 bmctl
upgrade cluster 명령어는 프리플라이트 검사의 두 번째 단계를 포함하여 여러 지점에서 실패할 수 있습니다.
해결 방법
업그레이드 로그를 확인하여 이 문제의 영향을 받는지 확인할 수 있습니다. 기본적으로 업그레이드 로그는 /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP에 있습니다.
노드에서 HAProxy 또는 Keepalived가 실행되고 있지 않으면 노드에서 kubelet을 다시 시작합니다.
systemctlrestartkubelet
업그레이드 및 업데이트, 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
경우에 따라 클러스터 업그레이드가 완료되지 않고 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...
노드가 베어메탈용 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를 설치하려면 다음 명령어를 실행하세요.
sudoapt-getinstalllibseccomp-dev
CentOS 또는 RHEL에서 최신 버전의 libseccomp를 설치하려면 다음 명령어를 실행하세요.
sudodnf-yinstalllibseccomp-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 이하에 적용됩니다.
USER_CLUSTER_NAMESPACE: 클러스터의 네임스페이스 기본적으로 베어메탈용 Anthos 클러스터의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정하면 네임스페이스는 cluster-test입니다.
USER_CLUSTER_NAME: 확인할 사용자 클러스터의 이름
출력의 클러스터 이름(다음 샘플 출력의 contexts.context.cluster 참조)이 관리자 클러스터 이름인 경우 지정된 사용자 클러스터가 영향을 받습니다.
[PARSER]# https://rubular.com/r/Vn30bO78GlkvyBNamecri
Formatregex
# The timestamp is described inhttps://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_KeytimeTime_Format%Y-%m-%dT%H:%M:%S.%L%z
Time_Keepoff
포드 밀도가 높으면 과도한 로깅과 모니터링 오버헤드가 발생할 수 있으며, 이로 인해 측정항목 서버가 중지되고 다시 시작할 수 있습니다. metrics-server-config ConfigMap을 수정하여 측정항목 서버가 계속 실행되도록 더 많은 리소스를 할당할 수 있습니다. 그러나 조정으로 인해 metrics-server-config를 수정해도 클러스터 업데이트 또는 업그레이드 작업 중에 기본값으로 되돌아갈 수 있습니다.
측정항목 서버는 즉시 영향을 받지 않지만 다음에 다시 시작하면 되돌린 ConfigMap을 선택하고 다시 과도한 오버헤드에 취약해집니다.
해결 방법
1.11.x의 경우 ConfigMap 수정을 스크립트로 작성하고 이를 클러스터에 대한 업데이트나 업그레이드와 함께 수행할 수 있습니다. 1.12 이상의 경우 지원팀에 문의하세요.
로그 기록 및 모니터링
1.11, 1.12
지원 중단된 측정항목이 Cloud Monitoring 대시보드에 영향을 미침
여러 Anthos 측정항목이 지원 중단되었으며 베어메탈용 Anthos 클러스터 출시 버전 1.11부터는 이러한 지원 중단된 측정항목에 대한 데이터가 더 이상 수집되지 않습니다. 알림 정책에서 이러한 측정항목을 사용하는 경우 알림 조건을 트리거하는 데이터가 없습니다.
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으로 이동
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 파일 경로로 바꿉니다.
노드에 기본 게이트웨이가 여러 개 있으면 포드 내에서 google.com과 같은 외부 엔드포인트로의 연결이 끊어질 수 있습니다.
이 문제의 영향을 받는지 확인하려면 노드에서 다음 명령어를 실행합니다.
iprouteshow
응답에 default 인스턴스가 여러 개 있으면 이는 영향을 받는다 점을 나타냅니다.
네트워킹
1.12
사용자 클러스터에서 네트워킹 커스텀 리소스 수정사항을 덮어씀
베어메탈용 Anthos 클러스터 버전 1.12.x는 사용자 클러스터에서 네트워킹 커스텀 리소스를 수동으로 수정할 수 있습니다. 베어메탈용 Anthos 클러스터는 클러스터 업그레이드 중 사용자 클러스터의 커스텀 리소스를 관리자 클러스터의 커스텀 리소스와 조정합니다. 이 조정에서 사용자 클러스터의 네트워킹 커스텀 리소스에 직접 수정한 수정사항을 덮어씁니다. 네트워킹 커스텀 리소스를 관리자 클러스터에서만 수정해야 하지만 베어메탈용 Anthos 클러스터 버전 1.12.x에서는 이 요구사항을 적용하지 않습니다.
관리자 클러스터에서 이러한 커스텀 리소스를 수정하면 조정 단계에서 변경사항이 사용자 클러스터에 적용됩니다.
해결 방법
사용자 클러스터에서 이전에 멘션한 커스텀 리소스를 수정한 경우 업그레이드하기 전에 관리자 클러스터에서 해당 커스텀 리소스를 수정합니다. 이 단계는 구성 변경사항이 보존되도록 합니다. 베어메탈용 Anthos 클러스터 버전 1.13.0 이상에서는 사용자 클러스터의 네트워킹 커스텀 리소스를 직접 수정할 수 없습니다.
네트워킹
1.11, 1.12, 1.13, 1.14, 1.15
너무 많은 동시 연결로 인한 NAT 오류
클러스터의 특정 노드에 대해 노드 IP 주소는 클러스터 외부의 주소로 라우팅된 패킷에 대해 네트워크 주소 변환(NAT)을 제공합니다. 마찬가지로 인바운드 패킷이 번들 부하 분산(spec.loadBalancer.mode:
bundled)을 사용하도록 구성된 부하 분산 노드에 진입할 때 소스 네트워크 주소 변환(SNAT)은 패킷을 IP 노드 주소로 라우팅하며 그런 다음에 패킷이 백엔드 포드로 전달됩니다.
베어메탈용 Anthos 클러스터에 사용되는 NAT의 포트 범위는 32768–65535입니다. 이 범위에 따라 해당 노드에서 프로토콜별 병렬 연결 수가 32,767로 제한됩니다. 각 연결에는 conntrack 테이블의 항목이 필요합니다. 단기 지속 연결이 너무 많으면 conntrack 테이블에 NAT용 포트가 부족해집니다. 가비지 수집기가 오래된 항목을 삭제하지만 삭제가 즉각적이지 않습니다.
노드 연결 수가 32,767에 근접하면 NAT가 필요한 연결에서 패킷 손실이 보이기 시작합니다.
문제가 있는 노드의 anetd 포드에서 다음 명령어를 실행하여 이 문제를 식별할 수 있습니다.
외부 트래픽 정책을 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, 1.15
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를 다시 시작합니다.
이그레스 NAT 게이트웨이 기능 미리보기를 사용하는 경우 다른 EgressNATPolicy 객체에 이미 사용되는 egressSourceIP 주소를 지정하는 트래픽 선택 규칙을 설정할 수 있습니다. 이렇게 하면 이그레스 트래픽 라우팅이 충돌합니다.
해결 방법
개발팀과 협력하여 EgressNATPolicy 커스텀 리소스에 egressSourceIP 주소를 지정하기 전에 사용 가능한 유동 IP 주소를 결정합니다.
네트워킹
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
포드 연결 실패 및 역방향 경로 필터링
베어메탈용 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 포드가 그 위치에서 시작됩니다.
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, 1.15
CentOS에서 클러스터 생성 또는 업그레이드 실패
2020년 12월에 CentOS 커뮤니티 및 Red Hat에서 CentOS 지원 종료를 발표했습니다. 2022년 1월 31일에 CentOS 8이 지원 종료(EOL)되었습니다. 지원 종료로 인해 yum 저장소가 CentOS에서 작동하지 않아 클러스터 생성 및 클러스터 업그레이드 작업이 실패합니다. 이는 지원되는 모든 CentOS 버전에 적용되며 베어메탈용 Anthos 클러스터의 모든 버전에 영향을 미칩니다.
RHEL 및 CentOS에서는 클러스터 수준 제한이 100,000개의 엔드포인트로 제한됩니다. Kubernetes 서비스 서비스 2개가 동일한 포드 집합을 참조하는 경우 별도의 엔드포인트 집합 2개로 계산됩니다. RHEL 및 CentOS의 기본 nftable 구현으로 인해 이러한 제한이 발생합니다. 베어메탈용 Anthos 클러스터에 내재된 제한이 아닙니다.
보안
1.10, 1.11, 1.12, 1.13, 1.14, 1.15
컨테이너에서 containerd 및 SELinux로 Dockerfile에 정의된 VOLUME에 쓸 수 없음
containerd를 컨테이너 런타임으로 사용하고 운영체제에 SELinux가 사용 설정된 경우 애플리케이션 Dockerfile에 정의된 VOLUME을 쓰지 못할 수 있습니다. 예를 들어 다음 Dockerfile로 빌드된 컨테이너는 /tmp 폴더에 쓸 수 없습니다.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
이 문제의 영향을 받았는지 확인하려면 문제가 있는 컨테이너를 호스팅하는 노드에서 다음 명령어를 실행합니다.
SELinux에서 컨테이너 런타임이 tmpfs 마운트에 라벨을 설정하지 못하게 하면 포드 생성에 실패하는 경우가 있습니다. 실패하는 경우는 드물지만 SELinux가 Enforcing 모드이고 일부 커널에 있을 때 이러한 오류가 발생할 수 있습니다.
SELinux가 포드 생성 실패의 원인인지 확인하려면 다음 명령어를 사용하여 kubelet 로그의 오류를 확인합니다.
journalctl-ukubelet
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-mavc
이 명령어는 감사 로그에서 액세스 벡터 캐시(AVC) 권한 오류를 검색합니다. 다음 샘플 응답의 avc: denied에서 포드 생성 실패가 SELinux 시행과 관련이 있음을 확인합니다.
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* 문자열이 있는 업그레이드 작업 로그를 확인합니다.
다음 오류 메시지가 있으면 이 문제에 해당합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2023-08-15(UTC)"],[],[]]
대시보드를 선택하고 Anthos 클러스터 노드 상태 대시보드를 삭제합니다.