Wenn Sie einen TKGS-Cluster nicht bereitstellen können, überprüfen Sie diese Liste mit den häufigsten Fehlern und beheben Sie diese.

Überprüfen der Cluster-API-Protokolle

Wenn Sie keinen TKG-Cluster erstellen können, überprüfen Sie, ob CAPW/V funktioniert.

Der CAPW/V-Controller ist die infrastrukturspezifische Implementierung der Cluster-API. CAPW/V wird über Supervisor aktiviert. CAPW/V ist eine Komponente von TKG und kann den Lebenszyklus von TKG-Clustern verwalten.

CAPW/V ist für das Erstellen und Aktualisieren des VirtualNetwork verantwortlich. Nur wenn das virtuelle Netzwerk bereit ist, kann die Erstellung der Clusterknoten verschoben werden. Hat der Workflow zur Clustererstellung diese Phase bestanden?

CAPW/V ist für das Erstellen und Aktualisieren des VirtualMachineService verantwortlich. Wurde der VirtualMachineService erfolgreich erstellt? Wurde die externe IP-Adresse abgerufen? Hat der Workflow zur Clustererstellung diese Phase bestanden?

Um diese Schritte zu beantworten, überprüfen Sie das Cluster-API-Protokoll wie folgt: 
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-...

Fehler bei der Validierung der Clusterspezifikation

Gemäß der YAML-Spezifikation darf das Leerzeichen in einem Schlüsselnamen verwendet werden. Es handelt sich um eine Skalarzeichenfolge, die ein Leerzeichen enthält und keine Anführungszeichen erfordert.

Die TKGS-Validierung lässt jedoch die Verwendung des Leerzeichens in Schlüsselnamen nicht zu. In TKGS darf ein gültiger Schlüsselname nur aus alphanumerischen Zeichen, einem Bindestrich (z. B. key-name), einem Unterstrich (z. B. KEY_NAME) oder einem Punkt (z. B. key.name) bestehen.

Wenn Sie das Leerzeichen in einem Schlüsselnamen in der Clusterspezifikation verwenden, wird der TKGS-Cluster nicht bereitgestellt. Im Protokoll „vmware-system-tkg-controller-manager“ wird folgende Fehlermeldung angezeigt.

Invalid value: \"Key Name\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')"

Entfernen Sie zum Beheben des Fehlers das Leerzeichen oder ersetzen Sie es durch ein unterstütztes Zeichen.

Fehler beim Anwenden der TKG-Cluster-YAML

Wenn Sie beim Anwenden der TKG-Cluster-YAML Fehler erhalten, führen Sie die Fehlerbehebung wie folgt durch.
Clusternetzwerk ist nicht im richtigen Zustand
Informationen zum Workflow für die TKG-Cluster-Bereitstellung:
  • CAPV erstellt ein VirtualNetwork-Objekt für jedes TKG-Clusternetzwerk.
  • Wenn Supervisor mit NSX-Netzwerk konfiguriert ist, überwacht NCP VirtualNetwork-Objekte und erstellt einen NSX Tier-1-Router und ein NSX-Segment für jedes VirtualNetwork.
  • CAPV überprüft den Status von VirtualNetwork und fährt mit dem nächsten Schritt im Workflow fort.

Der VM-Dienstcontroller sucht nach benutzerdefinierten Objekten, die von CAPV erstellt wurden, und verwendet diese Spezifikationen, um die VMs zu erstellen und zu konfigurieren, aus denen der TKG-Cluster besteht.

NSX Container Plugin (NCP) ist ein Controller, der Netzwerkressourcen überwacht, die über die Kubernetes-API zu „etcd“ hinzugefügt wurden, und die Erstellung entsprechender Objekte in NSX orchestriert.

Jeder dieser Controller wird als Kubernetes-Pods auf der Supervisor-Steuerungsebene ausgeführt. Um Netzwerkprobleme zu beheben, überprüfen Sie das CAPV-Controller-Protokoll, das VM-Dienstprotokoll und das NCP-Protokoll.

