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

이 페이지에는 베어메탈용 Anthos 클러스터의 알려진 문제가 모두 나와 있습니다. 제품 버전이나 카테고리별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 원하는 필터를 선택하세요.

베어메탈용 Anthos 클러스터 버전을 선택하세요.

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

또는 문제를 검색합니다.

카테고리 식별된 버전 문제 및 해결 방법
네트워킹 1.15.0-1.15.2

CoreDNS orderPolicy가 인식되지 않음

OrderPolicy는 매개변수로 인식되지 않고 사용되지 않습니다. 대신 베어메탈용 Anthos 클러스터에는 항상 Random이 사용됩니다.

이 문제는 CoreDNS 템플릿이 업데이트되지 않아서 orderPolicy가 무시되기 때문에 발생합니다.


해결 방법:

CoreDNS 템플릿을 업데이트하고 수정사항을 적용합니다. 이 수정사항은 업그레이드가 수행될 때까지 지속됩니다.

  1. 기존 템플릿을 수정합니다.
    
    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

우선순위 클래스 누락으로 인해 제거되거나 대기 중인 Anthos Network Gateway 구성요소

kube-system의 네트워크 게이트웨이 포드에서 다음에 요약된 출력 예시와 같이 Pending 또는 Evicted 상태를 표시할 수 있습니다.


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

이러한 오류는 제거 이벤트 또는 노드 리소스로 인해 포드를 예약할 수 없음을 나타냅니다. Anthos Network Gateway 포드에는 PriorityClass가 없으므로 다른 워크로드와 같은 기본 우선순위가 있습니다. 노드에 리소스 제약이 있으면 네트워크 게이트웨이 포드가 삭제될 수 있습니다. 이 동작은 특히 ang-node DaemonSet에 좋지 않습니다. 이러한 포드는 특정 노드에 예약되어야 하며 마이그레이션할 수 없기 때문입니다.


해결 방법:

1.15 이상으로 업그레이드합니다.

단기적으로 문제를 해결하려면 PriorityClass를 수동으로 Anthos Network Gateway 구성요소에 할당합니다. 베어메탈용 Anthos 클러스터 컨트롤러는 클러스터 업그레이드 중과 같은 조정 프로세스 중에 이러한 수동 변경사항을 덮어씁니다.

  • system-cluster-critical PriorityClass를 ang-controller-managerautoscaler 클러스터 컨트롤러 배포에 할당합니다.
  • 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로 업그레이드할 수 없습니다. 클러스터 만들기 작업과 업그레이드 작업 중에 베어메탈용 Anthos 클러스터는 클러스터 이름과 버전을 포함하는 이름으로 상태 점검 리소스를 만듭니다.

  • 버전 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

이 문제는 베어메탈용 Anthos 클러스터 버전 1.14.2 이상에서 해결되었습니다.


해결 방법:

클러스터를 버전 1.15.x로 업그레이드하기 전에 버전 1.14.2 이상으로 업그레이드할 수 없는 경우 부트스트랩 클러스터를 사용하여 버전 1.15.x로 직접 업그레이드할 수 있습니다.


bmctl upgrade cluster --use-bootstrap=true
작업 1.15

버전 1.15 클러스터에서는 중복된 유동 IP 주소를 허용하지 않음

Anthos Network Gateway로는 기존 NetworkGatewayGroup 커스텀 리소스에서 이미 사용된 spec.floatingIPs의 IP 주소가 포함된 새로운 NetworkGatewayGroup 커스텀 리소스를 만들 수 없습니다. 이 규칙은 베어메탈용 Anthos 클러스터 버전 1.15.0 이상에서 웹훅을 통해 적용됩니다. 기존의 중복된 유동 IP 주소는 오류를 일으키지 않습니다. 웹훅에서만 중복 IP 주소가 포함된 새 NetworkGatewayGroups 커스텀 리소스의 생성을 막습니다.

웹훅 오류 메시지는 충돌하는 IP 주소와 이를 이미 사용 중인 기존 커스텀 리소스를 식별합니다.


IP address exists in other gateway with name default

이그레스 NAT 게이트웨이와 같은 고급 네트워킹 기능에 대한 초기 문서에서는 중복 IP 주소에 대해 경고하지 않습니다. 처음에는 조정자에서 default라는 NetworkGatewayGroup 리소스만 인식했습니다. 이제 Anthos Network Gateway가 시스템 네임스페이스에서 모든 NetworkGatewayGroup 커스텀 리소스를 인식합니다. 기존 NetworkGatewayGroup 커스텀 리소스는 그대로 유지됩니다.


