Snapshots zur Diagnose von Clusterproblemen erstellen

In diesem Dokument wird gezeigt, wie Sie mit dem Befehl gkectl diagnose Diagnose-Snapshots zur Fehlerbehebung in Ihren Clustern erstellen, die mit Google Distributed Cloud (nur Software) für VMware erstellt wurden. Das gkectl-Tool hat zwei Befehle zur Fehlerbehebung bei Clustern: gkectl diagnose snapshot und gkectl diagnose cluster. Die Befehle sind sowohl für Administrator- als auch für Nutzercluster verfügbar.

Weitere Informationen zur Verwendung des Befehls gkectl diagnose cluster zum Diagnostizieren von Clusterproblemen finden Sie unter Clusterprobleme diagnostizieren.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

`gkectl diagnose snapshot`

Dieser Befehl komprimiert den Status, die Konfigurationen und die Logs eines Clusters in einer TAR-Datei. Wenn Sie gkectl diagnose snapshot ausführen, führt dieser Befehl automatisch gkectl diagnose cluster als Teil des Prozesses aus und die Ausgabedateien werden in einem neuen Ordner im Snapshot namens /diagnose-report abgelegt.

Standard-Snapshot

Die Standardkonfiguration des Befehls gkectl diagnose snapshot erfasst die folgenden Informationen zu Ihrem Cluster:

Kubernetes-Version.
Status von Kubernetes-Ressourcen in den Namespaces "kube-system" und "gke-system": Cluster, Maschine, Knoten, Services, Endpunkte, ConfigMaps, ReplicaSets, CronJobs, Pods und die Inhaber dieser Pods, einschließlich Deployments, DaemonSets und StatefulSets.
Status der Steuerungsebene.
Details zu jeder Knotenkonfiguration, einschließlich IP-Adressen, iptables-Regeln, Bereitstellungspunkten, Dateisystem, Netzwerkverbindungen und ausgeführten Prozessen.
Container-Logs aus dem Knoten der Steuerungsebene des Administratorclusters, wenn Kubernetes API-Server nicht verfügbar ist.
vSphere-Informationen einschließlich VM-Objekten und zugehörigen Ereignissen basierend auf Ressourcenpools Außerdem werden Informationen zu den mit VMs verknüpften Rechenzentrums-, Cluster-, Netzwerk- und Datastore-Objekten erfasst.
F5 BIG-IP-Load-Balancer-Informationen, einschließlich virtueller Server, virtueller Adresse, Pool, Knoten und Monitor
Logs aus dem Befehl gkectl diagnose snapshot.
Logs von Preflight-Jobs.
Logs von Containern in Namespaces basierend auf den Szenarien.
Informationen zum Ablauf des Kubernetes-Zertifikats des Administratorclusters in der Snapshot-Datei /nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
Eine HTML-Indexdatei für alle Dateien im Snapshot.
Optional die Konfigurationsdatei des Administratorclusters, die zum Installieren und Aktualisieren des Clusters mit dem Flag --config verwendet wird.

Anmeldedaten, einschließlich für vSphere und F5, werden entfernt, bevor die TAR-Datei erstellt wird.

Einfacher Snapshot

In Google Distributed Cloud Version 1.29 und höher ist eine einfache Version von gkectl diagnose snapshot sowohl für Administrator- als auch für Nutzercluster verfügbar. Der einfache Snapshot beschleunigt den Snapshot-Prozess, da er weniger Informationen über den Cluster erfasst. Wenn Sie dem Befehl --scenario=lite hinzufügen, werden nur die folgenden Informationen im Snapshot enthalten:

Status von Kubernetes-Ressourcen in den Namespaces "kube-system" und "gke-system": Cluster, Maschine, Knoten, Services, Endpunkte, ConfigMaps, ReplicaSets, CronJobs, Pods und die Inhaber dieser Pods, einschließlich Deployments, DaemonSets und StatefulSets
Logs aus dem Befehl gkectl diagnose snapshot

