Diese Seite wurde von der Cloud Translation API übersetzt.

Systemdiagnosen

Systemdiagnosen sind eine Möglichkeit, den Betrieb Ihrer vorhandenen Cluster zu testen und zu überwachen. Systemdiagnosen werden regelmäßig automatisch ausgeführt. Sie können auch bmctl verwenden, um Systemdiagnosen nach Bedarf auszuführen. In diesem Dokument wird jede Prüfung beschrieben, unter welchen Bedingungen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt und wie die Ergebnisse interpretiert werden sollten.

Was wird geprüft?

Es gibt zwei Kategorien von Google Distributed Cloud-Systemdiagnosen:

Prüfungen von Knotenrechnern
Clusterweite Prüfungen

In den folgenden Abschnitten wird beschrieben, was für die einzelnen Kategorien geprüft wird. Diese Prüfungen werden sowohl für regelmäßige als auch für On-Demand-Systemdiagnosen verwendet.

Prüfungen von Knotenrechnern

In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für Knotenmaschinen ausgewertet wird. Mit diesen Prüfungen wird bestätigt, dass die Knotenmaschinen richtig konfiguriert sind und dass sie über genügend Ressourcen und Konnektivität für die Clustererstellung, Cluster-Upgrades und den Clusterbetrieb verfügen.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-Ressourcen HealthCheck mit dem Namen bm-system-NODE_IP_ADDRESS-machine (z. B. bm-system-192.0.2.54-machine), die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Systemdiagnoseressourcen finden Sie unter HealthCheckBenutzerdefinierte Ressourcen.

Hinweis: Die allgemeinen Maschinenprüfungen und die Maschinenprüfungen Google Cloud werden auch in Preflight-Prüfungen verwendet.

Häufige Maschinenprüfungen:

Auf den Clustermaschinen wird ein unterstütztes Betriebssystem verwendet.
Die Betriebssystemversion wird unterstützt.
Das Betriebssystem verwendet eine unterstützte Kernelversion.
Im Kernel ist die BPF Just In Time-Compiler-Option (CONFIG_BPF_JIT=y) aktiviert.
Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.
Die Knotencomputer erfüllen die Mindestanforderungen an die CPU.
Auf den Knotenmaschinen sind mehr als 20% der CPU-Ressourcen verfügbar.
Die Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.
Die Knotenmaschinen erfüllen die Mindestanforderungen an den Festplattenspeicher.
Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.
Die Standardroute zum Weiterleiten von Paketen an das Standardgateway ist auf den Knoten vorhanden.
Das Domain Name System (DNS) funktioniert (diese Prüfung wird übersprungen, wenn der Cluster für die Ausführung hinter einem Proxy konfiguriert ist).
Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, ist der Spiegel erreichbar.

Google Cloud -Prüfungen bestehen aus Folgendem:

Artifact Registry, gcr.io ist erreichbar (diese Prüfung wird übersprungen, wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist).
Google APIs sind erreichbar.

Systemdiagnosen für Maschinen bestehen aus Folgendem:

kubelet ist aktiv und wird auf Knotencomputern ausgeführt.
containerd ist aktiv und wird auf Knotencomputern ausgeführt.
Der Systemstatus des CNI-Endpunkts (Container Network Interface) ist „Fehlerfrei“.
Pod-CIDRs überschneiden sich nicht mit den IP-Adressen der Knotenmaschinen.

Die kubeadm-Zertifikate sind nicht abgelaufen.

Weitere Informationen zu den Anforderungen an Knotenmaschinen finden Sie unter Voraussetzungen für Clusterknoten-Rechner.

Clusterweite Prüfungen

In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für einen Cluster ausgewertet wird.

Standardprüfungen

Die Standard-Clusterprüfungen, die automatisch im Rahmen der regelmäßigen Systemdiagnosen ausgeführt werden, können auch bei Bedarf im Rahmen von Cluster-Systemdiagnosen ausgeführt werden. Diese Prüfungen sorgen dafür, dass Kubernetes-Clusterressourcen richtig konfiguriert sind und ordnungsgemäß funktionieren.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-Ressourcen HealthCheck mit dem Namen bm-system-default-*, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Systemdiagnoseressourcen finden Sie unter Benutzerdefinierte Ressourcen für HealthCheck.

Bei den Standard-Clusterprüfungen werden die folgenden Ressourcentypen und Bedingungen geprüft:

DaemonSet
- Konfigurationen sind gültig
- DaemonSets sind fehlerfrei
Bereitstellung
- Konfigurationen sind gültig
- Bereitstellungen sind fehlerfrei
Knoten (die folgenden Bedingungen beziehen sich alle auf Knoten)
- Status „Knoten bereit“
- Kubelet-Festplattendruck
- Kubelet-Arbeitsspeicherdruck
- kubelet-Prozess-ID-Druck (PID)
- Häufigkeit von Kubelet-Neustarts
- Kubelet ist fehlerfrei
- Netzwerkverfügbarkeit
- containerd-Funktion
- Häufigkeit von containerd-Neustarts
- Docker Overlay2-Funktion
- Häufigkeit von Docker-Neustarts
- Häufigkeit von Ereignissen zum Aufheben der Registrierung von Netzwerkgeräten
- Kernel-Deadlocks
- KubeProxy ist fehlerfrei
- Schreibgeschütztes Dateisystem
Pod
- Konfigurationen sind gültig
- Pods sind fehlerfrei
- Container sind fehlerfrei
PodDisruptionBudget (PDB)
- Konfigurationen sind gültig
- PDB-Laufzeitfunktion
- PDBs stimmen mit Pods überein
- Pods, die nicht von mehreren PDBs verwaltet werden
Ressourcenanforderungen
- Für Pods auf Zielknoten sind CPU- und Speicheranforderungen festgelegt.
- Die durchschnittliche Ressourcenanfrage pro Knoten liegt innerhalb des verfolgten Limits.
Dienst
- Konfigurationen sind gültig
- Dienste sind fehlerfrei
StatefulSet
- Konfigurationen sind gültig
- StatefulSet