해결 방법:

NetworkGatewayGroup 커스텀 리소스를 만들 때에만 오류가 발생합니다.

이 오류를 해결하려면 다음 안내를 따르세요.

  1. 다음 명령어를 사용하여 NetworkGatewayGroups 커스텀 리소스를 나열합니다.
    
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
    
  2. 기존 NetworkGatewayGroup 커스텀 리소스를 열고 충돌하는 유동 IP 주소(spec.floatingIPs)를 삭제합니다.
    
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system RESOURCE_NAME
    
  3. 변경사항을 적용하려면 수정된 커스텀 리소스를 닫고 저장합니다.
Anthos VM 런타임 1.13.7

비공개 레지스트리를 사용하는 1.13.7 클러스터에서 VM이 시작되지 않을 수 있음

비공개 레지스트리를 사용하는 신규 또는 업그레이드된 버전 1.13.7 클러스터에서 Anthos VM 런타임을 사용 설정하면 노드 네트워크에 연결하거나 GPU를 사용하는 VM이 제대로 시작하지 않을 수 있습니다. 이 문제는 vm-system 네임스페이스의 일부 시스템 포드에서 이미지 가져오기 오류가 발생하기 때문에 발생합니다. 예를 들어 VM에서 노드 네트워크를 사용하는 경우 일부 포드에서 다음과 같은 이미지 가져오기 오류를 보고할 수 있습니다.


macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

이 문제는 베어메탈용 Anthos 클러스터 버전 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

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 전달 규칙을 확인합니다.


sudo iptables -L FORWARD

iptablesKUBE-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 포드 두 개가 존재합니다.

이 문제는 베어메탈용 Anthos 클러스터 버전 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.modemanual로 설정)의 경우 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 포드에 비정상 종료 루프가 발생할 수 있습니다. 이 동작으로 인해 노드가 ReadyNotReady 상태 간에 순환하고 클러스터 설치가 실패할 수 있습니다. 이 문제는 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이 포드 변경사항을 관찰하지 못함

이러한 문제로 인해 클러스터가 작동하지 않을 수 있습니다.

이 문제는 베어메탈용 Anthos 클러스터 1.12.9, 1.13.6, 1.14.3 및 이후 출시 버전에서 수정되었습니다. 이러한 최신 출시 버전에는 etcd 버전 3.4.21이 사용됩니다. 베어메탈용 Anthos 클러스터의 모든 이전 버전이 이 문제의 영향을 받습니다.

해결 방법

즉시 업그레이드할 수 없으면 클러스터의 노드 수를 줄여서 클러스터 실패 위험을 완화할 수 있습니다. etcd_network_client_grpc_sent_bytes_total 측정항목이 300MBps 미만이 될 때까지 노드를 삭제합니다.

측정항목 탐색기에서 이 측정항목을 보려면 다음 안내를 따르세요.

  1. Google Cloud 콘솔의 측정항목 탐색기로 이동합니다.

    측정항목 탐색기로 이동

  2. 구성 탭을 선택합니다.
  3. 측정항목 선택을 확장하고 필터 표시줄에 Kubernetes Container를 입력한 후 하위 메뉴를 사용해서 측정항목을 선택합니다.
    1. 활성 리소스 메뉴에서 Kubernetes 컨테이너를 선택합니다.
    2. 활성 측정항목 카테고리 메뉴에서 Anthos를 선택합니다.
    3. 활성 측정항목 메뉴에서 etcd_network_client_grpc_sent_bytes_total을 선택합니다.
    4. 적용을 클릭합니다.
네트워킹 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 객체 상태가 '실패'인 경우 베어메탈용 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 구성이 비어 있습니다.


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에서 해결되었습니다.

해결 방법:

오래된 수명 주기 컨트롤러 배포자 포드를 삭제하려면 다음 안내를 따르세요.

  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는 클러스터 이름입니다.

  2. 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

수신 경로 수가 많아 BGPSession 상태가 계속 변경됨

베어메탈용 Anthos 클러스터 고급 네트워킹은 외부 피어가 많은 수의 경로(약 100개 이상)를 공지할 때 BGP 세션을 올바르게 관리하지 못합니다. 수신 경로가 많으면 노드 로컬 BGP 컨트롤러가 BGP 세션을 조정하는 데 너무 오래 걸려 상태를 업데이트할 수 없습니다. 상태 업데이트 또는 상태 점검이 없으면 세션이 비활성 상태로 삭제됩니다.

