Cluster-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 gkectl diagnose cluster 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.

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.

Weitere Informationen zu den Knotenanforderungen finden Sie unter CPU-, RAM- und Speicheranforderungen.

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 HealthCheckBenutzerdefinierte Ressourcen.

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 Proxy- und Firewallregeln.

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
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:

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

   Hinweis: Alle Ressourcen für regelmäßige Systemdiagnosen haben das Label baremetal.cluster.gke.io/periodic-health-check=true.

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

3. 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:

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

2. 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 gkectl diagnose cluster ausführen oder ob 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 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log erstellt.

Logs lokal ansehen

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

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

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

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

   Zum Log-Explorer

2. Geben Sie im Feld Abfrage die Folgendes ein:

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

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

Hinweis :In Google Distributed Cloud for VMware kann die regelmäßige Statusprüfung nicht deaktiviert werden.

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

On-Demand-Systemdiagnosen

Verwenden Sie den Befehl gkectl diagnose cluster, um Systemdiagnosen auf Anfrage auszuführen. Wenn Sie gkectl diagnose cluster verwenden, um Systemdiagnosen auszuführen, gelten die folgenden Regeln:

• Wenn Sie einen Nutzercluster mit dem Befehl gkectl diagnose cluster 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 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log).

• Logs für Systemdiagnosen werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnoselogs.

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:

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

2. 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:

• Diagnosesnapshots erstellen, wenn der erweiterte Cluster aktiviert ist

• Auswirkungen von Ausfällen in Google Distributed Cloud verstehen

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. Logs und Messwerte.
• Unterstützte Komponenten, Versionen und Funktionen von Google Distributed Cloud für VMware (nur Software).