Überprüfen Sie die Containerprotokolle, wobei name-XXXX der eindeutige Pod-Name ist, wenn Sie folgenden Befehl ausführen: 
kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce
Ungültige Anzahl der Steuerungsebenenknoten

TKG-Cluster auf Supervisor unterstützt 1 oder 3 Steuerungsebenenknoten. Wenn Sie eine andere Anzahl an Replikaten eingeben, schlägt die Clusterbereitstellung fehl.

Ungültige Speicherklasse für Steuerungsebenen-/Worker-VM
Führen Sie den folgenden Befehl aus: 
kubectl describe ns <tkg-clsuter-namesapce>

Stellen Sie sicher, dass dem Namespace, in dem Sie versuchen, den TKG-Cluster zu erstellen, eine Speicherklasse zugewiesen wurde. Im vSphere-Namespace muss ein Ressourcenkontingent vorhanden sein, das auf diese Speicherklasse verweist, und die Speicherklasse muss in Supervisor vorhanden sein.

Stellen Sie sicher, dass der Name mit der Speicherklasse übereinstimmt, die in Supervisor vorhanden ist. Führen Sie kubectl get storageclasses Supervisor als vSphere-Administrator aus. WCP kann den Namen umwandeln, wenn das Speicherprofil auf Supervisor angewendet wird (z. B. werden Bindestriche zu Unterstrichen).

Ungültige VM-Klasse

Stellen Sie sicher, dass der in der Cluster-YAML angegebene Wert mit einer der von kubectl get virtualmachineclass zurückgegebenen VM-Klassen übereinstimmt. Nur gebundene Klassen können von einem TKG-Cluster verwendet werden. Eine VM-Klasse ist gebunden, wenn Sie sie zum vSphere-Namespace hinzufügen.

Der Befehl kubectl get virtualmachineclasses gibt alle VM-Klassen auf dem Supervisor zurück, aber nur diejenigen, die gebunden sind, können verwendet werden.

TKR-Distributionen konnten nicht gefunden werden
Es wird eine Fehlermeldung ähnlich der folgenden angezeigt: 
“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”

Dies ist wahrscheinlich auf ein Problem mit der Inhaltsbibliothek zurückzuführen. Um die verfügbaren Funktionen aufzulisten, verwenden Sie den Befehl kubectl get virtualmachineimages -A. Das Ergebnis ist das, was in Ihrer Inhaltsbibliothek verfügbar ist und synchronisiert oder hochgeladen wird.

Für TKG auf Supervisor gibt es neue TKR-Namen, die mit der neuen TKR-API kompatibel sind. Sie müssen sicherstellen, dass Sie jede TKR in der Inhaltsbibliothek korrekt benennen.

Name in Inhaltsbibliothek: photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

Entsprechender Name in der TKG-Clusterspezifikation: version: v1.23.8+vmware.2-tkg.1-zshippable

TKG-YAML wird angewendet. Es werden keine VMs erstellt

Wenn die TKG 2.0-Cluster-YAML gültig ist und angewendet wird, die Knoten-VMs jedoch nicht erstellt werden, führen Sie eine Fehlerbehebung wie folgt durch.
Überprüfen der CAPI-/CAPV-Ressourcen

Überprüfen Sie, ob TKG die Ressourcen auf CAPI-/CAPV-Ebene erstellt hat.

  • Überprüfen Sie, ob CAPV die VirtualMachine-Ressourcen erstellt hat.
  • Überprüfen Sie die VM-Operator-Protokolle, um festzustellen, warum die VM nicht erstellt wurde. Beispiel: Die OVF-Bereitstellung ist möglicherweise aufgrund unzureichender Ressourcen auf dem ESX-Host fehlgeschlagen.
  • Überprüfen Sie die CAPV- und VM-Operator-Protokolle.
  • Überprüfen Sie die NCP-Protokolle. NCP ist für die Realisierung von VirtualNetwork, VirtualNetworkInterface und LoadBalancer für die Steuerungsebene verantwortlich. Wenn ein Fehler im Zusammenhang mit diesen Ressourcen auftritt, kann dies ein Problem darstellen.
