Diagnostique problemas de clusters

A ferramenta gkectl tem dois comandos para resolver problemas com clusters: gkectl diagnose cluster e gkectl diagnose snapshot. Os comandos funcionam com clusters de administrador e de utilizador. Este documento mostra como usar o comando gkectl diagnose para diagnosticar problemas nos seus clusters.

Tenha em atenção a seguinte limitação com os clusters avançados:

• Versão 1.31: os comandos gkectl diagnose não são suportados em clusters avançados.
• Versão 1.32 e superior: os comandos gkectl diagnose são suportados em clusters avançados.

Para mais informações sobre como usar o comando gkectl diagnose snapshot para criar instantâneos que podem ajudar o apoio técnico ao cliente do Google Cloud a diagnosticar problemas, consulte o artigo Crie instantâneos para diagnosticar clusters.

Dica: depois de executar um comando gkectl diagnose, use o Gemini Cloud Assist (pré-visualização) para ajudar a compreender o resultado. Por exemplo, pode colar o relatório gerado ou mensagens de erro específicas no Gemini Cloud Assist e pedir-lhe que explique as potenciais causas de quaisquer problemas e recomende os passos seguintes.

gkectl diagnose cluster

Este comando executa verificações de estado no cluster e comunica erros. O comando executa verificações de funcionamento nos seguintes componentes:

• vCenter
  • Credencial
  • DRS
  • Grupos de antiafinidade
  • Rede
  • Versão
  • Centro de dados
  • Armazenamento de dados
  • ResourcePool
  • Pasta
  • Rede
• Balanceador de carga (F5, Seesaw ou manual)
• Cluster de utilizadores e node pools
• Agrupe objetos
• Prontidão do servidor de conetividade do cluster de utilizadores
• Objetos de máquinas e os nós de cluster correspondentes
• Pods nos espaços de nomes kube-system e gke-system
• Plano de controlo
• Volumes persistentes do vSphere no cluster
• Sinais de contenção de memória e vCPU (CPU virtual) do cluster de utilizadores e de administrador
• ESXi do cluster de utilizadores e de administrador alarmes de utilização de CPU do anfitrião e utilização de memória pré-configurados.
• Hora do dia (TOD)
• Política de rede de nós para um cluster com o Dataplane V2 ativado
• Estado geral do agente do nó do plano de dados V2

Diagnostique um cluster de administrador

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

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de administrador.

A seguinte saída de exemplo é devolvida pelo comando 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!

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

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

Substitua CLUSTER_CONFIG pelo caminho do ficheiro de configuração do cluster de administrador ou de utilizador.

Nota: defina sempre --kubeconfig para o caminho do ficheiro kubeconfig do cluster de administrador, independentemente de estar a diagnosticar um cluster de administrador ou de utilizador.

O exemplo de resultado seguinte mostra que o comando gkectl diagnose cluster já consegue ligar-se corretamente ao cluster e verificar se existem 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]"...
...

Diagnostique um cluster de utilizadores

Para diagnosticar um cluster de utilizadores, tem de especificar o nome do cluster de utilizadores. Se precisar de obter o nome de um cluster de utilizadores, execute o seguinte comando:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de utilizadores.

Especifique o nome do cluster de utilizadores juntamente com o ficheiro de configuração da seguinte forma:

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

Substitua USER_CLUSTER_NAME pelo nome do cluster de utilizadores.

A seguinte saída de exemplo é devolvida pelo comando 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!

Diagnostique o estado da máquina virtual

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

O resultado é semelhante ao seguinte:

- 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 seguinte descreve algumas resoluções possíveis para problemas com a execução do comando gkectl diagnose cluster:

Problema	Causas possíveis	Resolução
O servidor da API Kubernetes não está acessível, quer para o cluster de administrador, quer para os clusters de utilizador.	Verifique os gráficos de latência de memória OOB (out-of-box) do estado de funcionamento da máquina virtual, que, idealmente, devem ter uma latência de memória próxima de zero. A contenção de memória também pode aumentar a contenção da CPU e os gráficos de disponibilidade da CPU podem ter um pico, uma vez que haverá troca envolvida.	Aumentar a memória física. Para outras opções, consulte as sugestões de resolução de problemas do VMware.
O tempo limite da criação do Nodepool é excedido.	Latência de leitura/escrita elevada do VMDK. Verifique o estado de funcionamento da VM OOB para a latência de leitura e escrita do disco virtual. De acordo com a VMware, uma latência total superior a 20 ms indica um problema.	Consulte as soluções da VMware para problemas de desempenho do disco.

Erro BundleUnexpectedDiff

O recurso da API Kubernetes Cluster gerido por um pacote do Google Distributed Cloud pode ser modificado acidentalmente, o que pode causar uma falha dos componentes do sistema ou uma falha na atualização do cluster.

Na versão 1.13 e posteriores do Google Distributed Cloud, o onprem-user-cluster-controller verifica periodicamente o estado dos objetos e comunica quaisquer diferenças inesperadas do estado pretendido através de registos e eventos. Estes objetos incluem o plano de controlo do cluster de utilizadores e suplementos, como Serviços e DaemonSets.

O exemplo de saída seguinte 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.

O exemplo de resultado seguinte mostra os registos 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 os registos não bloqueiam a operação do cluster. Os objetos que têm diferenças inesperadas em relação ao estado pretendido são substituídos na atualização do cluster seguinte.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

• Requisitos para abrir um registo de apoio técnico.
• Ferramentas para ajudar a resolver problemas, como registos e métricas.
• Componentes suportados, versões e funcionalidades do Google Distributed Cloud para VMware (apenas software).