Probleme bei der Installation oder Aktualisierung von Clustern beheben

Auf dieser Seite finden Sie Informationen zur Fehlerbehebung, wenn bei der Installation oder dem Upgrade von GKE on Bare Metal Probleme auftreten.

Bootstrap-Clusterprobleme

Wenn GKE on Bare Metal Cluster erstellt oder aktualisiert, wird ein Kubernetes in Docker-Cluster (Art) bereitgestellt, um vorübergehend die Kubernetes-Controller zu hosten, die zum Erstellen oder Upgraden von Clustern erforderlich sind. Dieser temporäre Cluster wird als Bootstrap-Cluster bezeichnet.

Wenn bei der Installation bereits ein Artcluster in Ihrer Bereitstellung vorhanden ist, löscht GKE on Bare Metal den vorhandenen Typcluster. Der Löschvorgang erfolgt erst, nachdem die Installation oder das Upgrade erfolgreich war. Wenn Sie den vorhandenen Typcluster auch nach Erfolg beibehalten möchten, verwenden Sie das Flag --keep-bootstrap-cluster von bmctl.

GKE on Bare Metal erstellt eine Konfigurationsdatei für den Bootstrap-Cluster unter WORKSPACE_DIR/.kindkubeconfig. Sie können eine Verbindung zum Bootstrap-Cluster nur während der Erstellung und des Upgrades des Clusters herstellen.

Der Bootstrap-Cluster muss auf ein Docker-Repository zugreifen, um Images abrufen zu können. Die Registry verwendet standardmäßig Container Registry, es sei denn, Sie verwenden eine private Registry. Während der Clustererstellung erstellt bmctl die folgenden Dateien:

  • bmctl-workspace/config.json: enthält Anmeldedaten für das Google Cloud-Dienstkonto für den Registry-Zugriff. Die Anmeldedaten werden aus dem Feld gcrKeyPath in der Clusterkonfigurationsdatei abgerufen.

  • bmctl-workspace/config.toml: Enthält die containerd-Konfiguration im kind-Cluster.

Fehler beim Bootstrap-Cluster beheben

So beheben Sie Fehler beim Bootstrap-Cluster:

  • Stellen Sie während der Clustererstellung und -aktualisierung eine Verbindung zum Bootstrap-Cluster her.
  • Rufen Sie die Logs des Bootstrap-Clusters ab.

Sie finden die Logs auf dem Computer, auf dem Sie bmctl ausführen, in den folgenden Ordnern:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Ersetzen Sie CLUSTER_NAME und TIMESTAMP durch den Namen Ihres Clusters und die Zeit des entsprechenden Systems.

Um die Logs direkt vom Bootstrap-Cluster abzurufen, können Sie während der Clustererstellung und -aktualisierung den folgenden Befehl ausführen:

docker exec -it bmctl-control-plane bash

Der Befehl öffnet ein Terminal innerhalb des Containers der bmctl-Steuerungsebene, der im Bootstrap-Cluster ausgeführt wird.

Prüfen Sie die Logs kubelet und containerd mit den folgenden Befehlen und suchen Sie in der Ausgabe nach Fehlern oder Warnungen:

journalctl -u kubelet
journalctl -u containerd

Probleme beim Clusterupgrade

Wenn Sie GKE on Bare Metal upgraden, können Sie den Fortschritt überwachen und den Status Ihrer Cluster und Knoten prüfen. Anhand der folgenden Anleitung können Sie feststellen, ob das Upgrade wie gewohnt fortgesetzt wird oder ob ein Problem auftritt.

Fortschritt des Upgrades beobachten

Verwenden Sie den Befehl kubectl describe cluster, um während des Upgrades den Status eines Clusters anzusehen:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Ersetzen Sie die folgenden Werte:

  • CLUSTER_NAME ist der Name des Clusters.
  • CLUSTER_NAMESPACE ist der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG ist die kubeconfig-Administratordatei.
    • Standardmäßig wird ein Bootstrap-Cluster für Administrator-, Hybrid- und eigenständige Clusterupgrades verwendet. Wenn Sie den Upgradefortschritt überwachen möchten, wenn ein Bootstrap-Cluster verwendet wird, geben Sie den Pfad zur kubeconfig-Datei des Bootstrap-Clusters an: .kindkubeconfig. Diese Datei befindet sich im Arbeitsbereichsverzeichnis.