Clusterstatus erfassen

Wenn die gkectl diagnose cluster-Befehle Fehler finden, sollten Sie den Status des Clusters erfassen und die Informationen an Cloud Customer Care senden. Sie können diese Informationen mit dem Befehl gkectl diagnose snapshot erfassen.

gkectl diagnose snapshot hat ein optionales Flag für --config. Zusätzlich zum Erfassen von Informationen zum Cluster erfasst dieses Flag die Konfigurationsdatei, die zum Erstellen oder Aktualisieren des Clusters verwendet wurde.

Status des Administratorclusters erfassen

Führen Sie den folgenden Befehl aus, um den Status eines Administrator-Clusters zu erfassen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config

Der Parameter --config ist optional:

Wenn im Zielcluster ein Problem mit einer virtuellen IP-Adresse (VIP) auftritt, verwenden Sie das Flag --config, um die Konfigurationsdatei des Administratorclusters bereitzustellen und weitere Debugging-Informationen bereitzustellen.

In Version 1.29 und höher können Sie --scenario=lite verwenden, wenn Sie nicht alle Informationen im Standard-Snapshot benötigen.

Die Ausgabe enthält eine Liste von Dateien und den Namen einer TAR-Datei, wie in der folgenden Beispielausgabe gezeigt:

Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"...
   Using default snapshot configuration...
   Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE
   Taking snapshots...
       commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       ...
       nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet
       nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log
       ...
   Snapshot succeeded. Output saved in [TAR_FILE_NAME].tar.gz.

Führen Sie den folgenden Befehl aus, um die Tar-Datei in ein Verzeichnis zu extrahieren:

tar -zxf TAR_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME

Ersetzen Sie Folgendes:

TAR_FILE_NAME: der Name der Tar-Datei.
EXTRACTION_DIRECTORY_NAME: das Verzeichnis, in das Sie das Tar-Dateiarchiv extrahieren möchten.

Führen Sie die folgenden Befehle aus, um sich die Liste der durch den Snapshot erstellten Dateien anzusehen:

cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY
ls kubectlCommands
ls nodes/NODE_NAME/commands
ls nodes/NODE_NAME/files

Ersetzen Sie NODE_NAME durch den Namen des Knotens, für den Sie die Dateien aufrufen möchten.

Wenn Sie sich die Details eines bestimmten Vorgangs ansehen möchten, öffnen Sie eine der Dateien.

SSH-Schlüssel für den Administratorcluster angeben

Wenn Sie einen Snapshot des Administratorclusters erhalten, findet gkectl automatisch den privaten SSH-Schlüssel für den Administratorcluster. Sie können den Schlüssel auch explizit mit dem Parameter --admin-ssh-key-path angeben.

Folgen Sie der Anleitung unter SSH-Verbindung zu einem Clusterknoten herstellen, um die SSH-Schlüssel herunterzuladen.

Setzen Sie im gkectl diagnose snapshot-Befehl --admin-ssh-key-path auf den decodierten Schlüsselpfad:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --admin-ssh-key-path=PATH_TO_DECODED_KEY

Status des Nutzerclusters erfassen

Führen Sie den folgenden Befehl aus, um den Status eines Nutzerclusters zu erfassen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

Die folgende Beispielausgabe enthält eine Liste von Dateien und den Namen einer Tar-Datei:

Taking snapshot of user cluster "[USER_CLUSTER_NAME]"...
Using default snapshot configuration...
Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    ...
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    ...
    nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet
    nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log
    ...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

Snapshot-Szenarien

Mit Snapshot-Szenarien können Sie steuern, welche Informationen in einem Snapshot enthalten sind. Verwenden Sie das Flag --scenario, um ein Szenario anzugeben. In der folgenden Liste sind die möglichen Werte aufgeführt:

