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

Diese Seite wurde von der Cloud Translation API übersetzt.

Systemdiagnosen

Mit Systemdiagnosen können Sie den Betrieb Ihrer vorhandenen Cluster testen und überwachen. Systemdiagnosen werden in regelmäßigen Abständen automatisch ausgeführt. Sie können auch bmctl verwenden, um Systemdiagnosen bei Bedarf auszuführen. In diesem Dokument wird jede Prüfung beschrieben. Außerdem wird erläutert, unter welchen Umständen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt wird und wie die Ergebnisse zu interpretieren sind.

Was wird überprüft?

Es gibt zwei Kategorien von Google Distributed Cloud-Systemdiagnosen:

Knotenmaschinenprüfungen
Clusterweite Prüfungen

In den folgenden Abschnitten wird beschrieben, was für jede Kategorie 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. Diese Prüfungen bestätigen, dass Knotenmaschinen ordnungsgemäß konfiguriert sind und über ausreichende Ressourcen und Konnektivität für die Clustererstellung, Clusterupgrades und den Clusterbetrieb verfügen.

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

Gängige Computerprüfungen umfassen Folgendes:

Clustermaschinen verwenden ein unterstütztes Betriebssystem.
Betriebssystemversion wird unterstützt.
Das Betriebssystem verwendet eine unterstützte Kernel-Version.
Im Kernel ist die JIT-Compiler-Option (BPF Just In Time) aktiviert (CONFIG_BPF_JIT=y).
Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.
Knotenmaschinen erfüllen die Mindest-CPU-Anforderungen.
Auf Knotenmaschinen stehen mehr als 20% der CPU-Ressourcen zur Verfügung.
Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.
Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.
Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.
Die Standardroute zum 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 einer Registry-Spiegelung konfiguriert ist, ist dieser erreichbar.

Google Cloud-Prüfungen auf Computern umfassen Folgendes:

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

Systemdiagnosen für Maschinen umfassen Folgendes:

kubelet ist aktiv und wird auf Knotenmaschinen ausgeführt.
containerd ist aktiv und wird auf Knotenmaschinen ausgeführt.
Der Zustandsendpunkt des Container Network Interface (CNI) 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 der Systemdiagnose eines Clusters bewertet wird.

Netzwerkprüfungen

Die folgenden clientseitigen Netzwerkprüfungen von 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 Bare-Metal-HealthCheck-Ressourcen namens bm-system-network, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Ressourcen für Systemdiagnosen finden Sie unter Benutzerdefinierte HealthCheck-Ressourcen.

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

Informationen zu Protokollen und Portnutzung für Ihre Google Distributed Cloud-Cluster finden Sie unter Netzwerkanforderungen.

Die Netzwerkprüfungen für eine Preflight-Prüfung unterscheiden sich von den Netzwerkdiagnosen. Eine Liste der Netzwerkprüfungen für eine Preflight-Prüfung finden Sie unter Preflight-Prüfungen zum Erstellen von Clustern oder Preflight-Prüfungen für Clusterupgrades.

Kubernetes

Kubernetes-Prüfungen, die automatisch im Rahmen von Preflight- und regelmäßigen Systemdiagnosen 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 Bare-Metal-Ressourcen HealthCheck namens bm-system-kubernetes, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Ressourcen für Systemdiagnosen finden Sie unter Benutzerdefinierte HealthCheck-Ressourcen.

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 im Rahmen von Preflight-Prüfungen und regelmäßigen Systemdiagnosen automatisch ausgeführt und können bei Bedarf ausgeführt werden. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eines der aufgeführten Add-ons fehlt. Die Prüfung gibt nur dann Fehler zurück, wenn die Add-ons vorhanden sind und bei der Ausführung des Befehls Fehler aufweisen.

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

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

Wenn die Systemdiagnose Konfigurationsabweichungen erkennt, wird der Wert der benutzerdefinierten bm-system-add-ons-Bare-Metal-Ressource HealthCheck Status.Pass auf false festgelegt. 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 für die Ressource, z. B. Deployment.
Namespace: der Namespace, in dem sich die Ressource befindet.
Name ist der Name der -Ressource.
Diff: ein Vergleich im Stringformat der Unterschiede zwischen dem angegebenen Ressourcenmanifest und dem Manifest für die geänderte Ressource.

`HealthCheck` benutzerdefinierte Ressourcen

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

Benutzerdefinierte HealthCheck-Ressourcen für Bare Metal (API Version: baremetal.cluster.gke.io/v1): Diese Ressourcen enthalten Details zu regelmäßigen Systemdiagnosen. Diese Ressourcen befinden sich auf dem Administratorcluster in Cluster-Namespaces. HealthCheck-Ressourcen von Bare Metal 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 Messwerte von Systemdiagnosen zu melden. Diese Ressourcen befinden sich im Namespace kube-system jedes Clusters. Aktualisierungen dieser Ressourcen sind bestmöglich. Wenn bei einer Aktualisierung ein Problem fehlschlägt, z. B. bei einem vorübergehenden Netzwerkfehler, wird der Fehler ignoriert.

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

Bare-Metal-Systemdiagnosen GKE Enterprise-Systemdiagnosen Schweregrad

Bare-Metal-Systemdiagnosen	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:

Zum Lesen der Ergebnisse regelmäßiger Systemdiagnosen 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 regelmäßig ausgeführten Systemdiagnosen und ob die Prüfungen 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 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, z. B. wann ein Systemdiagnosejob zuletzt geplant und instrumentiert wurde.

