Controlli di integrità

Version 1.16 

• Ultimi
• Versione 1.16
• Versioni precedenti (non supportate)

I controlli di integrità sono un modo per testare e monitorare il funzionamento dei cluster esistenti. I controlli di integrità vengono eseguiti autonomamente, periodicamente. Puoi anche utilizzare bmctl per eseguire controlli di integrità on demand. Questo documento descrive ogni controllo, in quali circostanze viene eseguito automaticamente, come e quando eseguirlo manualmente e come interpretare i risultati.

Cosa viene controllato?

Esistono due categorie di GDCV per i controlli di integrità Bare Metal:

• Controlli delle macchine dei nodi

• Controlli a livello di cluster

Le seguenti sezioni descrivono cosa viene controllato per ciascuna categoria. Questi controlli vengono utilizzati per controlli di integrità periodici e 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 dispongono di risorse e connettività sufficienti per la creazione e gli upgrade dei cluster e le relative operazioni.

Questi controlli corrispondono alle risorse personalizzate HealthCheck Bare Metal denominate bm-system-NODE_IP_ADDRESS-machine (ad esempio bm-system-192.0.2.54-machine) in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse per il controllo di integrità, consulta HealthCheck risorse personalizzate.

Nota: anche i controlli comuni delle macchine e quelli di Google Cloud a livello di macchina vengono utilizzati anche nei controlli preflight.

I controlli delle macchine comuni comprendono quanto segue:

• Le macchine cluster utilizzano un sistema operativo supportato.

• La versione del sistema operativo è supportata.

• Il sistema operativo utilizza una versione del kernel supportata.

• Il kernel ha l'opzione del compilatore Just In Time (JIT) abilitata (CONFIG_BPF_JIT=y) BPF.

