Das gkectl-Tool hat zwei Befehle zur Fehlerbehebung bei Clustern: gkectl diagnose cluster und gkectl diagnose snapshot. Die Befehle sind sowohl für Administrator- als auch für Nutzercluster verfügbar. In diesem Dokument erfahren Sie, wie Sie mit dem Befehl gkectl diagnose Probleme in Clustern diagnostizieren können.
Weitere Informationen zur Verwendung des Befehls gkectl diagnose snapshot zum Erstellen von Snapshots, die Cloud Customer Care bei der Diagnose von Problemen helfen können, finden Sie unter Snapshots zur Diagnose von Clustern erstellen.
gkectl diagnose cluster
Mit diesem Befehl werden Systemdiagnosen für den Cluster durchgeführt und Fehler gemeldet. Der Befehl führt Systemdiagnosen für die folgenden Komponenten aus:
- vCenter
- Anmeldedaten
- DRS
- Anti-Affinitätsgruppen
- Netzwerk
- Version
- Rechenzentrum
- Datastore
- ResourcePool
- Ordner
- Netzwerk
- Load Balancer (F5, Seesaw oder manuell)
- Nutzercluster und Knotenpools
- Clusterobjekte
- Bereitschaft des Konnektivitätsservers für den Nutzercluster
- Maschinenobjekte und die entsprechenden Clusterknoten
- Pods in den Namespaces
kube-systemundgke-system - Steuerungsebene
- Nichtflüchtige vSphere-Volumes im Cluster
- Signale zur vCPU (virtuellen CPU) des Nutzer- und Administratorclusters und Speicherkonflikten
- Vorkonfigurierte ESXi-Alarme für die Host-CPU- und Speichernutzung von Nutzer- und Administratorclustern
- Tageszeit (TOD)
- Knotennetzwerkrichtlinie für einen Cluster mit aktivierter Dataplane V2
- Gesamtzustand des Dataplane V2-Knoten-Agents
Administratorcluster diagnostizieren
Geben Sie den Pfad zu Ihrem Administratorcluster an, um einen Administratorcluster zu diagnostizieren:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei Ihres Administratorclusters.
Der Befehl gkectl diagnose cluster gibt die folgende Beispielausgabe zurück:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS
- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
Wenn ein Problem mit einer virtuellen IP-Adresse (VIP) im Zielcluster auftritt, verwenden Sie das Flag --config, um die Konfigurationsdatei des Administratorclusters bereitzustellen und weitere Debugging-Informationen bereitzustellen.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Ersetzen Sie CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei des Administrator- oder Nutzerclusters.
Die folgende Beispielausgabe zeigt, dass der Befehl gkectl diagnose cluster jetzt eine korrekte Verbindung zum Cluster herstellen und auf Probleme prüfen kann:
Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...
Nutzercluster diagnostizieren
Zur Diagnose eines Nutzerclusters müssen Sie den Namen des Nutzerclusters angeben. Führen Sie den folgenden Befehl aus, um den Namen eines Nutzerclusters abzurufen:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Geben Sie den Namen des Nutzerclusters zusammen mit der Konfigurationsdatei so an:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name=USER_CLUSTER_NAME
Ersetzen Sie USER_CLUSTER_NAME durch den Namen des Nutzerclusters.
Der Befehl gkectl diagnose cluster gibt die folgende Beispielausgabe zurück:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>
- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success
- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
Status von virtuellen Maschinen diagnostizieren
Wenn bei der Erstellung virtueller Maschinen ein Problem auftritt, führen Sie gkectl diagnose cluster aus, um eine Diagnose des VM-Status zu erhalten.
Die Ausgabe sieht in etwa so aus:
- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
Reason: 1 machine VMs error(s).
Unhealthy Resources:
Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
Debug Information:
null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot
Fehlerbehebung
Die folgende Tabelle enthält einige mögliche Lösungen für Probleme beim Ausführen des Befehls gkectl diagnose cluster:
| Problem | Mögliche Ursachen | Lösung |
|---|---|---|
| Der Kubernetes API-Server ist weder für den Administratorcluster noch für Nutzercluster erreichbar. | Sehen Sie sich die Diagramme zur Speicherlatenz des virtuellen Maschinenstatus (Out-of-Box, OOB) an, die idealerweise eine Speicherlatenz um null aufweisen. Speicherkonflikte können auch CPU-Konflikte erhöhen und die CPU-Bereitschaftskurven können möglicherweise eine Spitze zeigen, da es zu Auslagerung kommt. | Mehr physischen Speicher erhalten. Weitere Optionen finden Sie unter Vorschläge zur Fehlerbehebung für VMware. |
| Zeitüberschreitung beim Erstellen des Knotenpools. | Hohe Lese-/Schreiblatenz des VMDK Prüfen Sie den OOB-Status der VM auf die Lese- und Schreiblatenz für virtuelle Laufwerke. Laut VMware weist eine Gesamtlatenz von mehr als 20 ms auf ein Problem hin. | Weitere Informationen finden Sie unter VMware-Lösungen für Probleme mit der Laufwerksleistung. |
BundleUnexpectedDiff Fehler
Die Kubernetes Cluster API-Ressource, die von einem Google Distributed Cloud-Bundle verwaltet wird, kann versehentlich geändert werden, was zu Fehlern bei Systemkomponenten oder Clusterupgrades oder -updates führen kann.
In Google Distributed Cloud Version 1.13 und höher prüft onprem-user-cluster-controller regelmäßig den Status von Objekten und meldet unerwartete Abweichungen vom gewünschten Zustand über Logs und Ereignisse. Zu diesen Objekten gehören die Steuerungsebene des Nutzerclusters und Add-ons wie Dienste und DaemonSets.
Die folgende Beispielausgabe zeigt ein unerwartetes Differenzereignis:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning BundleUnexpectedDiff 13m onpremusercluster/ci-bundle-diff Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.
Die folgende Beispielausgabe zeigt Logs, die von onprem-user-cluster-controller generiert wurden:
2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252 1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff: map[string]string{
2022-08-06T02:54:42.701376406Z - "mesh": (
2022-08-06T02:54:42.701381190Z - """
2022-08-06T02:54:42.701385438Z - defaultConfig:
2022-08-06T02:54:42.701389350Z - discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z - """
2022-08-06T02:54:42.701453099Z - ),
2022-08-06T02:54:42.701456286Z - "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z + "test-key": "test-data",
2022-08-06T02:54:42.701462434Z }
Die Ereignisse und Logs blockieren den Clustervorgang nicht. Objekte, die unerwartete Abweichungen vom gewünschten Status aufweisen, werden beim nächsten Clusterupgrade überschrieben.