system (Standard): Snapshot mit Logs in unterstützten System-Namespaces erstellen
all: Snapshot mit Logs in allen Namespaces erstellen, einschließlich benutzerdefinierter Namespaces.
lite (1.29 und höher): Snapshot mit nur Kubernetes-Ressourcen und gkectl-Logs erstellen. Alle anderen Logs wie Containerlogs und Knoten-Kernel-Logs werden ausgeschlossen.

Die verfügbaren Snapshot-Szenarien variieren je nach Google Distributed Cloud-Version.

Versionen vor 1.13: system, system-with-logs, all und all-with-logs.
Versionen 1.13 bis 1.28: system und all. Das system-Szenario ist mit dem alten system-with-logs-Szenario identisch. Das all-Szenario ist dasselbe wie das alte all-with-logs-Szenario.
Versionen 1.29 und höher: system, all und lite.

Wenn Sie einen Snapshot des Administratorclusters erstellen möchten, müssen Sie kein Szenario angeben:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

So erstellen Sie einen Snapshot eines Nutzerclusters mit dem system-Szenario:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system

So erstellen Sie einen Snapshot eines Nutzerclusters mit dem all-Szenario:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=all

So erstellen Sie einen Snapshot eines Nutzerclusters mit dem lite-Szenario:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=lite

Mit `--log-since` einen Snapshot begrenzen

Mit dem Flag --log-since können Sie die Logerfassung auf einen aktuellen Zeitraum beschränken. Sie können beispielsweise nur Logs der letzten zwei Tage oder der letzten drei Stunden erfassen. Standardmäßig erfasst diagnose snapshot alle Logs.

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=CLUSTER_NAME \
    --scenario=system \
    --log-since=DURATION

Ersetzen Sie <var>DURATION</var> durch einen Zeitwert wie 120m oder 48h.

Dabei gilt Folgendes:

Das Flag --log-since wird nur für die Logs kubectl und journalctl unterstützt.
Befehls-Flags wie --log-since sind in der benutzerdefinierten Snapshot-Konfiguration nicht zulässig.

Probelauf für einen Snapshot machen

Sie können das Flag --dry-run verwenden, um die auszuführenden Aktionen und die Snapshot-Konfiguration anzeigen zu lassen.

Geben Sie den folgenden Befehl ein, um einen Probelauf für Ihren Administratorcluster durchzuführen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=ADMIN_CLUSTER_NAME \
    --dry-run

Geben Sie den folgenden Befehl ein, um einen Probelauf für einen Nutzercluster durchzuführen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --dry-run

Snapshot-Konfiguration verwenden

Wenn diese beiden Szenarien (--scenario system oder all) nicht Ihren Anforderungen entsprechen, können Sie einen benutzerdefinierten Snapshot erstellen, indem Sie mit dem Flag --snapshot-config eine Snapshot-Konfigurationsdatei übergeben:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --snapshot-config=SNAPSHOT_CONFIG_FILE

Snapshot-Konfiguration generieren

Sie können für das jeweilige Szenario eine Snapshot-Konfiguration generieren, indem Sie die Flags --scenario und --dry-run übergeben. Um beispielsweise die Snapshot-Konfiguration für das Standardszenario system eines Nutzerclusters zu sehen, geben Sie folgenden Befehl ein:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system
    --dry-run

Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.

numOfParallelThreads: 10
excludeWords:
- password
kubectlCommands:
- commands:
  - kubectl get clusters -o wide
  - kubectl get machines -o wide
  - kubectl get clusters -o yaml
  - kubectl get machines -o yaml
  - kubectl describe clusters
  - kubectl describe machines
  namespaces:
  - default
- commands:
  - kubectl version
  - kubectl cluster-info
  - kubectl get nodes -o wide
  - kubectl get nodes -o yaml
  - kubectl describe nodes
  namespaces: []
