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 FeldgcrKeyPath
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.
- 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:
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.
- Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder eigenständiges Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters (
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.
- Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder eigenständiges Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters (
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.