Informationen zur Fehlerbehebung beim TKGS-Clusternetzwerk finden Sie in den Tipps in diesem Abschnitt.

Überprüfen des Knotennetzwerks

Jeder TKG-Cluster sollte über die folgenden Netzwerkressourcen verfügen.
Netzwerkobjekt Netzwerkressourcen Beschreibung Beheben Befehl
VirtualNetwork Tier-1-Router und verknüpftes Segment Knotennetzwerk für den Cluster Stellen Sie sicher, dass die SNAT-IP zugewiesen ist 
kubectl get virtualnetwork -n NS-NAME
VirtualNetworkInterface Logischer Port auf Segment Knotennetzwerkschnittstelle für Clusterknoten Sicherstellen, dass jede virtuelle Maschine über eine IP-Adresse verfügt 
kubectl get virtualmachines -n NS-NAME NODE-NAME

Überprüfen des Lastausgleichsdiensts für die Steuerungsebene

Der Lastausgleichsdienst für die Steuerungsebene des TKG-Clusters bietet Zugriff auf den Kubernetes-API-Server. Dieser Lastausgleichsdienst wird während der Clustererstellung automatisch vom System bereitgestellt. Es sollte über die folgenden Ressourcen verfügen.

Die Überprüfung des Status des Lastausgleichsdiensts der Steuerungsebene kann Ihnen dabei helfen, zu verstehen, ob Ressourcen bereit waren, als Fehler aufgetreten sind. Im Allgemeinen finden Sie diesen Lastausgleichsdienst unter Verwendung von „Diese Lastausgleichsdienste suchen“ mit diesem Befehl für den Supervisor-Cluster: kubectl get services -A | grep control-plane-service
Netzwerkobjekt Netzwerkressourcen Beschreibung Beheben Befehl
VirtualMachineService Nicht verfügbar VirtualMachineService wird erstellt und in einen k8s-Dienst übersetzt. Stellen Sie sicher, dass der Status aktualisiert ist und die virtuelle IP (VIP) des Lastausgleichsdiensts enthält. 
kubectl get virtualmachineservices -n NS-NAME SERVICE-NAME
Dienst Lastausgleichsserver mit VirtualServer-Instanz und zugeordneter Serverpool (Mitgliederpool) Der Kubebernetes-Dienst vom Typ „Lastausgleichsdienst“ wird für den Zugriff auf den TKG-Cluster-API-Server erstellt. Stellen Sie sicher, dass eine externe IP-Adresse zugewiesen ist. Stellen Sie sicher, dass Sie über die externe IP des LB-Diensts auf die TKG-Cluster-API zugreifen können.
Supervisor-Namespace: 
kubectl get services -A | grep control-plane-service
Cluster-Namespace: 
kubectl get services -n NS-NAME
Beide Namespaces 
curl -k https://EXTERNAL-IP:PORT/healthz
Endpoints Die Endpoint-Mitglieder (Knoten der Steuerungsebene des TKG-Clusters) sollten sich im Mitgliedspool befinden. Ein Endpoint wird erstellt, um alle Steuerungsebenenknoten des TKG-Clusters einzubeziehen. 
kubectl get endpoints -n NS-NAME SERVICE-NAME

Überprüfen der Lastausgleichsdienste auf Worker-Knoten

Eine Lastausgleichsdienst-Instanz für die Worker-Knoten des TKG-Clusters wird vom Benutzer erstellt, wenn ein Kubernetes-Dienst vom Typ „LoadBalancer“ erstellt wird.

Der erste Schritt besteht darin, sicherzustellen, dass der Cloud-Anbieter auf dem TKG-Cluster ausgeführt wird. 
kubectl get pods -n vmware-system-cloud-provider
Stellen Sie sicher, dass verwandte Kubernetes-Objekte erstellt wurden und sich im richtigen Zustand befinden.
Netzwerkobjekte Netzwerkressourcen Beschreibung Befehl
VirtualMachineService in Supervisor Nicht verfügbar Ein VirtualMachineService wird im Supervisor erstellt und in einen Kubernetes-Dienst im Supervisor übersetzt 
kubectl get virtualmachineservice -n NS-NAME SVC-NAME
Lastausgleichsdienst im Supervisor VirtualServer im TKG-Cluster-Lastausgleichsdienst und ein zugehöriger Mitgliederpool. Der Lastausgleichsdienst wird im Supervisor für den Zugriff auf diesen LB-Diensttyp erstellt 
kubectl get services -n NS-NAME SVC-NAME
Endpoints im Supervisor Die Endpoint-Mitglieder (TKG-Cluster-Worker-Knoten) sollten sich im Mitgliedspool in NSX befinden. Ein Endpoint wird erstellt, um alle Worker-Knoten des TKG-Clusters einzubeziehen 
# kubectl get endpoints -n NS-NAME SVC-NAME
Lastausgleichsdienst im TKG-Cluster Nicht verfügbar Für den Lastausgleichsdienst im vom Benutzer bereitgestellten TKG-Cluster sollte der Status mit der Lastausgleichsdienst-IP aktualisiert werden 
kubectl get services

Prüfen des Supervisor-NSX-Netzwerk-Stacks

Der Kubernetes-API-Server, der NCP-Pod und der Manager-Container, der in einem beliebigen Controller-Pod ausgeführt wird, sind die primären Ausgangspunkte für die Überprüfung von Infrastruktur-Netzwerkproblemen.

Die folgende Fehlermeldung kann auf ein Routing- oder MTU-Problem im Netzwerk-Fabric hindeuten, einschließlich der physischen Portgruppe, mit der die ESXi-Host-Netzwerkkarten verbunden sind: 
{"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"}
Stellen Sie zur Fehlerbehebung über SSH eine Verbindung mit dem ESXi-Host her und führen Sie den folgenden Befehl aus: 
esxcli network ip interface ipv4 get

Dieser Befehl listet alle VMkernel-Schnittstellen des Hosts auf. Wenn Sie über eine einzelne TEP-Schnittstelle verfügen, handelt es sich dabei immer um vmk10. Wenn Sie über eine zweite oder dritte TEP-Schnittstelle verfügen, sind dies vmk11 und vmk12 usw. Die Anzahl der erstellten TEP-Schnittstellen hängt davon ab, wie viele Uplinks Sie dem TEP im Uplink-Profil zugewiesen haben. Pro Uplink wird eine TEP-Schnittstelle erstellt, wenn Sie für die TEPs die Lastverteilung („Load Sharing“) über Uplinks ausgewählt haben.

Der Haupt-Ping-Befehl für TEP-zu-TEP-Verbindungen weist die folgende Syntax auf: 
vmkping ++netstack=vxlan -s 1572 -d -I vmk10 10.218.60.66
Dabei
  • ist -s die Paketgröße
  • bedeutet -d, dass keine Fragmentierung erfolgen soll
  • bedeutet -I, dass der Link von vmk10 bezogen werden soll
  • ist die IP address eine TEP-Schnittstelle auf einem anderen ESXi-Host oder NSX Edge, den Sie pingen
Wenn die MTU auf 1600 festgelegt ist, schlägt eine Paketgröße von über 1573 wahrscheinlich fehl (Sie benötigen nur eine MTU über 1500). Wenn die MTU auf 1500 festgelegt ist, schlagen wahrscheinlich alle Paketgrößen über 1473 fehl. Sie sollten die Schnittstelle im Befehl in vmk11 ändern, wenn Sie über zusätzliche TEP-Schnittstellen verfügen, von denen Sie den Ping-Befehl absetzen möchten.