Auf dieser Seite wird beschrieben, wie Sie Probleme beim Erstellen, Upgraden und Anpassen der Größe von Clustern in GKE on VMware untersuchen können.
Standard-Logging-Verhalten für gkectl und gkeadm
Für gkectl und gkeadm reicht es aus, die Standard-Logging-Einstellungen zu verwenden:
Für
gkectlist die Standard-Logdatei/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).logper Symlink mit der Dateilogs/gkectl-$(date).logim lokalen Verzeichnis verknüpft, in dem Siegkectlausführen.Für
gkeadmbefindet sich die Standard-Logdateilogs/gkeadm-$(date).logim lokalen Verzeichnis, in dem Siegkeadmausführen.Die Ausführlichkeitsstufe
-v5(Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.Die Logdatei enthält den ausgeführten Befehl und die Fehlermeldung.
Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.
Nicht-Standardstandorte für Logdateien festlegen
Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl angeben möchten, verwenden Sie das Flag --log_file. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.
Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm angeben möchten, verwenden Sie das Flag --log_file.
Cluster-API-Logs im Administratorcluster suchen
Wenn eine VM nicht gestartet wird, nachdem die Administrator-Steuerungsebene gestartet wurde, können Sie das Problem untersuchen. Dazu prüfen Sie die Logs des Pods der Cluster API-Controllers im Administratorcluster.
Suchen Sie den Namen des Pods der Cluster API-Controllers:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllersSehen Sie sich die Logs des
vsphere-controller-manageran. Geben Sie als Erstes den Pod an, aber keinen Container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEDie Ausgabe zeigt Ihnen, dass Sie einen Container angeben müssen, und gibt Ihnen die Namen der Container im Pod. Beispiel:
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Wählen Sie einen Container aus und rufen Sie dessen Logs auf:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Artcluster wird nicht gelöscht
Wenn Sie einen Administratorcluster erstellen, wird dabei ein kind-Cluster (auch Bootstrap-Cluster genannt) erstellt. Wenn der Vorgang des Administratorclusters abgeschlossen ist, wird der Cluster kind automatisch gelöscht.
Wenn die Fehlermeldung Failed to delete the kind cluster angezeigt wird, können Sie die folgenden Schritte auf Ihrer Administratorworkstation ausführen, um den Cluster kind manuell zu löschen:
Rufen Sie die Container-ID
kindab:docker inspect --format="{{.Id}}" gkectl-control-planeRufen Sie die Prozess-ID
containerd-shimab:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Beenden Sie den Prozess:
sudo kill -9 PROCESS_ID
Verwendung von govc zur Behebung von Problemen mit vSphere
Sie können govc verwenden, um Probleme mit vSphere zu untersuchen. Beispielsweise können Sie die Berechtigungen und den Zugriff für Ihre vCenter-Nutzerkonten bestätigen und vSphere-Logs erfassen.
Debugging mit den Logs des Bootstrap-Clusters
Während der Installation erstellt GKE on VMware einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht GKE on VMware den Bootstrap-Cluster, sodass Sie Ihren Administrator- und Nutzercluster haben. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren.
Wenn Sie --cleanup-external-cluster=false an gkectl create cluster übergeben, wird der Bootstrap-Cluster nicht gelöscht und Sie können die Logs des Bootstrap-Clusters verwenden, um Installationsprobleme zu beheben.
Suchen Sie die Namen der Pods, die im Namespace
kube-systemausgeführt werden:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
Rufen Sie die Logs für einen Pod auf:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
Um die Logs direkt aus dem Bootstrap-Cluster abzurufen, können Sie den folgenden Befehl während der Clustererstellung, -aktualisierung und -upgrades ausführen:
docker exec -it gkectl-control-plane bash
Der Befehl öffnet ein Terminal im Container der gkectl-Steuerungsebene, der im Bootstrap-Cluster ausgeführt wird.
Prüfen Sie die kubelet- und containerd-Logs mit den folgenden Befehlen und suchen Sie in der Ausgabe nach Fehlern oder Warnungen:
systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
Rollback für einen Knotenpool nach einem Upgrade durchführen
Wenn Sie einen Nutzercluster upgraden und dann ein Problem mit den Clusterknoten feststellen, können Sie für ausgewählte Knotenpools ein Rollback auf die vorherige Version durchführen.
Das Rollback für ausgewählte Knotenpools wird für Ubuntu- und COS-Knotenpools unterstützt, aber nicht für Windows-Knotenpools.
Die Version eines Knotenpools kann mit der Version der Steuerungsebene des Nutzerclusters identisch oder eine Nebenversion älter sein. Wenn sich die Steuerungsebene beispielsweise in der Version 1.14 befindet, können die Knotenpools die Version 1.14 oder 1.13 haben.
Verfügbare Knotenpoolversionen ansehen
Angenommen, Sie haben kürzlich ein Upgrade Ihres Nutzerclusters und Ihrer Steuerungsebene von Version 1.13.1-gke.35 auf Version 1.14.0 aktualisiert und dabei ein Problem mit den aktualisierten Worker-Knoten festgestellt. Daher beschließen Sie, für einen oder mehrere Knotenpools ein Rollback auf die zuvor ausgeführte Version durchzuführen: 1.13.1-gke.35.
Prüfen Sie, ob die vorherige Version für ein Rollback verfügbar ist:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Rollback für Knotenpools durchführen
Sie können für einen Knotenpool ein Rollback nach dem anderen oder für mehrere Knotenpools in einem Schritt ein Rollback durchführen.
Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von gkeOnPremVersion auf die vorherige Version fest: 1.13.1-gke.35 in diesem Beispiel:
nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...
Aktualisieren Sie den Cluster, um ein Rollback für die Knotenpools durchzuführen:
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Prüfen Sie, ob das Rollback ausgeführt wird:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
pool-1 ein Rollback auf Version 1.13.1-gke.35 durchgeführt wurde.
user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Upgrade auf eine neue Patchversion durchführen
Angenommen, das Problem wurde in einer neuen Patchversion, z. B. 1.14.1, behoben. Jetzt können Sie alle Knotenpools und die Steuerungsebene auf die neue Patchversion aktualisieren.
In der Konfigurationsdatei des Nutzerclusters:
Legen Sie den Wert von
gkeOnPremVersionauf die neue Patchversion fest, in diesem Beispiel 1.14.1-gke.x.Entfernen Sie für jeden Knotenpool das Feld
gkeOnPremVersionoder legen Sie dafür den leeren String fest. Wenn für einen Knotenpool keine Version angegeben ist, wird standardmäßig die für den Cluster angegebene Version für den Knotenpool verwendet.
Beispiel:
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
Führen Sie gkectl prepare und gkectl upgrade cluster aus, wie unter Upgrade von GKE on VMware beschrieben.
Überprüfen Sie die neue Clusterversion und sehen Sie sich die Versionen an, die jetzt für ein Rollback verfügbar sind:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y
Fehlerbehebung bei F5 BIG-IP-Problemen mithilfe der internen kubeconfig-Datei
Nach einer Installation generiert GKE on VMware eine kubeconfig-Datei mit dem Namen internal-cluster-kubeconfig-debug im Basisverzeichnis Ihrer Administrator-Workstation. Diese Datei „kubeconfig“ ist identisch mit der „kubeconfig“-Datei Ihres Administratorclusters, mit der Ausnahme, dass sie direkt auf den Steuerungsebenenknoten des Administratorclusters verweist, auf dem der Kubernetes API-Server ausgeführt wird. Sie können die Datei internal-cluster-kubeconfig-debug verwenden, um F5 BIG-IP-Probleme zu beheben.
Anpassen der Größe eines Nutzerclusters schlägt fehl
Wenn die Größenanpassung eines Nutzerclusters fehlschlägt:
Suchen Sie die Namen der MachineDeployments und der Maschinen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Beschreiben Sie ein MachineDeployment, um dessen Logs aufzurufen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
Prüfen Sie, ob auf neu erstellten Maschinen Fehler vorliegen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Für die Clustergrößenanpassung können keine Adressen zugewiesen werden
Dieses Problem tritt auf, wenn nicht genügend IP-Adressen zur Größenanpassung eines Nutzerclusters verfügbar sind.
kubectl describe machine zeigt den folgenden Fehler an:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
Weisen Sie diesem Cluster weitere IP-Adressen zu, um dieses Problem zu beheben. Löschen Sie dann die betroffene Maschine:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME
GKE on VMware erstellt eine neue Maschine und weist ihr eine der neu verfügbaren IP-Adressen zu.
Ausreichende Anzahl von zugewiesenen IP-Adressen, aber Maschine kann sich nicht beim Cluster registrieren
Dieses Problem kann auftreten, wenn ein IP-Adresskonflikt vorliegt. Beispiel: Eine IP-Adresse, die Sie für eine Maschine angegeben haben, wird für einen Load-Balancer verwendet.
Dieses Problem können Sie beheben, indem Sie Ihre Cluster-IP-Blockdatei aktualisieren, damit die Maschinenadressen nicht mit den Adressen in der Clusterkonfigurationsdatei in Konflikt stehen oder mit der Seesaw-IP-Blockdatei.
Snapshot wird automatisch erstellt, wenn das Erstellen oder Upgrade des Administratorclusters fehlschlägt.
Wenn Sie versuchen, einen Administratorcluster zu erstellen oder zu aktualisieren, und dieser Vorgang fehlschlägt, erstellt GKE on VMware einen externen Snapshot des Bootstrap-Clusters. Dies ist ein temporärer Cluster, der zum Erstellen oder Aktualisieren des Administratorclusters verwendet wird. Obwohl dieser Snapshot des Bootstrap-Clusters dem Snapshot ähnelt, der durch Ausführen des Befehls gkectl diagnose snapshot im Administratorcluster erstellt wird, wird dieser stattdessen automatisch ausgelöst. Dieser Snapshot des Bootstrap-Clusters enthält wichtige Debugging-Informationen für den Erstellungs- und Upgradeprozess des Administratorclusters. Bei Bedarf können Sie für den Google Cloud-Support diesen Snapshot bereitstellen.
Der externe Snapshot enthält Pod-Logs aus dem onprem-admin-cluster-controller, die Sie aufrufen können, um Probleme bei der Clustererstellung oder -upgrades zu beheben. Die Protokolle werden in einer separaten Datei gespeichert, z. B.:
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system
Systemdiagnosen werden automatisch ausgeführt, wenn das Cluster-Upgrade fehlschlägt
Wenn Sie versuchen, einen Administrator- oder Nutzercluster zu aktualisieren, und dieser Vorgang fehlschlägt, führt GKE on VMware automatisch den Befehl gkectl diagnose cluster auf dem Cluster aus.
Übergeben Sie das Flag --skip-diagnose-cluster an gkectl upgrade, um die automatische Diagnose zu überspringen.
Upgradeprozess bleibt hängen
GKE on VMware verwendet im Hintergrund den Kubernetes-Befehl drain während eines Upgrades. Diese drain-Prozedur kann durch ein Deployment mit nur einem Replikat blockiert werden, für das ein PodDisruptionBudget (PDB) mit minAvailable: 1 erstellt wurde.
Ab Version 1.13 von GKE on VMware können Sie Fehler über Kubernetes-Pod-Ereignisse prüfen.
Suchen Sie die Namen der Maschinen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Prüfen Sie mit dem Befehl
kubectl describe machine, ob Fehler aufgetreten sind:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Hier ist eine Beispielausgabe:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.
Für eine detailliertere Analyse des Status der Maschinenobjekte führen Sie gkectl diagnose cluster aus:
...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
Reason: 1 machine objects error(s).
Unhealthy Resources:
Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
Reason: 1 pod disruption budget error(s).
Unhealthy Resources:
PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.
Um dieses Problem zu beheben, speichern Sie das PDB und entfernen Sie es aus dem Cluster, bevor Sie versuchen, ein Upgrade durchzuführen. Sie können das PDB nach Abschluss des Upgrades wieder hinzufügen.
Status von virtuellen Maschinen diagnostizieren
Wenn beim Erstellen der virtuellen Maschine ein Problem auftritt, führen Sie gkectl diagnose cluster aus, um eine Diagnose des VM-Status abzurufen.
Hier ein Beispiel für eine Ausgabe:
- 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
Weitere Informationen finden Sie unter Clusterprobleme diagnostizieren.
Fehlende kubeconfig-Datei des Nutzerclusters neu erstellen
In einigen Situationen kann es sein, dass Sie eine kubeconfig-Datei des Nutzerclusters neu erstellen möchten:
- Wenn Sie versuchen, einen Nutzercluster zu erstellen, und der Erstellungsvorgang fehlschlägt und Sie die kubeconfig-Datei des Nutzerclusters haben möchten.
- Wenn die kubeconfig-Datei des Nutzerclusters fehlt, z. B. nach dem Löschen.
Führen Sie den folgenden Befehl aus, um die kubeconfig-Datei des Nutzerclusters neu zu erstellen:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
Ersetzen Sie Folgendes:
- USER_CLUSTER_KUBECONFIG: der Name der neuen kubeconfig-Datei für Ihren Nutzercluster.
- ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für Ihren Administratorcluster
Entfernen Sie nicht unterstützte Änderungen, um die Blockierung des Upgrades aufzuheben
Beim Upgrade von Clustern auf 1.16 oder frühere Versionen werden Änderungen an den meisten Feldern während des Upgrades im Hintergrund ignoriert. Das bedeutet, dass diese Änderungen während und nach dem Upgrade nicht wirksam werden.
Beim Upgrade von Nutzerclustern auf Version 1.28 oder höher validieren wir alle in der Konfigurationsdatei vorgenommenen Änderungen und geben einen Fehler für nicht unterstützte Änderungen zurück, anstatt sie einfach zu ignorieren. Wenn Sie beispielsweise versuchen, die automatische Knotenreparatur beim Upgrade eines Nutzerclusters auf 1.28 zu deaktivieren, schlägt das Upgrade mit der folgenden Fehlermeldung fehl:
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
Wenn Sie diesen Fehler umgehen müssen, können Sie das Problem folgendermaßen umgehen:
- Machen Sie die gewünschte Änderung rückgängig und führen Sie das Upgrade dann noch einmal aus. Im vorherigen Szenario würden Sie beispielsweise die Änderungen an der Konfiguration
AutoRepairzurücksetzen und danngkectl upgradenoch einmal ausführen. - Alternativ können Sie Konfigurationsdateien generieren, die dem aktuellen Status des Clusters entsprechen. Dazu führen Sie
gkectl get-configaus, aktualisieren diegkeOnPremVersion-Felder für den Cluster und die Knotenpools in der Konfigurationsdatei und führen danngkectl upgradenoch einmal aus.
gkectl-Befehlsfehler bei Verwendung von VPC Service Controls
Wenn Sie VPC Service Controls verwenden, werden beim Ausführen einiger gkectl-Befehle wie "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services" möglicherweise Fehler angezeigt. Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.