Fehlerbehebung bei Problemen mit dem Arbeitslastcluster

Dieser Abschnitt enthält Tipps, die Ihnen bei der Fehlerbehebung von Arbeitslastclustern helfen.

Informationen zur Fehlerbehebung bei Bereitstellungen eigenständiger Verwaltungscluster finden Sie unter Fehlerbehebung bei Problemen mit Verwaltungsclustern. Weitere Problemumgehungen für bekannte Probleme in dieser Version finden Sie in den Versionshinweisen oder in VMware KnowledgeBase-Artikeln.

Allgemeine Aufgaben

Löschen von Benutzern, Kontexten und Clustern mit kubectl

So bereinigen Sie den Zustand von kubectl, indem Sie bestimmte oder alle Benutzer, Kontexte und Cluster löschen:

1. Öffnen Sie die Datei ~/.kube/config.

2. Führen Sie für die zu löschenden user-Objekte Folgendes aus:

   kubectl config unset users.USER-NAME
   

   Dabei ist USER-NAME die Eigenschaft name jedes user-Objekts der obersten Ebene, wie in den config-Dateien aufgeführt.

3. Führen Sie für die zu löschenden context-Objekte Folgendes aus:

   kubectl config unset contexts.CONTEXT-NAME
   

   Dabei ist CONTEXT-NAME die Eigenschaft name jedes context-Objekts der obersten Ebene, wie in den config-Dateien aufgeführt, üblicherweise in der Form contexts.mycontext-admin@mycontext.

4. Führen Sie für die zu löschenden cluster-Objekte Folgendes aus:

   kubectl config unset clusters.CLUSTER-NAME
   

   Dabei ist CLUSTER-NAME die Eigenschaft name jedes cluster-Objekts der obersten Ebene, wie in den config-Dateien aufgeführt.

5. Wenn die config-Dateien den aktuellen Kontext als einen von Ihnen gelöschten Cluster auflisten, setzen Sie den Kontext zurück:

   kubectl config unset current-context
   

Pakete

Geheimer Schlüssel wird bei der Installation von Grafana anhand der YAML-Standarddatei nicht erstellt

Problem

Wenn Sie Grafana installieren, indem Sie eine standardmäßige Grafana-Konfigurationsdatei erzeugen, schlägt die Installation mit error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest) fehl.

Lösung

Erstellen Sie den geheimen Schlüssel manuell und verwenden Sie dieselbe YAML-Datei ohne das geheime Tag für die Installation von Grafana.

1. Führen Sie die Schritte unter Bereitstellen von Grafana im Arbeitslastcluster durch, um die Konfigurationsdatei für Ihre Grafana-Konfiguration zu erstellen.
2. Entfernen Sie die grafana.secret.*-Einträge aus der erzeugten Konfigurationsdatei.

3. Erstellen Sie einen geheimen Schlüssel manuell.

   kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin
   

4. Stellen Sie das Paket bereit.

   tanzu package install grafana \
   --package grafana.tanzu.vmware.com \
   --version AVAILABLE-PACKAGE-VERSION \
   --values-file grafana-data-values.yaml \
   --namespace TARGET-NAMESPACE
   

5. Führen Sie die verbleibenden Schritte unter Bereitstellen von Grafana im Arbeitslastcluster durch.

Fehler beim Ausführen von tanzu package repository

Problem

Der Befehl tanzu package repository schlägt mit einer Fehlermeldung fehl.

Lösung

Führen Sie kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml​ aus, um Details zu dem Fehler abzurufen.

Dabei gilt:

• REPOSITORY-NAME ist der Name des Paketrepositorys.
• NAMESPACE ist der Ziel-Namespace des Paketrepositorys.

Der Befehl tanzu package repository kann mit einer Fehlermeldung ähnlich der folgenden fehlschlagen:

Fehler	Beschreibung	Lösung
NOT_FOUND	Der Pfad der Repository-URL ist ungültig.	Stellen Sie sicher, dass die URL des Paketrepositorys über Ihr Cluster erreichbar ist.
UNKNOWN oder UNAUTHORIZED	Dieser Fehler kann beim Versuch, eine Verbindung zum Repository herzustellen, auftreten.
Ownership	Ein Repository mit derselben Paketrepository-URL ist bereits im Cluster installiert.	Führen Sie einen der folgenden Schritte aus: Führen Sie tanzu package available list -n NAMESPACE aus, um festzustellen, ob das zu installierende Paket bereits für die Installation verfügbar ist. Um den aktuellen fehlgeschlagenen Versuch, das Repository hinzuzufügen, rückgängig zu machen, führen Sie tanzu package repository delete REPOSITORY-NAME -n NAMESPACE aus. Führen Sie tanzu package repository list -A aus, um ein vorhandenes Paketrepository mit derselben URL abzurufen. Wenn Sie das Paketrepository abrufen, können Sie es auf eigene Gefahr löschen.

