Systemdiagnosen

Version 1.28 (latest)

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

Systemdiagnosen sind eine Möglichkeit, den Betrieb Ihrer vorhandenen Cluster zu testen und zu überwachen. Systemdiagnosen werden regelmäßig von selbst durchgeführt. Sie können auch bmctl verwenden, um bei Bedarf Systemdiagnosen auszuführen. In diesem Dokument wird beschrieben, in welchen Fällen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt werden muss und wie die Ergebnisse interpretiert werden können.

Was wird überprüft?

Es gibt zwei Kategorien von GDCV für Bare-Metal-Systemdiagnosen:

• Knotenmaschinenprüfungen

• Clusterweite Prüfungen

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

Knotenmaschinenprüfungen

In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für Knotenmaschinen ausgewertet wird. Mit diesen Prüfungen wird geprüft, ob Knotenmaschinen ordnungsgemäß konfiguriert sind und genügend Ressourcen und Konnektivität für die Clustererstellung, Clusterupgrades und den Clusterbetrieb vorhanden sind.

Diese Prüfungen entsprechen den benutzerdefinierten HealthCheck-Bare-Metal-Ressourcen namens 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 der Systemdiagnose finden Sie unter Benutzerdefinierte HealthCheck-Ressourcen.

Hinweis: Die gängigen Maschinen- und Google Cloud-Prüfungen werden auch bei Preflight-Prüfungen verwendet.

Gängige Maschinenprüfungen sehen so aus:

• Clustermaschinen verwenden ein unterstütztes Betriebssystem.

• Betriebssystemversion wird unterstützt.

• Das Betriebssystem verwendet eine unterstützte Kernel-Version.

• Im Kernel ist die Compiler-Option BPF Just In Time (JIT) aktiviert (CONFIG_BPF_JIT=y).

• Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.

• Knotenmaschinen erfüllen die CPU-Mindestanforderungen.

• Auf Knotenmaschinen sind mehr als 20% der CPU-Ressourcen verfügbar.

• Knotenmaschinen erfüllen die Mindestarbeitsspeicheranforderungen.

• Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

• Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.

• Die Standardroute für das Routing von Paketen an das Standardgateway ist in Knoten vorhanden.

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

Google Cloud-Prüfungen auf Maschinen umfassen Folgendes:

• Container Registry gcr.io ist erreichbar (diese Prüfung wird übersprungen, wenn der Cluster für die Verwendung eines Registry-Spiegels konfiguriert ist).

• Google APIs sind erreichbar.

Die Maschinen-Systemdiagnosen bestehen aus folgenden Elementen:

• kubelet ist aktiv und wird auf Knotenmaschinen ausgeführt.

• containerd ist aktiv und wird auf Knotenmaschinen ausgeführt.

• CNI-Systemstatus (Container Network Interface) ist fehlerfrei.

• Pod-CIDRs überschneiden sich nicht mit IP-Adressen von Knotenmaschinen.

Weitere Informationen zu den Anforderungen an Knotenmaschinen finden Sie unter Voraussetzungen für Clusterknotenmaschinen.

Clusterweite Prüfungen

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

Netzwerkprüfungen

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

• Wenn der Cluster gebündeltes Load-Balancing verwendet, müssen Knoten im Load-Balancing-Knotenpool eine ARP-Verbindung (Layer 2 Address Resolution Protocol) haben. Für die VIP-Erkennung ist ARP erforderlich.

• Auf den Knoten der Steuerungsebene sind die Ports 8443 und 8444 für die Verwendung durch GKE Identity Service geöffnet.

• Bei Knoten der Steuerungsebene sind die Ports 2382 und 2383 für die Verwendung durch die Instanz etcd-events geöffnet.

Informationen zu Protokollen und zur Portnutzung für Ihre GKE on Bare Metal-Cluster finden Sie unter Netzwerkanforderungen.

Die Netzwerkprüfungen für eine Preflight-Prüfung unterscheiden sich von denen des Netzwerks. 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 im Rahmen von Preflight- und regelmäßigen Systemdiagnosen automatisch ausgeführt werden, können auch on demand ausgeführt werden. Diese Systemdiagnosen 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 zum Zeitpunkt der Befehlsausführung Fehler aufweisen.

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

• API-Server funktioniert.

• Der Operator anetd ist richtig konfiguriert.

• Alle Knoten der Steuerungsebene sind benutzerfreundlich.

• 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 im Rahmen von Preflight-Prüfungen und regelmäßigen Systemdiagnosen automatisch ausgeführt und können on demand ausgeführt werden. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eines der aufgelisteten Add-ons fehlt. Die Prüfung gibt nur dann Fehler zurück, wenn die Add-ons vorhanden sind und zum Zeitpunkt der Befehlsausführung Fehler haben.

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

• Die Stackdriver-Komponenten von Cloud Logging und Connect Agent können verwendet werden:

  • stackdriver-log-aggregator

  • stackdriver-log-forwarder

  • stackdriver-metadata-agent

  • stackdriver-prometheus-k8

  • gke-connect-agent