Netzwerkprüfungen

Die folgenden clientseitigen Netzwerkprüfungen für Clusterknoten werden automatisch im Rahmen regelmäßiger Systemdiagnosen ausgeführt. Netzwerkprüfungen können nicht auf Anfrage ausgeführt werden. Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-Ressourcen HealthCheck mit dem Namen bm-system-network, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Systemdiagnoseressourcen finden Sie unter Benutzerdefinierte HealthCheck-Ressourcen.

Wenn der Cluster gebündeltes Load-Balancing verwendet, müssen Knoten im Load-Balancing-Knotenpool eine ARP-Konnektivität (Address Resolution Protocol) der Schicht 2 haben. ARP ist für die VIP-Erkennung erforderlich.
Auf Knoten der Steuerungsebene sind die Ports 8443 und 8444 für die Verwendung durch den GKE Identity Service geöffnet.
Auf den Knoten der Steuerungsebene sind die Ports 2382 und 2383 für die Verwendung durch die etcd-events-Instanz geöffnet.

Informationen zu Protokollen und zur Portnutzung für Ihre Cluster finden Sie unter Netzwerkanforderungen. Die Netzwerkprüfungen für eine Preflight-Prüfung unterscheiden sich von den Netzwerk-Systemdiagnosen. Eine Liste der Netzwerkprüfungen für eine Preflight-Prüfung finden Sie unter Preflight-Prüfungen für die Clustererstellung oder Preflight-Prüfungen für Clusterupgrades.

Kubernetes

Kubernetes-Prüfungen, die automatisch im Rahmen von Preflight- und regelmäßigen Integritätsprüfungen ausgeführt werden, können auch on demand ausgeführt werden. Bei diesen Statusprüfungen wird kein Fehler zurückgegeben, wenn eine der aufgeführten Komponenten der Steuerungsebene fehlt. Bei der Prüfung werden nur Fehler zurückgegeben, wenn die Komponenten vorhanden sind und zum Zeitpunkt der Befehlsausführung Fehler aufweisen.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-Ressourcen HealthCheck mit dem Namen bm-system-kubernetes, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Systemdiagnoseressourcen finden Sie unter HealthCheckBenutzerdefinierte Ressourcen.

Der API-Server funktioniert.
Der Operator anetd ist richtig konfiguriert.
Alle Knoten der Steuerungsebene sind betriebsbereit.
Die folgenden Komponenten der Steuerungsebene funktionieren ordnungsgemäß:
- anthos-cluster-operator
- controller-manager
- cluster-api-provider
- ais
- capi-kubeadm-bootstrap-system
- cert-manager
- kube-dns

Add-ons

Add-on-Prüfungen werden automatisch im Rahmen von Preflight-Prüfungen und regelmäßigen Systemdiagnosen ausgeführt und können on demand ausgeführt werden. Bei dieser Systemdiagnose wird kein Fehler zurückgegeben, wenn eines der aufgeführten Add-ons fehlt. Bei der Prüfung werden nur Fehler zurückgegeben, wenn die Add-ons vorhanden sind und bei der Ausführung des Befehls Fehler auftreten.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-Ressourcen HealthCheck mit dem Namen bm-system-add-ons*, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Systemdiagnoseressourcen finden Sie unter HealthCheckBenutzerdefinierte Ressourcen.

Cloud Logging-Stackdriver-Komponenten und Connect Agent sind betriebsbereit:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
Bei von Google Distributed Cloud verwalteten Ressourcen sind keine manuellen Änderungen (Konfigurationsabweichung) zu sehen:
- Feldwerte wurden nicht aktualisiert
- Optionale Felder wurden nicht hinzugefügt oder entfernt
- Ressourcen wurden nicht gelöscht

Wenn bei der Systemdiagnose eine Konfigurationsabweichung erkannt wird, wird der Wert Status.Pass der benutzerdefinierten Ressource bm-system-add-ons Bare Metal HealthCheck auf false gesetzt. Das Feld Description im Abschnitt Failures enthält Details zu allen geänderten Ressourcen, einschließlich der folgenden Informationen:

Version: Die API-Version für die Ressource.
Kind: Das Objektschema, z. B. Deployment, für die Ressource.
Namespace: der Namespace, in dem sich die Ressource befindet.
Name ist der Name der -Ressource.
Diff: Ein Stringformatvergleich der Unterschiede zwischen dem aufgezeichneten Ressourcenmanifest und dem Manifest für die geänderte Ressource.

Benutzerdefinierte `HealthCheck`-Ressourcen

Wenn eine Systemdiagnose ausgeführt wird, erstellt Google Distributed Cloud eine benutzerdefinierte Ressource HealthCheck. Benutzerdefinierte HealthCheck-Ressourcen sind persistent und bieten eine strukturierte Aufzeichnung der Aktivitäten und Ergebnisse der Systemdiagnose. Es gibt zwei Kategorien von benutzerdefinierten HeathCheck-Ressourcen:

Bare Metal HealthCheck benutzerdefinierte Ressourcen (API Version: baremetal.cluster.gke.io/v1): Diese Ressourcen enthalten Details zu regelmäßigen Integritätsprüfungen. Diese Ressourcen befinden sich im Administratorcluster in Cluster-Namespaces. Bare-Metal-HealthCheck-Ressourcen sind für das Erstellen von Cronjobs und Jobs für Systemdiagnosen verantwortlich. Diese Ressourcen werden regelmäßig mit den neuesten Ergebnissen aktualisiert.
Benutzerdefinierte Anthos-Ressourcen vom Typ HealthCheck (API Version: anthos.gke.io/v1): Diese Ressourcen werden verwendet, um Systemdiagnosemesswerte zu melden. Diese Ressourcen befinden sich im Namespace kube-system jedes Clusters. Die Aktualisierung dieser Ressourcen erfolgt nach bestem Wissen und Gewissen. Wenn ein Update aufgrund eines Problems fehlschlägt, z. B. eines vorübergehenden Netzwerkfehlers, wird der Fehler ignoriert.

