Consulte as dicas nesta seção para solucionar erros de rede do cluster TKG.

Verificar a rede do nó

Cada cluster TKG deve ter os seguintes recursos de rede.
Objeto de rede Recursos de rede Descrição Solucionar problemas Comando
VirtualNetwork Roteador de nível 1 e segmento vinculado Rede de nós para o cluster Certifique-se de que o SNAT IP esteja atribuído 
kubectl get virtualnetwork -n NS-NAME
VirtualNetworkInterface Porta lógica no segmento Interface de rede do nó para nós de cluster Certifique-se de que cada VirtualMachine tenha um endereço IP 
kubectl get virtualmachines -n NS-NAME NODE-NAME

Verificar o balanceador de carga do plano de controle

O balanceador de carga para o plano de controle do cluster TKG fornece acesso ao servidor de API Kubernetes. Esse balanceador de carga é provisionado automaticamente pelo sistema durante a criação do cluster. Ele deve ter os seguintes recursos.

A verificação do status do balanceador de carga do plano de controle pode ajudá-lo a entender se os recursos estavam prontos quando ocorreram erros. Em geral, você encontra esse balanceador de carga usando Localizar estes balanceadores de carga com este comando no cluster supervisor: kubectl get services -A | grep control-plane-service
Objeto de rede Recursos de rede Descrição Solucionar problemas Comando
VirtualMachineService N/A VirtualMachineService é criado e convertido em um serviço k8s. Certifique-se de que seu status esteja atualizado e inclua o IP virtual (VIP) do balanceador de carga. 
kubectl get virtualmachineservices -n NS-NAME SERVICE-NAME
Serviço Servidor do Balanceador de Carga com a instância do VirtualServer e o Pool de Servidores associado (pool de membros) O serviço Kubernetes do tipo Balanceador de Carga é criado para acesso ao servidor de API do cluster TKG. Certifique-se de que um IP externo esteja atribuído. Verifique se você pode acessar a API do cluster TKG por meio do IP externo do serviço LB.
Namespace do supervisor: 
kubectl get services -A | grep control-plane-service
Namespace do cluster: 
kubectl get services -n NS-NAME
Qualquer namespace 
curl -k https://EXTERNAL-IP:PORT/healthz
Endpoints Os membros do endpoint (nós do plano de controle do cluster TKG) devem estar no pool de membros. Um endpoint é criado para incluir todos os nós do plano de controle do cluster do TKG. 
kubectl get endpoints -n NS-NAME SERVICE-NAME

Verificar os serviços do balanceador de carga em nós de trabalho

Uma instância do balanceador de carga para os nós do trabalhador de cluster do TKG é criada pelo usuário quando um serviço do Kubernetes do tipo LoadBalancer é criado.

A primeira etapa é garantir que o provedor de nuvem esteja em execução no cluster TKG. 
kubectl get pods -n vmware-system-cloud-provider
Verifique se os objetos Kubernetes relacionados foram criados e estão em um estado correto.
Objetos de rede Recursos de rede Descrição Comando
VirtualMachineService no Supervisor N/A Um VirtualMachineService é criado no Supervisor e convertido em um serviço Kubernetes no Supervisor 
kubectl get virtualmachineservice -n NS-NAME SVC-NAME
Serviço do Balanceador de Carga no Supervisor VirtualServer no balanceador de carga do cluster TKG e um pool de membros associado. O serviço de balanceador de carga é criado no Supervisor para acesso a este tipo de serviço de LB 
kubectl get services -n NS-NAME SVC-NAME
Endpoints no Supervisor Os membros do endpoint (nós do trabalhador de cluster TKG) devem estar no pool de membros em NSX. Um endpoint é criado para incluir todos os nós de trabalhador do cluster do TKG 
# kubectl get endpoints -n NS-NAME SVC-NAME
Serviço do Balanceador de Carga no cluster TKG N/A O Serviço do Balanceador de Carga no cluster TKG implantado pelo usuário deve ter seu status atualizado com o IP do balanceador de carga 
kubectl get services

Verificar a pilha de rede Supervisor NSX

O servidor de API Kubernetes, o pod NCP e o contêiner de gerenciador que é executado em qualquer pod de controlador são os principais pontos de partida para verificar problemas de rede de infraestrutura.

A seguinte mensagem de erro pode indicar um problema de roteamento ou MTU em qualquer ponto da malha de rede, incluindo o grupo de proteções físico ao qual as NICs de hosts ESXi estão conectadas: 
{"log":"I0126 19:40:15.347154 1 log.go:172] http: TLS handshake error from 
100.64.128.1:4102: EOF\n","stream":"stderr","time":"2021-01-26T19:40:15.347256146Z"}
Para solucionar problemas, faça SSH no host ESXi e execute o seguinte comando: 
esxcli network ip interface ipv4 get

Esse comando lista todas as interfaces vmkernel do host. Se você tiver uma única interface TEP, ela sempre será vmk10. Se você tiver uma 2ª ou 3ª interface TEP, ela será vmk11 e vk12 e assim por diante. A quantidade de interfaces TEP que são criadas depende de quantos uplinks você atribuiu ao TEP no perfil de uplink. Uma interface TEP será criada por uplink, se você tiver selecionado "compartilhamento de carga" para os TEPs entre uplinks.

O comando principal TEP to TEP ping tem a seguinte sintaxe: 
vmkping ++netstack=vxlan -s 1572 -d -I vmk10 10.218.60.66
Onde
  • -s é o tamanho do pacote
  • -d significa não fragmentar
  • -I significa originar o link de vmk10
  • O IP address é uma interface TEP em outro host ESXi ou borda NSX que você está executando ping
Se o MTU estiver definido como 1600, um tamanho de pacote acima de 1573 deverá falhar (você só precisa de um MTU acima de 1500). Se a MTU estiver definida como 1500, qualquer coisa acima de 1473 deverá falhar. Convém alterar isso para vmk11 se você tiver interfaces TEP adicionais das quais deseja originar o ping.