Se você não conseguir provisionar um cluster TKG 2, revise esta lista de erros comuns para solucionar problemas.

Verificar logs da API do cluster

Se você não puder criar um cluster TKG, verifique se o CAPW/V está funcionando.

O controlador CAPW/V é a implementação específica da infraestrutura da API de cluster. O CAPW/V é ativado por meio de Supervisor. O CAPW/V é um componente do TKG e é responsável por gerenciar o ciclo de vida dos clusters do TKG.

O CAPW/V é responsável por criar e atualizar o VirtualNetwork. A criação dos nós de cluster somente poderá ser realizada se a VirtualNetwork estiver pronta. O fluxo de trabalho de criação do cluster foi aprovado nessa fase?

O CAPW/V é responsável por criar e atualizar o VirtualMachineService. O VirtualMachineService foi criado com êxito? Obteve o IP externo? O fluxo de trabalho de criação do cluster foi aprovado nessa fase?

Para responder a essas perguntas, verifique o log da API de cluster da seguinte maneira: 
kubectl config use-context tkg-cluster-ns
kubectl get pods -n vmware-system-capw  | grep capv-controller
kubectl logs -n vmware-system-capw -c manager capv-controller-manager-...

Erros ao aplicar o YAML do cluster TKG

Se você receber erros ao aplicar o YAML do cluster TKG, solucione o problema da seguinte maneira.
A rede de cluster não está no estado correto
Entenda o fluxo de trabalho de provisionamento de cluster do TKG:
  • O CAPV cria um objeto VirtualNetwork para cada rede de cluster do TKG.
  • Se Supervisor estiver configurado com a rede NSX, o NCP observará os objetos VirtualNetwork e criará um roteador NSX de Camada 1 e um segmento NSX para cada VirtualNetwork.
  • O CAPV verifica o status do VirtualNetwork e, quando estiver pronto, prossegue para a próxima etapa do fluxo de trabalho.

O controlador de serviço de VM está procurando objetos personalizados criados pelo CAPV e usa essas especificações para criar e configurar as VMs que compõem o cluster TKG.

NSX Container Plugin (NCP) é um controlador que observa os recursos de rede adicionados ao etcd por meio da API Kubernetes e orquestra a criação de objetos correspondentes em NSX.

Cada um desses controladores é executado como pods do Kubernetes no plano de controle Supervisor. Para solucionar problemas de rede, verifique o log do Controlador CAPV, o log do Serviço de VM e o log do NCP.

Verifique os logs do contêiner, em que name-XXXX é o nome exclusivo do pod quando você executa 
kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce
Contagem de nós do plano de controle inválida

O cluster TKG em Supervisor é compatível com 1 ou 3 nós do plano de controle. Se você inserir um número diferente de réplicas, o provisionamento do cluster falhará.

Classe de armazenamento inválida para a VM do plano de controle/worker
Execute o seguinte comando: 
kubectl describe ns <tkg-clsuter-namesapce>

Certifique-se de que uma classe de armazenamento tenha sido atribuída ao namespace no qual você está tentando criar o cluster TKG. É preciso que haja um ResourceQuota em vSphere Namespace fazendo referência a essa classe de armazenamento, e a classe de armazenamento precisa existir em Supervisor.

Certifique-se de que o nome corresponda à classe de armazenamento presente em Supervisor. Execute kubectl get storageclasses Supervisor como administrador vSphere. O WCP pode transformar o nome ao aplicar o perfil de armazenamento a Supervisor (por exemplo, os hífens se tornam sublinhados).

Classe de VM inválida

Certifique-se de que o valor fornecido no YAML do cluster corresponda a uma das classes de VM retornadas por kubectl get virtualmachineclassbindings. Somente classes associadas podem ser usadas por um cluster TKG. Uma classe de VM é associada quando você a adiciona ao vSphere Namespace.

O comando kubectl get virtualmachineclasses retorna todas as classes de VM em Supervisor, mas somente aquelas que estão associadas podem ser usadas.