- commands:
  - kubectl get pods -o wide
  - kubectl get deployments -o wide
  - kubectl get daemonsets -o wide
  - kubectl get statefulsets -o wide
  - kubectl get replicasets -o wide
  - kubectl get services -o wide
  - kubectl get jobs -o wide
  - kubectl get cronjobs -o wide
  - kubectl get endpoints -o wide
  - kubectl get configmaps -o wide
  - kubectl get pods -o yaml
  - kubectl get deployments -o yaml
  - kubectl get daemonsets -o yaml
  - kubectl get statefulsets -o yaml
  - kubectl get replicasets -o yaml
  - kubectl get services -o yaml
  - kubectl get jobs -o yaml
  - kubectl get cronjobs -o yaml
  - kubectl get endpoints -o yaml
  - kubectl get configmaps -o yaml
  - kubectl describe pods
  - kubectl describe deployments
  - kubectl describe daemonsets
  - kubectl describe statefulsets
  - kubectl describe replicasets
  - kubectl describe services
  - kubectl describe jobs
  - kubectl describe cronjobs
  - kubectl describe endpoints
  - kubectl describe configmaps
  namespaces:
  - kube-system
  - gke-system
  - gke-connect.*
prometheusRequests: []
nodeCommands:
- nodes: []
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - sudo iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1
  - sudo docker ps -a
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - sudo conntrack --count
nodeFiles:
- nodes: []
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/nf_conntrack_max
seesawCommands: []
seesawFiles: []
nodeCollectors:
- nodes: []
f5:
  enabled: true
vCenter:
  enabled: true

Die folgenden Informationen werden in der Ausgabe angezeigt:

numOfParallelThreads: Anzahl der parallelen Threads, die zum Erstellen von Snapshots verwendet werden.
excludeWords: Liste der Wörter, die aus dem Snapshot ausgeschlossen werden sollen. Dabei wird die Groß- und Kleinschreibung nicht berücksichtigt. Zeilen, die diese Wörter enthalten, werden aus den Snapshot-Ergebnissen entfernt. "Passwort" ist immer ausgeschlossen, unabhängig davon, ob Sie das angeben oder nicht.
kubectlCommands: Liste der auszuführenden kubectl-Befehle. Die Ergebnisse werden gespeichert. Die Befehle werden für die entsprechenden Namespaces ausgeführt. Bei kubectl logs-Befehlen werden alle Pods und Container in den entsprechenden Namespaces automatisch hinzugefügt. Reguläre Ausdrücke werden für die Angabe von Namespaces unterstützt. Wenn Sie keinen Namespace angeben, wird der Namespace default angenommen.
nodeCommands: Liste der Befehle, die auf den entsprechenden Knoten ausgeführt werden sollen. Die Ergebnisse werden gespeichert. Wenn keine Knoten angegeben werden, werden alle Knoten im Zielcluster berücksichtigt.
nodeFiles: Liste der Dateien, die von den entsprechenden Knoten erfasst werden sollen. Die Dateien werden gespeichert. Wenn keine Knoten angegeben sind, werden alle Knoten im Zielcluster berücksichtigt.
seesawCommands: Liste der auszuführenden Befehle zum Erfassen von Seesaw-Load-Balancer-Informationen. Die Ergebnisse werden gespeichert, wenn der Cluster den Seesaw-Load-Balancer verwendet.
seesawFiles: Liste der Dateien, die für den Seesaw-Load-Balancer erfasst werden sollen.
nodeCollectors: Ein Collector, der für Cilium-Knoten ausgeführt wird, um eBPF-Informationen zu erfassen.
f5: Ein Flag, das die Erfassung von Informationen zum F5 BIG-IP-Load-Balancer ermöglicht.
vCenter: Mit diesem Flag wird die Erfassung von Informationen in Bezug auf das vCenter aktiviert.
prometheusRequests: Liste der Prometheus-Anfragen. Die Ergebnisse werden gespeichert.

