Auf dieser Seite wird beschrieben, wie Sie Probleme bei der Installation oder dem Upgrade von Google Distributed Cloud-Clustern beheben.
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.
Vorübergehende Fehlermeldungen
Der Installationsprozess für Google Distributed Cloud ist eine kontinuierliche Abgleichsschleife. Während der Installation werden möglicherweise vorübergehende Fehlermeldungen im Log angezeigt.
Wenn die Installation erfolgreich abgeschlossen wurde, können diese Fehler einfach ignoriert werden. Im Folgenden finden Sie eine Liste typischer Fehlerprotokollmeldungen:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
dial tcp IP_ADDRESS:443: connect: connection refused
Internal error occurred: failed calling webhook "vcluster.kb.io": Post
https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
dial tcp IP_ADDRESS:443: connect: connection refused
Failed to register cluster with GKE Hub; gcloud output: error running command
'gcloud container fleet memberships register CLUSTER_NAME --verbosity=error --quiet':
error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF
Get
https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""
Wenn Ihr Google Cloud -Dienstkontoschlüssel abgelaufen ist, werden die folgenden Fehlermeldungen von bmctl
angezeigt:
Error validating cluster config: 3 errors occurred:
* GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
Sie müssen einen neuen Dienstkontoschlüssel generieren.
Bootstrap-Cluster zum Beheben von Problemen verwenden
Wenn Google Distributed Cloud selbstverwaltete (Administrator-, Hybrid- oder Standalone-)Cluster erstellt, wird ein Kubernetes in Docker (Art) Cluster bereitgestellt, der vorübergehend die zum Erstellen von Clustern erforderlichen Kubernetes-Controller hostet. Dieser vorübergehende Cluster wird als Bootstrap-Cluster bezeichnet. Nutzercluster werden von ihrem verwaltenden Administrator- oder Hybridcluster ohne Verwendung eines Bootstrap-Clusters erstellt und aktualisiert.
Wenn in Ihrer Bereitstellung bereits ein Artcluster vorhanden ist und Sie versuchen, einen Cluster zu installieren, löscht Google Distributed Cloud den vorhandenen Artcluster. Der Löschvorgang erfolgt erst, nachdem die Installation oder das Upgrade erfolgreich war.
Wenn Sie den vorhandenen Artcluster beibehalten möchten, verwenden Sie das Flag --keep-bootstrap-cluster
von bmctl
.
Google Distributed Cloud 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 Artifact Registry, es sei denn, Sie verwenden eine private Registry. Während der Clustererstellung erstellt bmctl
die folgenden Dateien:
bmctl-workspace/config.json
: enthält Google Cloud Anmeldedaten für das 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.
Bootstrap-Clusterlogs prüfen
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
Debug-Logging für containerd aktivieren
Wenn die Standard-Containerd-Logs nicht genügend Informationen für die Fehlerbehebung liefern, können Sie den Logging-Level erhöhen. Das Erhöhen des Protokollierungsgrads ist oft erforderlich, wenn komplexe Probleme diagnostiziert werden, z. B. Probleme mit einem Registry-Mirror oder ImagePullBackOff
-Fehler.
So erhöhen Sie die Protokollierungsstufe:
Debug-Logging aktivieren:
Öffnen Sie die containerd-Konfigurationsdatei (
/etc/containerd/config.toml
) mit Ihrem bevorzugten Texteditor.Suchen Sie in der Datei den Abschnitt
[debug]
und ändern Sie den Wert vonlevel
von""
in"debug"
.Speichern Sie die Datei und beenden Sie den Texteditor.
Prüfen Sie, ob Sie die Konfigurationsdatei erfolgreich aktualisiert haben:
cat /etc/containerd/config.toml | grep debug
Die Ausgabe sollte so aussehen:
[debug] level = "debug" shim_debug = false
Starten Sie containerd neu, um die Änderung der Logging-Ebene zu übernehmen:
sudo systemctl restart containerd
Wenn Sie neue Logeinträge generieren möchten, versuchen Sie, ein Image abzurufen, das nicht vorhanden ist oder von keinen Knoten oder Clustern verwendet wird. Beispiel:
# This command fails because the image doesn't exist crictl pull us-west1-docker.pkg.dev/gdc-project/samples/non-existent-image:latest
Dadurch wird containerd gezwungen, eine Aktion auszuführen und detaillierte Logs zu generieren.
Warten Sie, bis das Image abgerufen wurde oder ein Fehler aufgetreten ist, und erfassen Sie dann die containerd-Logs in einer Datei namens
containerd_log.txt
:journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt
Ersetzen Sie
TIME_PERIOD
durch einen Wert, der die Startzeit für die Logs angibt. Setzen Sie alle Werte, die Leerzeichen enthalten, in doppelte Anführungszeichen. Beispiel:"2 hours ago"
.Wenn Sie mit der Fehlerbehebung fertig sind, setzen Sie die Protokollebene auf die Standardeinstellung zurück. Wenn Sie das Debug-Logging aktiviert lassen, können Ihre Systemprotokolle überflutet werden, die Leistung kann beeinträchtigt werden und möglicherweise werden vertrauliche Informationen offengelegt.
Öffnen Sie die Datei
/etc/containerd/config.toml
und ändern Sie den Wert vonlevel
wieder in""
, den Standard-Logging-Level.Prüfen Sie, ob Sie die Konfiguration erfolgreich aktualisiert haben:
cat /etc/containerd/config.toml | grep level
Die Ausgabe sollte so aussehen:
level = ""
Starten Sie containerd neu, um die Änderung zu übernehmen:
sudo systemctl restart containerd
Ihr System hat jetzt wieder die Standardkonfiguration für die Protokollierung.
Probleme beim Clusterupgrade
Wenn Sie Google Distributed Cloud-Cluster upgraden, können Sie den Fortschritt überwachen und den Status Ihrer Cluster und Knoten prüfen.
- Sollten während eines Upgrades Probleme auftreten, versuchen Sie zu ermitteln, in welcher Phase der Fehler auftritt. Wenn Sie mehr darüber erfahren möchten, was mit einem Cluster während des Upgradeprozesses passiert, finden Sie unter Lebenszyklus und Phasen von Clusterupgrades weitere Informationen.
- Weitere Informationen zu den Auswirkungen von Problemen bei Clusterupgrades finden Sie unter Auswirkungen von Ausfällen in Google Distributed Cloud verstehen.
Die folgenden Informationen können Ihnen helfen, festzustellen, ob das Upgrade wie gewohnt fortgesetzt wird oder ob ein Problem vorliegt.
Upgrade-Fortschritt überwachen
Verwenden Sie den Befehl kubectl describe cluster
, um den Status eines Clusters während des Upgrades anzusehen:
kubectl describe cluster CLUSTER_NAME \
--namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ersetzen Sie die folgenden Werte:
CLUSTER_NAME
: der Name Ihres Clusters.CLUSTER_NAMESPACE
: der Namespace Ihres Clusters.ADMIN_KUBECONFIG
: die kubeconfig-Datei des Administrators.- Standardmäßig verwenden Administrator-, Hybrid- und Standalone-Cluster ein direktes Upgrade.
Wenn Sie das Flag
--use-bootstrap=true
mit dem Befehlbmctl upgrade
verwenden, wird für den Upgradevorgang ein Bootstrap-Cluster verwendet. Um den Upgradefortschritt bei Verwendung eines Bootstrap-Clusters zu prüfen, geben Sie den Pfad zur kubeconfig-Datei des Bootstrap-Clusters an,.kindkubeconfig
. Diese Datei befindet sich im Arbeitsbereichsverzeichnis.
- Standardmäßig verwenden Administrator-, Hybrid- und Standalone-Cluster ein direktes Upgrade.
Wenn Sie das Flag
Sehen Sie sich den Abschnitt Status
der Ausgabe an. Dort wird eine Zusammenfassung des Cluster-Upgradestatus angezeigt. Wenn der Cluster einen Fehler meldet, können Sie anhand der folgenden Abschnitte herausfinden, wo das Problem liegt.
Prüfen, ob die Knoten bereit sind
Verwenden Sie den Befehl kubectl get nodes
, um den Status von Knoten in einem Cluster während des Upgrades anzusehen:
kubectl get nodes --kubeconfig KUBECONFIG
Um zu prüfen, ob ein Knoten das Upgrade erfolgreich abgeschlossen hat, sehen Sie sich die Spalten VERSION
und AGE
in der Befehlsantwort an. VERSION
ist die Kubernetes-Version für den Cluster. Die Kubernetes-Version für eine bestimmte Google Distributed Cloud-Version finden Sie unter Versionsverwaltung.
Wenn der Knoten NOT READY
anzeigt, 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 zu Nachrichten, die angeben, warum der Knoten ein Problem hat.
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 Standalone-Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters an (
bmctl-workspace/.kindkubeconfig
).
- Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder Standalone-Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters an (
Die folgende Beispielausgabe zeigt, dass der Knoten, der aktualisiert wird, über eine
ABM VERSION
verfügt, die sich von der 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 Upgrades werden Knoten von Pods entleert und die Planung ist deaktiviert, bis der Knoten erfolgreich aktualisiert wurde. Mit dem Befehl kubectl get nodes
können Sie sehen, welche Knoten geleert 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
berichten. 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
: der Namespace Ihres Clusters.ADMIN_KUBECONFIG
: die kubeconfig-Datei des Administrators.- 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
).
- Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder Standalone-Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters an (
Für den Knoten, der per Drain beendet wird, wird der Status unter der Spalte MAINTENANCE
angezeigt.
Prüfen, warum ein Knoten seit langer Zeit per Drain beendet wurde
Verwenden Sie eine der Methoden im vorherigen Abschnitt, um den Knoten zu identifizieren, der mit dem Befehl kubectl get nodes
geleert wird. Verwenden Sie den Befehl kubectl get
pods
und filtern Sie nach diesem 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 Knoten, der per Drain beendet wird. Die Ausgabe gibt eine Liste von Pods zurück, die hängen bleiben oder langsam per Drain beendet werden. Das Upgrade wird fortgesetzt, auch wenn Pods hängen bleiben, wenn der Vorgang zum Beenden eines Knotens per Drain mehr als 20 Minuten dauert.
Ab Version 1.29 verwendet der Knotenausgleich-Prozess die Eviction API, die PodDisruptionBudgets
(PDBs) berücksichtigt.
Die folgenden PDB-Einstellungen können zu Problemen mit dem Knotenausgleich führen:
Pods, die von mehreren PDBs verwaltet werden
Statische PDB-Konfigurationen wie die folgenden:
maxUnavailable
==0
minUnavailable
>= Gesamtzahl der Replikate
Die Gesamtzahl der Replikate lässt sich nur schwer aus der PDB-Ressource ermitteln, da sie in einer Ressource auf höherer Ebene wie
Deployment
,ReplicaSet
oderStatefulSet
definiert ist. Der Abgleich von PDBs mit Pods verläuft ausschließlich anhand des Selektors in ihrer Konfiguration. Wenn Sie feststellen möchten, ob eine statische PDB-Konfiguration ein Problem verursacht, sollten Sie zuerst untersuchen, obpdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
ist, und dann prüfen, ob eine der erwähnten statischen Konfigurationen dies zulässt.
Laufzeitverstöße, z. B. wenn der berechnete Wert DisruptionsAllowed
für eine PDB-Ressource 0
ist, können auch den Knotenausgleich blockieren. Wenn Sie PodDisruptionBudget
-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment
oder HorizontalPodAutoscaler
, damit der Knoten unter Berücksichtigung der PodDisruptionBudget
-Konfiguration entleert wird.
So rufen Sie alle PodDisruptionBudget
-Objekte auf, die keine Störungen zulassen:
kubectl get poddisruptionbudget --all-namespaces \
-o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Pods auf Fehler prüfen
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.
Prüfen Sie die statischen Pods mit dem Befehl
crictl ps -a
und suchen Sie nach Kubernetes- oderetcd
-Pods, die abstürzen. Wenn Sie fehlgeschlagene Pods haben, sehen Sie in den Logs nach, warum sie abstürzen.Hier sind einige mögliche Ursachen für das Verhalten bei Absturzschleifen:
- Berechtigungen oder Eigentümer von Dateien, die in statischen Pods bereitgestellt werden, sind nicht korrekt.
- Die Verbindung zur virtuellen IP-Adresse funktioniert nicht.
- Probleme mit
etcd
.
Wenn der Befehl
crictl ps
nicht funktioniert oder nichts zurückgibt, prüfen Sie denkubelet
- und den containerd-Status. Verwenden Sie die Befehlesystemctl status SERVICE
undjournalctl -u SERVICE
, um sich die Logs anzusehen.
Nächste Schritte
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:
- Anforderungen für das Eröffnen eines Supportfalls.
- Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
- Unterstützte Komponenten.