I controlli di integrità sono un modo per testare e monitorare il funzionamento della tua
cluster. I controlli di integrità vengono eseguiti in modo autonomo, periodicamente. Puoi anche usare bmctl
per eseguire controlli di integrità on demand. Questo documento descrive ogni controllo, in che
viene eseguito automaticamente, come e quando eseguirlo manualmente e come
a interpretare i risultati.
Cosa viene controllato?
Esistono due categorie di controlli di integrità di Google Distributed Cloud:
Controlli delle macchine dei nodi
Controlli a livello di cluster
Le seguenti sezioni descrivono cosa viene controllato per ogni categoria. Questi controlli e vengono utilizzati per i controlli di integrità sia periodici che on demand.
Controlli delle macchine dei nodi
Questa sezione descrive cosa viene valutato dai controlli di integrità per le macchine nodo. Questi controlli confermano che le macchine nodo sono configurate correttamente e che disporre di risorse e connettività sufficienti per la creazione del cluster, upgrade e operazioni del cluster.
Questi controlli corrispondono alle risorse personalizzate Bare Metal HealthCheck
denominate
bm-system-NODE_IP_ADDRESS-machine
(ad esempio,
bm-system-192.0.2.54-machine
) in esecuzione nel cluster di amministrazione nel cluster
nello spazio dei nomi. Per saperne di più sulle risorse per il controllo di integrità, consulta HealthCheck
risorse personalizzate.
I controlli più comuni delle macchine sono i seguenti:
Le macchine cluster utilizzano un sistema operativo supportato.
La versione del sistema operativo è supportata.
Il sistema operativo utilizza una versione del kernel supportata.
Nel kernel è abilitata l'opzione del compilatore BPF Just In Time (JIT) (
CONFIG_BPF_JIT=y
).Per Ubuntu, il Uncomplicated Firewall (UFW) è disabilitato.
Le macchine nodo soddisfano i requisiti minimi di CPU.
Le macchine nodo hanno più del 20% delle risorse della CPU disponibili.
Le macchine nodo soddisfano i requisiti minimi di memoria.
Le macchine nodo soddisfano i requisiti minimi di archiviazione su disco.
La sincronizzazione dell'ora è configurata sulle macchine nodo.
La route predefinita per il routing dei pacchetti al gateway predefinito è presente in nodi.
Il DNS (Domain Name System) è funzionale (questo controllo viene ignorato se il cluster è configurato per essere eseguito dietro un proxy).
Se il cluster è configurato in modo da utilizzare un mirror del registro, sia raggiungibile.
I controlli di Google Cloud sulle macchine sono costituiti da quanto segue:
Container Registry,
gcr.io
è raggiungibile (questo controllo viene ignorato se è configurato in modo da utilizzare un mirror del registro).le API di Google sono raggiungibili.
I controlli di integrità delle macchine sono costituiti da quanto segue:
kubelet
è attivo e in esecuzione su macchine nodo.containerd
è attivo e in esecuzione su macchine nodo.Lo stato dell'endpoint di integrità di Container Network Interface (CNI) è integro.
I CIDR dei pod non si sovrappongono agli indirizzi IP delle macchine dei nodi.
Per ulteriori informazioni sui requisiti delle macchine dei nodi, consulta Nodo cluster prerequisiti della macchina.
Controlli a livello di cluster
Questa sezione descrive cosa viene valutato dai controlli di integrità per un cluster.
Controlli della rete
I seguenti controlli di rete dei nodi cluster lato client vengono eseguiti automaticamente
di controlli di integrità periodici. I controlli di rete non possono essere eseguiti on demand. Questi controlli
corrispondono alle risorse personalizzate HealthCheck
Bare Metal denominate
bm-system-network
in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per
ulteriori informazioni sulle risorse per il controllo di integrità, vedi HealthCheck
Google Cloud.
Se il cluster utilizza il bilanciamento del carico in bundle, i nodi nel nodo di bilanciamento del carico Il pool deve avere una connettività ARP (Indirizzo di risoluzione degli indirizzi di livello 2). ARP per il rilevamento VIP.
I nodi del piano di controllo hanno le porte 8443 e 8444 aperte per l'utilizzo GKE Identity Service.
I nodi del piano di controllo hanno le porte 2382 e 2383 aperte per essere utilizzate dal
etcd-events
istanza.
Per informazioni sui protocolli e sull'utilizzo delle porte per Google Distributed Cloud cluster, vedi Requisiti di rete.
I controlli di rete per un controllo preflight sono diversi dai controlli di integrità della rete. Per un elenco dei controlli di rete per un controllo preflight, vedi Controlli preflight per la creazione del cluster oppure Controlli preflight per gli upgrade del cluster.
Kubernetes
Controlli Kubernetes, che vengono eseguiti automaticamente nell'ambito di controlli preflight e periodici controlli di integrità, possono anche essere eseguiti on demand. Questi i controlli di integrità non restituiscono un errore se uno dei piani di controllo elencati componenti. Il controllo restituisce errori solo se i componenti esistono. e si verificano errori al momento dell'esecuzione del comando.
Questi controlli corrispondono alle risorse personalizzate Bare Metal HealthCheck
denominate
bm-system-kubernetes
risorse in esecuzione nel cluster di amministrazione nel cluster
nello spazio dei nomi. Per saperne di più sulle risorse per il controllo di integrità, consulta HealthCheck
risorse personalizzate.
Il server API funziona.
L'operatore
anetd
è configurato correttamente.Tutti i nodi del piano di controllo sono operabili.
I seguenti componenti del piano di controllo funzionano correttamente:
anthos-cluster-operator
controller-manager
cluster-api-provider
ais
capi-kubeadm-bootstrap-system
cert-manager
kube-dns
Componenti aggiuntivi
I controlli dei componenti aggiuntivi vengono eseguiti automaticamente nell'ambito dei controlli preflight e dell'integrità periodica esegue controlli e può essere eseguita on demand. Questo controllo di integrità non restituisce un errore se manca uno dei componenti aggiuntivi elencati. Solo il controllo restituisce gli errori se i componenti aggiuntivi esistono e presentano errori al momento dell'esecuzione del comando.
Questi controlli corrispondono alle risorse personalizzate HealthCheck
Bare Metal denominate
bm-system-add-ons*
risorse in esecuzione nel cluster di amministrazione nel cluster
nello spazio dei nomi. Per saperne di più sulle risorse per il controllo di integrità, consulta HealthCheck
risorse personalizzate.
I componenti Stackdriver di Cloud Logging e l'agente Connect sono azionabili:
stackdriver-log-aggregator
stackdriver-log-forwarder
stackdriver-metadata-agent
stackdriver-prometheus-k8
gke-connect-agent
Le risorse gestite da Google Distributed Cloud non mostrano modifiche manuali (deviazione della configurazione):
I valori dei campi non sono stati aggiornati
I campi facoltativi non sono stati aggiunti o rimossi
Le risorse non sono state eliminate
Se il controllo di integrità rileva una deviazione nella configurazione, viene eseguito il Bare Metal bm-system-add-ons
Il valore Status.Pass
della risorsa personalizzata HealthCheck
è impostato su false
. La
Il campo Description
nella sezione Failures
contiene dettagli su qualsiasi
di risorse che sono cambiate, incluse le seguenti informazioni:
Version
: la versione API per la risorsa.Kind
: lo schema dell'oggetto, ad esempioDeployment
, per la risorsa.Namespace
: lo spazio dei nomi in cui si trova la risorsa.Name
: il nome della risorsa.Diff
: un confronto in formato stringa delle differenze tra la risorsa il manifest registrato e il manifest per la risorsa modificata.
HealthCheck
risorse personalizzate
Quando viene eseguito un controllo di integrità, Google Distributed Cloud crea un'istanza HealthCheck
personalizzata
risorsa. HealthCheck
risorse personalizzate sono permanenti e forniscono una struttura
delle attività e dei risultati del controllo di integrità. Esistono due categorie di
HeathCheck
risorse personalizzate:
Risorse personalizzate di Bare Metal
HealthCheck
(API Version: baremetal.cluster.gke.io/v1
): queste risorse forniscono dettagli su controlli di integrità periodici. Queste risorse si trovano nel cluster di amministrazione nel cluster spazi dei nomi. Le risorse Bare MetalHealthCheck
sono responsabili della creazione cron job e job per il controllo di integrità. Queste risorse vengono aggiornate costantemente con i risultati più recenti.Risorse personalizzate di Anthos
HealthCheck
(API Version: anthos.gke.io/v1
): queste risorse vengono usate per generare report sulle metriche del controllo di integrità. Queste risorse sono nello spazio dei nomikube-system
di ogni cluster. Aggiornamenti di queste risorse sono migliori sforzi. Se un aggiornamento non riesce, ad esempio un problema temporaneo errore di rete, l'errore viene ignorato.
La tabella seguente elenca i tipi di risorse che vengono creati
Categoria HealthCheck
:
Controlli di integrità Bare Metal | Controlli di integrità di GKE Enterprise | Gravità |
---|---|---|
Tipo: macchina
Nome: |
Tipo: macchina
Nome: |
Critico |
Tipo: rete
Nome: |
Tipo: rete
Nome: |
Critico |
Tipo: Kubernetes
Nome: |
Tipo: Kubernetes
Nome: |
Critico |
Tipo: componenti aggiuntivi
Nome: |
Tipo: componenti aggiuntivi
Nome:
Nome: |
Facoltativo |
Per recuperare lo stato di HealthCheck
:
Per leggere i risultati dei controlli di integrità periodici, puoi ottenere lo stato risorse personalizzate:
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig ADMIN_KUBECONFIG --all-namespaces
Sostituisci
ADMIN_KUBECONFIG
con il percorso dell'amministratore kubeconfig del cluster.L'esempio seguente mostra i controlli di integrità eseguiti periodicamente se i controlli sono stati superati l'ultima volta che sono stati eseguiti:
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
Per leggere i dettagli di un controllo di integrità specifico, utilizza
kubectl describe
:kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
HEALTHCHECK_NAME
: il nome del controllo di integrità.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
Quando esamini la risorsa, la sezione
Status:
contiene quanto segue: campi importanti:Pass
: indica se l'ultimo job di controllo di integrità è stato superato o meno.Checks
: contiene informazioni sul job di controllo di integrità più recente.Failures
: contiene informazioni sul job non riuscito più recente.Periodic
: contiene informazioni, ad esempio quando è stata l'ultima volta il job di controllo è stato pianificato e strumentato.
Il seguente esempio di
HealthCheck
è per un controllo della macchina riuscito: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
Il seguente esempio di
HealthCheck
è relativo a un controllo della macchina non riuscito: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 ...
Per ottenere un elenco dei controlli di integrità per le metriche, utilizza il comando seguente:
kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system
Sostituisci
CLUSTER_KUBECONFIG
con il percorso del target kubeconfig del cluster.Nell'esempio seguente viene mostrato il formato della risposta:
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
cron job del controllo di integrità
Per i controlli di integrità periodici, ogni risorsa personalizzata HealthCheck
bare metal ha un
corrispondente
CronJob
con lo stesso nome. Questo CronJob
è responsabile della programmazione
controllo di integrità corrispondente da eseguire a intervalli prestabiliti. Il CronJob
include anche
un container ansible-runner
che esegue il controllo di integrità stabilendo
connessione shell sicura (SSH) ai nodi.
Per recuperare le informazioni sui cron job:
Ottieni un elenco di cron job eseguiti per un determinato cluster:
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
Il seguente esempio mostra una risposta tipica:
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
I valori nella colonna
SCHEDULE
indicano la pianificazione per ogni stato di salute controlla l'esecuzione del job sintassi di programmazione. Ad esempio, il jobbm-system-kubernetes
viene eseguito 17 minuti dopo l'ora (17
) ogni ora (*/1
) di ogni giorno (* * *
). Gli intervalli di tempo per i controlli di integrità periodici non sono modificabili, ma sono utili per risolvere i problemi sapere quando devono correre.Recupera i dettagli per una specifica risorsa personalizzata
CronJob
:kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
L'esempio seguente mostra un
CronJob
riuscito: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
Log dei controlli di integrità
Durante l'esecuzione, i controlli di integrità generano log. Se esegui controlli di integrità con
bmctl
o vengono eseguiti automaticamente nell'ambito di controlli di integrità periodici, i log vengono
inviate a Cloud Logging. Quando esegui controlli di integrità on demand,
i file di log vengono creati in una cartella con timestamp nella directory log/
del
sulla tua workstation di amministrazione. Ad esempio, se esegui il comando bmctl
check kubernetes
per un cluster denominato test-cluster
, troverai i log
in una directory come
bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923
.
Visualizza i log in locale
Puoi utilizzare kubectl
per visualizzare i log per i controlli di integrità periodici:
Ottieni i pod e trova il pod di controllo di integrità specifico che ti interessa:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
La seguente risposta di esempio mostra alcuni pod del controllo di integrità:
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
Recupera i log dei pod:
kubectl logs POD_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
POD_NAME
: il nome del pod del controllo di integrità.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
L'esempio seguente mostra parte di un log di pod per una macchina nodo riuscita controllo di integrità:
... 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" } } ...
L'esempio seguente mostra parte di un pod del controllo di integrità della macchina con nodo non riuscito log. L'esempio mostra che il controllo
kubelet
(check_kubelet_pass
) non è riuscito, che indica chekubelet
non è in esecuzione su questo nodo.... 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']"} ...
Visualizza i log in Cloud Logging
I log del controllo di integrità vengono trasmessi in flusso a Cloud Logging e possono essere visualizzati Esplora log. I controlli di integrità periodici sono classificati come pod log della console Cloud.
Nella console Google Cloud, vai alla pagina Esplora log nel Logging.
Nel campo Query, inserisci la seguente query di base:
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
La finestra Risultati delle query mostra i log per i controlli di integrità delle macchine del nodo.
Di seguito è riportato un elenco di query per i controlli di integrità periodici:
Macchina nodo
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
Rete
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-network.*"
Kubernetes
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-kubernetes.*"
Componenti aggiuntivi
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-add-ons.*"
Controlli di integrità periodici
Per impostazione predefinita, i controlli di integrità periodici vengono eseguiti ogni ora e verificano quanto segue: del cluster:
Puoi controllare l'integrità del cluster osservando il HealthCheck
Bare Metal
(healthchecks.baremetal.cluster.gke.io
) risorse personalizzate nel cluster di amministrazione.
I controlli di rete, Kubernetes e componenti aggiuntivi sono controlli a livello di cluster, quindi
è una singola risorsa per ogni controllo. Viene eseguito un controllo della macchina per ciascun nodo
di destinazione, con una risorsa per ogni nodo.
Per elencare le risorse
HealthCheck
Bare Metal per un determinato cluster, esegui il seguente comando:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del target del controllo di integrità.
La seguente risposta di esempio mostra il formato:
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
Il campo
Pass
perhealthchecks.baremetal.cluster.gke.io
indica se l'ultimo controllo di integrità è stato superato (true
) o meno (false
).
Per ulteriori informazioni sul controllo dello stato per i controlli di integrità periodici, consulta
HealthCheck
risorse personalizzate e log del controllo di integrità.
Disabilita controlli di integrità periodici
I controlli di integrità periodici sono abilitati per impostazione predefinita su tutti i cluster. Puoi disattivare
controlli di integrità periodici per un cluster impostando periodicHealthCheck.enable
su false
nella risorsa Cluster.
Per disattivare i controlli di integrità periodici:
Modifica il file di configurazione del cluster e aggiungi
periodicHealthCheck.enable
alle specifiche del cluster e imposta il valore sufalse
: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 ...
Aggiorna il cluster eseguendo il comando
bmctl update
:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che vuoi aggiornamento.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Per verificare che i controlli di integrità periodici siano stati disabilitati, esegui questo comando per confermare che
healthchecks.baremetal.cluster.gke.io
risorse sono state eliminate:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del target del controllo di integrità.
Riattiva i controlli di integrità periodici
I controlli di integrità periodici sono abilitati per impostazione predefinita su tutti i cluster. Se hai
controlli di integrità periodici disattivati, puoi riattivarli impostando il
periodicHealthCheck.enable
su true
nella risorsa cluster.
Per riattivare i controlli di integrità periodici:
Modifica il file di configurazione del cluster e aggiungi
periodicHealthCheck.enable
alle specifiche del cluster e imposta il valore sutrue
: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 ...
Aggiorna il cluster eseguendo il comando
bmctl update
:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che vuoi aggiornamento.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Per verificare che i controlli di integrità periodici siano abilitati, esegui quanto segue per confermare che Sono presenti
healthchecks.baremetal.cluster.gke.io
risorse:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del target del controllo di integrità.
Potrebbero essere necessari un paio di minuti prima che le risorse vengano visualizzate.
Controlli di integrità on demand
Le seguenti sezioni descrivono i controlli di integrità che puoi eseguire on demand
con bmctl check
. Quando utilizzi bmctl check
per eseguire controlli di integrità,
si applicano le seguenti regole:
Specifica il percorso di un cluster utente con un comando
bmctl check
del file kubeconfig per il cluster di amministrazione con il flag--kubeconfig
.I log vengono generati in una directory con timestamp nella cartella dei log del cluster su sulla workstation di amministrazione (per impostazione predefinita,
bmctl-workspace/CLUSTER_NAME/log
).Anche i log dei controlli di integrità vengono inviati a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.
Per ulteriori informazioni sulle opzioni per i comandi bmctl
, consulta il comando bmctl
riferimento.
Componenti aggiuntivi
Controlla che i componenti aggiuntivi di Kubernetes specificati per il cluster specificato siano solo tramite tastiera.
Per controllare i componenti aggiuntivi per un cluster:
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai controllare.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Per un elenco delle voci selezionate, vedi Componenti aggiuntivi nella sezione selezionata di questo documento.
Questo controllo genera file di log in un file check-addons-TIMESTAMP
nella cartella dei log del cluster sulla workstation di amministrazione. Anche i log
inviate a Cloud Logging. Per ulteriori informazioni sui log, consulta Controllo di integrità
log.
Cluster
Controlla tutti i nodi del cluster, il networking dei nodi, Kubernetes e i componenti aggiuntivi per
nel cluster specificato. Tu fornisci il nome del cluster e bmctl
cerca
di configurazione del cluster in bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml
, per impostazione predefinita.
Per controllare l'integrità di un cluster:
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai controllare.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Per un elenco dei controlli eseguiti, consulta le sezioni seguenti nella sezione di questo documento:
Questo controllo genera file di log in un file check-cluster-TIMESTAMP
nella cartella dei log del cluster sulla workstation di amministrazione. Anche i log
inviate a Cloud Logging. Per ulteriori informazioni sui log, consulta Controllo di integrità
log.
Configurazione
Controlla il file di configurazione del cluster. Questo controllo prevede che tu abbia generato
il file di configurazione e lo hai modificato per specificare la configurazione del cluster
per il tuo cluster. Lo scopo di questo comando è determinare se
eventuali impostazioni di configurazione sono errate, mancano o presentano errori di sintassi. Tu
fornisci il nome del cluster e bmctl
cerca il file di configurazione del cluster
alle ore bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml
, per impostazione predefinita.
Per controllare il file di configurazione di un cluster:
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai controllare.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Questo comando verifica la sintassi YAML del file di configurazione del cluster, l'accesso a Google Cloud e le autorizzazioni per l'account di servizio specificato di configurazione del cluster.
Questo controllo genera file di log in un file check-config-TIMESTAMP
nella cartella dei log del cluster sulla workstation di amministrazione. Anche i log
inviate a Cloud Logging. Per ulteriori informazioni sui log, consulta Controllo di integrità
log.
Connettività a Google Cloud
Verifica che tutte le macchine dei nodi cluster possano accedere a Container Registry (gcr.io
) e
l'endpoint delle API di Google (googleapis.com
).
Per verificare l'accesso del cluster alle risorse Google Cloud richieste:
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che stai controllare.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Questo controllo genera file di log in un file check-gcp-TIMESTAMP
nella cartella dei log del cluster sulla workstation di amministrazione. Anche i log
inviate a Cloud Logging. Per ulteriori informazioni sui log, consulta Controllo di integrità
log.
Kubernetes
Controlla l'integrità degli operatori Kubernetes critici in esecuzione nel piano di controllo. Questo controllo verifica che gli operatori critici funzionino correttamente e che i loro i pod non si arrestano in modo anomalo. Questo controllo di integrità non restituisce un errore se uno dei componenti del piano di controllo mancanti: restituisce errori solo se i componenti esistenti e presentano errori al momento dell'esecuzione del comando.
Per verificare l'integrità dei componenti di Kubernetes nel tuo cluster:
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che contiene l'oggetto nodi che stai controllando.ADMIN_KUBECONFIG
: il percorso di kubeconfig del cluster di amministrazione .
Per un elenco di elementi controllati, vedi Kubernetes nella sezione selezionata di questo documento.
Questo controllo genera file di log in una directory check-kubernetes-TIMESTAMP
nella cartella dei log del cluster sulla workstation di amministrazione. Anche i log
inviate a Cloud Logging. Per ulteriori informazioni sui log, consulta Controllo di integrità
log.
Nodi
Controlla le macchine dei nodi cluster per verificare che siano configurate correttamente e che dispongono di risorse e connettività sufficienti per gli upgrade del cluster operativa.
Per controllare l'integrità delle macchine nodo nel tuo cluster:
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster che contiene l'oggetto nodi che stai controllando.NODE_IP_ADDRESSES
: un elenco di indirizzi IP separati da virgole per le macchine nodo.ADMIN_KUBECONFIG
: il percorso di kubeconfig del cluster di amministrazione .
Per un elenco di ciò che viene controllato, vedi Controlli delle macchine dei nodi nella nella sezione Che cosa è stato controllato di questo documento.
Questo controllo genera file di log per ogni macchina del nodo cluster in un
Directory check-nodes-TIMESTAMP
nella cartella di log del cluster
sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per maggiori informazioni
informazioni sui log, consulta Log del controllo di integrità.
Prima del periodo di pubblicazione
Per informazioni sull'utilizzo di bmctl
per eseguire controlli preflight, vedi
Eseguire controlli preflight on demand per la creazione del cluster e
Esegui controlli preflight on demand per gli upgrade dei cluster.
Controllo preflight runtime VM
Il controllo preflight del runtime VM su Google Distributed Cloud convalida un set di macchine nodo
prerequisiti prima di utilizzare il runtime VM su Google Distributed Cloud e VM. Se
Il controllo preflight di runtime VM su Google Distributed Cloud non va a buon fine e la creazione della VM è bloccata. Quando
spec.enabled
è impostato su true
nella risorsa personalizzata VMRuntime
,
Il controllo preflight di runtime VM su Google Distributed Cloud viene eseguito automaticamente.
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
Per ulteriori informazioni, vedi Controllo preflight VM Runtime su Google Distributed Cloud.