Im Abschnitt Status der Ausgabe sehen Sie eine Zusammenfassung des Clusterupgrade-Status. Wenn der Cluster einen Fehler meldet, finden Sie in den folgenden Abschnitten Informationen dazu, wo das Problem auftritt.

Prüfen, ob die Knoten bereit sind

Verwenden Sie den Befehl kubectl get nodes, um während des Upgrades den Status der Knoten in einem Cluster anzusehen:

kubectl get nodes --kubeconfig KUBECONFIG

Sehen Sie sich in der Befehlsantwort die Spalten VERSION und AGE an, um zu prüfen, ob ein Knoten den Upgradeprozess erfolgreich abgeschlossen hat. VERSION ist die Kubernetes-Version für den Cluster. Informationen zur Kubernetes-Version einer bestimmten GKE on Bare Metal-Version finden Sie in der Tabelle unter Supportrichtlinie für Versionen.

Wenn für den Knoten NOT READY angezeigt wird, versuchen Sie, den Knoten zu verbinden, und prüfen Sie den Status des kubelet:

systemctl status kubelet

Sie können auch die Kubelet-Logs überprüfen:

journalctl -u kubelet

Überprüfen Sie die Ausgabe des Kubelet-Status und der Logs zu Meldungen, die angeben, warum beim Knoten ein Problem vorliegt.

Prüfen, welcher Knoten gerade aktualisiert wird

Mit dem Befehl kubectl get baremetalmachines können Sie prüfen, welcher Knoten im Cluster gerade aktualisiert wird:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Ersetzen Sie die folgenden Werte:

  • CLUSTER_NAMESPACE ist der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG ist die kubeconfig-Administratordatei.
    • Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder eigenständiges Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters (bmctl-workspace/.kindkubeconfig) an.

Die folgende Beispielausgabe zeigt, dass sich der ABM VERSION des Knotens, der gerade aktualisiert wird, vom DESIRED ABM VERSION unterscheidet:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Prüfen, welche Knoten gerade per Drain beendet werden

Während des Upgradeprozesses werden Pods per Drain beendet und die Planung ist deaktiviert, bis das Upgrade des Knotens erfolgreich abgeschlossen wurde. Verwenden Sie den Befehl kubectl get nodes, um zu sehen, welche Knoten derzeit von Pods per Drain beendet werden:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Nutzerclusters.

Die Spalte STATUS wird mit grep so gefiltert, dass nur Knoten angezeigt werden, die SchedulingDisabled melden. Dieser Status zeigt an, dass die Knoten gerade per Drain beendet werden.

Sie können den Knotenstatus auch über den Administratorcluster prüfen:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Ersetzen Sie die folgenden Werte:

  • CLUSTER_NAMESPACE ist der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG ist die kubeconfig-Administratordatei.
    • Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder eigenständiges Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters (bmctl-workspace/.kindkubeconfig) an.

Für den Knoten, der per Drain beendet wird, wird der Status in der Spalte MAINTENANCE angezeigt.

Prüfen, warum ein Knoten lange Zeit den Draining-Status hat

Verwenden Sie eine der Methoden im vorherigen Abschnitt, um den entleerten Knoten mit dem Befehl kubectl get nodes zu ermitteln. Verwenden Sie den Befehl kubectl get pods und filtern Sie nach diesem Knotennamen, um weitere Details anzusehen:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Ersetzen Sie NODE_NAME durch den Namen des Knotens, der per Drain beendet wird. Die Ausgabe gibt eine Liste von Pods zurück, die derzeit hängen bleiben oder langsam per Drain beendet werden. Das Upgrade wird auch bei hängenden Pods fortgesetzt, wenn der Ausgleichsprozess für einen Knoten mehr als 20 Minuten dauert.