클러스터 문제 진단

gkectl 도구에는 gkectl diagnose cluster 및 gkectl diagnose snapshot 등 문제를 해결하는 데 사용할 수 있는 두 가지 명령어가 있습니다. 명령어는 관리자 클러스터와 사용자 클러스터 모두에서 작동합니다. 이 문서에서는 gkectl diagnose 명령어를 사용하여 클러스터의 문제를 진단하는 방법을 보여줍니다.

gkectl diagnose snapshot 명령어를 사용하여 Cloud Customer Care의 문제 진단에 도움이 되는 스냅샷을 만드는 방법에 대한 자세한 내용은 클러스터 진단을 위한 스냅샷 만들기를 참조하세요.

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

gkectl diagnose cluster

이 명령어는 클러스터에서 상태 점검을 수행하고 오류를 보고합니다. 이 명령어는 다음 구성요소에서 상태 점검을 실행합니다.

  • vCenter
    • 사용자 인증 정보
    • DRS
    • 안티어피니티 그룹
    • 네트워크
    • 버전
    • 데이터센터
    • Datastore
    • ResourcePool
    • 폴더
    • 네트워크
  • 부하 분산기(F5, Seesaw 또는 수동)
  • 사용자 클러스터 및 노드 풀
  • 클러스터 객체
  • 사용자 클러스터의 Konnectivity 서버 준비
  • 머신 객체 및 해당 클러스터 노드
  • kube-system 및 gke-system 네임스페이스의 포드
  • 제어 영역
  • 클러스터의 vSphere 영구 볼륨
  • 사용자 및 관리자 클러스터 vCPU(가상 CPU)와 메모리 경합 신호
  • 사용자 및 관리자 클러스터 ESXi가 사전 구성된 호스트 CPU 사용량 및 메모리 사용량 경보
  • 하루 중 특정 시간(TOD)
  • Dataplane V2가 사용 설정된 클러스터의 노드 네트워크 정책
  • Dataplane V2 노드 에이전트의 전반적인 상태

관리자 클러스터 진단

관리자 클러스터를 진단하려면 관리자 클러스터 경로를 지정합니다.

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

gkectl diagnose cluster 명령어에서 반환된 출력 예시는 다음과 같습니다.

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

대상 클러스터의 가상 IP 주소(VIP)에 문제가 있는 경우 --config 플래그를 사용하여 관리자 클러스터 구성 파일을 제공하여 디버깅 정보를 더 제공합니다.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

CLUSTER_CONFIG를 관리자 또는 사용자 클러스터 구성 파일의 경로로 바꿉니다.

다음 출력 예시에서는 이제 gkectl diagnose cluster 명령어가 클러스터에 올바르게 연결하고 문제를 확인할 수 있음을 보여줍니다.

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

사용자 클러스터 진단

사용자 클러스터를 진단하려면 사용자 클러스터 이름을 지정해야 합니다. 사용자 클러스터의 이름을 가져와야 하는 경우 다음 명령어를 실행합니다.

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.

다음과 같이 구성 파일과 함께 사용자 클러스터의 이름을 지정합니다.

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

USER_CLUSTER_NAME을 사용자 클러스터 이름으로 바꿉니다.

gkectl diagnose cluster 명령어에서 반환된 출력 예시는 다음과 같습니다.

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

가상 머신 상태 진단

가상 머신을 만드는 중에 문제가 발생하면 gkectl diagnose cluster를 실행하여 가상 머신 상태를 진단합니다.

출력은 다음과 비슷합니다.


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot

문제 해결

다음 표에서는 gkectl diagnose cluster 명령어 실행과 관련된 문제에 대해 가능한 몇 가지 해결 방법을 보여줍니다.

문제가능한 원인해결 방법
관리자 클러스터 또는 사용자 클러스터에서 Kubernetes API 서버에 연결할 수 없습니다. 가상 머신 상태 OOB(Out-Of-Box) 메모리 지연 시간 그래프를 확인하세요. 메모리 지연 시간이 0에 가까우면 이상적입니다. 메모리 경합은 CPU 경합을 증가시킬 수도 있으며, 스와핑이 포함되어 있기 때문에 CPU 준비 상태 그래프가 급증할 수 있습니다. 물리적 메모리를 늘리세요. 다른 옵션은 VMware 문제 해결 제안을 참조하세요.
노드 풀 생성 시간이 타임아웃됩니다. VMDK 높은 읽기/쓰기 지연 시간. 가상 디스크 읽기 및 쓰기 지연 시간의 VM 상태 OOB를 확인하세요. VMware에 따르면 총 지연 시간이 20ms보다 긴 경우 문제가 있는 것입니다. 디스크 성능 문제에 대한 VMware 솔루션을 참조하세요.

오류 BundleUnexpectedDiff개

Google Distributed Cloud 번들에서 관리하는 Kubernetes Cluster API 리소스가 실수로 수정될 수 있으며 이로 인해 시스템 구성요소에 장애가 발생하거나 클러스터 업그레이드 또는 업데이트가 실패할 수 있습니다.

Google Distributed Cloud 버전 1.13 이상에서 onprem-user-cluster-controller는 주기적으로 객체 상태를 확인하고 로그와 이벤트를 통해 원하는 상태와의 예기치 않은 차이를 보고합니다. 이러한 객체에는 사용자 클러스터 제어 영역과 서비스 및 DaemonSet과 같은 부가기능이 포함됩니다.

다음 출력 예시는 예기치 않은 차이 이벤트를 보여줍니다.

 Type     Reason                 Age    From                              Message
 ----     ------                 ----   ----                              -------
 Warning  BundleUnexpectedDiff   13m    onpremusercluster/ci-bundle-diff  Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.

다음 출력 예시는 onprem-user-cluster-controller에서 생성한 로그를 보여줍니다.

2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252       1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff:   map[string]string{
2022-08-06T02:54:42.701376406Z -    "mesh": (
2022-08-06T02:54:42.701381190Z -        """
2022-08-06T02:54:42.701385438Z -        defaultConfig:
2022-08-06T02:54:42.701389350Z -          discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z -        """
2022-08-06T02:54:42.701453099Z -    ),
2022-08-06T02:54:42.701456286Z -    "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z +    "test-key":     "test-data",
2022-08-06T02:54:42.701462434Z   }

이벤트와 로그가 클러스터 작업을 차단하지 않습니다. 다음 클러스터 업그레이드에서 원하는 상태와 예기치 않은 차이가 있는 객체를 덮어씁니다.

다음 단계

추가 지원이 필요하면 Cloud Customer Care에 문의하세요.