Mit Systemdiagnosen können Sie den Betrieb Ihrer vorhandenen Cluster testen und überwachen. Systemdiagnosen werden regelmäßig automatisch ausgeführt. Mit bmctl
können Sie Systemdiagnosen auch auf Anfrage ausführen. In diesem Dokument wird jede Prüfung beschrieben, unter welchen Bedingungen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt und wie die Ergebnisse interpretiert werden sollten.
Was wird geprüft?
Es gibt zwei Kategorien von Google Distributed Cloud-Systemdiagnosen:
Prüfungen für Knotenrechner
Clusterweite Prüfungen
In den folgenden Abschnitten wird beschrieben, was für die einzelnen Kategorien geprüft wird. Diese Prüfungen werden sowohl für regelmäßige als auch für On-Demand-Systemdiagnosen verwendet.
Prüfungen für Knotenrechner
In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für Knotenmaschinen geprüft wird. Bei diesen Prüfungen wird bestätigt, dass die Knotenmaschinen richtig 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 HealthCheck
Benutzerdefinierte Ressourcen.
Zu den gängigen Maschinenprüfungen gehören:
Cluster-Maschinen verwenden ein unterstütztes Betriebssystem.
Die Betriebssystemversion wird unterstützt.
Das Betriebssystem verwendet eine unterstützte Kernelversion.
Für den Kernel ist die Option „BPF Just In Time (JIT) Compiler“ (
CONFIG_BPF_JIT=y
) aktiviert.Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.
Die Knotencomputer erfüllen die Mindestanforderungen an die CPU.
Auf den Knotenmaschinen sind mehr als 20% der CPU-Ressourcen verfügbar.
Die Knotencomputer erfüllen die Mindestanforderungen an den Arbeitsspeicher.
Die Knotencomputer erfüllen die Mindestanforderungen an den Speicherplatz.
Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.
Die Standardroute für das Weiterleiten von Paketen an das Standardgateway ist in den Knoten vorhanden.
Das Domain Name System (DNS) funktioniert. Diese Prüfung wird übersprungen, wenn der Cluster für die Ausführung hinter einem Proxy konfiguriert ist.
Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, ist der Spiegel erreichbar.
Die Google Cloud -Prüfungen umfassen Folgendes:
Container Registry,
gcr.io
ist erreichbar. Diese Prüfung wird übersprungen, wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist.Google APIs sind erreichbar.
Die 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 Status des CNI-Endpunkts (Container Network Interface) ist „Gesund“.
Pod-CIDRs dürfen sich nicht mit den IP-Adressen der Knotenmaschinen überschneiden.
Weitere Informationen zu den Anforderungen an Knotenmaschinen finden Sie unter Voraussetzungen für Clusterknoten-Rechner.
Clusterweite Prüfungen
In diesem Abschnitt wird beschrieben, was bei Systemdiagnosen für einen Cluster geprüft wird.
Netzwerkprüfungen
Die folgenden clientseitigen Netzwerkprüfungen für Clusterknoten werden automatisch im Rahmen der regelmäßigen Systemdiagnosen ausgeführt. Netzwerkprüfungen können nicht auf Anfrage 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 HealthCheck
Benutzerdefinierte Ressourcen.
Wenn der Cluster gebündeltes Load Balancing verwendet, müssen die Knoten im Load Balancing-Knotenpool eine ARP-Konnektivität (Layer 2 Address Resolution Protocol) haben. ARP ist für die VIP-Erkennung erforderlich.
Die Knoten der Steuerungsebene haben die Ports 8443 und 8444 für den GKE Identity Dienst geöffnet.
Die Knoten der Steuerungsebene haben die Ports 2382 und 2383 für die Verwendung durch die
etcd-events
-Instanz geöffnet.
Informationen zu Protokollen und Portnutzung für Ihre Cluster finden Sie unter Netzwerkanforderungen.
Die Netzwerkprüfungen für eine Preflight-Prüfung unterscheiden sich von den Netzwerksystemdiagnosen. 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 automatisch im Rahmen von Preflight- und regelmäßigen Gesundheitschecks ausgeführt werden, können auch on demand ausgeführt werden. Diese Prüfungen 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 bei der Befehlsausführung Fehler auftreten.
Diese Prüfungen entsprechen den benutzerdefinierten Bare Metal-HealthCheck
-Ressourcen mit dem Namen bm-system-kubernetes
, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Ressourcen für Systemdiagnosen finden Sie unter HealthCheck
Benutzerdefinierte Ressourcen.
Der API-Server funktioniert.
Der Operator
anetd
ist richtig konfiguriert.Alle Knoten der Steuerungsebene sind betriebsbereit.
Die folgenden Komponenten der Steuerungsebene funktionieren ordnungsgemäß:
anthos-cluster-operator
controller-manager
cluster-api-provider
ais
capi-kubeadm-bootstrap-system
cert-manager
kube-dns
Add-ons
Add-on-Prüfungen werden automatisch als Teil der Preflight-Prüfungen und der regelmäßigen Systemdiagnosen ausgeführt und können auf Anfrage 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 Befehlsausführung Fehler auftreten.
Diese Prüfungen entsprechen benutzerdefinierten Bare-Metal-HealthCheck
-Ressourcen mit dem Namen bm-system-add-ons*
, die im Administratorcluster im Cluster-Namespace ausgeführt werden. Weitere Informationen zu Ressourcen für Systemdiagnosen finden Sie unter HealthCheck
Benutzerdefinierte Ressourcen.
Die Cloud Logging-Stackdriver-Komponenten und der Connect-Agent sind funktionsfähig:
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 eine Abweichung der Konfiguration erkennt, wird der Wert der benutzerdefinierten Ressource Status.Pass
bm-system-add-ons
Bare MetalHealthCheck
auf false
gesetzt. Das Feld Description
im Abschnitt Failures
enthält Details zu allen geänderten Ressourcen, darunter die folgenden Informationen:
Version
: die API-Version der Ressource.Kind
: Das Objektschema, z. B.Deployment
, für die Ressource.Namespace
: der Namespace, in dem sich die Ressource befindet.Name
ist der Name der -Ressource.Diff
: Ein Stringformatvergleich der Unterschiede zwischen dem im Datenbestand vorhandenen Ressourcenmanifest und dem Manifest für die geänderte Ressource.
Benutzerdefinierte HealthCheck
-Ressourcen
Wenn eine Systemdiagnose ausgeführt wird, erstellt Google Distributed Cloud eine benutzerdefinierte Ressource HealthCheck
. Benutzerdefinierte HealthCheck
-Ressourcen sind persistent und bieten eine strukturierte Aufzeichnung der Aktivitäten und Ergebnisse der Systemdiagnose. Es gibt zwei Kategorien von benutzerdefinierten HeathCheck
-Ressourcen:
Bare Metal
HealthCheck
-benutzerdefinierte Ressourcen (API Version: baremetal.cluster.gke.io/v1
): Diese Ressourcen enthalten Details zu regelmäßigen Gesundheitschecks. Diese Ressourcen befinden sich im Administratorcluster in Cluster-Namespaces. Bare-Metal-HealthCheck
-Ressourcen sind für das Erstellen von Cronjobs und Jobs zur Systemdiagnose verantwortlich. Diese Ressourcen werden regelmäßig mit den neuesten Ergebnissen aktualisiert.Benutzerdefinierte Anthos-
HealthCheck
-Ressourcen (API Version: anthos.gke.io/v1
): Mit diesen Ressourcen werden Systemdiagnosemesswerte erfasst. Diese Ressourcen befinden sich im Namespacekube-system
jedes Clusters. Aktualisierungen dieser Ressourcen erfolgen auf Best-Effort-Basis. Wenn ein Update aufgrund eines Problems fehlschlägt, z. B. aufgrund eines vorübergehenden Netzwerkfehlers, wird der Fehler ignoriert.
In der folgenden Tabelle sind die Ressourcentypen aufgeführt, die für die jeweilige HealthCheck
-Kategorie erstellt werden:
Bare Metal HealthChecks | GKE Enterprise-Überwachung | 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:
Name: |
Optional |
So rufen Sie den Status von HealthCheck
ab:
Wenn Sie die Ergebnisse der regelmäßigen 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 sind die Systemdiagnosen zu sehen, die 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 abzurufen: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.
Der Abschnitt
Status:
enthält die folgenden wichtigen Felder:Pass
: Gibt an, ob der letzte Job der Systemdiagnose bestanden hat.Checks
: enthält Informationen zum letzten Systemdiagnose-Job.Failures
: Enthält Informationen zum letzten fehlgeschlagenen Job.Periodic
: enthält Informationen wie z. B. wann zuletzt ein Job für die Systemdiagnose 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 ...
Mit dem folgenden Befehl rufen Sie eine Liste der Systemdiagnosen für Messwerte ab:
kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system
Ersetzen Sie
CLUSTER_KUBECONFIG
durch den Pfad der kubeconfig-Datei des Zielclusters.Das folgende Beispiel zeigt das Antwortformat:
NAMESPACE NAME COMPONENT NAMESPACE STATUS LAST_COMPLETED kube-system bm-system-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 die Systemdiagnose
Für regelmäßige Systemdiagnosen hat jede benutzerdefinierte Bare-Metal-HealthCheck
-Ressource eine entsprechende CronJob
mit demselben Namen. Diese CronJob
ist dafür verantwortlich, die entsprechende Systemdiagnose in festgelegten Intervallen auszuführen. Der CronJob
enthält auch einen ansible-runner
-Container, der die Systemdiagnose durch Herstellen einer SSH-Verbindung (Secure Shell) zu den Knoten ausführt.
So rufen Sie Informationen zu Cronjobs ab:
Liste der Cron-Jobs abrufen, 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 jeden ausgeführten Dienststatus-Check in Zeitplansyntax an. Beispiel: Der Jobbm-system-kubernetes
wird jeden Tag (* * *
) um 17 Minuten nach der vollen Stunde (17
) ausgeführt. Die Zeitintervalle für die periodischen Systemdiagnosen können nicht bearbeitet werden. Es ist jedoch hilfreich für die Fehlerbehebung zu wissen, wann sie ausgeführt werden sollen.*/1
So rufen Sie Details zu einer bestimmten
CronJob
-benutzerdefinierten 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.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
Protokolle der Systemdiagnose
Bei der Ausführung von Systemdiagnosen werden Protokolle generiert. Unabhängig davon, ob Sie Systemdiagnosen mit bmctl
ausführen oder sie automatisch im Rahmen regelmäßiger Systemdiagnosen ausgeführt werden, werden Protokolle an Cloud Logging gesendet. Wenn Sie Systemdiagnosen auf Anfrage ausführen, werden Protokolldateien mit Zeitstempeln 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 die Protokolle 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:
Pods abrufen und den gewünschten Pod für die Systemdiagnose finden:
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.
Die folgende Beispielantwort enthält einige Pods für die Systemdiagnose:
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
Pod-Logs abrufen:
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 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 des Pod-Logs für die fehlgeschlagene Systemdiagnose eines Knotens. Das Beispiel zeigt, dass die
kubelet
-Prüfung (check_kubelet_pass
) fehlgeschlagen ist. Das bedeutet, dasskubelet
auf diesem Knoten nicht ausgeführt wird.... TASK [Reach a final verdict] *************************************************** Thursday 02 November 2023 17:30:19 +0000 (0:00:00.172) 0:00:17.218 ***** fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"} ...
Logs in Cloud Logging ansehen
Logs für Systemdiagnosen werden an Cloud Logging gestreamt und können im Log-Explorer aufgerufen werden. Regelmäßige Systemdiagnosen werden in den Konsolenprotokollen 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 Protokolle für die Systemdiagnosen der Knotencomputer angezeigt.
Hier finden Sie eine Liste von Abfragen für regelmäßige Systemdiagnosen:
Knotenrechner
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
Netzwerk
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-network.*"
Kubernetes
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-kubernetes.*"
Add-ons
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-add-ons.*"
Regelmäßige Systemdiagnosen
Standardmäßig werden die regelmäßigen Systemdiagnosen stündlich ausgeführt und die folgenden Clusterkomponenten geprüft:
Sie können den Clusterstatus anhand der benutzerdefinierten Bare Metal-Ressourcen HealthCheck
(healthchecks.baremetal.cluster.gke.io
) im Administratorcluster prüfen.
Die Prüfungen für Netzwerk, Kubernetes und Add-ons 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. Es gibt also eine Ressource für jeden Knoten.
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 Beispiel 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 bestanden (true
) oder fehlgeschlagen (false
) ist.
Weitere Informationen zum Prüfen des Status für regelmäßige Systemdiagnosen finden Sie unter HealthCheck
benutzerdefinierte Ressourcen und Systemdiagnoseprotokolle.
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 als Wertfalse
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 ...
Führen Sie den Befehl
bmctl update
aus, um den Cluster zu aktualisieren: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
Führen Sie den folgenden Befehl aus, um zu prüfen, ob 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, indem Sie in der Clusterressource das Feld periodicHealthCheck.enable
auf true
festlegen.
So aktivieren Sie regelmäßige Systemdiagnosen wieder:
Bearbeiten Sie die Clusterkonfigurationsdatei, fügen Sie der Clusterspezifikation das Feld
periodicHealthCheck.enable
hinzu und legen Sie als Werttrue
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 ...
Führen Sie den Befehl
bmctl update
aus, um den Cluster zu aktualisieren: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
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die entsprechenden
healthchecks.baremetal.cluster.gke.io
-Ressourcen vorhanden sind und die sitzungsübergreifenden Systemdiagnosen aktiviert 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 mit bmctl check
auf Anfrage 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 Clusterprotokollordner auf Ihrer Administrator-Workstation generiert (standardmäßig
bmctl-workspace/CLUSTER_NAME/log
).Logs für Systemdiagnosen werden ebenfalls an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle für Systemdiagnosen.
Weitere Informationen zu anderen Optionen für bmctl
-Befehle finden Sie in der bmctl
-Befehlsreferenz.
Add-ons
Prüfen Sie, ob die angegebenen Kubernetes-Add-ons für den angegebenen Cluster betriebsbereit sind.
So prüfen Sie die 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 aktivierten Add-ons finden Sie im Abschnitt „Aktivierte Add-ons“ unter Add-ons in diesem Dokument.
Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-addons-TIMESTAMP
im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.
Cluster
Prüfen Sie alle Clusterknoten, das Knotennetzwerk, Kubernetes und die Add-ons für den angegebenen Cluster. Sie geben den Clusternamen an und bmctl
sucht standardmäßig nach der Clusterkonfigurationsdatei unter bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml
.
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 geprüften Elemente finden Sie in diesem Dokument im Abschnitt „Was wird geprüft?“ in den folgenden Abschnitten:
Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-cluster-TIMESTAMP
im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.
Konfiguration
Prüfen Sie die Cluster-Konfigurationsdatei. Für diese Prüfung wird davon ausgegangen, dass Sie die Konfigurationsdatei generiert und bearbeitet haben, um die Details der Clusterkonfiguration 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
Mit diesem Befehl wird die YAML-Syntax der Clusterkonfigurationsdatei, derGoogle Cloud -Zugriff und die Berechtigungen für das in der Clusterkonfigurationsdatei angegebene Dienstkonto überprüft.
Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-config-TIMESTAMP
im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.
Verbindung zu Google Cloud
Prüfen Sie, ob alle Clusterknotencomputer auf die Container Registry (gcr.io
) und den Google APIs-Endpunkt (googleapis.com
) zugreifen können.
So prüfen Sie den Clusterzugriff auf die erforderlichen 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
Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-gcp-TIMESTAMP
im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.
Kubernetes
Prüfen Sie den Status wichtiger Kubernetes-Operatoren, die in der Steuerungsebene ausgeführt werden. Dabei wird geprüft, ob kritische Operatoren ordnungsgemäß funktionieren und ihre Pods nicht abstürzen. Diese Systemdiagnose gibt keinen Fehler zurück, wenn eine der Komponenten der Steuerebene fehlt. Sie gibt nur Fehler zurück, wenn die Komponenten vorhanden sind und bei der Befehlsausführung Fehler auftreten.
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
: Pfad der kubeconfig-Datei des Administratorclusters.
Eine Liste der geprüften Elemente finden Sie im Abschnitt „Was wird geprüft?“ unter Kubernetes in diesem Dokument.
Bei dieser Prüfung werden Protokolldateien im Verzeichnis check-kubernetes-TIMESTAMP
im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle der Systemdiagnose.
Knoten
Prüfen Sie die Clusterknotenmaschinen, um sicherzustellen, dass sie ordnungsgemäß konfiguriert sind und über ausreichende Ressourcen und eine ausreichende 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 Knotencomputer.ADMIN_KUBECONFIG
: Pfad der kubeconfig-Datei des Administratorclusters.
Eine Liste der geprüften Elemente finden Sie im Abschnitt „Was wird geprüft?“ unter Kriterien für die Überprüfung von Knotenmaschinen.
Bei dieser Prüfung werden Logdateien für jeden Clusterknotencomputer in einem check-nodes-TIMESTAMP
-Verzeichnis im Clusterprotokollordner auf Ihrer Administrator-Workstation generiert. Logs werden auch an Cloud Logging gesendet. Weitere Informationen zu den Protokollen finden Sie unter Protokolle zur Systemdiagnose.
Preflight
Informationen zum Ausführen von Preflight-Prüfungen mit bmctl
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
Bei der Preflight-Prüfung der VM Runtime on GDC werden eine Reihe von Voraussetzungen für Knotencomputer geprüft, bevor die VM Runtime on GDC und VMs verwendet werden. Wenn die Preflight-Prüfung der VM Runtime on GDC fehlschlägt, wird die VM-Erstellung blockiert. Wenn spec.enabled
in der benutzerdefinierten Ressource VMRuntime
auf true
festgelegt ist, wird die Preflight-Prüfung der VM Runtime on GDC 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 der VM Runtime on GDC.
Aktuelle Systemdiagnosen ausführen
Systemdiagnosen (und Preflight-Prüfungen) werden aktualisiert, sobald bekannte Probleme erkannt werden.
Wenn Sie bmctl
anweisen möchten, die Prüfungen aus dem neuesten Patch-Image Ihrer installierten Nebenversion auszuführen, verwenden Sie das Optionsflag --check-image-version latest
:
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest
Ersetzen Sie CLUSTER_NAME
durch den Namen des Clusters, den Sie prüfen.
So können Sie kürzlich erkannte bekannte Probleme erkennen, ohne zuerst Ihren Cluster zu aktualisieren.
Sie können die neuesten Preflight-Prüfungen auch ausführen, bevor Sie einen Cluster installieren oder aktualisieren. Weitere Informationen finden Sie unter Neueste Vorabprüfungen ausführen.
Erkennung von Konfigurationsabweichungen
Bei der Systemdiagnose für Add-ons wird unter anderem geprüft, ob unerwartete Änderungen an von Google Distributed Cloud verwalteten Ressourcen vorgenommen wurden. Dabei werden insbesondere die Manifeste für diese Ressourcen geprüft, um festzustellen, ob Änderungen von externen Entitäten vorgenommen wurden. Diese Prüfungen können vor unbeabsichtigten Änderungen warnen, die sich negativ auf die Clustergesundheit auswirken könnten. Außerdem enthalten sie wertvolle Informationen zur Fehlerbehebung.
Welche Manifeste werden geprüft?
Mit wenigen Ausnahmen werden bei der Systemdiagnose für Add-ons alle von Google Distributed Cloud verwalteten Ressourcen für Ihre Cluster geprüft. Das sind Ressourcen, die von der Google Distributed Cloud-Software installiert und verwaltet werden. Es gibt Hunderte dieser Ressourcen und die meisten ihrer Manifeste werden auf Abweichungen bei der Konfiguration geprüft. Die Manifeste gelten für alle Arten von Ressourcen, einschließlich, aber nicht beschränkt auf:
|
|
|
Nicht geprüfte Manifeste
Einige Manifeste werden von uns standardmäßig von der Überprüfung ausgeschlossen. Bestimmte Arten von Ressourcen wie Zertifikate, Geheimnisse und Dienstkonten werden aus Datenschutz- und Sicherheitsgründen ignoriert. Bei der Überprüfung von Add-ons werden auch einige Ressourcen und Ressourcenfelder ignoriert, da wir davon ausgehen, dass sie geändert werden, und nicht möchten, dass die Änderungen Konfigurationsabweichungsfehler auslösen. So werden bei der Prüfung beispielsweise replicas
-Felder in Bereitstellungen ignoriert, da der Autoscaler diesen Wert möglicherweise ändert.
Zusätzliche Manifeste oder Teile von Manifesten von der Überprüfung ausschließen
Im Allgemeinen empfehlen wir, keine Änderungen an von der Google Distributed Cloud verwalteten Ressourcen vorzunehmen oder Änderungen an ihnen zu ignorieren.
Wir wissen jedoch, dass Ressourcen manchmal geändert werden müssen, um Anforderungen an bestimmte Fälle zu erfüllen oder Probleme zu beheben. Aus diesem Grund stellen wir für jeden Cluster in Ihrer Flotte ein ignore-config-drift
-ConfigMap bereit. Mit diesen ConfigMaps können Sie Ressourcen und bestimmte Ressourcenfelder angeben, die von der Bewertung ausgeschlossen werden sollen.
In Google Distributed Cloud wird für jeden Cluster eine ignore-config-drift
-ConfigMap erstellt. Diese ConfigMaps befinden sich im verwaltenden Cluster (Administrator- oder Hybridcluster) im entsprechenden Cluster-Namespace. Wenn Sie beispielsweise einen Administratorcluster (admin-one
) haben, der zwei Nutzercluster (user-one
und user-two
) verwaltet, finden Sie die ignore-config-drift
-ConfigMap für den user-one
-Cluster im admin-one
-Cluster im Namespace cluster-user-one
.
So schließen Sie eine Ressource oder Ressourcenfelder von der Überprüfung aus:
Fügen Sie der ConfigMap
ignore-config-drift
das Felddata.ignore-resources
hinzu.Dieses Feld nimmt ein Array von JSON-Strings an. Jeder String gibt eine Ressource und optional bestimmte Felder in der Ressource an.
Geben Sie die Ressource und optional die zu ignorierenden Felder als JSON-Objekt im String-Array an:
Das JSON-Objekt für eine Ressource und Felder hat die folgende Struktur:
{ "Version": "RESOURCE_VERSION", "Kind": "RESOURCE_KIND", "Namespace": "RESOURCE_NAMESPACE", "Name": "RESOURCE_NAME", "Fields": [ "FIELD_1_NAME", "FIELD_2_NAME", ... "FIELD_N_NAME" ] }
Ersetzen Sie Folgendes:
RESOURCE_VERSION
: (Optional) DerapiVersion
-Wert für die Ressource.RESOURCE_KIND
: (Optional) Derkind
-Wert für die Ressource.RESOURCE_NAMESPACE
: (Optional) Dermetadata.namespace
-Wert für die Ressource.RESOURCE_NAME
: (Optional) Dermetadata.name
-Wert für die Ressource.FIELD_NAME
: (Optional) Geben Sie ein Array von Ressourcenfeldern an, die ignoriert werden sollen. Wenn Sie keine Felder angeben, werden bei der Überprüfung durch die Add-ons alle Änderungen an der Ressource ignoriert.
Alle Felder im JSON-Objekt sind optional, sodass eine Vielzahl von Permutationen zulässig ist. Sie können ganze Kategorien von Ressourcen ausschließen oder sehr genau vorgehen und bestimmte Felder einer bestimmten Ressource ausschließen.
Wenn Sie beispielsweise möchten, dass die Add-ons nur Änderungen an dem Abschnitt
command
derais
-Bereitstellung in Ihrem Administratorcluster ignorieren, könnte die JSON-Datei so aussehen:{ "Version": "apps/v1", "Kind": "Deployment", "Namespace": "anthos-identity-service", "Name": "ais", "Fields": [ "command" ] }
Sie fügen dieses JSON-Objekt
ignore-resources
in derconfig-drift-ignore
-ConfigMap als Stringwert in einem Array hinzu, wie im folgenden Beispiel gezeigt:apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: "2024-09-24T00:39:45Z" name: config-drift-ignore namespace: cluster-example-admin ownerReferences: - apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster name: example-admin ... data: ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]' ...
Mit dieser Beispiel-ConfigMap-Einstellung können Sie
command
-Felder imais
-Deployment hinzufügen, entfernen oder bearbeiten, ohne dass Konfigurationsabweichungsfehler ausgelöst werden. Änderungen an Feldern außerhalb des Bereichscommand
in der Bereitstellung werden jedoch weiterhin von der Add-on-Prüfung erkannt und als Konfigurationsabweichung gemeldet.Wenn Sie alle Bereitstellungen ausschließen möchten, könnte der Wert für
ignore-resources
so aussehen:... data: ignore-resources: '[{"Kind":"Deployment"}]' ...
Da
ignore-resources
ein Array von JSON-Strings akzeptiert, können Sie mehrere Ausschlussmuster angeben. Wenn Sie Probleme beheben oder mit Ihren Clustern experimentieren und keine Fehler bei der Konfigurationsabweichung auslösen möchten, kann diese Flexibilität, sowohl sehr gezielte Ressourcen als auch Ressourcenfelder oder breitere Kategorien von Ressourcen von der Abweichungserkennung auszuschließen, nützlich sein.