문제를 발견하고 나타낼 수 있는 BGP 세션의 바람직하지 않은 동작은 다음과 같습니다.

  • 지속적인 bgpsession 삭제 및 재생성
  • bgpsession.status.stateEstablished로 되지 않음
  • 경로가 공지되지 않거나 공지와 철회를 반복함

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, 1.15

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의 실패

노드 수가 많은 베어메탈용 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 한도를 수동으로 늘리는 것입니다.

  1. metrics-server-operator 축소:
    
    kubectl scale deploy metrics-server-operator --replicas=0
    
  2. 구성을 업데이트하고 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>
  3. 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 커스텀 리소스를 수정할 수 있습니다.

  1. 기존 YAML 정의를 가져옵니다.
    
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다.
  3. 업데이트된 YAML 파일을 다시 적용합니다.
    
    kubectl apply -f stackdriver.yaml
    

kubectl apply의 마지막 단계에서 문제가 발생할 수 있습니다.


해결 방법:

기존 리소스를 변경하는 데 kubectl apply를 사용하지 마세요. 대신 다음 예시와 같이 kubectl edit 또는 kubectl patch를 사용합니다.

  1. Stackdriver 커스텀 리소스를 수정합니다.
    
    kubectl edit stackdriver -n kube-system stackdriver
    
  2. YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다.
  3. 저장 후 편집기를 종료합니다.

kubectl patch를 사용하는 다른 방법:

  1. 기존 YAML 정의를 가져옵니다.
    
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. YAML 파일에서 기능을 사용 설정하거나 구성을 업데이트합니다.
  3. 업데이트된 YAML 파일을 다시 적용합니다.
    
    kubectl patch stackdriver stackdriver --type merge \
        -n kube-system --patch-file stackdriver.yaml
    
로그 기록 및 모니터링 1.12, 1.13, 1.14, 1.15

백로그 청크 손상으로 인한 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에 로그가 표시되지 않습니다.


해결 방법:

이 오류를 해결하려면 다음 단계를 완료합니다.

  1. 손상된 백로그 청크를 식별합니다. 다음 오류 메시지 예시를 검토합니다.
    
    [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 파일을 삭제해야 합니다.
  2. 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 포드가 삭제되었는지 확인합니다.
  3. stackdriver-log-forwarder가 실행 중인 SSH를 사용하여 노드에 연결합니다.
  4. 노드에서 var/log/fluent-bit-buffers/tail.1/의 손상된 *.flb 파일을 모두 삭제합니다.

    손상된 파일이 너무 많아서 스크립트를 적용해 모든 백로그 청크를 삭제하려면 다음 스크립트를 사용합니다.
    1. 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
      
    2. 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
      
    3. cleanup DaemonSet를 삭제합니다.
      
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
          fluent-bit-cleanup
      
    4. 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.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 사용자 클러스터에서 노드 문제 감지기 실패

베어메탈용 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에 오버헤드가 충분하지 않으면 포드가 제거가 많은 기간 동안 클러스터에서 네트워크 불안정이 발생할 수 있습니다.

클러스터가 영향을 받는 경우, 사용자가 클러스터에 새 노드를 추가했는데 사용 가능한 podCIDR이 없을 때 anetd 포드가 다음 오류를 보고합니다.


error="required IPv4 PodCIDR not available"

해결 방법

다음 단계를 사용하여 문제를 해결합니다.

  1. 1.14.1 이상 버전으로 업그레이드합니다.
  2. 워커 노드를 삭제한 후 다시 추가합니다.
  3. 제어 영역 노드를 삭제한 후 클러스터 다운타임을 방지하기 위해 하나씩 다시 추가합니다.
업그레이드 및 업데이트 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 명령어를 다시 실행합니다.

  1. 모든 healthchecks.baremetal.cluster.gke.io 리소스 나열
    
    kubectl get healthchecks.baremetal.cluster.gke.io \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
  2. 이전 단계에서 나열한 모든 healthchecks.baremetal.cluster.gke.io 리소스를 삭제합니다.
    
    kubectl delete healthchecks.baremetal.cluster.gke.io \
        HEALTHCHECK_RESOURCE_NAME \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    
    HEALTHCHECK_RESOURCE_NAME을 상태 확인 리소스의 이름으로 바꿉니다.
  3. bmctl restore cluster 명령어를 다시 실행합니다.
네트워킹 1.12.0

플랫 모드에서 서비스 외부 IP 주소가 작동하지 않음

flatIPv4true로 설정된 클러스터에서는 외부 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

이 문제로 인해 업그레이드 실패가 발생하지는 않지만 제어 영역 노드에서 실행하지 않아야 할 포드가 업그레이드 실패를 일으킬 수 있습니다. 이러한 워크로드 포드는 제어 영역 노드에 부담을 주고 클러스터 불안정을 초래할 수 있습니다.

영향을 받는지 여부 확인

  1. 제어 영역 노드를 찾아서 다음 명령어를 사용합니다.
    
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
        -o name --kubeconfig KUBECONFIG_PATH
    
  2. 노드에서 taint 목록을 확인하려면 다음 명령어를 사용합니다.
    
    kubectl describe node NODE_NAME \
        --kubeconfig KUBECONFIG_PATH
    

    필수 taint가 어느 하나도 나열되지 않았으면 영향을 받은 것입니다.

해결 방법

영향을 받는 버전 1.14.0 클러스터의 각 제어 영역 노드에 대해 다음 단계를 수행하여 적절한 기능을 복원합니다. 이러한 단계는 node-role.kubernetes.io/master:NoSchedule taint 및 관련 포드에 적용됩니다. 제어 영역 노드에 PreferNoSchedule taint를 사용하려면 그에 따라 단계를 조정합니다.

작업, Anthos VM 런타임 1.11, 1.12, 1.13, 1.14, 1.15

업로드 오류와 함께 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에서 리소스를 삭제합니다.

해결 방법

수동으로 관리되는 컬렉션 리소스를 보존하려면 다음 안내를 따르세요.

  1. 기존 PodMonitoring 커스텀 리소스를 모두 백업합니다.
  2. 클러스터를 버전 1.12로 업그레이드하고 Managed Service for Prometheus를 사용 설정합니다.
  3. 업그레이드된 클러스터에 PodMonitoring 커스텀 리소스를 다시 배포합니다.
업그레이드 및 업데이트 1.13

Docker 컨테이너 런타임의 일부 버전 1.12 클러스터를 버전 1.13으로 업그레이드할 수 없음

Docker 컨테이너 런타임을 사용하는 버전 1.12 클러스터에 다음 주석이 누락되었으면 이를 버전 1.13으로 업그레이드할 수 없습니다.


baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

이 문제의 영향을 받는 경우에는 bmctlbmctl-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

해결 방법

실패한 작업은 아티팩트를 생성하지만 클러스터는 작동하지 않습니다. 이 문제의 영향을 받는 경우 다음 단계에 따라 아티팩트를 정리하고 클러스터를 만드세요.

설치, 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.12의 기본값인 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에 모든 제어 영역 구성요소를 루트가 아닌 사용자로 실행하는 루트 없는 제어 영역 기능이 도입되었습니다. 모든 구성요소를 루트가 아닌 사용자로 실행하면 0077umask 설정이 더 제한적인 시스템에서는 설치 또는 업그레이드 실패가 발생할 수 있습니다.


해결 방법

제어 영역 노드를 재설정하고 모든 제어 영역 머신에서 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 서비스 계정 사용자 인증 정보 또는 연결된 권한을 확인하지 않습니다.

설치 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

애플리케이션 기본 사용자 인증 정보 및 bmctl

bmctlglobal로 설정되지 않은 경우 애플리케이션 기본 사용자 인증 정보(ADC)를 사용하여 cluster spec에서 클러스터 작업의 위치 값을 검사합니다.


해결 방법

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-segmentationtx-udp_tnl-csum-segmentation 플래그를 사용 중지로 설정해야 합니다. 이 플래그는 vSphere 드라이버 VMXNET3에서 수행하는 하드웨어 세분화 오프로드와 관련이 있으며 베어메탈용 Anthos 클러스터의 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 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 명령줄 인터페이스를 사용하여 haproxykeepalived 컨테이너가 실행 중인지 확인합니다.


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 런타임을 사용 중지하려면 다음 안내를 따르세요.

  1. VMRuntime 커스텀 리소스를 수정합니다.
    
    kubectl edit vmruntime
    
  2. 사양에서 enabledfalse로 설정합니다.
    
    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      ...
    
  3. 편집기에서 커스텀 리소스를 저장합니다.
  4. 클러스터 업그레이드가 완료되면 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}은 문제 리소스의 이름입니다.