Fehler beim Ausführen von tanzu package installed

Problem

Der Befehl tanzu package installed schlägt mit einer Fehlermeldung fehl.

Lösung

Führen Sie kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml​ aus, um Details zu dem Fehler abzurufen.

Dabei gilt:

• INSTALLED-PACKAGE-NAME ist der Name des installierten Pakets.
• NAMESPACE ist der Namespace des installierten Pakets.

Der Befehl tanzu package installed kann mit einer Fehlermeldung ähnlich der folgenden fehlschlagen:

Fehler	Beschreibung	Lösung
Ownership	Ein Paket mit demselben Namen ist bereits im Cluster installiert.	Führen Sie tanzu package installed list -A aus, um festzustellen, ob das zu installierende Paket bereits installiert ist. Ist dies der Fall, möchten Sie unter Umständen das bereits installierte Paket verwenden, dessen Version aktualisieren oder das Paket löschen, um mit der Installation fortfahren zu können.
Evaluating starlark template	Dieser Fehler kann auftreten, wenn der aufgelistete Konfigurationswert fehlt.	Führen Sie tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE --values-schema aus, um alle verfügbaren Konfigurationswerte anzuzeigen und die erforderlichen Konfigurationswerte für den Befehl tanzu package install anzugeben.
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE	Das angegebene Paket und die Paketmetadaten sind im Ziel-Namespace nicht verfügbar.	Stellen Sie sicher, dass das angegebene Paket in der Ausgabe von tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE​ aufgeführt ist. Falls nicht, fügen Sie das Paketrepository mit dem Paket zum Ziel-Namespace hinzu.
Namespace NAMESPACE not found	Der Namespace, in dem Sie das Paket installieren möchten, ist nicht vorhanden.	In TKG v2.1 und höheren Versionen basieren tanzu package-Befehle auf kctrl. Das Flag —create-namespace wird darin nicht mehr unterstützt. Vor der Installation eines Pakets oder Paket-Repositorys muss der Ziel-Namespace bereits vorhanden sein.
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE​	Das mit dem Flag service-account-name bereitgestellte Dienstkonto wird bereits von einem anderen installierten Paket verwendet.	Lassen Sie zu, dass das Paket-Plug-In vom Dienstkonto erstellt wird, oder wählen Sie einen anderen Namen für das Dienstkonto aus.

Pods

Pods verbleiben aufgrund der vCenter-Konnektivität im Cluster mit dem Status „Ausstehend“

Problem

Wenn Sie kubectl get pods -A in dem erstellten Cluster ausführen, verbleiben bestimmte Pods im Status „Ausstehend“.

Sie führen kubectl describe pod -n pod-namespace pod-name auf einem betroffenen Pod aus und sehen das folgende Ereignis:

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Lösung

Stellen Sie sicher, dass Konnektivitäts- und Firewallregeln vorhanden sind, um die Kommunikation zwischen dem Cluster und vCenter sicherzustellen. Informationen zu firewallbasierten Ports und Protokollanforderungen finden Sie in den vSphere 8-Listen in VMware Ports and Protocols.

Speicher

Das Ändern des Standardobjekts StorageClass führt zu einem Abstimmungsfehler in Arbeitslastclustern

Problem

Das Ändern der Eigenschaften eines in TKG enthaltenen StorageClass-Standardobjekts führt zu einem Paketabstimmungsfehler in Arbeitslastclustern, die die Speicherklasse verwenden.

Lösung:

Um eine Speicherklasse anzupassen, erstellen Sie eine neue StorageClass-Definition mit einem anderen name anstatt die Standardobjektdefinition zu ändern. Konfigurieren Sie den Cluster neu, um die neue Speicherklasse zu verwenden.

Arbeitslastcluster

Beim Bereitstellen eines Clusters tritt eine Zeitüberschreitung auf, der Cluster wird aber dennoch erstellt

Problem

Die Ausführung von tanzu cluster create schlägt mit einem Zeitüberschreitungsfehler ähnlich dem folgenden fehl:

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

Lösung

Verwenden Sie das Flag --timeout, um die Wartezeit bis zum Abschluss der Clustererstellung festzulegen. Die Standardwartezeit beträgt 30 Minuten.

