Fehlerbehebung: Diagnose und Zurücksetzen von Clustern

Sie können Cluster diagnostizieren oder überprüfen, um Fehler zu beheben, und einen Snapshot des Clusterstatus erstellen. Wenn Sie mit einer Installation teilweise erfolgreich waren, der Cluster aber Fehler zurückgibt oder nicht ordnungsgemäß funktioniert, können Sie versuchen, den Cluster zurückzusetzen.

Cluster mit bmctl check cluster diagnostizieren

Sie können den Status der erstellten Cluster mit dem Befehl bmctl check cluster erfassen. Mit den Flags für den Vergleich können Sie den Diagnosebereich des Befehls auswählen, um fokussierte Informationen zu erhalten.

Mithilfe der Diagnoseinformationen können Sie Probleme entdecken und Ihre Bereitstellungen effektiver beheben. Der Befehl erfasst alle relevanten Cluster- und Knotenkonfigurationsdateien für Ihren definierten Bereich und verpackt die Informationen dann in einem einzigen TAR-Archiv.

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Ersetzen Sie Folgendes:

  • CLUSTER_NAME gibt den Namen des Zielclusters an.

  • ADMIN_KUBECONFIG_PATH gibt den Pfad zur Datei kubeconfig des Administratorclusters an.

Dieser Befehl gibt ein TAR-Archiv aus, das relevante Informationen zur Fehlerbehebung aus allen Systemkomponenten und Maschinen im angegebenen Cluster enthält.

Sie können den Bereich der Diagnoseinformationen, die erfasst werden, mit den folgenden Befehls-Flags, ändern:

  • Das Flag --snapshot-scenario all erhöht den Bereich des Diagnose-Snapshots, sodass alle Pods im angegebenen Cluster berücksichtigt werden:
bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • Das Flag --snapshot-dry-run arbeitet mit dem Flag --snapshot-config string. Verwenden Sie das Flag --snapshot-dry-run, um eine Konfigurationsdatei auszugeben, die Sie ändern können, um einen benutzerdefinierten Diagnosebereich zu definieren. Der Bereich kann bestimmte Pods, Namespaces oder Knotenbefehle enthalten.

Nachdem Sie die mit dem Flag --snapshot-dry-run erstellte Ausgabedatei geändert haben, können Sie sie als Eingabe zur Diagnose Ihres bestimmten Bereichs mit dem Flag --snapshot-config string verwenden (siehe unten). Wenn Sie dieses Flag weglassen, wird eine Standardkonfiguration angewendet.

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH
  • Das Flag --snapshot-config weist den Befehl bmctl an, die in der Snapshot-Konfigurationsdatei angegebenen Bereichsoptionen zu verwenden. Im Allgemeinen erstellen Sie die Snapshot-Konfigurationsdatei mit dem Flag --snapshot-dry-run.
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Cluster diagnostizieren, wenn der Administratorcluster nicht erreichbar ist

Wenn der Administratorcluster ausgefallen oder nicht erreichbar ist, verwenden Sie eine Snapshot-Konfigurationsdatei, um einen Cluster-Snapshot zu erstellen. Eine Snapshot-Konfigurationsdatei im YAML-Format. Die Konfigurationsdatei enthält die folgenden Felder, um anzugeben, wie Informationen für Ihren Cluster erfasst werden:

  • numOfParallelThreads: Die Snapshot-Routine führt in der Regel zahlreiche Befehle aus. Mehrere parallele Threads führen dazu, dass die Routine schneller ausgeführt wird. Wir empfehlen, numOfParallelThreads auf 10 zu setzen, wie im folgenden Beispiel gezeigt. Wenn die Snapshots zu lang dauern, erhöhen Sie diesen Wert.

  • excludeWords: Der Snapshot enthält eine große Datenmenge für Ihre Clusterknoten. Verwenden Sie excludeWords, um Sicherheitsrisiken zu reduzieren, wenn Sie Ihren Snapshot teilen. Schließen Sie beispielsweise password aus, damit die entsprechenden Passwortstrings nicht identifiziert werden können.

  • nodeCommands: In diesem Abschnitt werden die folgenden Informationen angegeben:

    • nodes: Eine Liste von IP-Adressen für die Clusterknoten, von denen Sie Informationen erfassen möchten. Wenn Sie einen Snapshot erstellen möchten, wenn der Administratorcluster nicht erreichbar ist, geben Sie mindestens eine Knoten-IP-Adresse an.

    • commands: eine Liste der Befehle (und Argumente), die auf jedem Knoten ausgeführt werden sollen. Die Ausgabe der einzelnen Befehle ist im Snapshot enthalten.

  • nodeFiles: In diesem Abschnitt werden die folgenden Informationen angegeben:

    • nodes: Eine Liste von IP-Adressen für die Clusterknoten, von denen Sie Dateien erfassen möchten. Geben Sie mindestens eine IP-Adresse des Knotens an, um einen Snapshot zu erstellen, wenn der Administratorcluster nicht erreichbar ist.

    • files: Eine Liste der Dateien, die von jedem Knoten abgerufen werden sollen. Wenn die angegebenen Dateien auf einem Knoten gefunden werden, werden sie in den Snapshot aufgenommen.

  • nodeSSHKey ist der Pfad zu Ihrer SSH-Schlüsseldatei für Ihre Knoten. Dieses Feld ist erforderlich, um einen Snapshot zu erstellen, wenn der Administratorcluster nicht erreichbar ist.

