Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Controlli di integrità

I controlli di integrità sono un modo per testare e monitorare il funzionamento dei tuoi cluster esistenti. I controlli di integrità vengono eseguiti autonomamente e periodicamente. Puoi anche utilizzare bmctl per eseguire controlli di integrità on demand. Questo documento descrive ogni controllo, le circostanze in cui viene eseguito automaticamente, come e quando eseguirlo manualmente e come 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 sezioni seguenti descrivono cosa viene controllato per ogni categoria. Questi controlli vengono utilizzati sia per i controlli di integrità periodici sia per quelli 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 sono configurate correttamente e che dispongono di risorse e connettività sufficienti per la creazione, gli upgrade e il funzionamento dei cluster.

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) che vengono eseguite nel cluster amministrativo nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse di controllo di integrità, consulta HealthCheck risorse personalizzate.

I controlli comuni delle macchine sono i seguenti:

Le macchine del cluster utilizzano un sistema operativo (OS) supportato.
La versione del sistema operativo è supportata.
Il sistema operativo utilizza una versione del kernel supportata.
Nel kernel è attivata l'opzione del compilatore BPF Just In Time (CONFIG_BPF_JIT=y).
Per Ubuntu, Uncomplicated Firewall (UFW) è disattivato.
Le macchine Node soddisfino i requisiti minimi della CPU.
Le macchine di nodo dispongono di più del 20% delle risorse della CPU disponibili.
Le macchine dei nodi soddisfino i requisiti minimi di memoria.
Le macchine dei nodi soddisfino i requisiti minimi di spazio di archiviazione su disco.
La sincronizzazione dell'ora è configurata sulle macchine dei nodi.
La route predefinita per l'instradamento dei pacchetti al gateway predefinito è presente nei nodi.
Il DNS (Domain Name System) è funzionale (questo controllo viene saltato se il cluster è configurato per funzionare dietro un proxy).
Se il cluster è configurato per utilizzare un mirror del registry, il mirror del registry deve essere raggiungibile.

I controlli di Google Cloud per le macchine sono costituiti da quanto segue:

Container Registry, gcr.io è raggiungibile (questo controllo viene ignorato se il cluster è configurato per utilizzare un mirror del registry).
Le API di Google sono raggiungibili.

I controlli di integrità della macchina consistono in:

kubelet sia attivo ed eseguito sulle macchine dei nodi.
containerd sia attivo ed eseguito sulle macchine dei nodi.
Lo stato dell'endpoint di integrità dell'interfaccia di rete del contenitore (CNI) è OK.
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 di rete

I seguenti controlli della 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 su richiesta. Questi controlli corrispondono alle risorse personalizzate HealthCheck on bare metal denominate bm-system-network che vengono eseguite nel cluster di amministrazione nello spazio dei nomi del cluster. Per maggiori informazioni sulle risorse di controllo di integrità, consulta le risorse personalizzate HealthCheck.

Se il cluster utilizza il bilanciamento del carico incluso, i nodi nel pool di nodi del bilanciamento del carico devono avere connettività ARP (Address Resolution Protocol) di livello 2. L'ARP è obbligatoria per la rilevazione dei VIP.
I nodi del piano di controllo hanno le porte 8443 e 8444 aperte per l'utilizzo da parte di GKE Identity Service.
I nodi del piano di controllo hanno le porte 2382 e 2383 aperte per l'utilizzo da parte dell'istanza etcd-events.

Per informazioni sui protocolli e sull'utilizzo delle porte per i cluster, 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 di cluster o Controlli preflight per gli upgrade dei cluster.

Kubernetes

I controlli Kubernetes, che vengono eseguiti automaticamente nell'ambito dei controlli di idoneità e periodici, possono anche essere eseguiti su richiesta. Questi controlli di salute 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-kubernetesresources in esecuzione nel cluster amministrativo nello spazio dei nomi del cluster. Per ulteriori informazioni sulle risorse di controllo di integrità, consulta HealthCheck risorse personalizzate.

Il server API è in funzione.
L'operatore anetd è configurato correttamente.
Tutti i nodi del piano di controllo sono operativi.
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 dei controlli di integrità periodici e possono essere eseguiti su richiesta. 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 presentano errori al momento dell'esecuzione del comando.

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