Snapshots in einen Cloud Storage-Bucket hochladen

Sie können alle Snapshots eines bestimmten Clusters in einen Cloud Storage-Bucket hochladen, um die Aufzeichnung, Analyse und Speicherung zu vereinfachen. Dies ist besonders hilfreich, wenn Sie Unterstützung von Cloud Customer Care benötigen.

Erfüllen Sie die folgenden anfänglichen Anforderungen, bevor Sie Snapshots in einen Cloud Storage-Bucket hochladen:

Aktivieren Sie storage.googleapis.com im Flotten-Hostprojekt. Sie können auch ein anderes Projekt verwenden, das Flotten-Hostprojekt wird jedoch empfohlen.
```
gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
```
Weisen Sie dem Dienstkonto im übergeordneten Projekt die roles/storage.admin zu und übergeben Sie die JSON-Schlüsseldatei des Dienstkontos mit dem Parameter --service-account-key-file. Sie können jedes Dienstkonto verwenden, aber das Connect-Registrierungsdienstkonto wird empfohlen. Weitere Informationen finden Sie unter Dienstkonten.

Hinweis: Wenn Sie das Flag --share-with im Befehl gkectl diagnose snapshot verwenden, ist diese Einrichtungsanforderung nicht erforderlich. Wenn Sie den Zugriff auf Ihren Snapshot manuell für Cloud Customer Care freigeben möchten, verwenden Sie den folgenden Befehl und verwenden Sie beim Erstellen des Snapshots nicht das Flag --share-with.
```
gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
  --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \
  --role "roles/storage.admin"
```
Ersetzen Sie CONNECT_REGISTER_SERVICE_ACCOUNT durch das Connect Register-Dienstkonto.

Wenn diese Anforderungen erfüllt sind, können Sie den Snapshot in den Cloud Storage-Bucket hochladen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name CLUSTER_NAME \
    --upload \
    --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

Das Flag --share-with kann eine Liste der Dienstkontonamen akzeptieren. Ersetzen Sie GOOGLE_SUPPORT_SERVICE_ACCOUNT durch das Cloud Customer Care-Dienstkonto, das von Cloud Customer Care bereitgestellt wird, zusammen mit allen anderen von Cloud Customer Care bereitgestellten Dienstkonten.

Wenn Sie das Flag --upload verwenden, sucht der Befehl in Ihrem Projekt nach einem Storage-Bucket, dessen Name mit "anthos-snapshot-" beginnt. Wenn ein solcher Bucket vorhanden ist, lädt der Befehl den Snapshot in diesen Bucket hoch. Wenn der Befehl keinen Bucket mit einem passenden Namen findet, wird ein neuer Bucket mit dem Namen anthos-snapshot-UUID erstellt, wobei UUID eine eindeutige Kennung mit 32 Ziffern ist.

Wenn Sie das Flag --share-with verwenden, müssen Sie den Zugriff auf den Bucket nicht manuell für Cloud Customer Care freigeben.

Die folgende Beispielausgabe wird angezeigt, wenn Sie einen Snapshot in einen Cloud Storage-Bucket hochladen:

Using "system" snapshot configuration...
Taking snapshot of user cluster <var>CLUSTER_NAME</var>...
Setting up <var>CLUSTER_NAME</var> ssh key...DONE
Using the gke-connect register service account key...
Setting up Google Cloud Storage bucket for uploading the snapshot...DONE
Taking snapshots in 10 thread(s)...
   ...
Snapshot succeeded.
Snapshots saved in "<var>SNAPSHOT_FILE_PATH</var>".
Uploading snapshot to Google Cloud Storage......  DONE
Uploaded the snapshot successfully to gs://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/<var>xSNAPSHOT_FILE_NAME</var>.
Shared successfully with service accounts:
<var>GOOGLE_SUPPORT_SERVICE_ACCOUNT</var>

Nächste Schritte