Wenn bei einem Ihrer Cluster ein Problem auftritt, können Sie Hilfe von Cloud Customer Care erhalten. Customer Care fordert Sie möglicherweise auf, einen Snapshot des Clusters zu erstellen, mit dem das Problem diagnostiziert werden kann. Ein Snapshot erfasst Cluster- und Knotenkonfigurationsdateien und verpackt diese Informationen in einer einzelnen TAR-Datei.
In diesem Dokument wird beschrieben, wie Sie Standard-Snapshots oder benutzerdefinierte Snapshots eines Clusters erstellen. Außerdem wird erläutert, wie Sie Snapshots erstellen, wenn bei einem Cluster bestimmte Fehler auftreten.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Standard-Snapshots
In den folgenden Abschnitten wird beschrieben, was ein Standard-Snapshot ist und wie Sie einen erstellen. Informationen zu benutzerdefinierten Snapshots finden Sie im Abschnitt Benutzerdefinierte Snapshots.
Welche Informationen enthält ein Standard-Snapshot?
Der Snapshot eines Clusters ist eine TAR-Datei mit Konfigurationsdateien und Logs zum Cluster. 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.
Details zu jeder Knotenkonfiguration, einschließlich IP-Adressen, iptables-Regeln, Bereitstellungspunkten, Dateisystem, Netzwerkverbindungen und ausgeführten Prozessen.
Informationen über VM Runtime auf GDC und alle VMs und VM-bezogenen Ressourcen, die in Ihrem Cluster laufen. Weitere Informationen dazu, was standardmäßig erfasst wird und wie Sie VM-spezifische Snapshots erstellen, finden Sie unter VM-Informationen in Snapshots in diesem Dokument.
Logs aus dem Befehl
bmctl check cluster --snapshot
.
Die Anmeldedaten eines Clusters sind nicht im Standard-Snapshot enthalten. Wenn Cloud Customer Care diese Informationen anfordert, finden Sie entsprechende Informationen unter Clusterinformationen abrufen.
Eine umfassende Liste der Informationen, die Sie beim Ausführen des Snapshot-Befehls erfassen, finden Sie im folgenden Abschnitt zur Konfigurationsdatei im Detail. Diese Konfigurationsdatei zeigt, welche Befehle ausgeführt werden, wenn ein Standard-Snapshot erstellt wird.
Standard-Snapshot erstellen
Mit dem Befehl bmctl check cluster
wird ein Snapshot eines Clusters erstellt. Mit diesem Befehl können Sie eine der folgenden Aktionen ausführen:
- Snapshot erstellen und diesen Snapshot automatisch in einen Cloud Storage-Bucket hochladen.
- Snapshot eines Clusters erstellen und die Snapshot-Datei auf dem lokalen Rechner speichern, auf dem Sie den Befehl ausführen.
Methode 1: Standard-Snapshot erstellen und automatisch in den Cloud Storage-Bucket hochladen
So erstellen Sie einen Snapshot und laden ihn in einen Cloud Storage-Bucket hoch:
Richten Sie die API und das Dienstkonto wie unter Konfigurieren Sie ein Dienstkonto, das auf einen Cloud Storage-Bucket zugreifen kann.
Dieser Schritt muss nur einmal durchgeführt werden.
Führen Sie den folgenden
bmctl
-Befehl aus, um einen Snapshot zu erstellen und automatisch in einen Cloud Storage-Bucket hochzuladen:bmctl check cluster --snapshot --cluster=CLUSTER_NAME \ --admin-kubeconfig=ADMIN_KUBECONFIG \ --service-account-key-file SA_KEY_FILE
Ersetzen Sie die folgenden Einträge durch spezifische Informationen für Ihre Cluster- Umgebung:
CLUSTER_NAME
: den Namen des Clusters, von dem Sie einen Snapshot erstellen möchtenADMIN_KUBECONFIG
: Der Pfad zur kubeconfig-Datei des Administratorclusters.SA_KEY_FILE
: Der Pfad zur heruntergeladenen JSON-Schlüsseldatei für das im vorherigen Schritt erstellte Dienstkonto. Wenn Sie das Flag--service-account-key-file
nicht verwenden, verwendet der Befehl die Anmeldedaten, die der UmgebungsvariableGOOGLE_APPLICATION_CREDENTIALS
zugeordnet sind. Die explizite Angabe der Anmeldedaten für das Dienstkonto mit dem Flag hat Vorrang.
Dieser Befehl generiert eine Snapshot-TAR-Datei und speichert sie lokal. Wenn das Dienstkonto korrekt eingerichtet ist, lädt der Befehl auch die TAR-Datei des Snapshots in einen Bucket in Cloud Storage hoch. Der Befehl sucht in Ihrem 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 passenden Namen findet, wird ein neuer Bucket mit dem Namenanthos-snapshot-UUID
erstellt, wobeiUUID
eine eindeutige Kennung mit 32 Ziffern ist.Zugriff für Cloud Customer Care freigeben, wie unter Cloud Customer Care erlauben, Ihren hochgeladenen Cluster-Snapshot anzusehen.
Methode 2: Standard-Snapshot nur auf dem lokalen Rechner erstellen
Verwenden Sie das --local
-Flag, um sicherzustellen, dass Ihr Cluster-Snapshot nur lokal gespeichert wird. Sie können den Status der erstellten Cluster mit dem folgenden Befehl erfassen:
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--admin-kubeconfig=ADMIN_KUBECONFIG --local
Ersetzen Sie Folgendes:
CLUSTER_NAME
gibt den Namen des Zielclusters an.ADMIN_KUBECONFIG
: Der Pfad zur kubeconfig-Datei des Administratorclusters.
Dieser Befehl gibt eine TAR-Datei auf Ihren lokalen Rechner aus. Der Name dieser TAR-Datei hat das Format snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz
, wobei TIMESTAMP
das Datum und die Uhrzeit der Dateierstellung angibt. Diese TAR-Datei enthält relevante Debugging-Informationen zu den Systemkomponenten und Maschinen eines Clusters.
Wenn Sie diesen Befehl ausführen, werden Informationen zu Pods aus den folgenden Namespaces erfasst: gke-system
,gke-connect
,capi-system
,capi-webhook-system
,cert-manager
und capi-kubeadm-bootstrap-system
Sie können den Umfang der Diagnoseinformationen jedoch mit dem Flag --snapshot-scenario all
erweitern. Dieses Flag erweitert den Bereich des Diagnose-Snapshots, sodass alle Pods in einem Cluster enthalten sind:
bmctl check cluster --snapshot --snapshot-scenario all \
--cluster=CLUSTER_NAME \
--kubeconfig=KUBECONFIG_PATH \
--local
Snapshot-Szenarien
Der Befehl bmctl check cluster --snapshot
unterstützt zwei Szenarien. Verwenden Sie das Flag --scenario
, um ein Szenario anzugeben. In der folgenden Liste sind die möglichen Werte aufgeführt:
system
: Snapshot von Systemkomponenten erstellen, einschließlich ihrer Logsall
: Snapshot aller Pods erstellen, einschließlich ihrer Logs
Sie können jedes der beiden Szenarien mit einem Administrator- oder Nutzercluster verwenden. Im folgenden Beispiel wird ein Snapshot des Administratorclusters mit dem system
-Szenario erstellt:
bmctl check cluster --snapshot --snapshot-scenario system \ --cluster=ADMIN_CLUSTER_NAME \ --kubeconfig=ADMIN_KUBECONFIG_PATH
Im folgenden Beispiel wird ein Snapshot eines Nutzerclusters mit dem Szenario all
erstellt:
bmctl check cluster --snapshot --snapshot-scenario all \ --cluster=USER_CLUSTER_NAME \ --kubeconfig=USER_KUBECONFIG_PATH
Probelauf für einen Snapshot durchführen
Wenn Sie das Flag --snapshot-dry-run
verwenden, erstellt der Befehl keinen Snapshot.
Stattdessen wird angezeigt, welche Aktionen der Snapshot-Befehl ausführen würde, und es wird eine Snapshot-Konfigurationsdatei ausgegeben. Informationen zur Snapshot-Konfigurationsdatei finden Sie unter Benutzerdefinierten Snapshot erstellen.
Geben Sie den folgenden Befehl ein, um einen Snapshot-Probelauf für Ihren Administratorcluster durchzuführen:
bmctl check cluster --snapshot --snapshot-dry-run \ --cluster=ADMIN_CLUSTER_NAME \ --kubeconfig=ADMIN_KUBECONFIG_PATH
Geben Sie den folgenden Befehl ein, um einen Snapshot-Probelauf für einen Nutzercluster durchzuführen:
bmctl check cluster --snapshot --snapshot-dry-run \ --cluster=USER_CLUSTER_NAME \ --kubeconfig=USER_KUBECONFIG_PATH
Logs für einen bestimmten Zeitraum abrufen
Mit dem Flag --since
können Sie Logs aus einem Zeitraum abrufen, der für Sie besonders interessant ist. Auf diese Weise können Sie kleinere und zielgerichtetere Snapshots des Loggings erstellen, die in den letzten Sekunden, Minuten oder Stunden erfolgt sind.
Mit dem folgenden bmctl
-Befehl wird beispielsweise ein Snapshot des Loggings erstellt, das in den letzten drei Stunden passiert ist:
bmctl check cluster --snapshot --since=3h \ --cluster=CLUSTER_NAME \ --kubeconfig=ADMIN_KUBECONFIG_PATH
Geben Sie ein Verzeichnis an, in dem der Snapshot vorübergehend gespeichert wird.
Mit dem Flag --snapshot-temp-output-dir
können Sie ein Verzeichnis angeben, in dem der Snapshot vorübergehend gespeichert wird:
bmctl check cluster --snapshot --snapshot-temp-output-dir=TEMP_OUTPUT_DIR \ --cluster=CLUSTER_NAME \ --kubeconfig=ADMIN_KUBECONFIG_PATH
Wenn Sie kein Verzeichnis angeben, wird der Snapshot vorübergehend im Verzeichnis /tmp
gespeichert. Die Verwendung der Option --snapshot-temp-output-dir
ist zu empfehlen, wenn der Speicherplatz im Standardverzeichnis /tmp
begrenzt ist.
Console-Logging unterdrücken
Mit dem Flag --quiet
können Sie unterdrücken, dass Logmeldungen während einer Snapshot-Ausführung in der Console angezeigt werden. Stattdessen werden die Konsolenlogs als Teil des Snapshots in der Datei „bmctl_diagnose_snapshot.log“ gespeichert.
Führen Sie den folgenden Befehl aus, um zu verhindern, dass Logmeldungen in der Konsole angezeigt werden:
bmctl check cluster --snapshot --quiet \ --cluster=CLUSTER_NAME \ --kubeconfig=ADMIN_KUBECONFIG_PATH
Benutzerdefinierte Snapshots
Sie möchten vielleicht aus folgenden Gründen einen benutzerdefinierten Snapshot eines Clusters erstellen:
- Um mehr Informationen zu Ihrem Cluster einzuschließen als die, die im Standard-Snapshot enthalten sind
- Um einige Informationen auszuschließen, die im Standard-Snapshot enthalten sind
Benutzerdefinierten Snapshot erstellen
Für das Erstellen eines benutzerdefinierten Snapshots ist eine Snapshot-Konfigurationsdatei erforderlich. In den folgenden Schritten wird erläutert, wie Sie die Konfigurationsdatei erstellen, ändern und verwenden, um einen benutzerdefinierten Snapshot eines Clusters zu erstellen:
Erstellen Sie eine Snapshot-Konfigurationsdatei, indem Sie den folgenden Befehl in Ihrem Cluster ausführen und die Ausgabe in eine Datei schreiben:
bmctl check cluster \ --snapshot --snapshot-dry-run --cluster CLUSTER_NAME \ --kubeconfig KUBECONFIG_PATH
Legen Sie fest, welche Informationen in Ihrem benutzerdefinierten Snapshot enthalten sein sollen. Ändern Sie dazu die Snapshot-Konfigurationsdatei, die Sie in Schritt 1 erstellt haben. Wenn Sie beispielsweise möchten, dass der Snapshot zusätzliche Informationen enthält, beispielsweise wie lange ein bestimmter Knoten bereits ausgeführt wird, fügen Sie den Linux-Befehl
uptime
zum entsprechenden Bereich der Konfigurationsdatei hinzu.Das folgende Snippet einer Konfigurationsdatei zeigt, wie der Snapshot-Befehl
uptime
-Informationen zum Knoten10.200.0.3
bereitstellen kann. Diese Informationen sind nicht in einem Standard-Snapshot enthalten.... nodeCommands: - nodes: - 10.200.0.3 commands: - uptime ...
Nachdem Sie die Konfigurationsdatei geändert haben, um festzulegen, welche Art von Snapshot Sie wünschen, erstellen Sie den benutzerdefinierten Snapshot, indem Sie den folgenden Befehl ausführen:
bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE \ --cluster CLUSTER_NAME--kubeconfig KUBECONFIG_PATH
Das Flag
--snapshot-config
weist den Befehlbmctl
an, den Inhalt der Snapshot-Konfigurationsdatei zu verwenden, um zu festzulegen, welche Informationen im Snapshot angezeigt werden.
Konfigurationsdatei im Detail
Die folgende Beispiel-Konfigurationsdatei für einen Snapshot zeigt die Standardbefehle und -dateien, die zum Erstellen eines Snapshots verwendet werden. Sie können jedoch weitere Befehle und Dateien hinzufügen, wenn zusätzliche Diagnoseinformationen erforderlich sind:
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
Die folgenden Einträge in Ihrer Konfigurationsdatei unterscheiden sich wahrscheinlich von denen in der vorherigen Beispielkonfigurationsdatei:
- Die IP-Adressen der Knoten in den Abschnitten
nodeCommands
undnodeFiles
- Der Pfad zum
nodeSSHKey
Ihres Clusters
Felder in der Konfigurationsdatei
Eine Snapshot-Konfigurationsdatei im YAML-Format. Die Konfigurationsdatei enthält die folgenden Felder:
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
auf10
zu setzen, wie in der vorherigen Beispielkonfigurationsdatei gezeigt. Wenn die Snapshots zu lange dauern, erhöhen Sie diesen Wert.excludeWords
: Der Snapshot enthält eine große Datenmenge für Ihre Clusterknoten. Verwenden SieexcludeWords
, um Sicherheitsrisiken zu reduzieren, wenn Sie Ihren Snapshot teilen. Schließen Sie beispielsweisepassword
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 von 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
: der Pfad zu Ihrer SSH-Schlüsseldatei. Wenn der Administratorcluster nicht erreichbar ist, ist dieses Feld erforderlich.
Snapshots bei bestimmten Fehlern erstellen
Bei bestimmten Ereignissen, z. B. bei einem angehaltenen Upgrade, sind möglicherweise zusätzliche Schritte oder Befehlsparameter erforderlich, um einen Snapshot erfolgreich zu erstellen.
Standard-Snapshot bei hängen gebliebenen Installationen oder Upgrades erstellen
Wenn Sie Administrator-, Hybrid- oder eigenständige Cluster installieren oder upgraden, kann bmctl
manchmal an Punkten hängen bleiben, an denen die folgenden Ausgaben angezeigt werden:
- Warten, bis Cluster-kubeconfig bereit ist
- Warten, bis Cluster bereit ist
- Warten, bis Knotenpools bereit sind
- Warten auf Abschluss des Upgrades
Wenn die Installation oder das Upgrade hängen bleibt, können Sie mit dem Bootstrap-Cluster einen Snapshot des Clusters erstellen, wie im folgenden Beispiel gezeigt:
bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
--kubeconfig=WORKSPACE_DIR/.kindkubeconfig
Benutzerdefinierten Snapshot bei hängen gebliebenen Installationen oder Upgrades erstellen
In den folgenden Schritten wird gezeigt, wie Sie einen benutzerdefinierten Snapshot eines Clusters erstellen, wenn die Installation oder das Upgrade angehalten wurde:
Rufen Sie eine Snapshot-Konfigurationsdatei des Clusters aus dem Archiv ab.
Ändern Sie die Snapshot-Konfigurationsdatei so, dass der Snapshot die gewünschten Informationen enthält.
Erstellen Sie den benutzerdefinierten Snapshot mit folgendem Befehl:
bmctl check cluster --snapshot --snapshot-config=SNAPSHOT_CONFIG_FILE \ --cluster=CLUSTER_NAME --kubeconfig=WORKSPACE_DIR/.kindkubeconfig
Benutzerdefinierten Snapshot erstellen, wenn der Administratorcluster nicht erreichbar ist
Wenn der Administratorcluster nicht erreichbar ist, können Sie mit dem folgenden Befehl einen benutzerdefinierten Snapshot des Clusters erstellen:
bmctl check cluster --snapshot --cluster CLUSTER_NAME
--node-ssh-key SSH_KEY_FILE
--nodes NODE_1_IP_ADDRESS, NODE_2_IP_ADDRESS, ...
Ersetzen Sie im Befehl die folgenden Einträge durch Informationen, die für Ihre Clusterumgebung spezifisch sind:
CLUSTER_NAME
: Der Name des Clusters, von dem Sie einen Snapshot erstellen möchten.SSH_KEY_FILE
: Der Pfad zur Knoten-SSH-Schlüsseldatei.NODE_x_IP_ADDRESS
: Die IP-Adresse eines Clusterknotens, zu dem Sie Informationen erhalten möchten.
Alternativ können Sie Knoten-IP-Adressen in separaten Zeilen auflisten:
bmctl check cluster
--snapshot --cluster CLUSTER_NAME \
--node-ssh-key SSH_KEY_FILE \
--nodes NODE_1_IP_ADDRESS \
--nodes NODE_2_IP_ADDRESS
...
VM-Informationen in Snapshots
Wenn Sie VM Runtime in GDC verwenden, um virtuelle Maschinen (VMs) in Google Distributed Cloud zu erstellen und zu verwalten, können Sie relevante Diagnoseinformationen in Snapshots erfassen. Snapshots sind eine wichtige Ressource zum Diagnostizieren und Beheben von Problemen mit Ihren VMs.
Standardmäßig erfasste Daten
Wenn Sie einen Standard-Snapshot erstellen, enthält er die Informationen zu VM Runtime in GDC und den zugehörigen Ressourcen.
VM Runtime in GDC ist in Google Distributed Cloud gebündelt. Die benutzerdefinierte VMRuntime
-Ressource ist auf Ihren Clustern verfügbar, die Arbeitslasten ausführen.
Auch wenn Sie die VM Runtime in GDC nicht aktiviert haben, enthält der Snapshot die YAML-Beschreibung für benutzerdefinierte VMRuntime
-Ressourcen.
Wenn Sie VM Runtime in GDC aktiviert haben, enthalten Snapshots Status- und Konfigurationsinformationen für die VM-bezogenen Ressourcen (wenn die Objekte vorhanden sind) in Ihrem Cluster. VM-bezogene Ressourcen umfassen Kubernetes-Objekte wie Pods, Deployments, DaemonSets und ConfigMaps.
Objekte im vm-system
-Namespace
Status- und Konfigurationsinformationen für die folgenden Objekte befinden sich in kubectlCommands/vm-system
im generierten Snapshot:
KubeVirt
VirtualMachineType
VMHighAvailabilityPolicy
Objekte in anderen Namespaces
Wenn Sie eine VM (VirtualMachine
) erstellen, können Sie den Namespace angeben. Wenn Sie keinen Namespace angeben, ruft die VM den Namespace default
ab. Die anderen Objekte in diesem Abschnitt wie VirtualMachineInstance
sind alle an den Namespace für die entsprechende VM gebunden.
Status- und Konfigurationsinformationen für die folgenden Objekte befinden sich in kubectlCommands/VM_NAMESPACE
im generierten Snapshot. Wenn Sie keinen bestimmten Namespace für Ihre VM festgelegt haben, befinden sich die Informationen in kubectlCommands/default
:
VirtualMachine
VirtualMachineInstance
VirtualMachineDisk
GuestEnvironmentData
VirtualMachineAccessRequest
VirtualMachinePasswordResetRequest
Objekte, die keinen Namespace haben
Die folgenden Objekte haben keinen Namespace. Daher befinden sich die entsprechenden Informationen direkt im generierten Snapshot in kubectlCommands
:
VMRuntime
DataVolume
CDI
GPUAllocation
Snapshot-Konfigurationsdatei nur zum Erfassen von VM-Details verwenden
Wenn Sie Probleme speziell für VMs diagnostizieren, können Sie mithilfe einer Snapshot-Konfigurationsdatei die erfassten Informationen sowohl auf VM-bezogene Details beschränken als auch die erfassten VM-Informationen anpassen.
Die folgende Snapshot-Konfigurationsdatei veranschaulicht, wie Sie einen VM-spezifischen Snapshot erstellen können. Sie können zusätzliche Befehle hinzufügen, um weitere Informationen für Ihren Snapshot zu erfassen.
---
kubectlCommands:
- commands:
- kubectl get vm -o wide
- kubectl get vmi -o wide
- kubectl get gvm -o wide
- kubectl get vm -o yaml
- kubectl get vmi -o yaml
- kubectl get gvm -o yaml
- kubectl describe vm
- kubectl describe vmi
- kubectl describe gvm
namespaces:
- .*
- commands:
- kubectl get virtualmachinetype -o wide
- kubectl get virtualmachinedisk -o wide
- kubectl get virtualmachinetype -o yaml
- kubectl get virtualmachinedisk -o yaml
- kubectl describe virtualmachinetype
- kubectl describe virtualmachinedisk
namespaces:
- vm-system
Weitere Informationen zur Verwendung von Snapshot-Konfigurationsdateien finden Sie in diesem Dokument unter Benutzerdefinierte Snapshots.