Fehlerdiagnose von Clusterproblemen

10

Version 1.10 

• Neueste Version
• Version 1.16
• Frühere Versionen (nicht unterstützt)

In diesem Dokument wird gezeigt, wie Sie mit gkectl diagnose Probleme in Ihren Clustern diagnostizieren.

Überblick

Das gkectl-Tool hat zwei Befehle zur Fehlerbehebung bei Clustern: gkectl diagnose cluster und gkectl diagnose snapshot. Die Befehle sind sowohl für Administrator- als auch für Nutzercluster verfügbar.

gkectl diagnose cluster

Führt Systemdiagnosen für Ihren Cluster aus und meldet Fehler. Führt Systemdiagnosen für die folgenden Komponenten aus:

• vCenter
  • Anmeldedaten
  • DRS
  • Anti-Affinitätsgruppen
  • Netzwerk
  • Version
  • Rechenzentrum
  • Datastore
  • Ressourcenpool
  • Ordner
  • Netzwerk
• Load-Balancer (F5, Seesaw, Manuell)
• Nutzercluster und Knotenpools
• Clusterobjekte
• Bereitschaft des Konnektivitätsservers für den Nutzercluster
• Maschinenobjekte und die entsprechenden Clusterknoten
• Pods in den Namespaces "kube-system" und "gke-system"
• Nutzersteuerungsebene, wenn der Zielcluster ein Nutzercluster ist
• Nichtflüchtige vSphere-Volumes im Cluster
• Signale zur vCPU (virtuellen CPU) des Nutzer- und Administratorclusters und Speicherkonflikten
• ESXi-Alarme zur vorkonfigurierten Host-CPU-Auslastung und Speichernutzung von Nutzer- und Administratorclustern.
• Tageszeit (TOD)
• Knotennetzwerkrichtlinie für einen Cluster mit aktivierter Dataplane V2
• Gesamtzustand des Dataplane V2-Knoten-Agents

gkectl diagnose snapshot

Komprimiert den Status, die Konfigurationen und Logs eines Clusters in einer Tarball-Datei. Die Standardkonfiguration des Befehls erfasst insbesondere 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 Nutzersteuerungsebene, wenn der Zielcluster ein Nutzercluster ist (die Steuerungsebene des Nutzerclusters wird im Administratorcluster ausgeführt)

• 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 Auch mit VMs verknüpfte Rechenzentrums-, Cluster-, Netzwerk- und Datastore-Objekte

• 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 in das system-with-logs- und das all-with-logs-Szenario.

• 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 Upgraden des Clusters mit dem Flag --config verwendet wird.

Anmeldedaten, einschließlich vSphere- und F5-Anmeldedaten, werden entfernt, bevor die Tarball-Datei erstellt wird.

Cluster diagnostizieren

Sie können gkectl diagnose cluster ausführen, um nach häufigen Problemen in Verbindung mit Ihrem Cluster zu suchen.

Hinweis: Das Flag --kubeconfig sollte immer auf die kubeconfig-Datei des Administratorclusters verweisen. gkectl diagnose gibt einen Fehler zurück, wenn Sie die kubeconfig des Nutzerclusters angeben.

Hinweis: Wenn es ein VIP-Problem mit dem Targeting gibt, verwenden Sie die --config-Konfigurationsdatei des Administratorclusters. So erhalten Sie weitere Informationen zur Fehlerbehebung.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Beispielausgabe:

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

Administratorcluster diagnostizieren

Sie können einen Administratorcluster diagnostizieren, indem Sie seinen Namen oder nur die kubeconfig-Datei weitergeben.

kubeconfig-Datei des Administratorclusters verwenden

Wenn Sie die kubeconfig-Datei des Administratorclusters übergeben, wählt gkectl automatisch den Administratorcluster aus:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Namen des Administratorclusters verwenden

Führen Sie den folgenden Befehl aus, um den Namen des Administratorclusters abzurufen:

kubectl get cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Übergeben Sie dann den Namen des Administratorclusters an gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name=ADMIN_CLUSTER_NAME

Wenn Ihr Administratorcluster ordnungsgemäß funktioniert, gibt gkectl diagnose cluster eine Ausgabe wie diese hier zurück:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

Nutzercluster diagnostizieren

Um einen Cluster zu diagnostizieren, rufen Sie zuerst den Namen des Nutzerclusters ab:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

Übergeben Sie dann die kubeconfig-Datei des Administratorclusters und den Namen des Nutzerclusters:

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

Hinweis: gkectl diagnose gibt einen Fehler zurück, wenn Sie die kubeconfig-Datei des Nutzerclusters angeben.

Wenn Ihr Nutzercluster ordnungsgemäß funktioniert, gibt gkectl diagnose cluster eine Ausgabe wie diese hier zurück:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in 

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

Fehlerbehebung bei festgestellten Problemen mit Clustern

Wenn beim Ausführen des Befehls gke diagnose cluster die folgenden Probleme auftreten, können Sie folgende mögliche Lösungen ausprobieren.

.

Problem	Mögliche Ursachen	Lösung
Der Kubernetes API-Server ist weder für den Administratorcluster noch für Nutzercluster erreichbar.	Sehen Sie sich die Diagramme zur Speicherlatenz des virtuellen Maschinenstatus (Out-of-Box, OOB) an, die idealerweise eine Speicherlatenz um null aufweisen. Speicherkonflikte können auch CPU-Konflikte erhöhen und die CPU-Bereitschaftskurven können möglicherweise eine Spitze zeigen, da es zu Auslagerung kommt.	Mehr physischen Speicher erhalten. Weitere Optionen finden Sie unter Vorschläge zur Fehlerbehebung für VMware.
Zeitüberschreitung beim Erstellen des Knotenpools.	Hohe Lese-/Schreiblatenz des VMDK Prüfen Sie den OOB-Status der VM auf die Lese- und Schreiblatenz für virtuelle Laufwerke. Laut VMware weist eine Gesamtlatenz von mehr als 20 ms auf ein Problem hin.	Weitere Informationen finden Sie unter VMware-Lösungen für Probleme mit der Laufwerksleistung.

Clusterstatus erfassen

Wenn gkectl diagnose cluster Fehler findet, sollten Sie den Status des Clusters erfassen und die Informationen an Google senden. Verwenden Sie dazu den Befehl gkectl diagnose snapshot.

gkectl diagnose snapshot hat das optionale Flag --config. Zusätzlich zum Erfassen von Informationen über den Cluster erfasst dieses Flag die Anthos-Cluster in der VMware-Konfigurationsdatei, mit der der Cluster erstellt oder aktualisiert wurde.

Hinweis: Das Flag --kubeconfig sollte immer auf die kubeconfig-Datei des Administratorclusters verweisen. gkectl diagnose gibt einen Fehler zurück, wenn Sie die kubeconfig-Datei des Nutzerclusters angeben.

Status des Administratorclusters erfassen

Führen Sie den folgenden Befehl aus, um den Status eines Administratorclusters zu erfassen, wobei --config optional ist:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Hinweis: Verwenden Sie bei einem VIP-Problem mit dem Targeting-Cluster --config für die Administratorcluster-Konfigurationsdatei. So erhalten Sie weitere Informationen zur Fehlerbehebung.

Die Ausgabe enthält eine Liste von Dateien und den Namen einer Tarball-Datei:

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 [TARBALL_FILE_NAME].tar.gz.

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

tar -zxf [TARBALL_FILE_NAME] --directory [EXTRACTION_DIRECTORY_NAME]

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

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 dann in Ihrem gkectl diagnose snapshot-Befehl --admin-ssh-key-path auf den Pfad Ihrer decodierten Schlüsseldatei:

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 Ausgabe enthält eine Liste von Dateien und den Namen einer Tarball-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

