Auf dieser Seite wird beschrieben, wie Sie Probleme beim Erstellen und Upgraden 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 möglicherweise bei der Behebung von Problemen 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. Sollten während der Installation Probleme auftreten, können Sie die Bootstrap-Clusterlogs für die Fehlerbehebung verwenden.
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 sich ansehen möchten.Um die Logs direkt vom Bootstrap-Cluster abzurufen, führen Sie während der Clustererstellung und -aktualisierung den folgenden Befehl aus:
docker exec -it gkectl-control-plane bashDieser Befehl öffnet ein Terminal innerhalb des Containers
gkectl-control-plane, der im Bootstrap-Cluster ausgeführt wird.Prüfen Sie die Logs
kubeletundcontainerdmit 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
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, der durch Ausführen des Befehls gkectl diagnose snapshot im Administratorcluster erstellt wird, aber der Prozess wird automatisch ausgelöst. Der Bootstrap-Cluster-Snapshot enthält wichtige Debugging-Informationen für das Erstellen und Upgraden des Administratorclusters. Bei Bedarf können Sie für Cloud Customer Care diesen Snapshot bereitstellen.
Der externe Snapshot enthält Pod-Logs aus dem onprem-admin-cluster-controller, die Sie zum Beheben von Problemen beim Erstellen oder Aktualisieren von Clustern aufrufen können. Die Logs 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 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
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 oder mit der Seesaw-IP-Blockdatei in Konflikt stehen.
Probleme beim Clusterupgrade
In den folgenden Abschnitten finden Sie Tipps zum Beheben von Problemen, die während eines Clusterupgrades auftreten können.
Rollback eines Knotenpools 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 niedriger sein. Wenn die Steuerungsebene beispielsweise Version 1.14 ist, können die Knotenpools die Version 1.14 oder 1.13 haben.
Verfügbare Knotenpoolversionen ansehen
Angenommen, Sie haben vor Kurzem ein Upgrade für die Worker-Knoten und Steuerungsebene Ihres Nutzerclusters von Version 1.13.1-gke.35 auf Version 1.14.0 ausgeführt und dabei ein Problem mit den aktualisierten Worker-Knoten festgestellt. Sie beschließen, einen oder mehrere Knotenpools auf die zuvor ausgeführte Version zurückzusetzen: 1.13.1-gke.35. Bevor Sie mit dem Rollback beginnen können, müssen Sie prüfen, ob die vorherige Version für ein 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 ein Rollback für die Version eines Knotenpools für einzelne Knotenpools durchführen oder mehrere Knotenpools in einem einzigen Schritt zurücksetzen.
Führen Sie die folgenden Schritte aus, um das Rollback einer Knotenpoolversion durchzuführen:
Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von
gkeOnPremVersionauf die vorherige Version. Im folgenden Beispiel erfahren Sie, 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 ausführen
Sie können alle Knotenpools und die Steuerungsebene auf eine neue Patchversion aktualisieren. Dies kann hilfreich sein, wenn Sie ein Rollback zu einer vorherigen 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. Dieses Beispiel verwendet 1.14.1-gke.x.Entfernen Sie für jeden Knotenpool das Feld
gkeOnPremVersionoder legen Sie ihn auf den leeren String fest. Wenn für einen Knotenpool keine Version angegeben ist, wird für den Knotenpool standardmäßig die Version verwendet, die für den Cluster angegeben ist.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 Google Distributed Cloud aktualisieren beschrieben.Prüfen Sie die neue Clusterversion und sehen Sie sich die Versionen an, die für ein 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 gkectl diagnose cluster-Befehl im Cluster aus.
Übergeben Sie das Flag --skip-diagnose-cluster an gkectl upgrade, um die automatische Diagnose zu überspringen.
Upgradeprozess bleibt hängen
Im Hintergrund verwendet Google Distributed Cloud während eines Upgrades den Kubernetes-Befehl drain. 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 Google Distributed Cloud Version 1.13 können Sie Fehler über Kubernetes-Pod-Ereignisse prüfen.
Suchen Sie die Namen der Maschinen:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesSuchen Sie mit dem Befehl
kubectl describe machinenach Fehlern: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 für eine detailliertere Analyse des Maschinenobjektstatus den folgenden Befehl aus:
gkectl diagnose clusterDie 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.
Um dieses Problem zu beheben, speichern Sie das PDB und entfernen Sie es aus dem Cluster, bevor Sie das Upgrade durchführen. Sie können das PDB 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 früher werden Änderungen an den meisten Feldern während des Upgrades unbemerkt 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, die in der Konfigurationsdatei vorgenommen wurden, und geben einen Fehler für nicht unterstützte Änderungen zurück, anstatt sie einfach zu ignorieren. Dieses Feature ist nur für Nutzercluster verfügbar. Beim Upgrade von Administratorclustern werden Änderungen an den meisten Feldern unbemerkt ignoriert und nach dem Upgrade nicht wirksam.
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
}
Sie können diesen Fehler so umgehen:
- Setzen Sie die versuchte Änderung zurück und führen Sie das Upgrade noch einmal aus. Beispiel: Im vorherigen Szenario würden Sie die an der
AutoRepair-Konfiguration vorgenommenen Änderungen rückgängig machen undgkectl upgradenoch einmal ausführen. - Alternativ können Sie Konfigurationsdateien generieren, die dem aktuellen Status des Clusters entsprechen, indem Sie
gkectl get-configausführen, diegkeOnPremVersion-Felder für den Cluster und die Knotenpools in der Konfigurationsdatei aktualisieren undgkectl upgradenoch einmal ausführen.
F5 BIG-IP-Probleme mit der internen kubeconfig-Datei beheben
Nach einer Installation generiert GKE on VMware eine kubeconfig-Datei namens internal-cluster-kubeconfig-debug im Basisverzeichnis der 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.
Probleme mit vSphere beheben
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.
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 neuenkubeconfig-Datei für Ihren Nutzercluster.ADMIN_CLUSTER_KUBECONFIG: der Pfad derkubeconfig-Datei für Ihren Administratorcluster.
Nächste Schritte
- Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.