해결 방법

로그에 이러한 오류가 있으면 다음 단계를 완료합니다.

  1. kubectl edit를 사용하여 로그 메시지에 포함된 리소스에서 kubectl.kubernetes.io/last-applied-configuration 주석을 삭제합니다.
  2. 변경사항을 저장하고 리소스에 적용합니다.
  3. 클러스터 업그레이드를 다시 시도합니다.
업그레이드 및 업데이트 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...

해결 방법

업그레이드 차단을 해제하려면 업그레이드하려는 클러스터에 대해 다음 명령어를 실행합니다.


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.13, 1.14, 1.15

노드가 오프라인 상태일 때 노드 드레이닝을 시작할 수 없음

노드가 베어메탈용 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 참조)이 관리자 클러스터 이름인 경우 지정된 사용자 클러스터가 영향을 받습니다.


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)로 함수를 복원합니다.

  1. 사용자 클러스터 kubeconfig 파일을 찾습니다. 클러스터를 만들면 베어메탈용 Anthos 클러스터가 관리자 워크스테이션에 kubeconfig 파일을 생성합니다. 기본적으로 이 파일은 bmctl-workspace/USER_CLUSTER_NAME 디렉터리에 있습니다.
  2. kubeconfig가 올바른 사용자 클러스터 kubeconfig인지 확인하세요.
    
    kubectl get nodes \
        --kubeconfig PATH_TO_GENERATED_FILE
    
    PATH_TO_GENERATED_FILE를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다. 응답으로 사용자 클러스터의 노드에 대한 세부정보가 반환됩니다. 클러스터의 머신 이름이 올바른지 확인합니다.
  3. 다음 명령어를 실행하여 관리자 클러스터에서 손상된 kubeconfig 파일을 삭제합니다.
    
    kubectl delete secret \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig
    
  4. 다음 명령어를 실행하여 올바른 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

루트가 아닌 로그인 사용자로 스냅샷 만들기

containerd를 컨테이너 런타임으로 사용하는 경우 스냅샷을 루트가 아닌 사용자로 실행하려면 /usr/local/bin이 사용자의 PATH에 있어야 합니다. 그렇지 않으면 crictl: command not found 오류가 표시되면서 실패합니다.

루트 사용자로 로그인되어 있지 않으면 sudo가 스냅샷 명령어를 실행하는 데 사용됩니다. sudo PATH는 루트 프로필과 다를 수 있으며 /usr/local/bin을 포함할 수 없습니다.


해결 방법

/usr/local/bin을 포함하도록 /etc/sudoerssecure_path를 업데이트합니다. 또는 다른 /bin 디렉터리에 crictl의 심볼릭 링크를 만듭니다.

작업, Anthos VM 런타임 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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'

해결 방법:

로그 기록 및 모니터링 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

예기치 않은 모니터링 청구

