Probleme bei der Clusterinstallation oder -upgrades beheben

Diese Seite enthält Informationen zur Fehlerbehebung, wenn Sie Probleme beim Installieren oder Aktualisieren von Anthos-Clustern auf Bare Metal haben.

Bootstrap-Clusterprobleme

Wenn Anthos-Cluster in Bare-Metal Cluster erstellen oder upgraden, wird ein Kubernetes in Docker-Cluster (Art) bereitgestellt, um die zum Erstellen oder Aktualisieren von Clustern erforderlichen Kubernetes-Controller vorübergehend zu hosten. Dieser temporäre Cluster wird als Bootstrap-Cluster bezeichnet.

Wenn in Ihrer Bereitstellung bereits ein Artcluster vorhanden ist und Sie versuchen, einen Cluster zu installieren, löschen Anthos-Cluster in Bare-Metal den vorhandenen Artcluster. Der Löschvorgang erfolgt erst, nachdem die Installation oder das Upgrade erfolgreich war. Verwenden Sie das Flag --keep-bootstrap-cluster von bmctl, um den vorhandenen Typcluster auch nach dem Erfolg beizubehalten.

Anthos-Cluster auf 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 ein Upgrade für Anthos-Cluster auf Bare Metal ausführen, können Sie den Fortschritt beobachten 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 es ein Problem gibt.

Umstellungsfortschritt überwachen

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

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

Ersetzen Sie die folgenden Werte:

  • CLUSTER_NAME ist der Name Ihres Clusters.
  • CLUSTER_NAMESPACE ist der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG: Die Administrator-kubeconfig-Datei.
    • Standardmäßig wird ein Bootstrap-Cluster für Administrator-, Hybrid- und eigenständige Clusterupgrades verwendet. Wenn Sie den Upgradefortschritt bei Verwendung eines Bootstrap-Clusters beobachten möchten, geben Sie den Pfad zur kubeconfig-Datei des Bootstrap-Clusters an: .kindkubeconfig. Diese Datei befindet sich im Verzeichnis „Workspace“.

Im Abschnitt Status der Ausgabe finden Sie eine Zusammenfassung des Clusterupgrade-Status. Wenn der Cluster einen Fehler meldet, lesen Sie in den folgenden Abschnitten, wo der Fehler aufgetreten ist.

Prüfen, ob die Knoten bereit sind

Verwenden Sie den Befehl kubectl get nodes, um den Status der Knoten in einem Cluster während des Upgrades 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 des Clusters. Die Kubernetes-Version für eine bestimmte Anthos on Bare Metal-Version finden Sie in der Tabelle unter Versionsunterstützungsrichtlinie.

Wenn NOT READY auf dem Knoten angezeigt wird, versuchen Sie, den Knoten zu verbinden und den Kubelet-Status zu prüfen:

systemctl status kubelet

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

journalctl -u kubelet

Prüfen Sie die Ausgabe des Kubelet-Status und der Logs in Nachrichten, die angeben, warum der Knoten ein Problem hat.

Prüfen, welcher Knoten derzeit aktualisiert wird

Mit dem Befehl kubectl get baremetalmachines können Sie prüfen, welcher Knoten im Cluster derzeit 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: Die Administrator-kubeconfig-Datei.
    • Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder Standalone-Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters an (bmctl-workspace/.kindkubeconfig).

Die folgende Beispielausgabe zeigt, dass der Knoten, der gerade aktualisiert wird, einen anderen ABM VERSION hat als der DESIRED ABM VERSION:

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 die Pods von Knoten per Drain beendet und die Planung ist deaktiviert, bis das Upgrade für den Knoten erfolgreich durchgeführt wurde. Mit dem Befehl kubectl get nodes können Sie 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 gefiltert, sodass nur Knoten angezeigt werden, die SchedulingDisabled melden. Dieser Status gibt an, dass die Knoten 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: Die Administrator-kubeconfig-Datei.
    • Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder Standalone-Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters an (bmctl-workspace/.kindkubeconfig).

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

Prüfen, warum ein Knoten seit Langem den Status „Draining“ hat

Verwenden Sie eine der Methoden im vorherigen Abschnitt, um den zu entfernenden 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 aufzurufen:

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

Ersetzen Sie NODE_NAME durch den Namen des per Drain beendeten Knotens. Die Ausgabe gibt eine Liste der Pods zurück, die derzeit hängen oder sich nur langsam entleeren lassen. Das Upgrade wird auch bei hängen gebliebenen Pods fortgesetzt, wenn der Ausgleich auf einem Knoten mehr als 20 Minuten dauert.