• Per Ubuntu, lo standard UFW (Uncomplicated Firewall) è 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) funziona (questo controllo viene ignorato se il cluster è configurato per l'esecuzione tramite proxy).

• Se il cluster è configurato per utilizzare un mirroring del registro, il mirroring del registro è raggiungibile.

I controlli macchina di Google Cloud sono costituiti da quanto segue:

• Container Registry, gcr.io è raggiungibile (questo controllo viene ignorato se il cluster è configurato per utilizzare un mirroring del registro).

• Le API di Google sono raggiungibili.

I controlli di integrità delle macchine sono costituiti dai seguenti elementi:

• kubelet è attivo e in esecuzione sulle macchine nodo.

• containerd è attivo e in esecuzione sulle macchine nodo.

• Lo stato dell'endpoint di integrità 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 Prerequisiti delle macchine dei nodi del cluster.

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 del cluster lato client vengono eseguiti automaticamente nell'ambito di controlli di integrità periodici. I controlli della rete non possono essere eseguiti on demand. Questi controlli corrispondono alle risorse personalizzate HealthCheck Bare Metal denominate bm-system-network che vengono eseguite nel cluster di amministrazione nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse per il controllo di integrità, consulta Le risorse personalizzate di HealthCheck.

• Se il cluster utilizza il bilanciamento del carico in bundle, i nodi nel pool di nodi di bilanciamento del carico devono avere una connettività ARP (Indirizzo di risoluzione degli indirizzi di livello 2). L'ARP è richiesto per il rilevamento VIP.

• I nodi del piano di controllo hanno le porte 2382 e 2383 aperte per essere utilizzate dall'istanza etcd-events.

Per informazioni sui protocolli e sull'utilizzo delle porte per i tuoi cluster GKE su Bare Metal, consulta 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, consulta Controlli preflight per la creazione del cluster o Controlli preflight per gli upgrade del cluster.

Kubernetes

Anche i controlli Kubernetes, che vengono eseguiti automaticamente nell'ambito di controlli preflight e di integrità periodici, possono essere eseguiti on demand. Questi controlli di integrità non restituiscono un errore se manca uno dei componenti del piano di controllo elencati. Il controllo restituisce errori solo se i componenti esistono e presentano errori al momento dell'esecuzione del comando.

Questi controlli corrispondono alle risorse personalizzate HealthCheck Bare Metal denominate bm-system-kubernetesrisorse in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per ulteriori informazioni 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 utilizzabili.

• 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 di controlli preflight e di controlli di integrità periodici e possono essere eseguiti on demand. Questo controllo di integrità non restituisce un errore se manca uno dei componenti aggiuntivi elencati. Il controllo restituisce errori solo se i componenti aggiuntivi esistono e contengono errori al momento dell'esecuzione del comando.

Questi controlli corrispondono a risorse personalizzate HealthCheck Bare Metal denominate bm-system-add-ons*risorse in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse per il controllo di integrità, consulta HealthCheck risorse personalizzate.

• I componenti Stackdriver di Cloud Logging e l'agente Connect sono utilizzabili:

  • stackdriver-log-aggregator

  • stackdriver-log-forwarder

  • stackdriver-metadata-agent

  • stackdriver-prometheus-k8

  • gke-connect-agent

• GDCV per le risorse gestite da Bare Metal non mostra 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 deviazioni della configurazione, il valore Status.Pass della risorsa personalizzata bm-system-add-ons Bare Metal HealthCheck è impostato su false. Il campo Description nella sezione Failures contiene dettagli su eventuali risorse che sono state modificate, tra cui le seguenti informazioni:

• Version: la versione API della risorsa.
• Kind: lo schema degli oggetti, ad esempio Deployment, per la risorsa.
• Namespace: lo spazio dei nomi in cui si trova la risorsa.
• Name: il nome della risorsa.
• Diff: un confronto nel formato stringa delle differenze tra il manifest della risorsa registrato e il manifest della risorsa modificata.

HealthCheck risorse personalizzate

Quando viene eseguito un controllo di integrità, GDCV per Bare Metal crea una risorsa HealthCheck personalizzata. Le risorse personalizzate HealthCheck sono permanenti e forniscono un registro strutturato delle attività e dei risultati dei controllo di integrità. Esistono due categorie di risorse personalizzate HeathCheck:

• Risorse personalizzate Bare Metal HealthCheck (API Version: baremetal.cluster.gke.io/v1): queste risorse forniscono dettagli sui controlli di integrità periodici. Queste risorse si trovano sul cluster di amministrazione negli spazi dei nomi dei cluster. Le risorse HealthCheck Bare Metal sono responsabili della creazione di cron job e job per il controllo di integrità. Queste risorse vengono costantemente aggiornate con i risultati più recenti.

• Risorse personalizzate Anthos HealthCheck (API Version: anthos.gke.io/v1): queste risorse vengono utilizzate per generare report sulle metriche del controllo di integrità. Queste risorse si trovano nello spazio dei nomi kube-system di ogni cluster. Gli aggiornamenti di queste risorse sono il migliore impegno. Se un aggiornamento non riesce a risolvere un problema, ad esempio un errore di rete temporaneo, l'errore viene ignorato.

La seguente tabella elenca i tipi di risorse create per una qualsiasi categoria HealthCheck:

Controlli di integrità Bare Metal	Controlli di integrità di GKE Enterprise	Gravità
Tipo: macchina Nome: bm-system-NODE_IP_ADDRESS-machine	Tipo: macchina Nome: bm-system-NODE_IP_ADDRESS-machine	Critico
Tipo: rete Nome: bm-system-network	Tipo: rete Nome: bm-system-network	Critico
Tipo: Kubernetes Nome: bm-system-kubernetes	Tipo: Kubernetes Nome: bm-system-kubernetes	Critico
Tipo: componenti aggiuntivi Nome: bm-system-add-ons	Tipo: componenti aggiuntivi Nome: bm-system-add-ons-add-ons Nome: bm-system-add-ons-configdrift	Facoltativo

Per recuperare lo stato HealthCheck:

1. Per leggere i risultati dei controlli di integrità periodici, puoi ottenere le risorse personalizzate associate:

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

   Sostituisci ADMIN_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

   Il seguente esempio mostra i controlli di integrità eseguiti periodicamente e se 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
   

   Nota: tutte le risorse per il controllo di integrità periodico hanno l'etichetta baremetal.cluster.gke.io/periodic-health-check=true.

2. Per leggere i dettagli relativi a un controllo di integrità specifico, usa 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 file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.

   Quando esamini la risorsa, la sezione Status: contiene i seguenti 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 come quando è stata l'ultima volta in cui un job di controllo di integrità è stato pianificato e strumentato.

   Il seguente esempio di HealthCheck serve a 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 riguarda 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
     ...
   

3. Per ottenere un elenco dei controlli di integrità per le metriche, utilizza il seguente comando:

   kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system
   

   Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di destinazione.

   Il seguente esempio mostra 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
   

Crono job per il controllo di integrità

Per i controlli di integrità periodici, ogni risorsa personalizzata HealthCheck bare metal ha un CronJob corrispondente con lo stesso nome. Questo CronJob è responsabile della pianificazione dell'esecuzione del controllo di integrità corrispondente a intervalli prestabiliti.

Per recuperare le informazioni sui cron job:

1. Recupera un elenco dei cron job eseguiti per un determinato cluster:

   kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Sostituisci quanto segue:

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
   • 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 job di controllo di integrità eseguito nella sintassi di pianificazione. Ad esempio, il job bm-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 per risolvere i problemi è utile sapere quando dovrebbero essere eseguiti.

2. Recupera i dettagli per una risorsa personalizzata CronJob specifica:

   kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Sostituisci quanto segue:

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.

   Il seguente esempio mostra un errore 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 del controllo di integrità

Quando vengono eseguiti i controlli di integrità, generano log. Sia che vengano eseguiti controlli di integrità con bmctl sia che vengano eseguiti automaticamente nell'ambito di controlli di integrità periodici, i log vengono inviati a Cloud Logging. Quando esegui controlli di integrità on demand, i file di log vengono creati in una cartella con timestamp nella directory log/ della cartella del cluster sulla 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:

1. 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 file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.

   La seguente risposta di esempio mostra alcuni pod per il 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
   

2. Recupera i log dei pod:

   kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Sostituisci quanto segue:

   • POD_NAME: il nome del pod controllo di integrità.
   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.

   L'esempio seguente mostra parte di un log del pod per un controllo di integrità della macchina nodo riuscito:

   ...
   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 log dei pod per il controllo di integrità della macchina non riuscito. L'esempio mostra che il controllo kubelet (check_kubelet_pass) non è riuscito, a indicare che kubelet 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 per il controllo di integrità vengono trasmessi a Cloud Logging e possono essere visualizzati in Esplora log. I controlli di integrità periodici sono classificati come pod nei log della console.

1. Nella console Google Cloud, vai alla pagina Esplora log nel menu Logging.

   Vai a Esplora log

2. Nel campo Query, inserisci la seguente query di base:

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

3. La finestra Risultati delle query mostra i log per i controlli di integrità delle macchine dei nodi.

Di seguito è riportato un elenco di query per i controlli di integrità periodici:

• Macchina del 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 i seguenti componenti del cluster:

• Macchina
• Rete
• Kubernetes
• Componenti aggiuntivi

Puoi controllare l'integrità del cluster esaminando le risorse personalizzate HealthCheck (healthchecks.baremetal.cluster.gke.io) Bare Metal nel cluster di amministrazione. I controlli di rete, Kubernetes e dei componenti aggiuntivi sono a livello di cluster, perciò è presente una singola risorsa per ogni controllo. Viene eseguito un controllo della macchina per ogni nodo nel cluster di destinazione, quindi esiste una risorsa per ogni nodo.

• Per elencare le risorse HealthCheck Bare Metal per un determinato cluster, esegui questo comando:

  kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
      --namespace=CLUSTER_NAMESPACE
  

  Sostituisci quanto segue:

  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

  • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster di destinazione 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 per healthchecks.baremetal.cluster.gke.io indica se l'ultimo controllo di integrità è stato superato (true) o non è stato superato (false).

Per maggiori informazioni sul controllo dello stato dei controlli di integrità periodici, consulta Risorse personalizzate di HealthCheck e Log del controllo di integrità.

Disattiva i controlli di integrità periodici

I controlli di integrità periodici sono abilitati per impostazione predefinita su tutti i cluster. Puoi disabilitare i controlli di integrità periodici per un cluster impostando il campo periodicHealthCheck.enable su false nella risorsa cluster.

Per disattivare i controlli di integrità periodici:

1. Modifica il file di configurazione del cluster, aggiungi il campo periodicHealthCheck.enable alla specifica del cluster e impostane il valore su false:

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

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

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

3. Per verificare che i controlli di integrità periodici siano stati disabilitati, esegui questo comando per confermare che le risorse healthchecks.baremetal.cluster.gke.io corrispondenti siano state eliminate:

   kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   Sostituisci quanto segue:

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster di destinazione 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 disabilitato i controlli di integrità periodici, puoi riabilitarli impostando il campo periodicHealthCheck.enable su true nella risorsa cluster.

Per riattivare i controlli di integrità periodici:

1. Modifica il file di configurazione del cluster, aggiungi il campo periodicHealthCheck.enable alla specifica del cluster e impostane il valore su true:

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

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

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

3. Per verificare che siano abilitati controlli di integrità periodici, esegui questo comando per confermare che siano presenti le risorse healthchecks.baremetal.cluster.gke.io corrispondenti:

   kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   Sostituisci quanto segue:

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster di destinazione del controllo di integrità.

   La visualizzazione delle risorse potrebbe richiedere un paio di minuti.

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 i controlli di integrità, si applicano le seguenti regole:

• Quando controlli un cluster utente con un comando bmctl check, specifica il percorso 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 sulla workstation di amministrazione (per impostazione predefinita, bmctl-workspace/CLUSTER_NAME/log).

• Anche i log del controllo di integrità vengono inviati a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Per ulteriori informazioni sulle opzioni dei comandi bmctl, consulta la documentazione di riferimento sui comandi bmctl.

Componenti aggiuntivi

Verifica che i componenti aggiuntivi di Kubernetes specificati per il cluster specificato siano utilizzabili.

• Per verificare 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 controllando.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che viene controllato, consulta la sezione Componenti aggiuntivi nella sezione Cosa viene controllato del presente documento.

Questo controllo genera file di log in una directory check-addons-TIMESTAMP nella cartella di log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Cluster

Controlla tutti i nodi del cluster, il networking dei nodi, Kubernetes e i componenti aggiuntivi per il cluster specificato. Tu fornisci il nome del cluster e bmctl cerca il file di configurazione del cluster su 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 controllando.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che viene controllato, consulta le seguenti sezioni nella sezione Cosa viene controllato di questo documento:

• Controlli a livello di macchina del nodo
• Controlli della rete
• Kubernetes
• Componenti aggiuntivi

Questo controllo genera file di log in una directory check-cluster-TIMESTAMP nella cartella di log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Configurazione

Controlla il file di configurazione del cluster. Questo controllo prevede che tu abbia generato e modificato il file di configurazione per specificare i dettagli di configurazione del cluster. Lo scopo di questo comando è determinare se un'impostazione di configurazione è errata, mancante o presenta errori di sintassi. Fornisci il nome del cluster e bmctl cerca il file di configurazione del cluster su bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml, per impostazione predefinita.

• Per controllare un file di configurazione del cluster:

  bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster che stai controllando.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Questo comando controlla la sintassi YAML del file di configurazione del cluster, l'accesso a Google Cloud e le autorizzazioni per l'account di servizio specificato nel file di configurazione del cluster.

Questo controllo genera file di log in una directory check-config-TIMESTAMP nella cartella di log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Piattaforma Google Cloud

Verifica che tutte le macchine nodo cluster possano accedere a Container Registry (gcr.io) e all'endpoint delle API di Google (googleapis.com).

• Per verificare l'accesso al 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 controllando.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Questo controllo genera file di log in una directory check-gcp-TIMESTAMP nella cartella di log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

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 pod non abbiano arresti anomali. Questo controllo di integrità non restituisce un errore in mancanza di uno qualsiasi dei componenti del piano di controllo, ma restituisce errori solo se i componenti esistono e presentano errori al momento dell'esecuzione del comando.

• Per verificare l'integrità dei componenti Kubernetes nel cluster:

  bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster che contiene i nodi che stai controllando.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che è stato controllato, vedi Kubernetes nella sezione Cosa è stato controllato del presente documento.

Questo controllo genera file di log in una directory check-kubernetes-TIMESTAMP nella cartella dei log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Nodi

Controlla le macchine dei nodi cluster per verificare che siano configurate correttamente e che dispongano di risorse e connettività sufficienti per gli upgrade e le operazioni dei cluster.

• 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 i nodi che stai controllando.
  • NODE_IP_ADDRESSES: un elenco separato da virgole di indirizzi IP per le macchine nodo.
  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che viene controllato, consulta Controlli delle macchine dei nodi nella sezione Cosa viene controllato di questo documento.

Questo controllo genera file di log per ogni macchina del nodo cluster in una directory check-nodes-TIMESTAMP nella cartella del log del cluster sulla workstation di amministrazione. I log vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log del controllo di integrità.

Preflight

Per informazioni sull'utilizzo di bmctl per eseguire i controlli preflight, consulta Eseguire controlli preflight on demand per la creazione del cluster ed Eseguire controlli preflight on demand per gli upgrade del cluster.

Controllo preflight del runtime VM

Il controllo preflight Google Distributed Cloud del runtime VM convalida un insieme di prerequisiti delle macchine nodo prima di utilizzare il runtime VM su Google Distributed Cloud e VM. Se il controllo preflight del runtime VM su Google Distributed Cloud non va a buon fine, la creazione della VM viene bloccata. Se spec.enabled è impostato su true nella risorsa personalizzata VMRuntime, il controllo preflight del 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, consulta Controllo preflight del runtime VM su Google Distributed Cloud.

Passaggi successivi

• Rilevamento dei problemi dei nodi

• Controlla la connettività del cluster con nettest

• Crea snapshot per diagnosticare i problemi dei cluster