I componenti di Stackdriver Logging 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 (deviazione di 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 deriva della configurazione, il valore Status.Pass della risorsa personalizzata bm-system-add-ons Bare MetalHealthCheck viene impostato su false. Il campo Description nella sezione Failures contiene i dettagli di tutte le risorse che sono state modificate, tra cui 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 permanenti e forniscono un record strutturato delle attività e dei risultati dei controllo di integrità. Esistono due categorie di HeathCheck risorse personalizzate:

Risorse personalizzate HealthCheck Bare Metal (API Version: baremetal.cluster.gke.io/v1): forniscono dettagli sui controlli di salute periodici. Queste risorse si trovano nel cluster amministrativo negli spazi dei nomi del cluster. Le risorse Bare Metal HealthCheck sono responsabili della creazione di job e cron job di controllo di integrità'integrità. Queste risorse vengono aggiornate costantemente con i risultati più recenti.
Risorse personalizzate HealthCheck di Anthos (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 che vengono creati per ciascuna categoria HealthCheck:

Controlli di salute bare metal Controlli di salute di GKE Enterprise Gravità

Controlli di salute bare metal	Controlli di salute 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

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:

Per leggere i risultati dei controlli di integrità periodici, puoi recuperare 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.

L'esempio seguente mostra i controlli di integrità eseguiti periodicamente e se sono stati superati nell'ultima esecuzione:

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 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à dell'integrità più recente.
Failures: contiene informazioni sul job non riuscito più recente.
Periodic: contiene informazioni come l'ultima volta che è stato pianificato e sottoposto a strumentazione un job di controllo dell'integrità.

Il seguente esempio di HealthCheck è relativo 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
  ...

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.

L'esempio seguente 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

Cron job di 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 pianificazione dell'esecuzione del corrispondente controllo di integrità a intervalli prestabiliti. CronJob include anche un contenitore ansible-runner che esegue il controllo di integrità stabilendo una connessione Secure Shell (SSH) ai nodi.

Per recuperare informazioni sui cron job:

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 job di controllo di stato eseguito in sintassi di pianificazione. Ad esempio, il job bm-system-kubernetes viene eseguito alle ore 00:17 (17) ogni ora (*/1) di ogni giorno (* * *). Gli intervalli di tempo per i controlli di salute periodici non sono modificabili, ma è utile per la risoluzione dei problemi sapere quando devono essere eseguiti.

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.

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à

Quando vengono eseguiti, i controlli di integrità generano log. I log vengono inviati a Cloud Logging indipendentemente dal fatto che i controlli di integrità vengano eseguiti con bmctl o automaticamente nell'ambito di controlli di integrità periodici. Quando esegui i controlli di integrità su richiesta, i file di log vengono creati in una cartella con timestamp nella directory log/ della cartella del cluster 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.

Visualizzare i log localmente

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

Ottieni i pod e trova il pod di controllo di integrità dell'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 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

Recupera i log del 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.

L'esempio seguente mostra parte di un log del pod per un controllo di integrità della macchina del 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 del log del pod del controllo di integrità della macchina del nodo non riuscito. Il sample mostra che il controllo di kubelet (check_kubelet_pass) non è riuscito, indicando 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 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.

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

Vai a Esplora log

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

Ecco 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 lo stato del cluster esaminando le risorse personalizzate HealthCheck (healthchecks.baremetal.cluster.gke.io) Bare Metal 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 nel cluster di destinazione, quindi esiste 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à dell'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 superato (false).

Per ulteriori informazioni su come controllare lo stato dei controlli di integrità periodici, consulta Risorse personalizzate HealthCheck e Log dei controlli di integrità.

Disattivare i controlli di integrità periodici

I controlli di integrità periodici sono abilitati per impostazione predefinita su tutti i cluster. Puoi disattivare 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:

Modifica il file di configurazione del cluster e aggiungi il campo periodicHealthCheck.enable alla specifica del cluster e imposta il relativo 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
  ...

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 da aggiornare.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
Per verificare che i controlli di integrità periodici siano stati disattivati, esegui il seguente 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à dell'integrità.

Riattivare 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 riattivarli impostando il campo periodicHealthCheck.enable su true nella risorsa Cluster.

Per riattivare i controlli di integrità periodici:

Modifica il file di configurazione del cluster e aggiungi il campo periodicHealthCheck.enable alla specifica del cluster e imposta il relativo 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
  ...

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 da aggiornare.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
Per verificare che i controlli di integrità periodici siano abilitati, esegui il seguente comando per confermare che le risorse healthchecks.baremetal.cluster.gke.io corrispondenti siano presenti:
```
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à dell'integrità.
Potrebbero essere necessari alcuni minuti prima che le risorse vengano visualizzate.

Controlli di integrità on demand

Le sezioni seguenti descrivono i controlli di integrità che puoi eseguire su richiesta 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).
I log di controllo di integrità vengono inviati anche a Cloud Logging. Per ulteriori informazioni sui log, consulta Log dei controlli di integrità.

Per ulteriori informazioni sulle altre opzioni per i comandi bmctl, consulta la guida di riferimento del comando bmctl.

Componenti aggiuntivi

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

Per controllare i componenti aggiuntivi di 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, vedi Componenti aggiuntivi nella sezione Cosa viene controllato di questo documento.

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

Cluster

Controlla tutti i nodi del cluster, la rete dei nodi, Kubernetes e i componenti aggiuntivi per il cluster specificato. Fornisci il nome del cluster e, per impostazione predefinita, bmctl cerca il file di configurazione del cluster in bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

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 della sezione Cosa viene controllato di questo documento:

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

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

Configurazione

Controlla il file di configurazione del cluster. Questo controllo presuppone che tu abbia generato il file di configurazione e lo abbia modificato per specificare i dettagli della 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, per impostazione predefinita, bmctl cerca il file di configurazione del cluster in bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

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 il account di servizio specificato nel file di configurazione del cluster.

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

Connettività a Google Cloud

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

Per controllare 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 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 dei log del cluster sulla workstation di amministrazione. I log vengono anche inviati a Cloud Logging. Per ulteriori informazioni sui log, vedi Log dei controlli 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 relativi pod non si arrestino in modo anomalo. Questo controllo di integrità non restituisce un errore se manca uno dei componenti del piano di controllo: restituisce errori solo se i componenti esistono e presentano errori al momento dell'esecuzione del comando.

Per controllare 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 node che stai controllando.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che viene controllato, consulta Kubernetes nella sezione Cosa viene controllato 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. I log vengono anche inviati a Cloud Logging. Per ulteriori informazioni sui log, vedi Log dei controlli di integrità.

Nodi

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

Per controllare l'integrità delle macchine dei nodi nel 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 node che stai controllando.
- NODE_IP_ADDRESSES: un elenco di indirizzi IP separati da virgole per le macchine dei nodi.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Per un elenco di ciò che viene controllato, consulta Controlli della macchina del nodo nella sezione Cosa viene controllato di questo documento.

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

Preflight

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

Controllo preflight del runtime della VM

Il controllo preflight del runtime delle VM su GDC convalida un insieme di prerequisiti della macchina del nodo prima di utilizzare il runtime delle VM su GDC e sulle VM. Se il controllo preflight del runtime della VM su GDC non va a buon fine, la creazione della VM viene bloccata. Quando spec.enabled è impostato su true nella risorsa personalizzata VMRuntime, il controllo preliminare dell'ambiente di runtime VM su GDC viene eseguito automaticamente.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

Per saperne di più, consulta Controllo di preflight del runtime delle VM su GDC.

Esegui gli ultimi controlli di integrità

I controlli di integrità (e i controlli preflight) vengono aggiornati man mano che vengono identificati i problemi noti. Per indicare a bmctl di eseguire i controlli dall'immagine della patch più recente della versione minore installata, utilizza il flag di opzione --check-image-version latest:

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

Sostituisci CLUSTER_NAME con il nome del cluster che stai controllando.

In questo modo puoi rilevare eventuali problemi noti identificati di recente senza eseguire prima l'upgrade del cluster.

Puoi anche eseguire i controlli preliminari più recenti prima di installare o eseguire l'upgrade di un cluster. Per ulteriori informazioni, consulta Eseguire i controlli preliminari più recenti.

Rilevamento della deviazione dalla configurazione

Quando viene eseguito il controllo di integrità dei componenti aggiuntivi, tra le altre cose, vengono verificate le 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 essere avvisato in anticipo di modifiche involontarie che potrebbero pregiudicare l'integrità del cluster. Forniscono inoltre informazioni preziose per la risoluzione dei problemi.

Quali manifest vengono controllati

Con poche eccezioni, il controllo dello stato dei componenti aggiuntivi esamina tutte le risorse gestite da Google Distributed Cloud per i tuoi cluster. Si tratta di 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 eventuali deviazioni nella configurazione. I manifest sono destinati a tutti i tipi di risorse, tra cui, 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 impostazione predefinita, escludiamo alcuni manifest dalla revisione. Per motivi di privacy e sicurezza, ignoriamo tipi specifici di risorse, come certificati, secret e account utente. Il controllo dei componenti aggiuntivi ignora anche alcune risorse e alcuni campi delle risorse, perché ci aspettiamo che vengano modificate e non vogliamo che le modifiche attiveranno errori di deriva della configurazione. Ad esempio, il controllo ignora i campi replicas in Deployment, perché il gestore della scalabilità automatica potrebbe modificare questo valore.

Come escludere dalla revisione manifest o parti di manifest aggiuntivi

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 specifici delle richieste o per risolvere problemi. Per questo motivo, forniamo un ignore-config-driftConfigMap per ogni cluster del tuo parco risorse. Utilizza 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 (amministratore o ibrido) nello spazio dei nomi del cluster corrispondente. Ad esempio, se hai un cluster di amministrazione (admin-one) che gestisce due cluster di utenti (user-one e user-two), puoi trovare la 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:

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

Questo campo accetta un array di stringhe JSON, con ogni stringa che specifica una risorsa e, facoltativamente, campi specifici della risorsa.
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 della risorsa da ignorare. Se non specifichi alcun campo, il controllo dei componenti aggiuntivi ignora tutte le modifiche alla risorsa.
Ciascuno dei campi dell'oggetto JSON è facoltativo, pertanto sono consentite varie permutazioni. Puoi escludere intere categorie di risorse oppure essere molto preciso ed escludere campi specifici da una risorsa specifica.

Ad esempio, se vuoi che il controllo dei componenti aggiuntivi ignori le modifiche solo alla sezione command del deployment ais nel tuo cluster di amministrazione, il JSON potrebbe avere il seguente aspetto:
```
{
  "Version": "apps/v1",
  "Kind": "Deployment",
  "Namespace": "anthos-identity-service",
  "Name": "ais",
  "Fields": [
    "command"
  ]
}
```
Aggiungi questo oggetto JSON a ignore-resources nel ConfigMap config-drift-ignore come valore di 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"]}]'
  ...
```
Questo esempio di impostazione 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 esterni alla sezione command nel deployment vengono comunque rilevate dal controllo dei componenti aggiuntivi e segnalate come deviazione della configurazione.

Se vuoi escludere tutti i deployment, il valore 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 evoluzione della configurazione, questa flessibilità per escludere dal rilevamento della deriva sia le risorse molto mirate sia i campi delle risorse o categorie più ampie di risorse può essere utile.

Controlli di integrità

Cosa viene controllato?

Controlli delle macchine dei nodi

Controlli a livello di cluster

Controlli di rete

Kubernetes

Componenti aggiuntivi

HealthCheck risorse personalizzate

Cron job di controllo di integrità

Log dei controlli di integrità

Visualizzare i log localmente

Visualizza i log in Cloud Logging

Controlli di integrità periodici

Disattivare i controlli di integrità periodici

Riattivare i controlli di integrità periodici

Controlli di integrità on demand

Componenti aggiuntivi

Cluster

Configurazione

Connettività a Google Cloud

Kubernetes

Nodi

Preflight

Controllo preflight del runtime della VM

Esegui gli ultimi controlli di integrità

Rilevamento della deviazione dalla configurazione

Quali manifest vengono controllati

Quali manifest non vengono controllati

Come escludere dalla revisione manifest o parti di manifest aggiuntivi

Passaggi successivi

`HealthCheck` risorse personalizzate