• GDCV für Bare-Metal-verwaltete Ressourcen zeigt keine manuellen Änderungen (Konfigurationsabweichung):

  • Feldwerte wurden nicht aktualisiert

  • Optionale Felder wurden nicht hinzugefügt oder entfernt

  • Ressourcen wurden nicht gelöscht

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

• Version: die API-Version für die Ressource.
• Kind: das Objektschema wie 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.

HealthCheck benutzerdefinierte Ressourcen

Beim Ausführen einer Systemdiagnose erstellt GDCV für Bare Metal eine benutzerdefinierte HealthCheck-Ressource. Benutzerdefinierte HealthCheck-Ressourcen sind persistent und bieten einen strukturierten Datensatz der Aktivitäten und Ergebnisse der Systemdiagnose. Es gibt zwei Kategorien von benutzerdefinierten HeathCheck-Ressourcen:

• Benutzerdefinierte HealthCheck-Bare-Metal-Ressourcen (API Version: baremetal.cluster.gke.io/v1): Diese Ressourcen enthalten Details zu regelmäßigen Systemdiagnosen. Diese Ressourcen befinden sich im Administratorcluster in Cluster-Namespaces. HealthCheck-Bare-Metal-Ressourcen sind für das Erstellen von Cronjobs und -Jobs für Systemdiagnosen verantwortlich. Diese Ressourcen werden laufend mit den neuesten Ergebnissen aktualisiert.

• Benutzerdefinierte HealthCheck-Anthos-Ressourcen (API Version: anthos.gke.io/v1): Diese Ressourcen werden verwendet, um Messwerte für Systemdiagnosen zu melden. Diese Ressourcen befinden sich im Namespace kube-system jedes Clusters. Updates dieser Ressourcen werden nach bestem Wissen und Gewissen durchgeführt. Wenn bei einer Aktualisierung ein Problem nicht auftritt, z. B. ein vorübergehender Netzwerkfehler, wird der Fehler ignoriert.

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

Systemdiagnosen für Bare-Metal-Produkte	GKE Enterprise-Systemdiagnosen	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

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.

   Im folgenden Beispiel sehen Sie, welche Systemdiagnosen 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
   

   Hinweis: Alle Ressourcen der regelmäßigen Systemdiagnose haben das Label baremetal.cluster.gke.io/periodic-health-check=true.

2. Verwenden Sie kubectl describe, um Details zu einer bestimmten Systemdiagnose zu lesen:

   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 überprü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 wie das Datum, an dem 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 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
     ...
   

3. Verwenden Sie den folgenden Befehl, um eine Liste der Systemdiagnosen für Messwerte abzurufen:

   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
   

Systemdiagnose-Cronjobs

Bei regelmäßigen Systemdiagnosen hat jede benutzerdefinierte Bar-Metal-Ressource HealthCheck eine entsprechende CronJob mit demselben Namen. Mit diesem CronJob wird die Ausführung der entsprechenden Systemdiagnose in festgelegten Intervallen geplant.

So rufen Sie Informationen zu Cronjobs ab:

1. 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 einzelnen Systemdiagnosejobs in der Zeitplansyntax an. Der Job bm-system-kubernetes wird beispielsweise 17 Minuten nach der vollen Stunde (17) pro Stunde (*/1) eines jeden Tages (* * *) ausgeführt. Die Zeitintervalle für regelmäßige Systemdiagnosen können nicht bearbeitet werden. Sie sind aber nützlich, um herauszufinden, wann sie ausgeführt werden sollen.

2. Rufen Sie Details für eine bestimmte benutzerdefinierte 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
   

Systemdiagnose-Logs

Bei der Ausführung von Systemdiagnosen generieren sie Logs. Unabhängig davon, ob Sie Systemdiagnosen mit bmctl oder automatisch im Rahmen regelmäßiger Systemdiagnosen ausführen, werden Logs an Cloud Logging gesendet. Wenn Sie Systemdiagnosen bei Bedarf ausführen, werden Logdateien in einem Ordner mit Zeitstempel im Verzeichnis log/ des 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:

1. Rufen Sie Pods ab und suchen Sie nach dem gewünschten Pod für die Systemdiagnose:

   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.

   Das folgende Antwortbeispiel 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. Rufen Sie Pod-Logs ab:

   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 eines Logs zur Systemdiagnose von fehlgeschlagenen Knotenmaschinen. Das Beispiel zeigt, dass die kubelet-Prüfung (check_kubelet_pass) fehlgeschlagen ist, was darauf hinweist, dass die kubelet nicht auf diesem Knoten 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

Systemdiagnose-Logs werden an Cloud Logging gestreamt und können im Log-Explorer angesehen 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 Knotenmaschinen angezeigt.

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

• Knotenmaschine

  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

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

• Maschine
• Netzwerk
• Kubernetes
• Add-ons

Sie können den Clusterzustand prüfen, indem Sie sich die benutzerdefinierten Bare-Metal-Ressourcen HealthCheck (healthchecks.baremetal.cluster.gke.io) im Administratorcluster ansehen. Die Netzwerk-, Kubernetes- und Add-on-Prüfungen 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, sodass für jeden Knoten eine Ressource vorhanden ist.