Não é possível encontrar distribuições TKR
Se você vir um erro semelhante ao seguinte: 
“Error from server (unable to find Kubernetes distributions): 
admission webhook “version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” 
denied the request: unable to find Kubernetes distributions”

Isso provavelmente ocorre devido a um problema na biblioteca de conteúdo. Para listar o que você tem disponível, use o comando kubectl get virtualmachineimages -A. O resultado é o que está disponível e sincronizado ou carregado na sua biblioteca de conteúdo.

Para o TKG em Supervisor, há novos nomes de TKR que são compatíveis com a nova API do TKR. Você precisa nomear cada TKR corretamente na biblioteca de conteúdo.

Nome na biblioteca de conteúdo: photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

Nome correspondente na especificação do cluster TKG: version: v1.23.8+vmware.2-tkg.1-zshippable

TKG YAML é aplicado, mas nenhuma VM é criada

Se o YAML do cluster do TKG 2 for válido e aplicado, mas as VMs do nó não forem criadas, solucione o problema da seguinte maneira.
Verificar recursos CAPI/CAPV

Verifique se a TKG criou os recursos de nível CAPI/CAPV.

  • Verifique se o CAPV criou os recursos do VirtualMachine.
  • Verifique os logs do Operador da VM para ver por que a VM não foi criada. Por exemplo, a implantação do OVF pode ter falhado devido a recursos insuficientes no host ESX.
  • Verifique os logs do operador CAPV e VM.
  • Verificar logs do NCP O NCP é responsável por realizar o VirtualNetwork, o VirtualNetworkInterface e o LoadBalancer para o plano de controle. Se houver algum erro relacionado a esses recursos, isso poderá ser um problema.
Erro de serviços de máquina virtual
Erro de serviços de máquina virtual
  • Execute kubectl get virtualmachineservices no seu namespace
  • Um Serviço de Máquina Virtual foi criado?
  • Execute kubectl describe virtualmachineservices no seu namespace
  • Há erros relatados no Serviço de Máquina Virtual?
Erro de rede virtual

Execute kubectl get virtualnetwork no seu namespace.

A Rede Virtual foi criada para este cluster?

Execute kubectl describe virtual network no seu namespace.

A Interface de Rede Virtual foi criada para a VM?

O plano de controle do cluster TKG não está em execução

Se o plano de controle do TKG não estiver em execução, verifique se os recursos estavam prontos quando o erro ocorreu. É um plano de controle do Join Node que não está ativo ou é um Init Node? Além disso, verifique se a ID do Provedor não está definida no objeto de nó.
Verificar se os recursos estavam prontos quando ocorreu o erro

Além de procurar logs, a verificação do status dos objetos relacionados ControlPlaneLoadBalancer ajudará você a entender se os recursos estavam prontos quando ocorreu o erro. Consulte solução de problemas de rede.

É um plano de controle do Join Node que não está ativo ou é um Init Node?

Às vezes, as junções de nós não funcionam corretamente. Observe os logs do nó para uma determinada VM. O cluster pode estar sem os nós do trabalhador e do plano de controle se o nó init não for ativado com êxito.

A ID do provedor não está definida no objeto de nó

Se a VM for criada, verifique se ela tem IPs e, em seguida, examine os logs do cloud-init (os comandos kubeadm são executados corretamente)

Verifique os logs do controlador CAPI para ver se há algum problema. Você pode verificar isso usando kubectl get nodes no cluster TKG e, em seguida, verificar se a ID do provedor existe no objeto de nó.

Nós de trabalhador do TKG não são criados

Se o cluster TKG e as VMs do plano de controle forem criados, mas nenhum trabalhador for criado ou nenhum outro objeto de máquina virtual for criado, tente o seguinte: 
kubectl describe cluster CLUSTER-NAME

Verifique se há recursos de máquina virtual no namespace. Houve outros criados?

Caso contrário, verifique os logs do CAPV para ver por que ele não está criando os outros objetos de máquina virtual dados de inicialização não disponíveis.