In der folgenden Tabelle sind die Ressourcentypen aufgeführt, die für die Kategorie HealthCheck erstellt werden:

Bare-Metal-Health-Checks Anthos HealthChecks Schweregrad

Bare-Metal-Health-Checks	Anthos HealthChecks	Schweregrad
Typ: Standard Name: `bm-system-default-daemonset` Name: `bm-system-default-deployment` Name: `bm-system-default-node` Name: `bm-system-default-pod` Name: `bm-system-default-poddisruptionbudget` Name: `bm-system-default-resource` Name: `bm-system-default-service` Name: `bm-system-default-statefulset`	Typ: Standard Name: `bm-system-default-daemonset` Name: `bm-system-default-deployment` Name: `bm-system-default-node` Name: `bm-system-default-pod` Name: `bm-system-default-poddisruptionbudget` Name: `bm-system-default-resource` Name: `bm-system-default-service` Name: `bm-system-default-statefulset`	Kritisch
Typ: Maschine Name: `bm-system-NODE_IP_ADDRESS-machine`	Typ: Maschine Name: `bm-system-NODE_IP_ADDRESS-machine`	Kritisch
Typ: Netzwerk Name: `bm-system-network`	Typ: Netzwerk Name: `bm-system-network`	Kritisch
Typ: kubernetes Name: `bm-system-kubernetes`	Typ: kubernetes Name: `bm-system-kubernetes`	Kritisch
Typ: Add-ons Name: `bm-system-add-ons`	Typ: Add-ons Name: `bm-system-add-ons-add-ons` Name: `bm-system-add-ons-configdrift`	Optional

Typ: Standard

Name: bm-system-default-daemonset

Name: bm-system-default-deployment

Name: bm-system-default-node

Name: bm-system-default-pod

Name: bm-system-default-poddisruptionbudget

Name: bm-system-default-resource

Name: bm-system-default-service

Name: bm-system-default-statefulset

Typ: Standard

Name: bm-system-default-daemonset

Name: bm-system-default-deployment

Name: bm-system-default-node

Name: bm-system-default-pod

Name: bm-system-default-poddisruptionbudget

Name: bm-system-default-resource

Name: bm-system-default-service

Name: bm-system-default-statefulset

Kritisch

Typ: Maschine

Name: bm-system-NODE_IP_ADDRESS-machine

Typ: Maschine

Name: bm-system-NODE_IP_ADDRESS-machine

Kritisch

Typ: Netzwerk

Name: bm-system-network

Typ: Netzwerk

Name: bm-system-network

Kritisch

Typ: kubernetes

Name: bm-system-kubernetes

Typ: kubernetes

Name: bm-system-kubernetes

Kritisch

Typ: Add-ons

Name: bm-system-add-ons

Typ: Add-ons

Name: bm-system-add-ons-add-ons

Name: bm-system-add-ons-configdrift

Optional

So rufen Sie den Status von HealthCheck ab:

Wenn Sie die Ergebnisse regelmäßiger Systemdiagnosen lesen möchten, können Sie die zugehörigen benutzerdefinierten Ressourcen abrufen:

kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig ADMIN_KUBECONFIG \
    --all-namespaces

Ersetzen Sie ADMIN_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.

Das folgende Beispiel zeigt die Systemdiagnosen, die regelmäßig ausgeführt werden, und ob die Prüfungen beim letzten Ausführen bestanden wurden:

NAMESPACE               NAME                               PASS    AGE
cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
cluster-test-admin001   bm-system-add-ons                  true    11d
cluster-test-admin001   bm-system-kubernetes               true    11d
cluster-test-admin001   bm-system-network                  true    11d
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

Verwenden Sie kubectl describe, um Details zu einer bestimmten Systemdiagnose abzurufen:

kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

Ersetzen Sie Folgendes:

HEALTHCHECK_NAME: der Name der Systemdiagnose
ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
CLUSTER_NAMESPACE: den Namespace des Clusters.

Wenn Sie die Ressource prüfen, enthält der Abschnitt Status: die folgenden wichtigen Felder:

Pass: Gibt an, ob der letzte Systemdiagnosejob bestanden wurde.
Checks: enthält Informationen zum letzten Systemdiagnosejob.
Failures: Enthält Informationen zum letzten fehlgeschlagenen Job.
Periodic: Enthält Informationen dazu, wann ein Systemdiagnosejob zuletzt geplant und instrumentiert wurde.

Das folgende HealthCheck-Beispiel zeigt eine erfolgreiche Maschinenprüfung:

Name:         bm-system-192.0.2.54-machine
Namespace:    cluster-test-user001
Labels:       baremetal.cluster.gke.io/periodic-health-check=true
              machine=192.0.2.54
              type=machine
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
Metadata:
  Creation Timestamp:  2023-09-22T18:03:27Z
  ...
Spec:
  Anthos Bare Metal Version:  1.16.0
  Cluster Name:               nuc-user001
  Interval In Seconds:        3600
  Node Addresses:
    192.168.1.54
  Type:  machine