tanzu cluster create --timeout TIME

Dabei gilt: TIME ist der Zeitraum in Minuten, in dem auf den Abschluss der Clustererstellung gewartet wird. Beispiel: 60m.

Arbeitslastcluster bleibt beim Löschen hängen

Problem

tanzu cluster delete kann den Arbeitslastcluster nicht löschen.

Informationen zum manuellen Löschen des Clusters finden Sie in den beiden folgenden Lösungen.

Lösung 1

1. Löschen Sie auf dem Zielcluster das StatefulSet-Objekt für AKO, das im Namespace avi-system ausgeführt wird:

   kubectl delete sts ako -n avi-system
   

Lösung 2

1. Melden Sie sich beim Cluster an und löschen Sie die Worker-Maschinen:

   kubectl delete machine worker1 worker2
   

2. Schalten Sie in vCenter die Worker-Knoten-VMs aus und löschen Sie sie.

3. Bearbeiten Sie Maschinen der Steuerungsebene und entfernen Sie den Finalizer-Link:

   finalizers:
    - machine.cluster.x-k8s.io
   

4. Löschen Sie die Maschinen der Steuerungsebene:

   kubectl delete machine controlplane1 controlplane2
   

5. Schalten Sie in vCenter die VMs der Steuerungsebene aus und löschen Sie sie.

Cluster-Worker-Knoten in Status NotReady aufgrund nicht übereinstimmender MTUs

Problem

Unterschiedliche Einstellungen für maximale Übertragungseinheiten (MTUs) auf den Worker-Knoten in einem Cluster führen zu einer TLS-Handshake-Zeitüberschreitung.

Protokolle von journalctl -u kubelet auf einem Knoten zeigen einen Kommunikationsfehler mit dem API-Server an. Wenn kubectl get nodes ausgeführt wird, wird angezeigt, dass Worker-Knoten in den Status NotReady versetzt wurden.

Sie können das Problem wie folgt neu bestätigen:

1. Führen Sie auf dem Steuerungsebenenknoten und den Worker-Knoten-Maschinen ip link aus und vergleichen Sie die MTU-Werte der Schnittstelle eth0. Wenn sie nicht übereinstimmen, ist dies ein Hinweis auf dieses Problem.
2. Führen Sie Crash Diagnostics (Crashd) aus und überprüfen Sie die kubelet-Protokolle, um festzustellen, ob bei den Verbindungen eine Zeitüberschreitung eintritt oder sich die Worker-Knoten im Status NotReady befinden. Weitere Informationen zum Ausführen von Crashd finden Sie unter Fehlerbehebung bei Arbeitslastclustern mit Absturzdiagnosen

3. Bestätigen Sie, dass die folgenden Befehle fehlschlagen, wenn Sie sie auf einer Maschine ausführen, die sich in den Knotenstatus NotReady versetzt wurde:

   • openssl s_client -connect IP:PORT

   • curl IP:PORT -k /healthz

   Dabei ist IP und PORT die IP-Adresse und die Portnummer des Steuerungsebenen-Endpoints des Kubernetes-API-Servers. PORT ist standardmäßig auf 6443 gesetzt.

Lösung

1. Überprüfen Sie die privilegierten DaemonSets, die auf dem Cluster bereitgestellt sind, und überprüfen Sie alle DaemonSets von Drittanbietern, die möglicherweise die Netzwerkkonfigurationen des Hostbetriebssystems ändern. Möglicherweise müssen Sie sich an den Softwareanbieter wenden, um dies herauszufinden. Bei DaemonSets, die das Hostbetriebssystem ändern können, steht entweder .spec.template.spec.hostNetwork: true oder privileged: true oder NET_ADMIN im Funktionsfeld eines beliebigen Container-Sicherheitskontexts.

2. Wenn Sie große MTU-Einstellungen konfigurieren möchten, stellen Sie den Cluster mit Steuerungsebene mit einem höheren MTU-Wert bereit.

3. Stellen Sie sicher, dass das Clusternetzwerk entweder die Pfad-MTU-Erkennung zulässt oder über TCP-MSS-Klemmung verfügt, um eine korrekte MTU-Dimensionierung für externe Dienste wie beispielsweise vCenter- oder Containerregistrierungen zuzulassen.

4. Stellen Sie sicher, dass Sie dieselben MTU-Einstellungen für alle Knoten in einem Cluster konfigurieren.

5. Die Netzwerk-Firewall-Einstellungen müssen Pakete der konfigurierten MTU-Größe zulassen.