Fehler bei VM-Diensten
Fehler bei VM-Diensten
  • kubectl get virtualmachineservices in Ihrem Namespace ausführen
  • Wurde ein VM-Dienst erstellt?
  • kubectl describe virtualmachineservices in Ihrem Namespace ausführen
  • Werden Fehler im VM-Dienst gemeldet?
Virtuelle Netzwerkfehler

Führen Sie kubectl get virtualnetwork in Ihrem Namespace aus.

Wird das virtuelle Netzwerk für diesen Cluster erstellt?

Führen Sie kubectl describe virtual network in Ihrem Namespace aus.

Wird die virtuelle Netzwerkschnittstelle für die VM erstellt?

Die Steuerungsebene des TKG-Clusters wird nicht ausgeführt

Wenn die TKG-Steuerungsebene nicht ausgeführt wird, überprüfen Sie, ob die Ressourcen bereit waren, als der Fehler aufgetreten ist. Handelt es sich um eine Steuerungsebene für den Knotenbeitritt, die nicht aktiv ist, oder um einen Initialisierungsknoten? Überprüfen Sie außerdem, ob die Anbieter-ID im Knotenobjekt nicht festgelegt ist.
Überprüfen, ob Ressourcen bereit waren, als ein Fehler aufgetreten ist

Neben der Suche nach Protokollen hilft Ihnen die Überprüfung des Status der zugehörigen Objekte ControlPlaneLoadBalancer zu verstehen, ob die Ressourcen bereit waren, als der Fehler auftrat. Weitere Informationen finden Sie unter „Fehlerbehebung beim Netzwerk“.

Handelt es sich um eine Steuerungsebene für den Knotenbeitritt, die nicht aktiv ist, oder um einen Initialisierungsknoten?

Knotenbeitritte funktionieren manchmal nicht ordnungsgemäß. Sehen Sie sich die Knotenprotokolle für eine bestimmte VM an. Im Cluster fehlen möglicherweise Worker- und Steuerungsebenenknoten, wenn der Initialisierungsknoten nicht erfolgreich ausgeführt wird.

Anbieter-ID ist im Knotenobjekt nicht festgelegt

Wenn die VM erstellt wurde, überprüfen Sie, ob sie über IP-Adressen verfügt, und prüfen Sie dann die cloud-init-Protokolle (und ob kubeadm-Befehle werden ordnungsgemäß ausgeführt werden)

Überprüfen Sie die CAPI-Controller-Protokolle, um festzustellen, ob ein Problem vorliegt. Sie können dies mit kubectl get nodes auf dem TKG-Cluster überprüfen und dann prüfen, ob die Anbieter-ID auf dem Knotenobjekt vorhanden ist.

TKG-Worker-Knoten werden nicht erstellt

Wenn der TKG-Cluster und die Steuerungsebenen-VMs erstellt werden, aber keine Worker oder keine anderen VM-Objekte erstellt wurden, versuchen Sie Folgendes: 
kubectl describe cluster CLUSTER-NAME

Suchen Sie nach Ressourcen für virtuelle Maschinen im Namespace. Wurden weitere erstellt?

Überprüfen Sie die CAPV-Protokolle, um festzustellen, warum keine Bootstrap-Daten der anderen virtuellen Maschinenobjekte erstellt werden.

Wenn CAPI nicht über den Lastausgleichsdienst mit der Steuerungsebene des TKG-Clusters – entweder NSX mit der IP-Adresse der Knoten-VM oder VDS mit externem Lastausgleichsdienst – kommunizieren kann, rufen Sie die kubeconfig-Datei des TKG-Clusters mithilfe des geheimen Schlüssels im Namespace ab:

Rufen Sie die kubeconfig-Datei des TKG-Clusters mithilfe des geheimen Schlüssels im Namespace ab: 
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

Wenn dieser Vorgang mit der Meldung „Verbindung abgelehnt“ fehlschlägt, wurde Ihre Steuerungsebene wahrscheinlich nicht ordnungsgemäß initialisiert. Wenn eine E/A-Zeitüberschreitung vorliegt, überprüfen Sie die Konnektivität mit der IP-Adresse in „kubeconfig“.

