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.
kubectl
So bereinigen Sie den Zustand von kubectl
, indem Sie bestimmte oder alle Benutzer, Kontexte und Cluster löschen:
Öffnen Sie die Datei ~/.kube/config
.
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.
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
.
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.
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
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.
grafana.secret.*
-Einträge aus der erzeugten Konfigurationsdatei.Erstellen Sie einen geheimen Schlüssel manuell.
kubectl create secret generic grafana -n tanzu-system-dashboards --from-literal=admin=admin
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
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:
|
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.2 basieren tanzu package -Befehle auf kctrl , und das —create-namespace -Flag wird 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. |
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.
StorageClass
führt zu einem Abstimmungsfehler in ArbeitslastclusternProblem
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.
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
.
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
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
Melden Sie sich beim Cluster an und löschen Sie die Worker-Maschinen:
kubectl delete machine worker1 worker2
Schalten Sie in vCenter die Worker-Knoten-VMs aus und löschen Sie sie.
Bearbeiten Sie Maschinen der Steuerungsebene und entfernen Sie den Finalizer-Link:
finalizers:
- machine.cluster.x-k8s.io
Löschen Sie die Maschinen der Steuerungsebene:
kubectl delete machine controlplane1 controlplane2
Schalten Sie in vCenter die VMs der Steuerungsebene aus und löschen Sie sie.
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:
ip link
aus und vergleichen Sie die MTU-Werte der Schnittstelle eth0
. Wenn sie nicht übereinstimmen, ist dies ein Hinweis auf dieses Problem.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
Ü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.
Wenn Sie große MTU-Einstellungen konfigurieren möchten, stellen Sie den Cluster mit Steuerungsebene mit einem höheren MTU-Wert bereit.
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.
Stellen Sie sicher, dass Sie dieselben MTU-Einstellungen für alle Knoten in einem Cluster konfigurieren.
Die Netzwerk-Firewall-Einstellungen müssen Pakete der konfigurierten MTU-Größe zulassen.
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.
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.