Status:
  Check Image Version:  1.16.0-gke.26
  Checks:
    192.168.1.54:
      Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
      Message:
      Pass:     true
  ...
  Cluster Spec:
    Anthos Bare Metal Version:  1.16.0
    Bypass Preflight Check:     false
    Cluster Network:
      Bundled Ingress:  true
      Pods:
        Cidr Blocks:
          10.0.0.0/16
      Services:
        Cidr Blocks:
          10.96.0.0/20
  ...
  Conditions:
    Last Transition Time:  2023-11-22T17:53:18Z
    Observed Generation:   1
    Reason:                LastPeriodicHealthCheckFinished
    Status:                False
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  nuc-user001
    ...
  Pass:                  true
  Periodic:
    Last Schedule Time:                    2023-11-22T17:53:18Z
    Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
  Start Time:                              2023-09-22T18:03:28Z
Events:
  Type    Reason                  Age                  From                    Message
  ----    ------                  ----                 ----                    -------
  Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished

Das folgende HealthCheck-Beispiel zeigt eine fehlgeschlagene Maschinenprüfung:

Name:         bm-system-192.0.2.57-machine
Namespace:    cluster-user-cluster1
...
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
...
Status:
  Checks:
    192.0.2.57:
      Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
      Message:  following checks failed, ['check_kubelet_pass']
      Pass:     false
  Failures:
    Category:     AnsibleJobFailed
    Description:  Job: machine-health-check.
    Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
    Reason:       following checks failed, ['check_kubelet_pass']
  Pass:                  false
  Periodic:
    Last Schedule Time:                    2023-10-24T23:04:21Z
    Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
  ...

Mit dem folgenden Befehl rufen Sie eine Liste der Systemdiagnosen für Messwerte ab:

kubectl get healthchecks.anthos.gke.io \
    --kubeconfig CLUSTER_KUBECONFIG \
    --namespace kube-system

Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Zielclusters.

Das folgende Beispiel zeigt das Antwortformat:

NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
kube-system   bm-system-default-daemonset                                             Healthy   52m
kube-system   bm-system-default-deployment                                            Healthy   52m
kube-system   bm-system-default-node                                                  Healthy   52m
kube-system   bm-system-default-pod                                                   Healthy   52m
kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
kube-system   bm-system-default-resource                                              Healthy   52m
kube-system   bm-system-default-service                                               Healthy   52m
kube-system   bm-system-default-statefulset                                           Healthy   57m
kube-system   bm-system-kubernetes                                                    Healthy   57m
kube-system   bm-system-network                                                       Healthy   32m
kube-system   component-status-controller-manager                                     Healthy   5s
kube-system   component-status-etcd-0                                                 Healthy   5s
kube-system   component-status-etcd-1                                                 Healthy   5s
kube-system   component-status-scheduler                                              Healthy   5s

Cronjobs für Systemdiagnose

Bei regelmäßigen Systemdiagnosen hat jede benutzerdefinierte Bare-Metal-Ressource HealthCheck eine entsprechende CronJob mit demselben Namen. Diese CronJob ist dafür verantwortlich, die entsprechende Systemdiagnose in festgelegten Intervallen auszuführen. Die CronJob enthält auch einen ansible-runner-Container, der die Systemdiagnose ausführt, indem er eine Secure Shell-Verbindung (SSH) zu den Knoten herstellt.

So rufen Sie Informationen zu Cronjobs ab:

So rufen Sie eine Liste der Cronjobs ab, die für einen bestimmten Cluster ausgeführt wurden:
```
kubectl get cronjobs \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE
```
Ersetzen Sie Folgendes:
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
- CLUSTER_NAMESPACE: den Namespace des Clusters.
Das folgende Beispiel zeigt eine typische Antwort:
```
NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d
```
Die Werte in der Spalte SCHEDULE geben den Zeitplan für die Ausführung der einzelnen Health Check-Jobs in Zeitplansyntax an. Der Job bm-system-kubernetes wird beispielsweise täglich um 17 Minuten nach der vollen Stunde (17) ausgeführt, und zwar jede Stunde (*/1) eines jeden Tages (* * *). Die Zeitintervalle für regelmäßige Systemdiagnosen können nicht bearbeitet werden. Es ist jedoch hilfreich für die Fehlerbehebung zu wissen, wann sie ausgeführt werden sollen.

So rufen Sie Details zu einer bestimmten benutzerdefinierten CronJob-Ressource ab:

kubectl describe cronjob CRONJOB_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

Ersetzen Sie Folgendes:

ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
CLUSTER_NAMESPACE: den Namespace des Clusters.

Das folgende Beispiel zeigt eine erfolgreiche CronJob:

Name:                          bm-system-network
Namespace:                     cluster-test-admin
Labels:                        AnthosBareMetalVersion=1.16.1
                               baremetal.cluster.gke.io/check-name=bm-system-network
                               baremetal.cluster.gke.io/periodic-health-check=true
                               controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                               type=network
Annotations:                   target: node-network
Schedule:                      41 */1 * * *
Concurrency Policy:            Forbid
Suspend:                       False
Successful Job History Limit:  1
Failed Job History Limit:      1
Starting Deadline Seconds:     <unset>
Selector:                      <unset>
Parallelism:                   <unset>
Completions:                   1
Active Deadline Seconds:       3600s
Pod Template:
  Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
  Annotations:      target: node-network
  Service Account:  ansible-runner
  Containers:
  ansible-runner:
    Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
    Port:       <none>
    Host Port:  <none>
    Command:
      cluster
    Args:
      -execute-command=network-health-check
      -login-user=root
      -controlPlaneLBPort=443
    Environment:  <none>
    Mounts:
      /data/configs from inventory-config-volume (ro)
      /etc/ssh-key from ssh-key-volume (ro)
  Volumes:
  inventory-config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
    Optional:  false
  ssh-key-volume:
    Type:            Secret (a volume populated by a Secret)
    SecretName:      ssh-key
    Optional:        false
Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
Active Jobs:         <none>
Events:
  Type    Reason            Age   From                Message
  ----    ------            ----  ----                -------
  Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
  Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
  Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061

