Fehler beim Erstellen oder Upgraden von Clustern beheben

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 helfen Ihnen möglicherweise bei der Behebung von Problemen bei der Installation von Google Distributed Cloud.

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 Cluster vom Typ Kubernetes in Docker 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 von ihrem verwalteten Administrator oder Hybridcluster ohne die Verwendung eines Bootstrap-Clusters erstellt und aktualisiert.

Wenn bei der Installation bereits ein Artcluster in Ihrer Bereitstellung vorhanden ist, 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 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 Feld gcrKeyPath in der Clusterkonfigurationsdatei abgerufen.

  • bmctl-workspace/config.toml: Enthält die containerd-Konfiguration im kind-Cluster.

Bootstrap-Clusterlogs untersuchen

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.

Anhand der folgenden Anleitung können Sie feststellen, ob das Upgrade wie gewohnt fortgesetzt wird oder ein Problem auftritt.

Fortschritt der Umstellung überwachen

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

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 kubeconfig-Administratordatei
    • 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. Wenn Sie den Upgradefortschritt bei Verwendung eines Bootstrap-Clusters überwachen möchten, geben Sie den Pfad zur kubeconfig-Datei des Bootstrap-Clusters (.kindkubeconfig) an. Diese Datei befindet sich im Arbeitsbereichsverzeichnis.

Sehen Sie sich den Abschnitt Status der Ausgabe an. Er enthält eine Zusammenfassung des Clusterupgrade-Status. 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 während des Upgrades den Status der Knoten in einem Cluster aufzurufen:

kubectl get nodes --kubeconfig KUBECONFIG

Sehen Sie sich die Spalten VERSION und AGE in der Befehlsantwort an, um zu prüfen, ob ein Knoten das Upgrade 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, eine Verbindung zum Knoten herzustellen, und prüfen Sie den Kubelet-Status:

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 in Nachrichten, die angeben, warum im Knoten ein Problem auftritt.

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 ist der Namespace Ihres Clusters.
  • ADMIN_KUBECONFIG: 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.

Die folgende Beispielausgabe zeigt, dass für den Knoten, für den ein Upgrade durchgeführt wird, eine andere ABM VERSION als die DESIRED ABM VERSION verwendet wird:

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 von Knoten per Drain beendet. Die Planung ist deaktiviert, bis ein erfolgreiches Upgrade des Knotens durchgeführt wurde. Mit dem Befehl kubectl get nodes können Sie sehen, welche Knoten 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, damit nur Knoten angezeigt werden, die SchedulingDisabled melden. Dieser Status zeigt an, dass die Knoten per Drain beendet werden.

Sie können den Knotenstatus auch im 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 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.

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

Prüfen, warum ein Knoten lange Zeit per Drain beendet wurde

Verwenden Sie eine der Methoden im vorherigen Abschnitt, um den Knoten zu identifizieren, der geleert wird. Verwenden Sie dazu den Befehl kubectl get nodes. 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 Knotens, der per Drain beendet wird. Die Ausgabe gibt eine Liste von Pods zurück, die hängen geblieben sind oder nur langsam geleert werden. Das Upgrade wird auch bei hängen gebliebenen Pods fortgesetzt, wenn der Ausgleichsprozess für einen Knoten mehr als 20 Minuten dauert.

Ab Version 1.29 verwendet der Knotenausgleichsprozess die Evivity API, die PodDisruptionBudgets (PDBs) akzeptiert.

Die folgenden PDB-Einstellungen können zu Problemen mit dem Knotenausgleich führen:

  • Von mehreren PDBs verwaltete Pods

  • Statische PDB-Konfigurationen wie die folgenden:

    • maxUnavailable == 0
    • minUnavailable >= Replikate insgesamt

    Die Gesamtzahl der Replikate ist über die PDB-Ressource nur schwer zu ermitteln, da sie in einer übergeordneten Ressource wie Deployment, ReplicaSet oder StatefulSet definiert ist. PDBs werden Pods nur anhand des Selektors in ihrer Konfiguration abgeglichen. Ein guter Ansatz zur Diagnose, ob eine statische PDB-Konfiguration ein Problem verursacht, besteht darin, zuerst zu prüfen, ob pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy ist und ob eine der genannten statischen Konfigurationen dies zulässt.

Laufzeitverstöße, z. B. der berechnete DisruptionsAllowed-Wert für eine PDB-Ressource 0, können auch den Knotenausgleich verhindern. 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, sollten Sie Deployment oder HorizontalPodAutoscaler hochskalieren, damit der Knoten per Drain beendet werden kann, ohne dass die PodDisruptionBudget-Konfiguration beibehalten wird.

Verwenden Sie den folgenden Befehl, um alle PodDisruptionBudget-Objekte anzeigen zu 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 liegt in der Regel daran, dass die statischen Pods nicht fehlerfrei sind.

  1. Prüfen Sie die statischen Pods mit dem Befehl crictl ps -a und suchen Sie nach Kubernetes- oder etcd-Pods, die abstürzen. Wenn Pods fehlerhaft sind, sehen Sie sich die Logs für die Pods an, um herauszufinden, warum sie abstürzen.

    Im Folgenden sind einige Möglichkeiten für Absturzschleifenverhalten aufgeführt:

    • Berechtigungen oder Eigentümer von Dateien, die in statischen Pods bereitgestellt werden, sind falsch.
    • Es kann keine Verbindung zur virtuellen IP-Adresse hergestellt werden.
    • 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 sich die Logs anzusehen.

Nächste Schritte