Se o CAPI não puder se comunicar com o plano de controle do cluster TKG por meio do balanceador de carga, seja NSX com o IP da VM do nó ou VDS com o balanceador de carga externo, obtenha o kubeconfig do cluster TKG usando o segredo no namespace:

Obtenha o kubeconfig do cluster TKG usando o segredo no namespace: 
kubectl get secret -n <namespace> <tkg-cluster-name>-kubeconfig -o jsonpath='{.data.value}' | base64 -d 
> tkg-cluster-kubeconfig; kubectl --kubeconfig tkg-cluster-kubeconfig get pods -A

Se isso falhar com 'conexão recusada', seu plano de controle provavelmente não foi inicializado corretamente. Se houver um tempo limite de E/S, verifique a conectividade com o endereço IP no arquivo kubeconfig.

NSX com balanceador de carga incorporado:

  • Verifique se o plano de controle LB está ativo e acessível.
  • Se o LB não tiver IP, verifique os logs do NCP e verifique a interface do usuário do NSX-T para ver se os componentes relacionados estão nos estados corretos. (NSX-T LB, VirtualServer, ServerPool devem estar todos em estado íntegro).
  • Se o LB tiver IP, mas não estiver acessível (curl -k https://<LB- VIP>:6443/healthz deve retornar um erro não autorizado).

    Se o IP externo do tipo de serviço do LoadBalancer estiver em um estado "pendente", verifique se o cluster do TKG pode se comunicar com a API do Supervisor Kubernetes por meio do Supervisor LB VIP. Certifique-se de que não haja sobreposição de endereços IP.

Verifique se os nós do plano de controle do TKG estão em estado íntegro:
  • Verifique se o plano de controle do cluster do TKG relata algum erro (como não é possível criar o nó com a ID do provedor).
  • O provedor de nuvem do cluster TKG não marcou o nó com a ID de provedor correta, portanto, a CAPI não pode comparar a ID do provedor no nó de cluster convidado e o recurso de máquina no cluster supervisor para verificar.
SSH na VM do plano de controle ou use o cluster TKG kubeconfig para verificar se o pod do provedor de nuvem TKG está em execução/registrou algum erro. Consulte Conectando-se a clusters do TKG 2 em Supervisor como administrador do Kubernetes e usuário do sistema. 
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>

Se o VMOP não reconciliar VirtualMachineService com êxito, verifique o log do Operador da VM.

Se o NCP tiver problemas ao criar recursos NSX-T, verifique o log do NCP.

Se o plano de controle não foi inicializado corretamente, determine o IP da VM. O status deve conter o IP da VM. 
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
Verifique se o kubeadm registrou algum erro. 
cat /var/log/cloud-init-output.log | less

Cluster TKG provisionado preso na fase "Criando"

Execute os seguintes comandos para verificar o status do cluster.

kubectl get tkc -n <namespace>
kubectl get cluster -n <namespace> 
kubectl get machines -n <namespace>
O KubeadmConfig estava presente, mas o CAPI não conseguiu encontrá-lo. Verificado se o token em vmware-system-capv tinha as permissões corretas para consultar kubeadmconfig 
$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes
É possível que o cache do tempo de execução do controlador não estivesse sendo atualizado. Os caches de observação CAPI podem estar obsoletos e não estão selecionando os novos objetos. Se necessário, reinicie o capi-controller-manager para resolver o problema. 
kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

vSphere Namespace Preso na fase "Encerrando"

Verifique se o TKR, o Supervisor e o vCenter estão sincronizados do ponto de vista da compatibilidade de versão.

Os namespaces só poderão ser excluídos quando todos os recursos sob os namespaces forem excluídos. 
kubectl describe namespace NAME

Foi encontrado o seguinte erro: "Erro do servidor (não é possível encontrar distribuições do Kubernetes): admissão webhook "version.mutating.tanzukubernetescluster.run.tanzu.vmware.com" negou a solicitação: não foi possível encontrar distribuições do Kubernetes"

Verifique as imagens da máquina virtual em vCenter. 
kubectl get virtualmachineimages -A