Logs von Systemdiagnosen

Wenn Systemdiagnosen ausgeführt werden, werden Logs generiert. Unabhängig davon, ob Sie Systemdiagnosen mit bmctl ausführen oder sie automatisch im Rahmen regelmäßiger Systemdiagnosen ausgeführt werden, werden Logs an Cloud Logging gesendet. Wenn Sie Systemdiagnosen auf Anfrage ausführen, werden Logdateien in einem zeitgestempelten Ordner im Verzeichnis log/ Ihres Clusterordners auf Ihrer Administratorworkstation erstellt. Wenn Sie beispielsweise den Befehl

bmctl
check kubernetes

für einen Cluster mit dem Namen test-cluster ausführen, finden Sie Logs in einem Verzeichnis wie bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Logs lokal ansehen

Mit kubectl können Sie Logs für regelmäßige Systemdiagnosen aufrufen:

Rufen Sie die Pods ab und suchen Sie nach dem gewünschten Systemdiagnose-Pod:

kubectl get pods \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

Ersetzen Sie Folgendes:

ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
CLUSTER_NAMESPACE: den Namespace des Clusters.

Die folgende Beispielantwort zeigt einige Systemdiagnose-Pods:

NAME                                                              READY   STATUS      RESTARTS   AGE
bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
...
bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m

Pod-Logs abrufen:

kubectl logs POD_NAME  \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

Ersetzen Sie Folgendes:

POD_NAME: der Name des Systemdiagnose-Pods.
ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
CLUSTER_NAMESPACE: den Namespace des Clusters.

Das folgende Beispiel zeigt einen Teil eines Pod-Logs für eine erfolgreiche Systemdiagnose eines Knotencomputers:

...
TASK [Summarize health check] **************************************************
Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
ok: [10.200.0.4] => {
    "results": {
        "check_cgroup_pass": "passed",
        "check_cni_pass": "passed",
        "check_containerd_pass": "passed",
        "check_cpu_pass": "passed",
        "check_default_route": "passed",
        "check_disks_pass": "passed",
        "check_dns_pass": "passed",
        "check_docker_pass": "passed",
        "check_gcr_pass": "passed",
        "check_googleapis_pass": "passed",
        "check_kernel_version_pass": "passed",
        "check_kubelet_pass": "passed",
        "check_memory_pass": "passed",
        "check_pod_cidr_intersect_pass": "passed",
        "check_registry_mirror_reachability_pass": "passed",
        "check_time_sync_pass": "passed",
        "check_ubuntu_1804_kernel_version": "passed",
        "check_ufw_pass": "passed",
        "check_vcpu_pass": "passed"
    }
}
...

Das folgende Beispiel zeigt einen Teil des Logs eines fehlgeschlagenen Systemdiagnose-Pods für einen Knoten. Das Beispiel zeigt, dass die kubelet-Prüfung (check_kubelet_pass) fehlgeschlagen ist. Das bedeutet, dass kubelet auf diesem Knoten nicht ausgeführt wird.

...
TASK [Reach a final verdict] ***************************************************
Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
...

Logs in Cloud Logging ansehen

Logs für Systemdiagnosen werden an Cloud Logging gestreamt und können im Log-Explorer aufgerufen werden. Regelmäßige Systemdiagnosen werden in den Konsolenlogs als Pods klassifiziert.

Rufen Sie in der Google Cloud Console im Menü Logging die Seite Log-Explorer auf.

Zum Log-Explorer

Geben Sie im Feld Abfrage die Folgendes ein:

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

Im Fenster Abfrageergebnisse werden die Logs für Systemdiagnosen von Knotencomputern angezeigt.

Hier finden Sie eine Liste mit Abfragen für regelmäßige Systemdiagnosen:

Standard

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.default-*"

Knotenrechner

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

Netzwerk

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-network.*"

Kubernetes

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-kubernetes.*"

Add-ons

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-add-ons.*"

Regelmäßige Systemdiagnosen

Standardmäßig werden die regelmäßigen Systemdiagnosen stündlich ausgeführt und prüfen die folgenden Clusterkomponenten:

Default
Maschine
Netzwerk
Kubernetes
Add-ons

Sie können den Clusterstatus prüfen, indem Sie sich die benutzerdefinierten Bare Metal-Ressourcen HealthCheck (healthchecks.baremetal.cluster.gke.io) im Administratorcluster ansehen. Die Prüfungen für Netzwerk, Kubernetes und Add-ons sind Prüfungen auf Clusterebene. Daher gibt es für jede Prüfung eine einzelne Ressource. Für jeden Knoten im Zielcluster wird eine Maschinenprüfung ausgeführt. Daher gibt es für jeden Knoten eine Ressource.

Führen Sie den folgenden Befehl aus, um die HealthCheck-Ressourcen für Bare Metal für einen bestimmten Cluster aufzulisten:

kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE

Ersetzen Sie Folgendes:

ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
CLUSTER_NAMESPACE: der Namespace des Zielclusters der Systemdiagnose.

Die folgende Beispielantwort zeigt das Format:

NAMESPACE               NAME                               PASS    AGE
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

Das Feld Pass für healthchecks.baremetal.cluster.gke.io gibt an, ob die letzte Systemdiagnose bestanden (true) oder fehlgeschlagen (false) ist.

Weitere Informationen zum Prüfen des Status für regelmäßige Systemdiagnosen finden Sie unter Benutzerdefinierte HealthCheck-Ressourcen und Systemdiagnoseprotokolle.

Regelmäßige Systemdiagnosen deaktivieren

Regelmäßige Systemdiagnosen sind standardmäßig für alle Cluster aktiviert. Sie können regelmäßige Systemdiagnosen für einen Cluster deaktivieren, indem Sie das Feld periodicHealthCheck.enable in der Clusterressource auf false setzen.

