Auf dieser Seite wird beschrieben, wie Sie Probleme beim Erstellen und Aktualisieren von Clustern in Google Distributed Cloud untersuchen können.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Probleme bei der Installation
Die folgenden Abschnitte können Ihnen bei der Fehlerbehebung bei der Installation von Google Distributed Cloud helfen.
Bootstrap-Cluster zum Beheben von Problemen verwenden
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 Administratorcluster und Ihren Nutzercluster erhalten. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren. Wenn jedoch während der Installation Probleme auftreten, können Sie die Bootstrap-Clusterlogs verwenden, um das Problem zu beheben.
Wenn Sie --cleanup-external-cluster=false an gkectl create cluster übergeben, wird der Bootstrap-Cluster nicht gelöscht und Sie können den Bootstrap-Cluster verwenden, um Installationsprobleme zu beheben.
Logs des Bootstrap-Clusters prüfen
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-systemRufen Sie die Logs für einen Pod auf:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAMEErsetzen Sie
POD_NAMEdurch den Namen des Pods, den Sie aufrufen möchten.Wenn Sie die Logs direkt aus dem Bootstrap-Cluster abrufen möchten, führen Sie während der Clustererstellung, ‐aktualisierung und ‐upgrades den folgenden Befehl aus:
docker exec -it gkectl-control-plane bashMit diesem Befehl wird ein Terminal im
gkectl-control-plane-Container geöffnet, der im Bootstrap-Cluster ausgeführt wird.Verwenden Sie die folgenden Befehle, um die
kubelet- undcontainerd-Logs zu prüfen, 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
Snapshot des Bootstrap-Clusters untersuchen
Wenn Sie versuchen, einen Administratorcluster zu erstellen oder zu aktualisieren, und dieser Vorgang fehlschlägt, erstellt Google Distributed Cloud einen externen Snapshot des Bootstrap-Clusters.
Dieser Snapshot des Bootstrap-Clusters ähnelt dem Snapshot, den Sie mit dem Befehl gkectl diagnose snapshot im Administratorcluster erstellt haben. Der Prozess wird jedoch automatisch ausgelöst. Der Bootstrap-Cluster-Snapshot enthält wichtige Informationen zur Fehlerbehebung für den Erstellungs- und Upgradevorgang des Administratorclusters. Bei Bedarf können Sie Cloud Customer Care diesen Snapshot zur Verfügung stellen.
Der externe Snapshot enthält Pod-Logs aus dem onprem-admin-cluster-controller, die Sie aufrufen können, um Probleme bei der Clustererstellung oder beim Upgrade zu beheben. Die Protokolle werden in einer separaten Datei gespeichert, zum Beispiel:
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
--container_onprem-admin-cluster-controller_ \
--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
--namespace_kube-system
VM startet nach dem Start der Administrator-Steuerungsebene nicht
Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, können Sie das Problem untersuchen. Sehen Sie sich dazu die Logs des Cluster API-Controller-Pods im Administratorcluster an:
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 zuerst den Pod, aber keinen Container an: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
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.
Um dieses Problem zu beheben, aktualisieren Sie die Cluster-IP-Blockdatei so, dass die Maschinenadressen nicht mit den Adressen in Konflikt stehen, die in der Clusterkonfigurationsdatei oder der Seesaw-IP-Blockdatei angegeben sind.
Probleme beim Clusterupgrade
Die folgenden Abschnitte enthalten Tipps zum Beheben von Problemen, die während eines Clusterupgrades auftreten können.
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, für Windows-Knotenpools jedoch nicht.
Die Version eines Knotenpools kann mit der Version der Steuerungsebene des Nutzerclusters identisch sein 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 Ihre Worker-Knoten Ihre Worker-Knoten und die 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. Bevor Sie mit dem Rollback beginnen können, müssen Sie prüfen, ob die vorherige Version für das Rollback verfügbar ist.
Führen Sie den folgenden Befehl aus, um die verfügbaren Versionen anzusehen:
gkectl version --cluster-name USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Die Ausgabe zeigt die aktuelle Version und die vorherige Version für jeden Knotenpool. Beispiel:
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 der Knotenpoolversion durchführen
Sie können für die aktuelle Version eines Knotenpools ein Rollback durchführen oder für mehrere Knotenpools in einem einzigen Schritt ein Rollback durchführen.
Führen Sie die folgenden Schritte aus, um ein Rollback einer Knotenpoolversion durchzuführen:
Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von
gkeOnPremVersionauf die vorherige Version fest. Das folgende Beispiel zeigt, wie Sie ein Rollback auf Version 1.13.1-gke.35 durchführen: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_KUBECONFIGPrüfen Sie, ob das Rollback erfolgreich war:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGDie folgende Ausgabe zeigt, dass für
pool-1ein 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
Sie können alle Knotenpools und die Steuerungsebene auf eine neue Patchversion aktualisieren. Dies kann hilfreich sein, wenn Sie ein Rollback auf eine frühere Version durchgeführt haben und ein Upgrade auf eine Version durchführen möchten, die eine Fehlerkorrektur enthält.
Führen Sie die folgenden Schritte aus, um ein Upgrade auf eine neue Version durchzuführen:
Nehmen Sie die folgenden Änderungen in der Konfigurationsdatei des Nutzerclusters vor:
Legen Sie den Wert von
gkeOnPremVersionauf eine neue Patchversion fest. In diesem Beispiel wird 1.14.1-gke.x verwendet.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.Diese Änderungen sehen in etwa so aus:
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 prepareundgkectl upgrade clusteraus, wie unter Upgrade auf Google Distributed Cloud ausführen beschrieben.Prüfen Sie die neue Clusterversion und die Versionen, die für das Rollback verfügbar sind:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGDie Ausgabe sieht in etwa so aus:
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 ```
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 Google Distributed Cloud automatisch den Befehl gkectl diagnose cluster auf dem Cluster aus.
Wenn Sie die automatische Diagnose überspringen möchten, übergeben Sie das Flag --skip-diagnose-cluster an gkectl upgrade.
Upgradeprozess bleibt hängen
Im Hintergrund verwendet Google Distributed Cloud während eines Upgrades den Kubernetes-Befehl drain. Diese drain-Prozedur kann von einem Deployment mit nur einem Replikat blockiert werden, für das ein PodDisruptionBudget (PDB) mit minAvailable: 1 erstellt wurde.
Ab Version 1.13 von Google Distributed Cloud können Sie Fehler über Kubernetes-Pod-Ereignisse überprüfen.
Suchen Sie nach den Namen der Maschinen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesPrüfen Sie mit dem Befehl
kubectl describe machine, ob Fehler aufgetreten sind:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAMEDie Ausgabe sieht in etwa so aus:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.Optional: Führen Sie
gkectl diagnose clusteraus, um eine detailliertere Analyse des Maschinenobjektstatus zu erhalten.Die Ausgabe sieht in etwa so 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.
Speichern Sie das PDB und entfernen Sie es aus dem Cluster, bevor Sie das Upgrade ausführen, um dieses Problem zu beheben. Sie können das PDB dann nach Abschluss des Upgrades wieder hinzufügen.
Nicht unterstützte Änderungen entfernen, um die Blockierung des Upgrades aufzuheben
Beim Upgrade von Clustern auf Version 1.16 oder niedriger 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 Änderungen in der Konfigurationsdatei und geben einen Fehler für nicht unterstützte Änderungen zurück, anstatt sie einfach zu ignorieren. Diese Funktion ist nur für Nutzercluster verfügbar. Beim Upgrade von Administratorclustern werden Änderungen an den meisten Feldern ignoriert und nach dem Upgrade nicht mehr übernommen.
Wenn Sie beispielsweise versuchen, die automatische Knotenreparatur zu deaktivieren, wenn Sie für einen Nutzercluster ein Upgrade auf 1.28 durchführen, 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 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.
F5 BIG-IP-Probleme mit der internen kubeconfig-Datei beheben
Nach der Installation generiert GKE on VMware im Basisverzeichnis Ihrer Administrator-Workstation eine kubeconfig-Datei mit dem Namen internal-cluster-kubeconfig-debug. 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.
Probleme mit vSphere beheben
Sie können govc verwenden, um Probleme mit vSphere zu untersuchen. Sie können beispielsweise Berechtigungen und den Zugriff für Ihre vCenter-Nutzerkonten bestätigen und vSphere-Logs erfassen.
Fehlende kubeconfig-Datei des Nutzerclusters neu erstellen
In den folgenden Situationen kann es sinnvoll sein, die kubeconfig-Datei eines Nutzerclusters neu zu erstellen:
- Wenn Sie versuchen, einen Nutzercluster zu erstellen, 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 neuenkubeconfig-Datei für Ihren Nutzercluster.ADMIN_CLUSTER_KUBECONFIG: der Pfad der Dateikubeconfigfür Ihren Administratorcluster.
Nächste Schritte
- Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.