• 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 Antwortbeispiel 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 erfolgreich war (true) oder fehlgeschlagen ist (false).

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

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. Setzen Sie dazu das Feld periodicHealthCheck.enable in der Clusterressource auf false.

So deaktivieren Sie regelmäßige Systemdiagnosen:

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

2. Aktualisieren Sie den Cluster mit dem Befehl bmctl update:

   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

3. Wenn Sie prüfen möchten, ob regelmäßige Systemdiagnosen deaktiviert wurden, führen Sie den folgenden Befehl aus, um zu bestätigen, dass 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. Setzen Sie dazu das Feld periodicHealthCheck.enable in der Clusterressource auf true.

So aktivieren Sie regelmäßige Systemdiagnosen wieder:

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

2. Aktualisieren Sie den Cluster mit dem Befehl bmctl update:

   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

3. Wenn Sie prüfen möchten, ob regelmäßige Systemdiagnosen aktiviert sind, führen Sie den folgenden Befehl aus, um 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 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 Clusterlogordner auf Ihrer Administratorworkstation generiert (standardmäßig bmctl-workspace/CLUSTER_NAME/log).

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

Weitere Informationen zu Optionen für bmctl-Befehle finden Sie in der Referenz zu bmctl-Befehlen.

Add-ons

Prüfen Sie, ob die angegebenen Kubernetes-Add-ons für den angegebenen Cluster ausgeführt werden können.

• 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 dessen, was überprüft wird, finden Sie in diesem Dokument im Abschnitt „Wird geprüft“ unter Add-ons.

Diese Prüfung generiert Logdateien in einem Verzeichnis check-addons-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Cluster

Prüfen Sie alle Clusterknoten, Knotennetzwerke, 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 dessen, was überprüft wird, finden Sie in den folgenden Abschnitten im Abschnitt „Wird geprüft“ dieses Dokuments:

• Knotenprüfungen auf Maschinenebene
• Netzwerkprüfungen
• Kubernetes
• Add-ons

Diese Prüfung generiert Logdateien in einem Verzeichnis check-cluster-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Konfiguration

Prüfen Sie die Clusterkonfigurationsdatei. Bei dieser Prüfung wird davon ausgegangen, dass Sie die Konfigurationsdatei generiert und bearbeitet haben, um die Clusterkonfigurationsdetails 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

Dieser Befehl prüft die YAML-Syntax der Clusterkonfigurationsdatei, den Google Cloud-Zugriff und die Berechtigungen für das Dienstkonto, das in der Clusterkonfigurationsdatei angegeben ist.

Diese Prüfung generiert Logdateien in einem Verzeichnis check-config-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Google Cloud

Prüfen Sie, ob alle Maschinen mit Clusterknoten auf Container 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

Diese Prüfung generiert Logdateien in einem Verzeichnis check-gcp-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Kubernetes

Prüfen Sie den Status kritischer Kubernetes-Operatoren, die auf der Steuerungsebene ausgeführt werden. Mit dieser Prüfung wird sichergestellt, dass kritische Operatoren ordnungsgemäß funktionieren und ihre Pods nicht abstürzen. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eine der Komponenten der Steuerungsebene fehlt. Sie gibt nur dann Fehler zurück, wenn die Komponenten vorhanden sind und bei der Befehlsausführung Fehler haben.

• 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: der Pfad der kubeconfig-Datei des Administratorclusters.

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

Mit dieser Prüfung werden Logdateien im Verzeichnis check-kubernetes-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Knoten

Prüfen Sie, ob die Maschinen von Clusterknoten ordnungsgemäß konfiguriert sind und über ausreichende Ressourcen und 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 Knotenmaschinen.
  • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.

Eine Liste dessen, was geprüft wird, finden Sie in diesem Dokument im Abschnitt „Was überprüft“ unter Knotenmaschinenprüfungen.

Mit dieser Prüfung werden Logdateien für jede Maschine mit Clusterknoten im Verzeichnis check-nodes-TIMESTAMP des Clusterlogordners auf Ihrer Administratorworkstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Systemdiagnose-Logs.

Preflight

Informationen zur Verwendung von bmctl zum Ausführen von Preflight-Prüfungen 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

Die Preflight-Prüfung der VM-Laufzeit in Google Distributed Cloud validiert eine Reihe von Voraussetzungen für Knotenmaschinen, bevor die VM-Laufzeit in Google Distributed Cloud und VMs verwendet wird. Wenn die Preflight-Prüfung der VM-Laufzeit in Google Distributed Cloud fehlschlägt, wird die VM-Erstellung blockiert. Wenn spec.enabled in der benutzerdefinierten Ressource VMRuntime auf true gesetzt ist, wird die Preflight-Prüfung der VM-Laufzeit in Google Distributed Cloud 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 zur VM-Laufzeit in Google Distributed Cloud.

Nächste Schritte

• Knotenproblemerkennung

• Clusterkonnektivität mit nettest prüfen

• Snapshots zur Diagnose von Clusterproblemen erstellen