So deaktivieren Sie regelmäßige Systemdiagnosen:

Bearbeiten Sie die Clusterkonfigurationsdatei und fügen Sie dem Clusterspec das Feld periodicHealthCheck.enable hinzu. Legen Sie den Wert auf false fest:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: false
  ...

Aktualisieren Sie den Cluster mit dem folgenden Befehl:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die regelmäßigen Systemdiagnosen deaktiviert wurden und die entsprechenden healthchecks.baremetal.cluster.gke.io-Ressourcen gelöscht wurden:
```
kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Ersetzen Sie Folgendes:
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
- CLUSTER_NAMESPACE: der Namespace des Zielclusters der Systemdiagnose.

Regelmäßige Systemdiagnosen wieder aktivieren

Regelmäßige Systemdiagnosen sind standardmäßig für alle Cluster aktiviert. Wenn Sie regelmäßige Systemdiagnosen deaktiviert haben, können Sie sie wieder aktivieren, indem Sie das Feld periodicHealthCheck.enable in der Clusterressource auf true setzen.

So aktivieren Sie regelmäßige Systemdiagnosen wieder:

Bearbeiten Sie die Clusterkonfigurationsdatei und fügen Sie dem Clusterspec das Feld periodicHealthCheck.enable hinzu. Legen Sie den Wert auf true fest:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: true
  ...

Aktualisieren Sie den Cluster mit dem folgenden Befehl:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
Führen Sie den folgenden Befehl aus, um zu prüfen, ob regelmäßige Systemdiagnosen aktiviert sind, und zu bestätigen, dass die entsprechenden healthchecks.baremetal.cluster.gke.io-Ressourcen vorhanden sind:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Ersetzen Sie Folgendes:
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
- CLUSTER_NAMESPACE: der Namespace des Zielclusters der Systemdiagnose.
Es kann einige Minuten dauern, bis die Ressourcen angezeigt werden.

On-Demand-Systemdiagnosen

In den folgenden Abschnitten werden die Systemdiagnosen beschrieben, die Sie bei Bedarf mit bmctl check ausführen können. Wenn Sie bmctl check verwenden, um Systemdiagnosen auszuführen, gelten die folgenden Regeln:

Wenn Sie einen Nutzercluster mit einem bmctl check-Befehl prüfen, geben Sie den Pfad der kubeconfig-Datei für den Administratorcluster mit dem Flag --kubeconfig an.
Logs werden in einem Verzeichnis mit Zeitstempel im Cluster-Logordner auf Ihrer Administrator-Workstation generiert (standardmäßig bmctl-workspace/CLUSTER_NAME/log).
Logs für Systemdiagnosen werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Weitere Informationen zu anderen Optionen für bmctl-Befehle finden Sie in der bmctl-Befehlsreferenz.

Add-ons

Prüfen Sie, ob die angegebenen Kubernetes-Add-ons für den angegebenen Cluster betriebsbereit sind.

So prüfen Sie Add-ons für einen Cluster:
```
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie prüfen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Eine Liste der Prüfungen finden Sie in diesem Dokument im Abschnitt „Was wird geprüft?“ unter Add-ons.

Bei dieser Prüfung werden Logdateien in einem check-addons-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Cluster

Prüfen Sie alle Clusterknoten, das Knotennetzwerk, Kubernetes und Add-ons für den angegebenen Cluster. Sie geben den Clusternamen an und bmctl sucht standardmäßig unter bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml nach der Clusterkonfigurationsdatei.

So prüfen Sie den Status eines Clusters:
```
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie prüfen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Eine Liste der Prüfungen finden Sie in den folgenden Abschnitten im Abschnitt „Was wird geprüft“ in diesem Dokument:

Prüfungen auf Knotenrechner-Ebene
Standardprüfungen
Netzwerkprüfungen
Kubernetes
Add-ons

Bei dieser Prüfung werden Logdateien in einem check-cluster-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Konfiguration

Prüfen Sie die Cluster-Konfigurationsdatei. Bei dieser Prüfung wird davon ausgegangen, dass Sie die Konfigurationsdatei generiert und bearbeitet haben, um die Details der Clusterkonfiguration für Ihren Cluster anzugeben. Mit diesem Befehl wird geprüft, ob eine Konfigurationseinstellung falsch ist, fehlt oder Syntaxfehler enthält. Sie geben den Clusternamen an und bmctl sucht standardmäßig unter bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml nach der Clusterkonfigurationsdatei.

So prüfen Sie eine Clusterkonfigurationsdatei:
```
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie prüfen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Mit diesem Befehl wird die YAML-Syntax der ClusterkonfigurationsdateiGoogle Cloud sowie der Zugriff und die Berechtigungen für das in der Clusterkonfigurationsdatei angegebene Dienstkonto geprüft.

Bei dieser Prüfung werden Logdateien in einem check-config-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Verbindung zu Google Cloud

Prüfen Sie, ob alle Clusterknotenmaschinen auf Artifact Registry (gcr.io) und den Google APIs-Endpunkt (googleapis.com) zugreifen können.

So prüfen Sie den Clusterzugriff auf erforderliche Google Cloud Ressourcen:
```
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie prüfen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

Bei dieser Prüfung werden Logdateien in einem check-gcp-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Kubernetes

Prüfen Sie den Status wichtiger Kubernetes-Operatoren, die auf der Steuerungsebene ausgeführt werden. Bei dieser Prüfung wird sichergestellt, dass kritische Operatoren ordnungsgemäß funktionieren und ihre Pods nicht abstürzen. Bei dieser Systemdiagnose wird kein Fehler zurückgegeben, wenn eine der Komponenten der Steuerungsebene fehlt. Fehler werden nur zurückgegeben, wenn die Komponenten vorhanden sind und bei der Ausführung des Befehls Fehler auftreten.

So prüfen Sie den Status von Kubernetes-Komponenten in Ihrem Cluster:
```
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, der die Knoten enthält, die Sie prüfen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.

