Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Snapshots erstellen, um Clusterprobleme zu diagnostizieren

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`

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 der Befehl automatisch gkectl diagnose cluster als Teil des Prozesses aus und Ausgabedateien werden in einem neuen Ordner im Snapshot mit dem Namen /diagnose-report abgelegt.

Standard-Snapshot

In der Standardkonfiguration des Befehls gkectl diagnose snapshot werden die folgenden Informationen zum 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 Erfasst auch Informationen zu den mit VMs verbundenen Rechenzentrums-, Cluster-, Netzwerk- und Datastore-Objekten.
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.

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 in den Snapshot einbezogen:

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 wird mit diesem Flag die GKE on VMware-Konfigurationsdatei erfasst, 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 vorliegt, 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 aus dem 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 ist 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.

Geben Sie den SSH-Schlüssel für den Administratorcluster an

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 gkectl diagnose snapshot-Befehl für --admin-ssh-key-path den 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

Mithilfe von Snapshot-Szenarien können Sie festlegen, welche Informationen in einem Snapshot enthalten sein sollen. 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): Erstellen Sie einen Snapshot nur mit Kubernetes-Ressourcen und gkectl-Logs. Alle anderen Logs wie Containerlogs und Knoten-Kernellogs werden ausgeschlossen.

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

Versionen unter 1.13: system, system-with-logs, all und all-with-logs.
Versionen 1.13 bis 1.28: system und all. Das system-Szenario entspricht dem alten system-with-logs-Szenario. Das all-Szenario ist dasselbe wie das alte all-with-logs-Szenario.
Version 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

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 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 diese beiden Szenarien (--scenario system oder all) nicht Ihren Anforderungen entsprechen, können Sie einen benutzerdefinierten Snapshot erstellen. Dazu übergeben Sie eine Snapshot-Konfigurationsdatei mit dem Flag --snapshot-config:

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 Dokumentation, Analyse und Speicherung zu vereinfachen. Dies ist besonders hilfreich, wenn Sie Unterstützung von Cloud Customer Care benötigen.

Bevor Sie Snapshots in einen Cloud Storage-Bucket hochladen, müssen Sie die folgenden Grundvoraussetzungen erfüllen:

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
```
Gewähren Sie dem Dienstkonto im übergeordneten Projekt roles/storage.admin und übergeben Sie die JSON-Schlüsseldatei des Dienstkontos mit dem Parameter --service-account-key-file. Sie können ein beliebiges Dienstkonto verwenden. Wir empfehlen jedoch, das Verbindungsregisterdienstkonto zu verwenden. Weitere Informationen finden Sie unter Dienstkonten.

Hinweis: Wenn Sie das Flag --share-with im Befehl gkectl diagnose snapshot verwenden, ist diese Einrichtung nicht erforderlich. Wenn Sie den Zugriff auf Ihren Snapshot für Cloud Customer Care manuell freigeben möchten, verwenden Sie den folgenden Befehl und nicht das Flag --share-with beim Erstellen des Snapshots.
```
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 jetzt 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, sowie alle anderen Dienstkonten, die von Cloud Customer Care bereitgestellt werden.

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 übereinstimmenden Namen findet, wird ein neuer Bucket mit dem Namen anthos-snapshot-UUID erstellt, wobei UUID eine 32-stellige, universell eindeutige Kennzeichnung 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