Mit NSX ALB können Sie keine Cluster mit identischen Namen erstellen

Problem

Wenn Sie NSX Advanced Load Balancer für Arbeitslasten (AVI_ENABLE) oder die Steuerungsebene (AVI_CONTROL_PLANE_HA_PROVIDER) verwenden, kann der Avi-Controller möglicherweise nicht zwischen Clustern mit identischen Namen unterscheiden.

Lösung:

Legen Sie einen eindeutigen CLUSTER_NAME-Wert für jeden Cluster fest. Erstellen Sie nicht mehrere Arbeitslastcluster, die denselben CLUSTER_NAME haben und sich auch im selben Verwaltungscluster-Namespace befinden, wie durch den Wert NAMESPACE festgelegt.

Löschen von vSphere CSI-Volumes schlägt auf AVS möglicherweise fehl

Problem

In Azure vSphere Solution (AVS) kann das Löschen von persistenten vSphere CSI-Volumes (PVs) fehlschlagen. Zum Löschen eines PV ist die Berechtigung cns.searchable erforderlich. Das standardmäßige Administratorkonto für AVS, <[email protected]>, wird nicht mit dieser Berechtigung erstellt. Weitere Informationen finden Sie unter vSphere-Rollen und -Berechtigungen.

Lösung

Um ein vSphere CSI-PV auf AVS zu löschen, wenden Sie sich an den Azure-Support.

Das Löschen des Clusters auf AWS schlägt fehl, wenn der Cluster Netzwerkressourcen verwendet, die nicht mit Tanzu Kubernetes Grid bereitgestellt wurden

Problem

Die Befehle tanzu cluster delete und tanzu management-cluster delete hängen möglicherweise bei Clustern, die unabhängig vom Tanzu Kubernetes Grid-Bereitstellungsvorgang vom AWS Cloud Controller Manager erstellte Netzwerkressourcen verwenden. Zu diesen Ressourcen können Lastausgleichsdienste und andere Netzwerkdienste gehören, wie unter The Service Controller in der Dokumentation zum Kubernetes AWS Cloud-Anbieter aufgeführt.

Weitere Informationen finden Sie unter Cluster-API-Problem Drain workload clusters of service Type=Loadbalancer on teardown.

Lösung

Verwenden Sie kubectl delete, um Dienste vom Typ LoadBalancer aus dem Cluster zu löschen. Wenn dies fehlschlägt, verwenden Sie die AWS-Konsole, um alle LoadBalancer- und SecurityGroup-Objekte, die vom Cloud Controller Manager für diesen Dienst erstellt wurden, manuell zu löschen.

Vorsicht

Löschen Sie keine von Tanzu verwalteten Lastausgleichsdienste oder Sicherheitsgruppen mit den Tags key: sigs.k8s.io/cluster-api-proider-aws/cluster/CLUSTER-NAME,value: owned.

Das Löschen des Clusters schlägt fehl, wenn das Speicher-Volume ein Konto mit privatem Endpoint verwendet

Problem

Wenn der Azure CSI-Treiber bei einem Azure-Arbeitslastcluster in einer nicht verwalteten Ressourcengruppe ein persistentes Volume (PV) erstellt, das ein Speicherkonto mit privatem Endpoint verwendet, erstellt er einen privateEndpoint und vNet-Ressourcen, die nicht zusammen mit dem PV gelöscht werden. Dies führt dazu, dass das Löschen des Clusters mit einer Fehlermeldung wie subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use fehlschlägt.

Lösung:

Bevor Sie den Azure-Cluster löschen, löschen Sie die Netzwerkschnittstelle für den privaten Endpoint des Speicherkontos manuell:

1. Melden Sie sich über einen Browser beim Azure-Ressourcen-Explorer an.
2. Klicken Sie links auf Abonnements (Subscriptions) und erweitern Sie Ihr Abonnement.
3. Erweitern Sie unter Ihrem Abonnement links resourceGroups und erweitern Sie die Ressourcengruppe Ihrer TKG-Bereitstellung.
4. Erweitern Sie unter der Ressourcengruppe providers > Microsoft.Network > networkinterfaces.
5. Wählen Sie unter networkinterfaces die Netzwerkkartenressource aus, die nicht gelöscht werden kann.
6. Klicken Sie oben auf die Schaltfläche Read/Write und dann auf die Registerkarte Actions(POST, DELETE) direkt darunter.
7. Klicken Sie auf Löschen.
8. Nachdem die Netzwerkkarte gelöscht wurde, löschen Sie den Azure-Cluster.