Diagnosticar problemas de cluster.

A ferramenta gkectl tem dois comandos para solucionar problemas com clusters: gkectl diagnose cluster e gkectl diagnose snapshot. Os comandos funcionam com clusters de administrador e usuário. Neste documento, mostramos como usar gkectl diagnose para diagnosticar problemas nos clusters.

Para mais informações sobre como usar o comando gkectl diagnose snapshot para criar snapshots que ajudam o Cloud Customer Care a diagnosticar problemas; consulte Criar snapshots para diagnosticar clusters.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

gkectl diagnose cluster

Esse comando executa verificações de integridade no cluster e relata erros. O executa verificações de integridade nos seguintes componentes:

  • vCenter
    • Credencial
    • DRS
    • Grupos antiafinidade
    • Rede
    • Versão
    • Data center
    • Datastore
    • ResourcePool
    • Pasta
    • Rede
  • Balanceador de carga (F5, Seesaw ou manual)
  • Cluster de usuários e pools de nós
  • Objetos de cluster
  • Disponibilidade do servidor de conectividade do cluster de usuários
  • Objetos de máquina e os nós de cluster correspondentes
  • Pods nos namespaces kube-system e gke-system
  • Plano de controle
  • Volumes permanentes do vSphere no cluster
  • Sinais de contenção de memória e vCPU do usuário e administrador (CPU virtual)
  • O cluster de usuários e administradores ESXi pré-configurou os alarmes de uso de CPU do host e da memória.
  • Hora do dia (TOD)
  • Política de rede de nós para um cluster com o Dataplane V2 ativado
  • Integridade geral do agente do nó do Dataplane V2

Diagnosticar um cluster de administrador

Para diagnosticar um cluster de administrador, especifique o caminho para esse cluster:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo de configuração do cluster de administrador.

O exemplo de saída a seguir é retornado do gkectl diagnose cluster comando:

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!

Se houver um problema com um endereço IP virtual (VIP) no cluster de destino, use a sinalização --config para fornecer o arquivo de configuração do cluster de administrador para fornecem mais informações de depuração.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

Substitua CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de administrador ou de usuário.

O exemplo de saída a seguir mostra que o comando gkectl diagnose cluster Agora é possível se conectar corretamente ao cluster e verificar se há problemas:

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]"...
...

Diagnosticar um cluster de usuário

Para diagnosticar um cluster de usuário, especifique o nome dele. Se você precisar Para receber o nome de um cluster de usuário, execute o seguinte comando:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

Especifique o nome do cluster de usuário junto com o arquivo de configuração da seguinte maneira:

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

Substitua USER_CLUSTER_NAME pelo nome do cluster de usuário.

O exemplo de saída a seguir é retornado do gkectl diagnose cluster comando:

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!

Diagnosticar o status da máquina virtual

Se surgir um problema com a criação da máquina virtual, execute gkectl diagnose cluster para receber um diagnóstico do status da máquina virtual.

O resultado será assim:


- 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

Resolver problemas

A tabela a seguir descreve algumas possíveis soluções para problemas na execução o comando gkectl diagnose cluster:

ProblemaCausas possíveisResolução
O servidor da API Kubernetes não está acessível, seja para o cluster de administração ou para clusters de usuários. Verifique os gráficos de latência de memória (OBB, na sigla em inglês) de integridade da máquina virtual, que preferencialmente têm uma latência de memória por volta de zero. A contenção de memória também pode aumentar a contenção da CPU e os gráficos de prontidão da CPU podem ter um pico, porque haverá interação. Aumente a memória física. Para ver outras opções, consulte Sugestões de solução de problemas do VMware.
A criação do pool de nós expira. Alta latência de leitura/gravação do VMDK. Verifique a integridade da integridade da VM para a latência de leitura e gravação do disco virtual. De acordo com o VMware, uma latência total maior que 20 ms indica um problema. Consulte Soluções de VMware para problemas de desempenho do disco.

BundleUnexpectedDiff erro

O recurso da API Kubernetes Cluster gerenciado por um pacote do Google Distributed Cloud sejam modificados por acidente, o que pode causar falha nos componentes do sistema no upgrade do cluster ou falha na atualização.

Na versão 1.13 e mais recentes do Google Distributed Cloud, O onprem-user-cluster-controller verifica periodicamente o status dos objetos. relata diferenças inesperadas do estado desejado por meio de registros e eventos. Esses objetos incluem o plano de controle do cluster do usuário e complementos, como Serviços e DaemonSets.

O exemplo de saída a seguir mostra um evento de diferença inesperado:

 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.

A saída de exemplo a seguir mostra registros gerados pelo 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   }

Os eventos e registros não bloqueiam a operação do cluster. Os objetos que têm diferenças inesperadas do estado desejado são substituídas upgrade do cluster.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.