Per risolvere i problemi relativi alla rete del cluster TKG Service, fare riferimento ai suggerimenti di questa sezione.

Verificare rete del nodo

Ogni cluster TKG deve disporre delle seguenti risorse di rete.
Oggetto di rete Risorse di rete Descrizione Risoluzione dei problemi Comando
ReteVirtuale Router di livello 1 e segmento collegato Rete del nodo per il cluster Assicurarsi che l'IP SNAT sia assegnato 
kubectl get virtualnetwork -n NS-NAME
VirtualNetworkInterface Porta logica nel segmento Interfaccia di rete dei nodi del cluster Assicurarsi che ciascuna VirtualMachine disponga dell'indirizzo IP 
kubectl get virtualmachines -n NS-NAME NODE-NAME

Controllare il bilanciamento del carico per il piano di controllo

Il bilanciamento del carico per il piano di controllo del cluster TKG fornisce l'accesso al server dell'API Kubernetes. Il provisioning automatico di questo bilanciamento del carico viene eseguito dal sistema durante la creazione del cluster. Deve disporre delle risorse seguenti.

Se si verifica lo stato del bilanciamento del carico del piano di controllo, è possibile capire se le risorse erano pronte quando si sono verificati errori. In generale, il bilanciamento del carico viene trovato utilizzando Trova questi bilanciamenti del carico con il comando nel cluster supervisore: kubectl get services -A | grep control-plane-service
Oggetto di rete Risorse di rete Descrizione Risoluzione dei problemi Comando
VirtualMachineService N/D VirtualMachineService viene creato e convertito in un servizio k8s. Assicurarsi che lo stato sia aggiornato e che includa l'IP virtuale (VIP) del bilanciamento del carico. 
kubectl get virtualmachineservices -n NS-NAME SERVICE-NAME
Servizio Server di bilanciamento del carico con istanza VirtualServer e pool di server associato (pool di membri) Viene creato il servizio Kubernetes di tipo Bilanciamento del carico per l'accesso al server API del cluster TKG. Assicurarsi che sia stato assegnato un IP esterno. Assicurarsi di poter accedere all'API del cluster TKG tramite l'IP esterno del servizio LB.
Spazio dei nomi supervisore: 
kubectl get services -A | grep control-plane-service
Spazio dei nomi del cluster: 
kubectl get services -n NS-NAME
Entrambi gli spazi dei nomi: 
curl -k https://EXTERNAL-IP:PORT/healthz
Endpoint I membri dell'endpoint (nodi del piano di controllo del cluster TKG) devono trovarsi nel pool di membri. Viene creato un endpoint per includere tutti i nodi del piano di controllo del cluster TKG. 
kubectl get endpoints -n NS-NAME SERVICE-NAME

Controllare i servizi di bilanciamento del carico nei nodi di lavoro

Un'istanza del bilanciamento del carico per i nodi di lavoro del cluster TKG viene creata dall'utente quando viene creato un servizio Kubernetes di tipo LoadBalancer.

Il primo passaggio consiste nell'assicurarsi che il provider di cloud sia in esecuzione nel cluster TKG. 
kubectl get pods -n vmware-system-cloud-provider
Verificare che gli oggetti Kubernetes correlati siano stati creati e siano in uno stato corretto.
Oggetti di rete Risorse di rete Descrizione Comando
VirtualMachineService in Supervisore N/D Un VirtualMachineService viene creato in Supervisore e convertito in un servizio Kubernetes in Supervisore 
kubectl get virtualmachineservice -n NS-NAME SVC-NAME
Servizio di bilanciamento del carico in Supervisore VirtualServer nel bilanciamento del carico del cluster TKG e un pool di membri associato. Il servizio di bilanciamento del carico viene creato in Supervisore per l'accesso a questo tipo di servizio LB 
kubectl get services -n NS-NAME SVC-NAME
Endpoint nel supervisore I membri dell'endpoint (nodi di lavoro del cluster TKG) devono trovarsi nel pool di membri in NSX. Viene creato un endpoint per includere tutti i nodi di lavoro del cluster TKG 
# kubectl get endpoints -n NS-NAME SVC-NAME
Servizio di bilanciamento del carico nel cluster TKG N/D Lo stato del servizio di bilanciamento del carico nel cluster TKG distribuito dall'utente deve essere aggiornato con l'IP del bilanciamento del carico 
kubectl get services

Controllo dello stack di rete del Supervisore NSX

Il server dell'API Kubernetes, il pod NCP e il container di gestione eseguito in qualsiasi pod del controller sono i punti di avvio principali per la verifica dei problemi dei servizi di rete dell'infrastruttura.

Il seguente messaggio di errore può indicare un problema di routing o di MTU in qualsiasi punto della struttura di rete, incluso il gruppo di prot fisico a cui sono connesse le NIC degli host ESXi: 
{"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"}
Per risolvere i problemi, accedere tramite SSH all'host ESXi ed eseguire il comando seguente: 
esxcli network ip interface ipv4 get

Questo comando elenca tutte le interfacce vmkernel dell'host. Se si dispone di una singola interfaccia TEP, sarà sempre vmk10. Se si dispone di una 2ª o 3ª interfaccia TEP, sarà vmk11 e vk12 e così via. La quantità di interfacce TEP create dipende dal numero di uplink assegnati al TEP nel profilo di uplink. Viene creata un'interfaccia TEP per uplink se è stata selezionata l'opzione TEP tra uplink.

La sintassi del comando ping da TEP a TEP principale è la seguente: 
vmkping ++netstack=vxlan -s 1572 -d -I vmk10 10.218.60.66
Dove
  • -s è la dimensione del pacchetto
  • -d significa non frammenta
  • -I significa che origina il link da vmk10
  • L'IP address è un'interfaccia TEP su un altro host ESXi o su un NSX Edge con ping eseguito
Se l'MTU è impostata su 1600, le dimensioni di un pacchetto superiori a 1573 avranno esito negativo (è necessario solo che il valore dell'MTU sia superiore a 1500). Se l'MTU è impostata su 1500, qualsiasi valore superiore a 1473 avrà esito negativo. È possibile modificare questa opzione in vmk11 se si dispone di interfacce TEP aggiuntive da cui si desidera ottenere il ping.