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.
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
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 Namespacekube-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: |
Typ: Maschine
Name: |
Kritisch |
Typ: Netzwerk
Name: |
Typ: Netzwerk
Name: |
Kritisch |
Typ: Kubernetes
Name: |
Typ: Kubernetes
Name: |
Kritisch |
Typ: Add-ons
Name: |
Typ: Add-ons
Name: |
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 SystemdiagnoseADMIN_KUBECONFIG
: der Pfad der kubeconfig-Datei des AdministratorclustersCLUSTER_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.15.0 Cluster Name: nuc-user001 Interval In Seconds: 3600 Node Addresses: 192.168.1.54 Type: machine Status: Check Image Version: 1.15.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.15.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-kubernetes Healthy 57m kube-system bm-system-kubernetes-1.15.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 AdministratorclustersCLUSTER_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 Jobbm-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 AdministratorclustersCLUSTER_NAMESPACE
: den Namespace des Clusters.
Das folgende Beispiel zeigt eine erfolgreiche
CronJob
:Name: bm-system-network Namespace: cluster-test-admin Labels: AnthosBareMetalVersion=1.15.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.15.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 AdministratorclustersCLUSTER_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 SystemdiagnoseADMIN_KUBECONFIG
: der Pfad der kubeconfig-Datei des AdministratorclustersCLUSTER_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 diekubelet
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.
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:
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 AdministratorclustersCLUSTER_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ürhealthchecks.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 auffalse
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 AdministratorclustersCLUSTER_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 auftrue
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 AdministratorclustersCLUSTER_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:
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.