Controlli di integrità del cluster

I controlli di integrità sono un modo per testare e monitorare il funzionamento dei cluster esistenti. I controlli di integrità vengono eseguiti periodicamente in modo autonomo. Puoi anche utilizzare gkectl diagnose cluster 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.

Che 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 sezioni seguenti descrivono cosa viene controllato per ogni categoria. Questi controlli vengono utilizzati sia per i controlli di integrità periodici che on demand.

Controlli delle macchine dei nodi

Questa sezione descrive cosa viene valutato dai controlli di integrità per le macchine dei nodi. Questi controlli confermano che le macchine nodo siano configurate correttamente e che dispongano di risorse e connettività sufficienti per la creazione, gli upgrade e il funzionamento 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) che vengono eseguite nel cluster di amministrazione nello spazio dei nomi del cluster. Per saperne di più sulle risorse di controllo di integrità, consulta Risorse personalizzate HealthCheck.

I controlli comuni della macchina consistono in quanto segue:

• Le macchine del 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 BPF Just In Time (JIT) attivata (CONFIG_BPF_JIT=y).

• Per Ubuntu, Uncomplicated Firewall (UFW) è disabilitato.

• Le macchine nodo soddisfano i requisiti minimi della CPU.

• Le macchine dei nodi hanno a disposizione più del 20% delle risorse della CPU.

• Le macchine dei nodi soddisfano i requisiti minimi di memoria.

• Le macchine nodo soddisfano i requisiti minimi di spazio di archiviazione su disco.

• La sincronizzazione dell'ora è configurata sui computer nodo.

• La route predefinita per il routing dei pacchetti al gateway predefinito è presente nei nodi.

• Il DNS (Domain Name System) è funzionante (questo controllo viene ignorato se il cluster è configurato per essere eseguito dietro un proxy).

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

I controlli Google Cloud della macchina consistono in quanto segue:

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

• Le API di Google sono raggiungibili.

I controlli di integrità della macchina sono costituiti da quanto segue:

• kubelet è attivo e in esecuzione sulle macchine dei nodi.

• containerd è attivo e in esecuzione sulle macchine dei nodi.

• 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 dei nodi, consulta Requisiti di archiviazione, CPU e RAM.

Controlli a livello di cluster

Questa sezione descrive cosa viene valutato dai controlli di integrità per un cluster.

Controlli predefiniti

I controlli del cluster predefiniti, eseguiti automaticamente nell'ambito dei controlli di integrità periodici, possono anche essere eseguiti on demand nell'ambito dei controlli di integrità del cluster. Questi controlli assicurano che le risorse del cluster Kubernetes siano configurate correttamente e funzionino correttamente.

Questi controlli corrispondono alle risorse personalizzate Bare Metal HealthCheck denominate bm-system-default-*in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per saperne di più sulle risorse di controllo di integrità, consulta Risorse personalizzate HealthCheck.

I controlli del cluster predefinito verificano i seguenti tipi di risorse e condizioni:

• DaemonSet

  • Le configurazioni sono valide
  • I DaemonSet sono integri

• Deployment

  • Le configurazioni sono valide
  • I deployment sono integri

• Nodo (di seguito sono riportate tutte le condizioni del nodo)

  • Stato pronto del nodo
  • kubelet disk pressure
  • kubelet memory pressure
  • Pressione dell'ID processo (PID) kubelet
  • kubelet restart frequency
  • kubelet è integro
  • Disponibilità della rete
  • funzione containerd
  • Frequenza di riavvio di containerd
  • Funzione Docker Overlay2
  • Frequenza di riavvio di Docker
  • Frequenza degli eventi di annullamento della registrazione dei dispositivi di rete
  • Deadlock del kernel
  • KubeProxy è integro
  • File system di sola lettura

• Pod

  • Le configurazioni sono valide
  • I pod sono integri
  • I container sono integri

• PodDisruptionBudget (PDB)

  • Le configurazioni sono valide
  • Funzione di runtime PDB
  • I PDB corrispondono ai pod
  • Pod non gestiti da più PDB

• Richieste di risorse

  • I pod sui nodi di destinazione hanno impostato le richieste di CPU e memoria
  • La richiesta media di risorse per nodo rientra nel limite monitorato

• Servizio

  • Le configurazioni sono valide
  • I servizi sono integri

• StatefulSet

  • Le configurazioni sono valide
  • StatefulSet

Controlli di rete

