Diese Seite wurde von der Cloud Translation API übersetzt.

Snapshots zur Diagnose von Clusterproblemen erstellen

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. In diesem Dokument wird gezeigt, wie Sie mit dem Befehl gkectl diagnose Diagnose-Snapshots zur Fehlerbehebung in Ihren Clustern erstellen.

Weitere Informationen zur Diagnose von Clusterproblemen mit dem Befehl gkectl diagnose cluster finden Sie unter Clusterprobleme diagnostizieren.

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

`gkectl diagnose snapshot`

Mit diesem Befehl werden der Status, die Konfigurationen und Logs eines Clusters in einer TAR-Datei komprimiert. Wenn Sie gkectl diagnose snapshot ausführen, führt der Befehl im Rahmen des Prozesses automatisch gkectl diagnose cluster aus und die Ausgabedateien werden in einem neuen Ordner im Snapshot mit dem Namen /diagnose-report gespeichert.

Standard-Snapshot

In der Standardkonfiguration des Befehls gkectl diagnose snapshot werden die folgenden Informationen zu Ihrem Cluster erfasst:

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.
Containerlogs vom Knoten der Steuerungsebene des Administratorclusters, wenn der 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 Datacenter-, Cluster-, Netzwerk- und Datastore-Objekten erfasst.
Informationen zum F5 BIG-IP-Load-Balancer, 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, auch für vSphere und F5, werden entfernt, bevor die TAR-Datei erstellt wird.

Kompakter Snapshot

In Google Distributed Cloud Version 1.29 und höher ist eine vereinfachte 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, enthält der Snapshot nur die folgenden Informationen:

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 weitergeben. Sie können diese Informationen mit dem Befehl gkectl diagnose snapshot erfassen.

gkectl diagnose snapshot hat ein optionales Flag für --config. Mit diesem Flag werden nicht nur Informationen zum Cluster erfasst, sondern auch die Konfigurationsdatei für GKE on VMware, die zum Erstellen oder Upgrade 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 ein Problem mit einer virtuellen IP-Adresse (VIP) im Zielcluster auftritt, verwenden Sie das Flag --config, um die Konfigurationsdatei des Administratorclusters bereitzustellen und weitere Debugging-Informationen bereitzustellen.

Ab Version 1.29 können Sie --scenario=lite einfügen, 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, dessen Dateien Sie ansehen 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.

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

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

In Snapshot-Szenarien können Sie die Informationen steuern, die in einem Snapshot enthalten sind. Verwenden Sie das Flag --scenario, um ein Szenario anzugeben. Die folgende Liste enthält die möglichen Werte:

system (Standard): Snapshot mit Logs in unterstützten System-Namespaces erfassen.
all: Snapshot mit Logs in allen Namespaces erstellen, einschließlich benutzerdefinierter Namespaces.
lite (1.29 und höher): Snapshot nur mit Kubernetes-Ressourcen und gkectl-Logs erfassen. Alle anderen Logs wie Containerlogs und Knoten-Kernellogs sind 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 dasselbe wie das alte system-with-logs-Szenario. Das all-Szenario ist dasselbe wie das alte all-with-logs-Szenario.
Versionen 1.29 und höher: system, all und lite.

Zum Erstellen eines Snapshots des Administratorclusters 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

Verwenden Sie `--log-since`, um einen Snapshot einzuschränken

Mit dem Flag --log-since können Sie die Logerfassung auf einen aktuellen Zeitraum beschränken. Sie können beispielsweise nur die 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 durchführen

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 die beiden Szenarien --scenario system oder all nicht Ihren Anforderungen entsprechen, können Sie einen benutzerdefinierten Snapshot erstellen, indem Sie eine Snapshot-Konfigurationsdatei mit dem Flag --snapshot-config ü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

In der Ausgabe werden die folgenden Informationen 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. Das ist besonders hilfreich, wenn Sie Unterstützung von Cloud Customer Care benötigen.

Bevor Sie Snapshots in einen Cloud Storage-Bucket hochladen, prüfen und erfüllen Sie die folgenden Grundanforderungen:

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 mithilfe des Parameters --service-account-key-file. Sie können ein beliebiges Dienstkonto verwenden, aber das Connect Register-Dienstkonto 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 von Cloud Customer Care bereitgestellte Cloud Customer Care-Dienstkonto sowie alle anderen von Cloud Customer Care bereitgestellten Dienstkonten.

Wenn Sie das Flag --upload verwenden, durchsucht der Befehl Ihr Projekt nach einem Storage-Bucket mit einem Namen, der 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 übereinstimmenden Namen findet, wird ein neuer Bucket mit dem Namen anthos-snapshot-UUID erstellt, wobei UUID eine 32-stellige universell eindeutige Kennung 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