Probleme bei der Clusterinstallation oder dem Upgrade beheben

Auf dieser Seite finden Sie Informationen zur Fehlerbehebung, wenn beim Installieren oder Aktualisieren von GKE on Bare-Metal-Clustern Probleme auftreten.

Bootstrap-Clusterprobleme

Wenn GKE on Bare Metal selbstverwaltete (Administrator-, Hybrid- oder eigenständige) Cluster erstellt, wird ein Kubernetes in Docker-Cluster (Art) bereitgestellt, um vorübergehend die Kubernetes-Controller zu hosten, die zum Erstellen von Clustern erforderlich sind. Dieser temporäre Cluster wird als Bootstrap-Cluster bezeichnet. Nutzercluster werden vom verwaltenden Administrator- oder Hybridcluster ohne Verwendung eines Bootstrap-Clusters erstellt und aktualisiert.

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

GDCV for 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 ist standardmäßig auf Container Registry eingestellt, sofern Sie keine private Registry verwenden. 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

Mit dem Befehl wird ein Terminal im Container der bmctl-Steuerungsebene geöffnet, 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-Cluster 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 ein Problem auftritt.

Upgradefortschritt überwachen

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

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: der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG: die kubeconfig-Datei des Administrators
    • Standardmäßig verwenden Administrator-, Hybrid- und eigenständige Cluster ein direktes Upgrade. Wenn Sie das Flag --use-bootstrap=true mit dem Befehl bmctl upgrade verwenden, verwendet der Upgradevorgang einen Bootstrap-Cluster. Geben Sie den Pfad zur kubeconfig-Datei des Bootstrap-Clusters (.kindkubeconfig) an, um den Fortschritt des Upgrades bei der Verwendung eines Bootstrap-Clusters zu beobachten. Diese Datei befindet sich im Arbeitsbereich-Verzeichnis.

Im Abschnitt Status der Ausgabe finden 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 von Knoten in einem Cluster anzusehen:

kubectl get nodes --kubeconfig KUBECONFIG

In den Spalten VERSION und AGE in der Befehlsantwort können Sie prüfen, ob ein Knoten den Upgradeprozess erfolgreich abgeschlossen hat. VERSION ist die Kubernetes-Version für den Cluster. Die Kubernetes-Version für eine bestimmte GDCV für Bare-Metal-Version finden Sie in der Tabelle in der Richtlinie zur Versionsunterstützung.

Wenn für den Knoten NOT READY angezeigt wird, versuchen Sie, eine Verbindung zum Knoten herzustellen und den Kubelet-Status zu prüfen:

systemctl status kubelet

Sie können sich auch die Kubelet-Logs ansehen:

journalctl -u kubelet

Sehen Sie sich die Ausgabe des Kubelet-Status und der Logs zu Meldungen an, die angeben, warum auf dem Knoten ein Problem aufgetreten ist.

Prüfen, welcher Knoten 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: der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG: die kubeconfig-Datei des Administrators
    • 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 zu aktualisierenden Knotens 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 per Drain beendet werden

Während des Upgrades werden Pods per Drain beendet und die Planung ist deaktiviert, bis das Upgrade des Knotens erfolgreich abgeschlossen wurde. Mit dem Befehl kubectl get nodes können Sie feststellen, welche Knoten von Pods entleert 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 gefiltert, sodass 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 vom Administratorcluster aus prüfen:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Ersetzen Sie die folgenden Werte:

  • CLUSTER_NAMESPACE: der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG: die kubeconfig-Datei des Administrators
    • 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.

Der Knoten, der per Drain beendet wird, zeigt den Status in der Spalte MAINTENANCE an.

Prüfen, warum ein Knoten seit langer Zeit den Status des Draining-Status hat

Verwenden Sie eine der im vorherigen Abschnitt beschriebenen Methoden, um den entleerten Knoten mit dem Befehl kubectl get nodes zu ermitteln. Verwenden Sie den Befehl kubectl get pods und einen Filter für diesen Knotennamen, um zusätzliche 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 der Pods zurück, die feststecken oder langsam per Drain beenden. Das Upgrade wird auch bei hängen gebliebenen Pods fortgesetzt, wenn der Draining-Prozess auf einem Knoten mehr als 20 Minuten dauert.

Prüfen, warum Pods fehlerhaft sind

Upgrades können fehlschlagen, wenn ein Pod upgrade-first-node- oder upgrade-node-IP-Adressen der Steuerungsebene enthält. Dieses Verhalten ist in der Regel darauf zurückzuführen, dass die statischen Pods nicht fehlerfrei sind.

  1. Prüfen Sie die statischen Pods mit dem Befehl crictl ps -a und suchen Sie nach abstürzenden Kubernetes- oder etcd-Pods. Prüfen Sie bei fehlgeschlagenen Pods die Logs für die Pods, um zu ermitteln, warum sie abstürzen.

    Im Folgenden finden Sie einige Beispiele für das Verhalten von Absturzschleifen:

    • Die Berechtigungen oder der Eigentümer von Dateien, die in statischen Pods bereitgestellt werden, sind nicht korrekt.
    • Die Verbindung zur virtuellen IP-Adresse funktioniert nicht.
    • Probleme mit etcd.

  2. Wenn der Befehl crictl ps nicht funktioniert oder nichts zurückgibt, prüfen Sie den Status kubelet und containerd. Verwenden Sie die Befehle systemctl status SERVICE und journalctl -u SERVICE, um die Logs aufzurufen.