NSX mit eingebettetem Lastausgleichsdienst:

  • Stellen Sie sicher, dass der Lastausgleichsdienst für die Steuerungsebene aktiv und erreichbar ist.
  • Wenn der Lastausgleichsdienst nicht über eine IP verfügt, überprüfen Sie die NCP-Protokolle und die NSX-T Benutzeroberfläche, um festzustellen, ob sich die zugehörigen Komponenten in den richtigen Zuständen befinden. (NSX-T LB, VirtualServer, ServerPool sollten sich alle in einem fehlerfreien Zustand befinden.)
  • Wenn LB eine IP hat, aber nicht erreichbar ist (curl -k https://<LB- VIP>:6443/healthz sollte den Fehler „nicht autorisiert“ zurückgeben).

    Wenn sich der LoadBalancer-Typ der externen IP-Adresse des Diensts im Status „ausstehend“ befindet, überprüfen Sie, ob der TKG-Cluster über die LB-VIP des Supervisors mit der Kubernetes-API des Supervisors kommunizieren kann. Stellen Sie sicher, dass sich keine IP-Adressen überschneiden.

Überprüfen, ob sich TKG-Steuerungsebenenknoten in einem fehlerfreien Zustand befinden:
  • Überprüfen Sie, ob die Steuerungsebene des TKG-Clusters einen Fehler meldet (wie z. B. „Knoten mit Anbieter-ID kann nicht erstellt werden“).
  • Der Cloud-Anbieter des TKG-Clusters hat den Knoten nicht mit der korrekten Anbieter-ID markiert, daher kann CAPI die Anbieter-ID im Gastclusterknoten und die Maschinenressource im Supervisor-Cluster nicht vergleichen, um sie zu überprüfen.
Melden Sie sich per SSH bei der Steuerungsebenen-VM an oder verwenden Sie die kubeconfig-Datei des TKG-Clusters, um zu überprüfen, ob der Cloud Provider Pod von TKG ausgeführt wird bzw. Fehler protokolliert wurden. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu TKG-Dienst-Clustern als Kubernetes-Administrator und Systembenutzer. 
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>

Wenn der VirtualMachineService-Abgleich durch VMOP nicht erfolgreich war, überprüfen Sie das VM-Operator-Protokoll.

Wenn NCP Probleme beim Erstellen von NSX-T-Ressourcen hatte, überprüfen Sie das NCP-Protokoll.

Wenn die Steuerungsebene nicht ordnungsgemäß initialisiert wurde, ermitteln Sie die VM-IP. Der Status sollte die VM-IP enthalten. 
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
Überprüfen Sie, ob „kubeadm“ Fehler protokolliert hat. 
cat /var/log/cloud-init-output.log | less

Bereitgestellter TKG-Cluster bleibt in der Phase „Wird erstellt“ hängen

Führen Sie die folgenden Befehle aus, um den Status des Clusters zu überprüfen.

kubectl get tkc -n <namespace>
kubectl get cluster -n <namespace> 
kubectl get machines -n <namespace>
KubeadmConfig war vorhanden, konnte von CAPI aber nicht gefunden werden. Es wurde überprüft, ob das Token in „vmware-system-capv“ über die erforderlichen Berechtigungen zum Abfragen von „kubeadmconfig“ verfügte. 
$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes
Es ist möglich, dass der Controller-Laufzeit-Cache nicht aktualisiert wurde. Die CAPI-Watch-Caches sind möglicherweise veraltet und nehmen die neuen Objekte nicht auf. Starten Sie bei Bedarf „capi-controller-manager“ neu, um das Problem zu beheben. 
kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

vSphere-Namespace bleibt in der Phase „Wird beendet“ hängen

Stellen Sie sicher, dass TKR, Supervisor und vCenter im Hinblick auf die Versionskompatibilität synchron sind.

Namespaces können nur gelöscht werden, wenn alle Ressourcen unter den Namespaces wiederum gelöscht werden. 
kubectl describe namespace NAME

Der folgende Fehler wurde gefunden: „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“

Überprüfen Sie die Images der virtuellen Maschine in vCenter. 
kubectl get virtualmachineimages -A