Eine Liste der Prüfungen finden Sie im Abschnitt „Was wird geprüft?“ dieses Dokuments unter Kubernetes.

Bei dieser Prüfung werden Logdateien im Verzeichnis check-kubernetes-TIMESTAMP im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

Knoten

Prüfen Sie die Clusterknotenmaschinen, um sicherzustellen, dass sie richtig konfiguriert sind und dass sie genügend Ressourcen und Konnektivität für Clusterupgrades und den Clusterbetrieb haben.

So prüfen Sie den Zustand der Knotenmaschinen in Ihrem Cluster:
```
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, der die Knoten enthält, die Sie prüfen.
- NODE_IP_ADDRESSES: eine durch Kommas getrennte Liste von IP-Adressen für Knotenmaschinen.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.

Eine Liste der Prüfungen finden Sie im Abschnitt „Was wird geprüft?“ unter Knotenmaschinenprüfungen in diesem Dokument.

Bei dieser Prüfung werden Logdateien für jede Clusternodenmaschine in einem check-nodes-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Systemdiagnoseprotokolle.

Preflight

Informationen zum Ausführen von Preflight-Prüfungen mit bmctl finden Sie unter On-Demand-Preflight-Prüfungen für die Clustererstellung ausführen und On-Demand-Preflight-Prüfungen für Clusterupgrades ausführen.

Preflight-Prüfung für die VM-Laufzeit

Bei der Preflight-Prüfung der VM Runtime on GDC werden eine Reihe von Voraussetzungen für Knotencomputer geprüft, bevor die VM Runtime on GDC und VMs verwendet werden. Wenn die Preflight-Prüfung der VM Runtime on GDC fehlschlägt, wird die VM-Erstellung blockiert. Wenn spec.enabled in der benutzerdefinierten Ressource VMRuntime auf true festgelegt ist, wird die Preflight-Prüfung der VM Runtime on GDC automatisch ausgeführt.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

Weitere Informationen finden Sie unter Preflight-Prüfung für VM Runtime on GDC.

Aktuelle Systemdiagnosen ausführen

Systemdiagnosen (und Preflight-Prüfungen) werden aktualisiert, sobald bekannte Probleme erkannt werden. Wenn Sie bmctl anweisen möchten, die Prüfungen anhand des neuesten Patch-Images Ihrer installierten Nebenversion auszuführen, verwenden Sie das Optionsflag --check-image-version latest:

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie prüfen.

So können Sie kürzlich erkannte bekannte Probleme erkennen, ohne Ihren Cluster zuerst zu aktualisieren.

Sie können auch die neuesten Preflight-Prüfungen durchführen, bevor Sie einen Cluster installieren oder upgraden. Weitere Informationen finden Sie unter Aktuelle Vorabprüfungen ausführen.

Erkennung von Konfigurationsabweichungen

Wenn die Systemdiagnose für Add-ons ausgeführt wird, wird unter anderem nach unerwarteten Änderungen an Ressourcen gesucht, die von Google Distributed Cloud verwaltet werden. Bei der Prüfung werden die Manifeste dieser Ressourcen untersucht, um festzustellen, ob Änderungen von externen Stellen vorgenommen wurden. Diese Prüfungen können helfen, vor unbeabsichtigten Änderungen zu warnen, die sich negativ auf den Clusterzustand auswirken könnten. Außerdem enthalten sie wertvolle Informationen zur Fehlerbehebung.

Welche Manifeste werden geprüft?

Mit einigen Ausnahmen werden bei der Systemdiagnose für Add-ons alle von Google Distributed Cloud verwalteten Ressourcen für Ihre Cluster überprüft. Diese Ressourcen werden von der Google Distributed Cloud-Software installiert und verwaltet. Es gibt Hunderte dieser Ressourcen und die meisten ihrer Manifeste werden auf Konfigurationsabweichungen geprüft. Die Manifeste sind für alle Arten von Ressourcen, einschließlich, aber nicht beschränkt auf die folgenden:

ClusterRoles
ClusterRoleBindings
CustomResourceDefinitions
DaemonSets
Bereitstellungen
HorizontalPodAutoscalers
Aussteller

MetricsServers
MutatingWebhookConfigurations
Namespaces
Netzwerke
NetworkLoggings
PodDisruptionBudgets
Anbieter

Rollen
RoleBindings
Dienste
StorageClasses
ValidatingWebhookConfigurations

Welche Manifeste werden nicht geprüft?

Einige Manifeste werden von uns nicht überprüft. Aus Datenschutz- und Sicherheitsgründen werden bestimmte Arten von Ressourcen wie Zertifikate, Secrets und Dienstkonten ignoriert. Bei der Add-on-Prüfung werden auch einige Ressourcen und Ressourcenfelder ignoriert, da wir davon ausgehen, dass sie geändert werden, und wir nicht möchten, dass die Änderungen Konfigurationsabweichungsfehler auslösen. So werden beispielsweise replicas-Felder in Deployments ignoriert, da der Autoscaler diesen Wert ändern kann.

Zusätzliche Manifeste oder Teile von Manifesten von der Überprüfung ausschließen

Im Allgemeinen empfehlen wir, keine Änderungen an von Google Distributed Cloud verwalteten Ressourcen vorzunehmen oder Änderungen an diesen Ressourcen zu ignorieren. Wir wissen jedoch, dass Ressourcen manchmal geändert werden müssen, um auf besondere Anforderungen einzugehen oder Probleme zu beheben. Aus diesem Grund stellen wir für jeden Cluster in Ihrer Flotte eine ignore-config-drift-ConfigMap bereit. Mit diesen ConfigMaps geben Sie Ressourcen und bestimmte Ressourcenfelder an, die von der Bewertung ausgeschlossen werden sollen.

Google Distributed Cloud erstellt für jeden Cluster eine ignore-config-drift-ConfigMap. Diese ConfigMaps befinden sich im Verwaltungscluster (Administrator- oder Hybridcluster) im entsprechenden Cluster-Namespace. Wenn Sie beispielsweise einen Administratorcluster (admin-one) haben, der zwei Nutzercluster (user-one und user-two) verwaltet, finden Sie die ignore-config-drift-ConfigMap für den Cluster user-one im Cluster admin-one im Namespace cluster-user-one.

So schließen Sie eine Ressource oder Ressourcenfelder von der Überprüfung aus:

Fügen Sie der ConfigMap ignore-config-drift das Feld data.ignore-resources hinzu.

Dieses Feld akzeptiert ein Array von JSON-Strings, wobei jeder String eine Ressource und optional bestimmte Felder in der Ressource angibt.
Geben Sie die Ressource und optional die zu ignorierenden Felder als JSON-Objekt im String-Array an:

Das JSON-Objekt für eine Ressource und Felder hat die folgende Struktur:
```
{
  "Version": "RESOURCE_VERSION",
  "Kind": "RESOURCE_KIND",
  "Namespace": "RESOURCE_NAMESPACE",
  "Name": "RESOURCE_NAME",
  "Fields": [
    "FIELD_1_NAME",
    "FIELD_2_NAME",
    ...
    "FIELD_N_NAME"
  ]
}
```
Ersetzen Sie Folgendes:
- RESOURCE_VERSION: (optional) Der apiVersion-Wert für die Ressource.
- RESOURCE_KIND: (optional) Der kind-Wert für die Ressource.
- RESOURCE_NAMESPACE: (optional) der metadata.namespace-Wert für die Ressource.
- RESOURCE_NAME: (optional) Der metadata.name-Wert für die Ressource.
- FIELD_NAME: (optional) Geben Sie ein Array von Ressourcenfeldern an, die ignoriert werden sollen. Wenn Sie keine Felder angeben, werden alle Änderungen an der Ressource ignoriert.
Jedes der Felder im JSON-Objekt ist optional, sodass eine Vielzahl von Permutationen zulässig ist. Sie können ganze Kategorien von Ressourcen ausschließen oder sehr genau sein und bestimmte Felder einer bestimmten Ressource ausschließen.

Wenn beispielsweise bei der Add-on-Prüfung alle Änderungen am Abschnitt command der ais-Bereitstellung in Ihrem Administratorcluster ignoriert werden sollen, könnte das JSON so aussehen:
```
{
  "Version": "apps/v1",
  "Kind": "Deployment",
  "Namespace": "anthos-identity-service",
  "Name": "ais",
  "Fields": [
    "command"
  ]
}
```
Sie fügen dieses JSON-Objekt ignore-resources in der ConfigMap config-drift-ignore als Stringwert in einem Array hinzu, wie im folgenden Beispiel gezeigt:
```
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2024-09-24T00:39:45Z"
  name: config-drift-ignore
  namespace: cluster-example-admin
  ownerReferences:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    name: example-admin
  ...