I seguenti controlli di rete dei nodi del cluster lato client vengono eseguiti automaticamente nell'ambito dei controlli di integrità periodici. I controlli di rete non possono essere eseguiti on demand. Questi controlli corrispondono alle risorse personalizzate Bare Metal HealthCheck denominate bm-system-network che vengono eseguite nel cluster di amministrazione nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse di controllo di integrità, consulta HealthCheck risorse personalizzate.

• Se il cluster utilizza il bilanciamento del carico in bundle, i nodi nel pool di nodi di bilanciamento del carico devono avere la connettività del protocollo ARP (Address Resolution Protocol) di livello 2. ARP è necessario per il rilevamento VIP.

• I nodi del control plane hanno le porte 8443 e 8444 aperte per l'utilizzo da parte di GKE Identity Service.

• I nodi del control plane hanno le porte 2382 e 2383 aperte per l'utilizzo da parte dell'istanza etcd-events.

Per informazioni sull'utilizzo di protocolli e porte per i cluster, vedi Regole proxy e firewall.

Kubernetes

I controlli Kubernetes, eseguiti automaticamente nell'ambito dei controlli preflight e periodici di integrità, possono anche 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 Bare Metal HealthCheck denominate bm-system-kubernetesin esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per saperne di più sulle risorse di controllo di integrità, consulta Risorse personalizzate HealthCheck.

• Il server API funziona.

• L'operatore anetd è configurato correttamente.

• Tutti i nodi del control plane sono operativi.

• I seguenti componenti del control plane 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 dei controlli di integrità periodici e possono essere eseguiti su richiesta. Questo controllo di integrità non restituisce un errore se uno dei componenti aggiuntivi elencati non è presente. Il controllo restituisce errori solo se i componenti aggiuntivi esistono e presentano errori al momento dell'esecuzione dei comandi.

Questi controlli corrispondono alle risorse personalizzate Bare Metal HealthCheck denominate bm-system-add-ons*in esecuzione nel cluster di amministrazione nello spazio dei nomi del cluster. Per saperne di più sulle risorse di controllo di integrità, consulta Risorse personalizzate HealthCheck.

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

  • 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 (config drift):

  • 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 variazione della configurazione, il valore della risorsa personalizzata bm-system-add-ons Bare Metal HealthCheck Status.Pass viene impostato su false. Il campo Description nella sezione Failures contiene i dettagli di tutte le risorse che sono state modificate, incluse le seguenti informazioni:

• Version: la versione dell'API per la risorsa.
• Kind: lo schema dell'oggetto, 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 in 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à, Google Distributed Cloud crea una risorsa personalizzata HealthCheck. Le risorse personalizzate HealthCheck sono persistenti e forniscono un record strutturato delle attività e dei risultati del 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 nel cluster di amministrazione negli spazi dei nomi del cluster. Le risorse Bare Metal HealthCheck sono responsabili della creazione di cron job e job di controllo di integrità. Queste risorse vengono aggiornate costantemente con i risultati più recenti.

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

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

Controlli di integrità bare metal	Anthos HealthChecks	Gravità
Tipo: predefinito Nome: bm-system-default-daemonset Nome: bm-system-default-deployment Nome: bm-system-default-node Nome: bm-system-default-pod Nome: bm-system-default-poddisruptionbudget Nome: bm-system-default-resource Nome: bm-system-default-service Nome: bm-system-default-statefulset	Tipo: predefinito Nome: bm-system-default-daemonset Nome: bm-system-default-deployment Nome: bm-system-default-node Nome: bm-system-default-pod Nome: bm-system-default-poddisruptionbudget Nome: bm-system-default-resource Nome: bm-system-default-service Nome: bm-system-default-statefulset	Critico
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 di 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
   

2. 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 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 controllo di integrità è stato superato.
   • Checks: contiene informazioni sull'ultimo controllo di integrità.
   • Failures: contiene informazioni sull'ultimo job non riuscito.
   • Periodic: contiene informazioni come l'ultima volta che è stato pianificato e strumentato un job di controllo di integrità.

   Il seguente esempio di HealthCheck riguarda 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 di controlli di integrità per le metriche, utilizza questo 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-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-default-daemonset                                             Healthy   52m
   kube-system   bm-system-default-deployment                                            Healthy   52m
   kube-system   bm-system-default-node                                                  Healthy   52m
   kube-system   bm-system-default-pod                                                   Healthy   52m
   kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
   kube-system   bm-system-default-resource                                              Healthy   52m
   kube-system   bm-system-default-service                                               Healthy   52m
   kube-system   bm-system-default-statefulset                                           Healthy   57m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-network                                                       Healthy   32m
   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 di controllo di integrità