Der Befehl gkectl diagnose snapshot unterstützt vier Szenarien. Verwenden Sie das Flag --scenario, um ein Szenario anzugeben. In der folgenden Liste sind die möglichen Werte aufgeführt:

• all-with-logs: (Standard) all-Snapshot mit Logs erstellen

• system: Snapshot für die System-Namespaces erstellen: kube-system und gke-system

• system-with-logs: system-Snapshot mit Logs erstellen

• all: Snapshot für alle Namespaces erstellen

Sie können jedes der vier Szenarien mit einem Administrator- oder Nutzercluster verwenden. Es gibt also acht mögliche Varianten. Die folgenden Beispiele zeigen einige Möglichkeiten.

So erstellen Sie einen Snapshot des Administratorclusters mit dem all-with-logs-Szenario:

gkectl diagnose snapshot \
--kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--scenario=all-with-logs

So erstellen Sie einen Snapshot des Administratorclusters mit dem system-Szenario:

gkectl diagnose snapshot \
--kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--scenario=system

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

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

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

Mit --log-since einen Snapshot begrenzen

In den Szenarien system-with-logs und all-with-logs können Sie mit dem Flag --log-since 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.

So begrenzen Sie den Zeitraum für die Logerfassung:

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

Ersetzen Sie [DURATION] durch einen Zeitwert wie 120m oder 48h.

Hinweise:

• 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 vier Szenarien 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:

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

• 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 Google Cloud Storage-Bucket hochladen

Sie können alle Snapshots eines bestimmten Clusters in einen Google Cloud Storage-Bucket hochladen, um die Aufzeichnung, Analyse und Speicherung zu vereinfachen. Dies ist insbesondere dann hilfreich, wenn Sie Unterstützung vom Google Cloud-Support benötigen.

Stellen Sie vor der Ausführung dieses Befehls sicher, dass Sie diese Einrichtungsanforderungen erfüllt haben.

• 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.

  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.

• Folgen Sie der Anleitung zum Erstellen eines Google Cloud-Dienstkontos, falls noch nicht geschehen, und zum Freigeben des Zugriffs auf den Bucket für den Google Cloud-Support.

Wenn diese Anforderungen erfüllt sind, können Sie den Snapshot mit diesem Befehl hochladen:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name CLUSTER_NAME \
--upload-to BUCKET_NAME  \
--service-account-key-file SERVICE_ACCOUNT_KEY_FILE \
--share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

Ersetzen Sie SERVICE_ACCOUNT_KEY_FILE durch den Namen der Dienstkontoschlüsseldatei.

Das Flag --share-with kann eine Liste der Dienstkontonamen akzeptieren. Ersetzen Sie GOOGLE_SUPPORT_SERVICE_ACCOUNT durch das Google-Supportdienstkonto, das vom Google-Support bereitgestellt wird, sowie alle anderen Dienstkonten, die vom Google-Support bereitgestellt werden.

Bei Verwendung des optionalen Flags share-with muss es zusammen mit --upload-to und --service-account-file verwendet werden, damit der Snapshot zuerst in Google Cloud Storage hochgeladen werden kann und dann die Leseberechtigung freigegeben werden kann.

Beispielausgabe:

Using "system" snapshot configuration...
Taking snapshot of user cluster CLUSTER_NAME...
Setting up CLUSTER_NAME 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 "SNAPSHOT_FILE_PATH".
Uploading snapshot to Google Cloud Storage......  DONE
Uploaded the snapshot successfully to gs://BUCKET_NAME/CLUSTER_NAME/xSNAPSHOT_FILE_NAME.
Shared successfully with service accounts:
GOOGLE_SUPPORT_SERVICE_ACCOUNT

Bekannte Probleme

Version 1.1.2-gke.0: Pfad wird zu mehreren Rechenzentren aufgelöst

Weitere Informationen finden Sie in den Versionshinweisen zu Anthos-Clustern.

Versionen 1.1.x: Volume ist nicht an die Maschine angehängt

Weitere Informationen finden Sie in den Versionshinweisen zu Anthos-Clustern.