data:
  ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
  ...
```
Mit dieser Beispiel-ConfigMap-Einstellung können Sie command-Felder im ais-Deployment hinzufügen, entfernen oder bearbeiten, ohne dass Konfigurationsabweichungen auftreten. Änderungen an Feldern außerhalb des command-Abschnitts im Deployment werden jedoch weiterhin von der Add-on-Prüfung erkannt und als Konfigurationsabweichung gemeldet.

Wenn Sie alle Deployments ausschließen möchten, sieht der Wert ignore-resources möglicherweise so aus:
```
...
data:
  ignore-resources: '[{"Kind":"Deployment"}]'
...
```
Da ignore-resources ein Array von JSON-Strings akzeptiert, können Sie mehrere Ausschlussmuster angeben. Wenn Sie Probleme beheben oder mit Ihren Clustern experimentieren und keine Konfigurationsabweichungsfehler auslösen möchten, kann es hilfreich sein, sowohl sehr gezielte Ressourcen als auch Ressourcenfelder oder breitere Kategorien von Ressourcen aus der Abweichungserkennung auszuschließen.

Nächste Schritte

Hier finden Sie weitere Informationen:

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:

Anforderungen für das Eröffnen eines Supportfalls.
Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
Unterstützte Komponenten.

Systemdiagnosen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Was wird geprüft?

Prüfungen von Knotenrechnern

Clusterweite Prüfungen

Standardprüfungen

Netzwerkprüfungen

Kubernetes

Add-ons

Benutzerdefinierte HealthCheck-Ressourcen

Cronjobs für Systemdiagnose

Logs von Systemdiagnosen

Logs lokal ansehen

Logs in Cloud Logging ansehen

Regelmäßige Systemdiagnosen

Regelmäßige Systemdiagnosen deaktivieren

Regelmäßige Systemdiagnosen wieder aktivieren

On-Demand-Systemdiagnosen

Add-ons

Cluster

Konfiguration

Verbindung zu Google Cloud

Kubernetes

Knoten

Preflight

Preflight-Prüfung für die VM-Laufzeit

Aktuelle Systemdiagnosen ausführen

Erkennung von Konfigurationsabweichungen

Welche Manifeste werden geprüft?

Welche Manifeste werden nicht geprüft?

Zusätzliche Manifeste oder Teile von Manifesten von der Überprüfung ausschließen

Nächste Schritte

Systemdiagnosen

Benutzerdefinierte `HealthCheck`-Ressourcen