Per i controlli di integrità periodici, ogni risorsa personalizzata bare metal HealthCheck ha un CronJob corrispondente con lo stesso nome. Questo CronJob è responsabile della pianificazione del controllo di integrità corrispondente da eseguire a intervalli prestabiliti. CronJob include anche un container ansible-runner che esegue il controllo di integrità stabilendo una connessione Secure Shell (SSH) ai nodi.

Per recuperare informazioni sui cron job:

1. Visualizza 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 di ogni esecuzione del job di controllo dell'integrità 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 è utile per la risoluzione dei problemi sapere quando devono essere eseguiti.

2. Recupera i dettagli di 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 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à

Quando vengono eseguiti i controlli di integrità, vengono generati log. Che tu esegua controlli di integrità con gkectl diagnose cluster o 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 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log.

Visualizzare i log in locale

Puoi utilizzare kubectl per visualizzare i log dei controlli di integrità periodici:

1. Recupera i pod e trova quello specifico del controllo di integrità 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 di 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 di controllo di integrità.
   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.

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

   ...
   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 del pod di controllo di integrità della macchina del nodo non riuscito. L'esempio mostra che il controllo kubelet (check_kubelet_pass) non è riuscito, il che indica 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 del controllo di integrità vengono trasmessi in streaming 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 dei controlli di integrità della macchina del nodo.

Ecco un elenco di query per i controlli di integrità periodici:

• Predefinito

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

• Node machine

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

• Predefinito
• Macchina
• Rete
• Kubernetes
• Componenti aggiuntivi

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

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

  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 è riuscito (false).

Per saperne di più sul controllo dello stato dei controlli di integrità periodici, consulta Risorse personalizzate HealthCheck e Log dei controlli di integrità.

Controlli di integrità on demand

Per eseguire controlli di integrità on demand, utilizza il comando gkectl diagnose cluster. Quando utilizzi gkectl diagnose cluster per eseguire controlli di integrità, si applicano le seguenti regole:

• Quando controlli un cluster utente con un comando gkectl diagnose cluster, 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, /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log).

• Anche i log del controllo di integrità vengono inviati a Cloud Logging. Per saperne di più sui log, consulta Log dei controlli di integrità.

Rilevamento della deviazione della configurazione

Quando viene eseguito il controllo di integrità dei componenti aggiuntivi, tra le altre cose, vengono controllate modifiche impreviste alle risorse gestite da Google Distributed Cloud. Nello specifico, il controllo valuta i manifest di queste risorse per determinare se sono state apportate modifiche da entità esterne. Questi controlli possono aiutarti a prevedere modifiche involontarie che potrebbero essere dannose per l'integrità del cluster. Forniscono inoltre preziose informazioni per la risoluzione dei problemi.

Quali manifest vengono controllati

Con poche eccezioni, il controllo di integrità dei componenti aggiuntivi esamina tutte le risorse gestite da Google Distributed Cloud per i tuoi cluster. Queste sono risorse installate e amministrate dal software Google Distributed Cloud. Esistono centinaia di queste risorse e la maggior parte dei relativi manifest viene controllata per rilevare la deriva della configurazione. I manifest sono per tutti i tipi di risorse, inclusi, a titolo esemplificativo:

ClusterRoles ClusterRoleBindings CustomResourceDefinitions DaemonSet Deployment HorizontalPodAutoscalers Emittenti

MetricsServers MutatingWebhookConfigurations Spazi dei nomi Reti NetworkLoggings PodDisruptionBudgets Provider

Ruoli RoleBindings Servizi StorageClasses ValidatingWebhookConfigurations

Quali manifest non vengono controllati

Per progettazione, escludiamo alcuni manifest dalla revisione. Ignoriamo tipi specifici di risorse, come certificati, secret e service account, per motivi di privacy e sicurezza. Il controllo dei componenti aggiuntivi ignora anche alcune risorse e alcuni campi delle risorse, perché prevediamo che vengano modificati e non vogliamo che le modifiche attivino errori di deriva della configurazione. Ad esempio, il controllo ignora i campi replicas nei Deployment, perché il gestore della scalabilità automatica potrebbe modificare questo valore.

Come escludere manifest aggiuntivi o parti di manifest dalla revisione

