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

Diese Seite wurde von der Cloud Translation API übersetzt.

Systemdiagnosen

Mit Systemdiagnosen können Sie den Betrieb Ihrer vorhandenen Cluster testen und überwachen. Systemdiagnosen werden regelmäßig automatisch ausgeführt. Mit bmctl können Sie Systemdiagnosen auch auf Anfrage ausfü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 für Knotenrechner
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 für Knotenrechner

In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für Knotenmaschinen geprüft wird. Bei diesen Prüfungen wird bestätigt, dass die Knotenmaschinen richtig konfiguriert sind und über ausreichende Ressourcen und Konnektivität für die Clustererstellung, Clusterupgrades und den Clusterbetrieb verfügen.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-HealthCheck-Ressourcen 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 Ressourcen für Systemdiagnosen finden Sie unter HealthCheckBenutzerdefinierte Ressourcen.

Zu den gängigen Maschinenprüfungen gehören:

Cluster-Maschinen verwenden ein unterstütztes Betriebssystem.
Die Betriebssystemversion wird unterstützt.
Das Betriebssystem verwendet eine unterstützte Kernelversion.
Für den Kernel ist die Option „BPF Just In Time (JIT) Compiler“ (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 Knotencomputer erfüllen die Mindestanforderungen an den Arbeitsspeicher.
Die Knotencomputer erfüllen die Mindestanforderungen an den Speicherplatz.
Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.
Die Standardroute für das Weiterleiten von Paketen an das Standardgateway ist in 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.

Die Google Cloud -Prüfungen umfassen Folgendes:

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

Die Systemdiagnosen für Maschinen umfassen Folgendes:

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

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 geprüft wird.

Netzwerkprüfungen

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

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

Informationen zu Protokollen und Portnutzung für Ihre Cluster finden Sie unter Netzwerkanforderungen.

Die Netzwerkprüfungen für eine Preflight-Prüfung unterscheiden sich von den Netzwerksystemdiagnosen. 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 Gesundheitschecks ausgeführt werden, können auch on demand ausgeführt werden. Diese Prüfungen geben keinen Fehler zurück, wenn eine der aufgeführten Komponenten der Steuerungsebene fehlt. Die Prüfung gibt nur dann Fehler zurück, wenn die Komponenten vorhanden sind und bei der Befehlsausführung Fehler auftreten.

Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-HealthCheck-Ressourcen mit dem Namen bm-system-kubernetes, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Ressourcen für Systemdiagnosen 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 als Teil der Preflight-Prüfungen und der regelmäßigen Systemdiagnosen ausgeführt und können auf Anfrage ausgeführt werden. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eines der aufgeführten Add-ons fehlt. Die Prüfung gibt nur dann Fehler zurück, wenn die Add-ons vorhanden sind und bei der Befehlsausführung Fehler auftreten.

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

Die Cloud Logging-Stackdriver-Komponenten und der Connect-Agent sind funktionsfähig:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
Von Google Distributed Cloud verwaltete Ressourcen weisen keine manuellen Änderungen auf (Konfigurationsabweichung):
- Feldwerte wurden nicht aktualisiert
- Optionale Felder wurden nicht hinzugefügt oder entfernt
- Ressourcen wurden nicht gelöscht

Wenn die Systemdiagnose eine Abweichung der Konfiguration erkennt, wird der Wert der benutzerdefinierten Ressource Status.Pass bm-system-add-ons Bare MetalHealthCheck auf false gesetzt. Das Feld Description im Abschnitt Failures enthält Details zu allen geänderten Ressourcen, darunter die folgenden Informationen:

Version: die API-Version der 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 im Datenbestand vorhandenen 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 Gesundheitschecks. Diese Ressourcen befinden sich im Administratorcluster in Cluster-Namespaces. Bare-Metal-HealthCheck-Ressourcen sind für das Erstellen von Cronjobs und Jobs zur Systemdiagnose verantwortlich. Diese Ressourcen werden regelmäßig mit den neuesten Ergebnissen aktualisiert.
Benutzerdefinierte Anthos-HealthCheck-Ressourcen (API Version: anthos.gke.io/v1): Mit diesen Ressourcen werden Systemdiagnosemesswerte erfasst. Diese Ressourcen befinden sich im Namespace kube-system jedes Clusters. Aktualisierungen dieser Ressourcen erfolgen auf Best-Effort-Basis. Wenn ein Update aufgrund eines Problems fehlschlägt, z. B. aufgrund eines vorübergehenden Netzwerkfehlers, wird der Fehler ignoriert.

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

Bare Metal HealthChecks GKE Enterprise-Überwachung Schweregrad

Bare Metal HealthChecks	GKE Enterprise-Überwachung	Schweregrad
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: 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 der regelmäßigen 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.

Im folgenden Beispiel sind die Systemdiagnosen zu sehen, die regelmäßig ausgeführt werden, und ob sie bei der letzten Ausführung 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.

Der Abschnitt Status: enthält die folgenden wichtigen Felder:

Pass: Gibt an, ob der letzte Job der Systemdiagnose bestanden hat.
Checks: enthält Informationen zum letzten Systemdiagnose-Job.
Failures: Enthält Informationen zum letzten fehlgeschlagenen Job.
Periodic: enthält Informationen wie z. B. wann zuletzt ein Job für die Systemdiagnose geplant und instrumentiert wurde.

Das folgende HealthCheck-Beispiel bezieht sich auf 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 bezieht sich auf 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-10.200.0.3-machine                                            Healthy   56m
kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
kube-system   bm-system-kubernetes                                                    Healthy   57m
kube-system   bm-system-kubernetes-1.16.1-non-periodic                                Healthy   25d
kube-system   bm-system-network                                                       Healthy   32m
kube-system   check-kubernetes-20231114-190445-non-periodic                           Healthy   3h6m
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 die Systemdiagnose

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

So rufen Sie Informationen zu Cronjobs ab:

Liste der Cron-Jobs abrufen, 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 jeden ausgeführten Dienststatus-Check in Zeitplansyntax an. Beispiel: Der Job bm-system-kubernetes wird jeden Tag (* * *) um 17 Minuten nach der vollen Stunde (17) ausgeführt. Die Zeitintervalle für die periodischen Systemdiagnosen können nicht bearbeitet werden. Es ist jedoch hilfreich für die Fehlerbehebung zu wissen, wann sie ausgeführt werden sollen.*/1

So rufen Sie Details zu einer bestimmten CronJob-benutzerdefinierten 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

Protokolle der Systemdiagnose

Bei der Ausführung von Systemdiagnosen werden Protokolle generiert. Unabhängig davon, ob Sie Systemdiagnosen mit bmctl ausführen oder sie automatisch im Rahmen regelmäßiger Systemdiagnosen ausgeführt werden, werden Protokolle an Cloud Logging gesendet. Wenn Sie Systemdiagnosen auf Anfrage ausführen, werden Protokolldateien mit Zeitstempeln im Verzeichnis log/ Ihres Clusterordners auf Ihrer Administratorworkstation erstellt. Wenn Sie beispielsweise den Befehl bmctl check kubernetes für einen Cluster namens test-cluster ausführen, finden Sie die Protokolle 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:

Pods abrufen und den gewünschten Pod für die Systemdiagnose finden:

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 enthält einige Pods für die Systemdiagnose:

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 Pods für die Systemdiagnose.
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 der Knotenmaschine:

...
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 Pod-Logs für die fehlgeschlagene Systemdiagnose eines Knotens. 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 Konsolenprotokollen 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 Protokolle für die Systemdiagnosen der Knotencomputer angezeigt.

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

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 die folgenden Clusterkomponenten geprüft:

Maschine
Netzwerk
Kubernetes
Add-ons

Sie können den Clusterstatus anhand der benutzerdefinierten Bare Metal-Ressourcen HealthCheck (healthchecks.baremetal.cluster.gke.io) im Administratorcluster prüfen. Die Prüfungen für Netzwerk, Kubernetes und Add-ons erfolgen 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. Es gibt also eine Ressource für jeden Knoten.

Führen Sie den folgenden Befehl aus, um Bare Metal-HealthCheck-Ressourcen 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.

Das folgende Beispiel 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 HealthCheck benutzerdefinierte 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, fügen Sie der Clusterspezifikation das Feld periodicHealthCheck.enable hinzu und legen Sie als Wert 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
  ...

Führen Sie den Befehl bmctl update aus, um den Cluster zu aktualisieren:
```
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 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 in der Clusterressource das Feld periodicHealthCheck.enable auf true festlegen.

So aktivieren Sie regelmäßige Systemdiagnosen wieder:

Bearbeiten Sie die Clusterkonfigurationsdatei, fügen Sie der Clusterspezifikation das Feld periodicHealthCheck.enable hinzu und legen Sie als Wert 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
  ...

Führen Sie den Befehl bmctl update aus, um den Cluster zu aktualisieren:
```
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 entsprechenden healthchecks.baremetal.cluster.gke.io-Ressourcen vorhanden sind und die sitzungsübergreifenden Systemdiagnosen aktiviert 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 mit bmctl check auf Anfrage ausführen können. Wenn Sie bmctl check zum Ausführen von Systemdiagnosen verwenden, 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 Clusterprotokollordner auf Ihrer Administrator-Workstation generiert (standardmäßig bmctl-workspace/CLUSTER_NAME/log).
Logs für Systemdiagnosen werden ebenfalls an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle für Systemdiagnosen.

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 die 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 aktivierten Add-ons finden Sie im Abschnitt „Aktivierte Add-ons“ unter Add-ons in diesem Dokument.

Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-addons-TIMESTAMP im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.

Cluster

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

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 geprüften Elemente finden Sie in diesem Dokument im Abschnitt „Was wird geprüft?“ in den folgenden Abschnitten:

Prüfen auf Knotenmaschinenebene
Netzwerkprüfungen
Kubernetes
Add-ons

Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-cluster-TIMESTAMP im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.

Konfiguration

Prüfen Sie die Cluster-Konfigurationsdatei. Für diese 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 können Sie feststellen, 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 Clusterkonfigurationsdatei, derGoogle Cloud -Zugriff und die Berechtigungen für das in der Clusterkonfigurationsdatei angegebene Dienstkonto überprüft.

Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-config-TIMESTAMP im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.

Verbindung zu Google Cloud

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

So prüfen Sie den Clusterzugriff auf die erforderlichen 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 Protokolldateien im Verzeichnis check-gcp-TIMESTAMP im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.

Kubernetes

Prüfen Sie den Status wichtiger Kubernetes-Operatoren, die in der Steuerungsebene ausgeführt werden. Dabei wird geprüft, ob kritische Operatoren ordnungsgemäß funktionieren und ihre Pods nicht abstürzen. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eine der Komponenten der Steuerebene fehlt. Sie gibt nur Fehler zurück, wenn die Komponenten vorhanden sind und bei der Befehlsausführung Fehler auftreten.

So prüfen Sie den Status der 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 zu prüfenden Knoten enthält.
- ADMIN_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.

Eine Liste der geprüften Elemente finden Sie im Abschnitt „Was wird geprüft?“ unter Kubernetes in diesem Dokument.

Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-kubernetes-TIMESTAMP im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.

Knoten

Prüfen Sie die Clusterknotenmaschinen, um sicherzustellen, dass sie ordnungsgemäß konfiguriert sind und über ausreichende Ressourcen und eine ausreichende Konnektivität für Clusterupgrades und den Clusterbetrieb verfügen.

So prüfen Sie den Status 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 zu prüfenden Knoten enthält.
- NODE_IP_ADDRESSES: eine durch Kommas getrennte Liste von IP-Adressen für Knotencomputer.
- ADMIN_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.

Eine Liste der geprüften Elemente finden Sie im Abschnitt „Was wird geprüft?“ unter Kriterien für die Überprüfung von Knotenmaschinen.

Bei dieser Prüfung werden Logdateien für jeden Clusterknotencomputer in einem check-nodes-TIMESTAMP-Verzeichnis im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle zur Systemdiagnose.

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 der 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 der 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 aus dem neuesten Patch-Image 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 zuerst Ihren Cluster zu aktualisieren.

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

Erkennung von Konfigurationsabweichungen

Bei der Systemdiagnose für Add-ons wird unter anderem geprüft, ob unerwartete Änderungen an von Google Distributed Cloud verwalteten Ressourcen vorgenommen wurden. Dabei werden insbesondere die Manifeste für diese Ressourcen geprüft, um festzustellen, ob Änderungen von externen Entitäten vorgenommen wurden. Diese Prüfungen können vor unbeabsichtigten Änderungen warnen, die sich negativ auf die Clustergesundheit auswirken könnten. Außerdem enthalten sie wertvolle Informationen zur Fehlerbehebung.

Welche Manifeste werden geprüft?

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

ClusterRoles
ClusterRoleBindings
CustomResourceDefinitions
DaemonSets
Deployments
HorizontalPodAutoscalers
Aussteller

MetricsServers
MutatingWebhookConfigurations
Namespaces
Netzwerke
NetworkLoggings
PodDisruptionBudgets
Anbieter

Rollen
RoleBindings
Dienste
StorageClasses
ValidatingWebhookConfigurations

Nicht geprüfte Manifeste

Einige Manifeste werden von uns standardmäßig von der Überprüfung ausgeschlossen. Bestimmte Arten von Ressourcen wie Zertifikate, Geheimnisse und Dienstkonten werden aus Datenschutz- und Sicherheitsgründen ignoriert. Bei der Überprüfung von Add-ons werden auch einige Ressourcen und Ressourcenfelder ignoriert, da wir davon ausgehen, dass sie geändert werden, und nicht möchten, dass die Änderungen Konfigurationsabweichungsfehler auslösen. So werden bei der Prüfung beispielsweise replicas-Felder in Bereitstellungen ignoriert, da der Autoscaler diesen Wert möglicherweise ändert.

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

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

In Google Distributed Cloud wird für jeden Cluster eine ignore-config-drift-ConfigMap erstellt. Diese ConfigMaps befinden sich im verwaltenden Cluster (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 user-one-Cluster im admin-one-Cluster 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 nimmt ein Array von JSON-Strings an. Jeder String gibt eine Ressource und optional bestimmte Felder in der Ressource an.
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 bei der Überprüfung durch die Add-ons alle Änderungen an der Ressource ignoriert.
Alle Felder im JSON-Objekt sind optional, sodass eine Vielzahl von Permutationen zulässig ist. Sie können ganze Kategorien von Ressourcen ausschließen oder sehr genau vorgehen und bestimmte Felder einer bestimmten Ressource ausschließen.

Wenn Sie beispielsweise möchten, dass die Add-ons nur Änderungen an dem Abschnitt command der ais-Bereitstellung in Ihrem Administratorcluster ignorieren, könnte die JSON-Datei 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 config-drift-ignore-ConfigMap 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 Konfigurationsabweichungsfehler ausgelöst werden. Änderungen an Feldern außerhalb des Bereichs command in der Bereitstellung werden jedoch weiterhin von der Add-on-Prüfung erkannt und als Konfigurationsabweichung gemeldet.

Wenn Sie alle Bereitstellungen ausschließen möchten, könnte der Wert für ignore-resources so aussehen:
```
...
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 Fehler bei der Konfigurationsabweichung auslösen möchten, kann diese Flexibilität, sowohl sehr gezielte Ressourcen als auch Ressourcenfelder oder breitere Kategorien von Ressourcen von der Abweichungserkennung auszuschließen, nützlich sein.

Systemdiagnosen

Was wird geprüft?

Prüfungen für Knotenrechner

Clusterweite Prüfungen

Netzwerkprüfungen

Kubernetes

Add-ons

Benutzerdefinierte HealthCheck-Ressourcen

Cronjobs für die Systemdiagnose

Protokolle der Systemdiagnose

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 der VM-Laufzeit

Aktuelle Systemdiagnosen ausführen

Erkennung von Konfigurationsabweichungen

Welche Manifeste werden geprüft?

Nicht geprüfte Manifeste

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

Nächste Schritte

Benutzerdefinierte `HealthCheck`-Ressourcen