Das folgende HealthCheck-Beispiel bezieht sich auf eine erfolgreiche Maschinenprüfung:

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

Das folgende HealthCheck-Beispiel bezieht sich auf eine fehlgeschlagene Maschinenprüfung:

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

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

Cronjobs für Systemdiagnosen

Für regelmäßige Systemdiagnosen hat jede benutzerdefinierte Bare-Metal-Ressource HealthCheck eine entsprechende CronJob mit demselben Namen. Dieser CronJob sorgt dafür, dass die entsprechende Systemdiagnose so geplant wird, dass sie in festgelegten Intervallen ausgeführt wird.

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 jeden Systemdiagnosejob in der Zeitplansyntax an. Der Job bm-system-kubernetes wird beispielsweise an jedem Tag (* * *) jeweils 17 Minuten nach der vollen Stunde (17) ausgeführt (*/1). Die Zeitintervalle für regelmäßige Systemdiagnosen können nicht bearbeitet werden. Bei der Fehlerbehebung ist es jedoch nützlich zu wissen, 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

Systemdiagnoselogs

Bei der Ausführung von Systemdiagnosen werden Logs generiert. Logs werden an Cloud Logging gesendet, unabhängig davon, ob Sie Systemdiagnosen mit bmctl oder automatisch im Rahmen regelmäßiger Systemdiagnosen ausführen. Wenn Sie bei Bedarf Systemdiagnosen ausführen, werden Logdateien in einem Ordner mit Zeitstempel im Verzeichnis log/ Ihres Clusterordners auf Ihrer Administratorworkstation erstellt. Wenn Sie beispielsweise den Befehl bmctl check kubernetes für einen Cluster namens test-cluster ausführen, finden Sie 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 spezifischen 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.

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 die Pod-Logs ab:

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 des 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 eines Pod-Logs zur fehlgeschlagenen Systemdiagnose für Knotenmaschinen. Das Beispiel zeigt, dass die kubelet-Prüfung (check_kubelet_pass) fehlgeschlagen ist und angibt, 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

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

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

Zum Log-Explorer

Geben Sie im Feld Abfrage die Folgendes ein:

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

Das Fenster Abfrageergebnisse enthält die Logs für Systemdiagnosen von Knotenmaschinen.

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

Knotencomputer

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:

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 sind Prüfungen auf Clusterebene, sodass für jede Prüfung eine einzelne Ressource vorhanden ist. 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 die HealthCheck-Ressourcen von 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: 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 bestanden (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, indem Sie das Feld periodicHealthCheck.enable in der Clusterressource auf false setzen.

So deaktivieren Sie regelmäßige Systemdiagnosen:

Bearbeiten Sie die Clusterkonfigurationsdatei, fügen Sie der Clusterspezifikation das Feld periodicHealthCheck.enable hinzu und legen Sie 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: 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. Damit prüfen Sie, ob 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: 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 Systemdiagnosen mit bmctl check ausführen, gelten die folgenden Regeln:

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

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

Add-ons

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

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

Eine Liste der überprüften Elemente finden Sie in diesem Dokument im Abschnitt „Was wird überprüft“ unter Add-ons.

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

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 der überprüften Elemente finden Sie in den folgenden Abschnitten im Abschnitt „Was wurde überprüft“ dieses Dokuments:

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

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

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 lässt sich 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.

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

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

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

Kubernetes

Integrität kritischer Kubernetes-Operatoren prüfen, 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 Ausführung des Befehls Fehler vorliegen.

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

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

Durch diese Prüfung werden Logdateien in einem check-kubernetes-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administratorworkstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Logs der Systemdiagnose.

Knoten

Prüfen Sie die Maschinen, die Clusterknoten ausführen, ob sie richtig konfiguriert sind und über ausreichende Ressourcen und Konnektivität für Clusterupgrades und den Clusterbetrieb verfügen.

So prüfen Sie den Status von 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 der geprüften Elemente finden Sie in diesem Dokument im Abschnitt „Was wird überprüft“ unter Knotencomputerprüfungen.

Durch diese Prüfung werden Logdateien für jede Clusterknotenmaschine in einem check-nodes-TIMESTAMP-Verzeichnis im Cluster-Logordner auf Ihrer Administratorworkstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Logs finden Sie unter Logs der Systemdiagnose.

Vorflug

Informationen zur Verwendung von bmctl zum Ausführen von Preflight-Prüfungen finden Sie unter On-Demand-Preflight-Prüfungen zum Erstellen von Clustern ausführen und On-Demand-Preflight-Prüfungen für Clusterupgrades ausführen.

Preflight-Prüfung der VM-Laufzeit

Die Preflight-Prüfung „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 VM-Laufzeit in Google Distributed Cloud-Preflight-Prüfungen fehlschlägt, wird die VM-Erstellung blockiert. Wenn spec.enabled in der benutzerdefinierten Ressource VMRuntime auf true gesetzt ist, wird die VM-Laufzeit in Google Distributed Cloud-Preflight-Prüfungen automatisch ausgeführt.

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

Weitere Informationen finden Sie unter VM-Laufzeit in der Preflight-Prüfung von Google Distributed Cloud.

Systemdiagnosen

Was wird überprüft?

Knotenmaschinenprüfungen

Clusterweite Prüfungen

Netzwerkprüfungen

Kubernetes

Add-ons

HealthCheck benutzerdefinierte Ressourcen

Cronjobs für Systemdiagnosen

Systemdiagnoselogs

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

Vorflug

Preflight-Prüfung der VM-Laufzeit

Nächste Schritte

`HealthCheck` benutzerdefinierte Ressourcen