베어메탈용 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로 업그레이드할 수 없으면 다음 단계를 수행합니다.

    1. 원치 않는 결제가 있는 소스 포드와 서비스를 찾습니다.
      
      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"'
      
    2. 포드나 서비스에서 prometheus.io/scrap=true 주석을 삭제합니다.
    로그 기록 및 모니터링 1.11, 1.12, 1.13, 1.14, 1.15

    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 이상에서 업데이트됩니다.


    해결 방법

    대체 측정항목으로 마이그레이션하려면 다음 단계를 따르세요.

    1. Google Cloud 콘솔에서 Monitoring을 선택하거나 다음 버튼을 클릭합니다.
      Monitoring으로 이동
    2. 탐색 창에서 대시보드를 선택하고 Anthos 클러스터 노드 상태 대시보드를 삭제합니다.
    3. 샘플 라이브러리 탭을 클릭하고 Anthos 클러스터 노드 상태 대시보드를 재설치합니다.
    4. 알림 정책 만들기의 안내에 따라 업데이트된 node-cpu-usage-high.json 정책 정의 파일을 사용하여 정책을 만듭니다.
    로그 기록 및 모니터링 1.10, 1.11

    stackdriver-log-forwarderCrashloopBackOff 오류가 있음

    경우에 따라 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 파일 경로로 바꿉니다.

    1. 모든 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 포드가 삭제되었는지 확인합니다.
    2. 다음 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
      
    3. 다음 명령어를 사용하여 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
      
      두 명령어의 출력은 클러스터에 있는 노드 수와 동일해야 합니다.
    4. cleanup DaemonSet를 삭제합니다.
      
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system delete ds fluent-bit-cleanup
      
    5. 로그 전달자 포드를 다시 시작합니다.
      
      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

    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 이상으로 업그레이드하세요.

    업그레이드할 수 없는 경우 다음 단계를 수행하여 문제를 해결하세요.

    1. 수정할 stackdriver 리소스를 엽니다.
      
      kubectl -n kube-system edit stackdriver stackdriver
      
    2. 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
      
    3. 변경사항을 저장하고 텍스트 편집기를 닫습니다.
    4. 변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.
      
      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, 1.15

    너무 많은 동시 연결로 인한 NAT 오류

    클러스터의 특정 노드에 대해 노드 IP 주소는 클러스터 외부의 주소로 라우팅된 패킷에 대해 네트워크 주소 변환(NAT)을 제공합니다. 마찬가지로 인바운드 패킷이 번들 부하 분산(spec.loadBalancer.mode: bundled)을 사용하도록 구성된 부하 분산 노드에 진입할 때 소스 네트워크 주소 변환(SNAT)은 패킷을 IP 노드 주소로 라우팅하며 그런 다음에 패킷이 백엔드 포드로 전달됩니다.

    베어메탈용 Anthos 클러스터에 사용되는 NAT의 포트 범위는 3276865535입니다. 이 범위에 따라 해당 노드에서 프로토콜별 병렬 연결 수가 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, 1.15

    번들 레이어 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, 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를 다시 시작합니다.

    
    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    ANETD_XYZanetd 포드의 이름으로 바꿉니다.

    네트워킹 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    중복된 egressSourceIP 주소

    이그레스 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_filter0으로 다시 설정합니다. anetd 포드를 다시 시작하려면 다음 명령어를 사용하여 anetd 포드를 찾아 삭제하면 새 anetd 포드가 그 위치에서 시작됩니다.

    
    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    ANETD_XYZanetd 포드의 이름으로 바꿉니다.

    네트워킹 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    부트스트랩(종류) 클러스터 IP 주소 및 클러스터 노드 IP 주소 겹침

    192.168.122.0/2410.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 클러스터의 모든 버전에 영향을 미칩니다.


    해결 방법

    운영체제 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    운영체제 엔드포인트 제한사항

    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
    

    이 문제의 영향을 받았는지 확인하려면 문제가 있는 컨테이너를 호스팅하는 노드에서 다음 명령어를 실행합니다.

    
    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, 1.15

    포드 생성 중 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, 1.15

    containerd 서비스

    bmctl reset 명령어는 containerd 구성 파일 또는 바이너리를 삭제하지 않습니다. containerd systemd 서비스는 계속 실행 중인 상태입니다. 이 명령어는 노드에 예약된 포드를 실행하는 컨테이너를 삭제합니다.

    업그레이드 및 업데이트 1.10, 1.11, 1.12

    클러스터 업그레이드 후 노드 문제 감지기가 기본적으로 사용 설정되지 않음

    베어메탈용 Anthos 클러스터를 업그레이드하면 노드 문제 감지기가 기본적으로 사용 설정되지 않습니다. 이 문제는 출시 버전 1.10에서 1.12.1로 업그레이드하는 경우에 적용되며 출시 버전 1.12.2에서 해결되었습니다.


    해결 방법:

    노드 문제 감지기를 사용 설정하려면 다음 안내를 따르세요.

    1. node-problem-detector systemd 서비스가 노드에서 실행 중인지 확인합니다.
      1. SSH 명령어를 사용하여 노드에 연결합니다.
      2. node-problem-detector systemd 서비스가 노드에서 실행 중인지 확인합니다.
        
        systemctl is-active node-problem-detector
        
        명령어 결과에 inactive가 표시되면 노드 문제 감지기가 노드에서 실행되지 않은 것입니다.
    2. 노드 문제 감지기를 사용 설정하려면 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 서비스를 사용하는 경우 다 해결 방법이 도움이 될 수 있습니다.

    1. 워커 노드(제어 영역 노드 아님)에서 실행
    2. 서비스 사양의 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 is not a valid feature name.
    ...
    

    해결 방법:

    이 문제를 해결하려면 다음 안내를 따르세요.

    1. 관리자 워크스테이션에서 다음 명령어를 실행합니다.
      
      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'
      
    2. 클러스터 업그레이드를 다시 시도합니다.
    추가 지원이 필요하면 Google 지원에 문의하세요.