Auf dieser Seite erfahren Sie, wie Sie Probleme im Zusammenhang mit der Installation oder dem Upgrade von Google Distributed Cloud-Clustern beheben können.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Probleme bei der Installation
Die folgenden Abschnitte können Ihnen bei der Fehlerbehebung 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 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 Google Distributed Cloud 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
.
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 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.
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
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.
- Wenn während eines Upgrades Probleme auftreten, versuchen Sie zu ermitteln, in welcher Phase der Fehler auftritt. Weitere Informationen dazu, was während des Upgrades mit einem Cluster geschieht, finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.
- Weitere Informationen zu den Auswirkungen eines Problems während Clusterupgrades finden Sie unter Auswirkungen von Fehlern in Google Distributed Cloud verstehen.
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 Befehlbmctl 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.
- Standardmäßig verwenden Administrator-, Hybrid- und eigenständige Cluster ein direktes Upgrade.
Wenn Sie das Flag
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 Google Distributed Cloud-Version finden Sie im Versionsverlauf.
Wenn für den Knoten NOT READY
angezeigt wird, versuchen Sie, den Knoten zu verbinden 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.
- 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 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 gerade 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 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 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.
- Wenn ein Bootstrap-Cluster für ein Administrator-, Hybrid- oder eigenständiges Upgrade verwendet wird, geben Sie die kubeconfig-Datei des Bootstrap-Clusters (
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.
Ab Version 1.29 wird für den Knotenausgleichsprozess die Eviction API verwendet, die PodDisruptionBudgets
(PDBs) berücksichtigt.
Die folgenden PDB-Einstellungen können zu Problemen beim Knotenausgleich führen:
Pods, die von mehreren PDBs verwaltet werden
Statische PDB-Konfigurationen wie die folgenden:
maxUnavailable
==0
minUnavailable
>= Replikate insgesamt
Die Gesamtzahl der Replikate ist anhand der PDB-Ressource schwer zu ermitteln, da sie in einer übergeordneten Ressource wie
Deployment
,ReplicaSet
oderStatefulSet
definiert ist. PDBs stimmen nur anhand der Auswahl in ihrer Konfiguration mit Pods überein. Ein guter Ansatz zur Diagnose, ob eine statische PDB-Konfiguration ein Problem verursacht, besteht darin, zuerst zu prüfen, obpdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
ist und ob eine der genannten statischen Konfigurationen dies zulässt.
Laufzeitverstöße, wie der berechnete Wert DisruptionsAllowed
für eine PDB-Ressource mit dem Wert 0
, können auch den Knotenausgleich blockieren. Wenn Sie PodDisruptionBudget
Objekte konfiguriert haben, die keine weiteren Unterbrechungen zulassen können, können Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert werden. Um diesen Fehler zu vermeiden, empfehlen wir, Deployment
oder HorizontalPodAutoscaler
hochzuskalieren, damit der Knoten entleert, während die PodDisruptionBudget
-Konfiguration weiterhin berücksichtigt wird.
Mit dem folgenden Befehl können Sie alle PodDisruptionBudget
-Objekte anzeigen lassen, die keine Unterbrechungen zulassen:
kubectl get poddisruptionbudget --all-namespaces \
-o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
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.
Prüfen Sie die statischen Pods mit dem Befehl
crictl ps -a
und suchen Sie nach abstürzenden Kubernetes- oderetcd
-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
.
Wenn der Befehl
crictl ps
nicht funktioniert oder nichts zurückgibt, prüfen Sie den Statuskubelet
undcontainerd
. Verwenden Sie die Befehlesystemctl status SERVICE
undjournalctl -u SERVICE
, um die Logs aufzurufen.
Nächste Schritte
- Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.