In generale, ti consigliamo di non apportare modifiche alle risorse gestite da Google Distributed Cloud o di ignorare le modifiche apportate. Tuttavia, sappiamo che a volte le risorse richiedono modifiche per soddisfare requisiti di casi unici o per risolvere problemi. Per questo motivo, forniamo una ConfigMap ignore-config-drift per ogni cluster nel tuo parco risorse. Utilizzi questi ConfigMap per specificare le risorse e i campi delle risorse specifici da escludere dalla valutazione.

Google Distributed Cloud crea un ConfigMap ignore-config-drift per ogni cluster. Questi ConfigMap si trovano nel cluster di gestione (amministrativo o ibrido) nello spazio dei nomi del cluster corrispondente. Ad esempio, se hai un cluster di amministrazione (admin-one) che gestisce due cluster utente (user-one e user-two), puoi trovare la risorsa configMap ignore-config-drift per il cluster user-one nel cluster admin-one nello spazio dei nomi cluster-user-one.

Per escludere una risorsa o i campi delle risorse dalla revisione:

1. Aggiungi un campo data.ignore-resources al ConfigMap ignore-config-drift.

   Questo campo accetta un array di stringhe JSON, in cui ogni stringa specifica una risorsa e, facoltativamente, campi specifici nella risorsa.

2. Specifica la risorsa e, facoltativamente, i campi specifici da ignorare come oggetto JSON nell'array di stringhe:

   L'oggetto JSON per una risorsa e i campi ha la seguente struttura:

   {
     "Version": "RESOURCE_VERSION",
     "Kind": "RESOURCE_KIND",
     "Namespace": "RESOURCE_NAMESPACE",
     "Name": "RESOURCE_NAME",
     "Fields": [
       "FIELD_1_NAME",
       "FIELD_2_NAME",
       ...
       "FIELD_N_NAME"
     ]
   }
   

   Sostituisci quanto segue:

   • RESOURCE_VERSION: (facoltativo) il valore apiVersion per la risorsa.

   • RESOURCE_KIND: (facoltativo) il valore kind per la risorsa.

   • RESOURCE_NAMESPACE: (facoltativo) il valore metadata.namespace per la risorsa.

   • RESOURCE_NAME: (facoltativo) il valore metadata.name per la risorsa.

   • FIELD_NAME: (facoltativo) specifica un array di campi delle risorse da ignorare. Se non specifichi alcun campo, il controllo dei componenti aggiuntivi ignora tutte le modifiche alla risorsa.

   Ciascuno dei campi nell'oggetto JSON è facoltativo, pertanto sono consentite varie permutazioni. Puoi escludere intere categorie di risorse oppure puoi essere molto preciso ed escludere campi specifici da una risorsa specifica.

   Ad esempio, se vuoi che il controllo dei componenti aggiuntivi ignori eventuali modifiche apportate solo alla sezione command del deployment ais sul cluster di amministrazione, il JSON potrebbe avere il seguente aspetto:

   {
     "Version": "apps/v1",
     "Kind": "Deployment",
     "Namespace": "anthos-identity-service",
     "Name": "ais",
     "Fields": [
       "command"
     ]
   }
   

   Aggiungeresti questo oggetto JSON a ignore-resources in config-drift-ignore ConfigMap come valore stringa in un array, come mostrato nell'esempio seguente:

   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"]}]'
     ...
   

   Questa impostazione di ConfigMap ti consente di aggiungere, rimuovere o modificare i campi command nel deployment ais senza attivare errori di deriva della configurazione. Tuttavia, le modifiche ai campi al di fuori della sezione command nel deployment vengono comunque rilevate dal controllo dei componenti aggiuntivi e segnalate come deriva della configurazione.

   Se vuoi escludere tutti i deployment, il valore di ignore-resources potrebbe essere simile al seguente:

   ...
   data:
     ignore-resources: '[{"Kind":"Deployment"}]'
   ...
   

   Poiché ignore-resources accetta un array di stringhe JSON, puoi specificare più pattern di esclusione. Se stai risolvendo problemi o sperimentando con i tuoi cluster e non vuoi attivare errori di deriva della configurazione, questa flessibilità di escludere sia risorse molto mirate sia campi di risorse o categorie più ampie di risorse dal rilevamento della deriva può essere utile.

Passaggi successivi

Per ulteriori informazioni, consulta le seguenti risorse:

• Creare snapshot diagnostici quando è abilitato il cluster avanzato

• Comprendere l'impatto degli errori in Google Distributed Cloud

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

• Requisiti per l'apertura di una richiesta di assistenza.
• Strumenti per aiutarti a risolvere i problemi, come log e metriche.
• Componenti supportati, versioni e funzionalità di Google Distributed Cloud per VMware (solo software).