Systemdiagnosen

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.

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

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

Typ: Maschine

Name: bm-system-NODE_IP_ADDRESS-machine

Typ: Maschine

Name: bm-system-NODE_IP_ADDRESS-machine

Kritisch

Typ: Netzwerk

Name: bm-system-network

Typ: Netzwerk

Name: bm-system-network

Kritisch

Typ: Kubernetes

Name: bm-system-kubernetes

Typ: Kubernetes

Name: bm-system-kubernetes

Kritisch

Typ: Add-ons

Name: bm-system-add-ons

Typ: Add-ons

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

Name: bm-system-add-ons-configdrift

Optional

So rufen Sie den Status von HealthCheck ab:

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

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

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

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

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

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:

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.

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:

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

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.

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

Zum Log-Explorer

Geben Sie im Feld Abfrage die Folgendes ein:

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

Im Fenster Abfrageergebnisse werden die Logs für Systemdiagnosen von 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:

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

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

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

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

Systemdiagnosen

Was wird überprüft?

Knotenmaschinenprüfungen

Clusterweite Prüfungen

Netzwerkprüfungen

Kubernetes

Add-ons

HealthCheck benutzerdefinierte Ressourcen

Systemdiagnose-Cronjobs

Systemdiagnose-Logs

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

Google Cloud

Kubernetes

Knoten

Preflight

Preflight-Prüfung der VM-Laufzeit

Nächste Schritte

`HealthCheck` benutzerdefinierte Ressourcen