Verwenden Sie den folgenden Befehl, um mit einer Snapshot-Konfigurationsdatei einen Snapshot zu erstellen:

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

Ersetzen Sie SNAPSHOT_CONFIG durch den Pfad zu Ihrer Snapshot-Konfigurationsdatei.

Die folgende Beispielkonfigurationsdatei für einen Snapshot zeigt die Standardbefehle und -dateien, die zum Erstellen eines Snapshots verwendet werden. Wenn zusätzliche Diagnoseinformationen erforderlich sind, können Sie weitere Befehle und Dateien hinzufügen.

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file to each nodes

Snapshot für steckengebliebene Installation/Upgrade des Administrator-Clusters erstellen

Bei der Installation von Administrator-/Hybrid-/eigenständigen Clustern, wenn bmctl bei der folgenden Ausgabe hängen bleibt:

  • Warten, bis Cluster-kubeconfig bereit ist
  • Warten, bis Cluster bereit ist
  • Warten, bis Worker-Knotenpools bereit sind

oder beim Upgrade von Administrator-/Hybrid-/eigenständigen Clustern:

  • Warten auf Abschluss des Upgrades

können Sie den folgenden Befehl ausführen, um mit dem Bootstrap-Cluster einen Snapshot zu erstellen.

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

Cluster mit bmctl reset cluster zurücksetzen

Wenn ein Cluster nicht ordnungsgemäß installiert wird, können Sie die Knoten zurückgeben, indem Sie den Knoten zurücksetzen. Dann können Sie den Cluster neu installieren, nachdem Sie die Konfigurationsänderungen vorgenommen haben.

Selbstverwaltete Cluster zurücksetzen

Führen Sie den folgenden Befehl aus, um einen Cluster zurückzusetzen, der sich selbst verwaltet, z. B. einen Administratorcluster:

bmctl reset --cluster CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie zurücksetzen.

Nutzercluster zurücksetzen

Führen Sie den folgenden Befehl aus, um einen Nutzercluster zurückzusetzen:

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Ersetzen Sie CLUSTER_NAME durch den Namen des zurückzusetzenden Nutzerclusters und ersetzen Sie ADMIN_KUBECONFIG_PATH durch den Pfad zur kubeconfig-Datei des zugehörigen Administratorclusters. bmctl unterstützt die Verwendung von --kubeconfig als Alias für das Flag --admin-kubeconfig.

Clusterdetails zurücksetzen

Unabhängig vom Clustertyp gilt der Befehl zum Zurücksetzen für den gesamten Cluster. Es gibt keine Möglichkeit, eine Teilmenge von Knoten in einem Cluster anzusprechen.

Die Ausgabe des Befehls bmctl cluster reset sieht in etwa so aus:

bmctl reset --cluster cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

Beim Zurücksetzen versucht bmctl, die GKE Hub-Mitgliedschaft zu löschen und die betroffenen Knoten zu bereinigen. Beim Zurücksetzen werden auch Speicher-Deployments und Daten aus anthos-system StorageClass gelöscht.

Für alle Knoten wird bmctl ausgeführtkubeadm reset, entfernt die Tunnelschnittstellen, die für Cluster-Netzwerke verwendet werden, und löscht die folgenden Verzeichnisse:

  • /etc/kubernetes
  • /etc/cni/net.d
  • /root/.kube
  • /var/lib/kubelet

Bei Load-Balancer-Knoten führt bmctl außerdem die folgenden Aktionen aus:

  • Deaktiviert keepalived und haproxy-Dienste
  • Löscht die Konfigurationsdateien für keepalived und haproxy

Das Reset-Tool erwartet, dass sich die Clusterkonfigurationsdatei an folgendem Speicherort im aktuellen Arbeitsverzeichnis befindet:

bmctl-workspace/cluster name/cluster name.yaml