Controlli preflight

I controlli preflight sono una misura preventiva che ti aiuta a identificare i problemi prima di iniziare un'operazione importante del cluster, ad esempio la creazione o l'upgrade dei cluster. Quando questi controlli vengono eseguiti automaticamente prima di un'operazione, non vengono apportate modifiche ai cluster, a meno che non vengano superati tutti i controlli preflight. Puoi anche eseguire i controlli preflight su richiesta.

Questo documento descrive ogni controllo, le circostanze in cui viene eseguito automaticamente, come e quando eseguirlo manualmente e come interpretare i risultati.

In Google Distributed Cloud puoi eseguire controlli preflight per diverse situazioni:

  • Google Distributed Cloud esegue controlli preflight quando crei o esegui l'upgrade di cluster e risorse del pool di nodi con bmctl. Se i controlli non vanno a buon fine, non vengono apportate modifiche. Puoi anche bypassare questi controlli o eseguirli esplicitamente.

  • Google Distributed Cloud esegue anche controlli preflight interni quando un amministratore o un cluster ibrido crea o aggiorna le risorse Kubernetes sui cluster utente. I controlli vengono eseguiti prima che le modifiche vengano applicate ai cluster di utenti interessati. Se i controlli non vanno a buon fine, non vengono apportate modifiche.

PreflightCheck risorse personalizzate

Quando viene eseguito un controllo preflight, Google Distributed Cloud crea una PreflightCheck risorsa personalizzata. Le risorse personalizzate PreflightCheck sono permanenti e forniscono un record delle attività e dei risultati del controllo preflight.

Per recuperare le risorse personalizzate PreflightCheck:

  1. Visualizza un elenco dei controlli preflight eseguiti per un determinato cluster:

    kubectl get preflightchecks --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 risposta elenca le risorse per spazio dei nomi. Per un elenco completo, puoi eseguire kubectl get preflightchecks in tutti gli spazi dei nomi. Per ogni risorsa, la risposta mostra la data di creazione della risorsa e se i controlli preliminari sono stati superati o meno. La seguente risposta di esempio mostra le risorse PreflightCheck per lo spazio dei nomi cluster-test-admin001.

    NAMESPACE              NAME                                PASS    AGE
cluster-test-admin001   test-admin001                      true    52d
cluster-test-admin001   test-admin001jkm4q                 true    52d
cluster-test-admin001   test-admin001k79t7                 true    6d20h
cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h

  2. Recupera i dettagli di una risorsa personalizzata PreflightCheck specifica:

    kubectl describe preflightchecks --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 comando di esempio mostra una risorsa PreflightCheck per un controllo preliminare riuscito eseguito durante la creazione del cluster:

    Name:         create-cluster-20230922-175006
Namespace:    cluster-test-user001
Labels:       <none>
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         PreflightCheck
Metadata:
  Creation Timestamp:  2023-09-22T17:50:11Z
  Generation:          1
  Resource Version:    6502800
  UID:                 917daf64-963d-44b4-a1f9-c54972a39191
Spec:
  Check Image Version:  latest
  Config YAML:          ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-test-user
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: test-user001
  namespace: cluster-test-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.0
  gkeConnect:
    projectID: clusters-project
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 192.0.2.53
  ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-test-user001
spec:
  clusterName: test-user001
  nodes:
  - address: 192.0.2.54
  ...
Status:
  Checks:
    192.0.2.53:
      Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
      Message:  
      Pass:     true
    192.0.2.53-gcp:
      Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
      Message:  
      Pass:     true
    192.0.2.54:
      Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
      Message:  
      Pass:     true
    192.0.2.54-gcp:
      Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
      Message:  
      Pass:     true
    Gcp:
      Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
      Message:  
      Pass:     true
    Node - Network:
      Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
      Message:  
      Pass:     true
    Pod - Cidr:
      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
  ...
  Completion Time:                 2023-09-22T17:51:22Z
  Conditions:
    Last Transition Time:  2023-10-02T23:59:06Z
    Observed Generation:   1
    Reason:                Reconciling
    Status:                True
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  test-user001
      Nodes:
        Address:         192.0.2.54
    ...
  Pass:                  true
  Start Time:            2023-09-22T17:50:32Z
Events:                  <none>

    Nella risorsa personalizzata PreflightCheck precedente, la sezione Status contiene le seguenti informazioni:

    • La sezione Checks elenca i singoli controlli preflight eseguiti e se sono stati superati o meno. In questo esempio, sono stati eseguiti i seguenti controlli:
      • 192.0.2.53 e 192.0.2.54: controlli dei nodi (configurazione del sistema operativo, risorse e impostazioni software) per le macchine con indirizzi IP 192.0.2.53 e 192.0.2.54.
      • 192.0.2.53-gpc e 192.0.2.54-gcp: Google Cloud controlli di connettività (accesso a Container Registry e API Google) per le macchine con gli indirizzi IP 192.0.2.53 e 192.0.2.54.
      • Gcp:i controlli di connettività di Google Cloud per il cluster.
      • Node - Network: controlli di rete (connettività, funzionamento, accesso VIP e associazione porte) per il cluster.etcd
      • Pod - Cidr: l'indirizzo IP del pod controlla la presenza di indirizzi in sovrapposizione per il cluster.
    • La sezione Cluster Spec mostra la configurazione del cluster.
    • Il campo Pass mostra true, a indicare che i controlli preliminari sono stati superati collettivamente.

Log dei controlli preflight

Quando i controlli preflight vengono eseguiti a seguito di un comando bmctl, ad esempio bmctl check preflight, Google Distributed Cloud crea file di log. Ecco cosa viene generato e dove:

  • I log dei controlli di preflight vengono generati in una directory con il seguente schema di denominazione preflight-TIMESTAMP.

  • Questa directory di preflight viene creata nella directory log per il cluster nell'area di lavoro bmctl. Per impostazione predefinita, il percorso della directory log è bmctl-workspace/CLUSTER_NAME/log.

  • I log di preflight sono costituiti dai seguenti file:

    • File di log per i controlli delle macchine dei nodi, uno per ogni nodo del cluster. Questi file log vengono denominati utilizzando l'indirizzo IP del nodo. Ad esempio, un nome file potrebbe essere 192.0.2.53.

    • File di log per i controlli di accesso a Google Cloud , uno per ogni nodo del cluster. Questi file di log vengono denominati utilizzando l'indirizzo IP del nodo. Ad esempio, un nome file potrebbe essere 192.0.2.53-gcp.

    • File di log per i controlli di accesso al cluster Google Cloud , denominato gcp.

    • File di log per i controlli della rete del nodo, denominato node-network.

Se un controllo preflight non va a buon fine, questi file di log possono aiutarti a identificare e risolvere il problema.

Controlli preflight per la creazione del cluster

Quando crei cluster, Google Distributed Cloud esegue automaticamente i controlli preflight prima che vengano apportate modifiche.

Cosa viene controllato?

I controlli preflight per l'installazione verificano quanto segue:

  • Controlli delle macchine dei nodi:

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

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

    • Per Ubuntu, il gestore dei pacchetti apt è operativo e i pacchetti richiesti sono disponibili.

    • Per Red Hat Enterprise Linux, il gestore dei pacchetti dnf è operativo e i pacchetti richiesti sono disponibili.

    • Per Red Hat Enterprise Linux, Podman non è installato.

    • Le macchine Node soddisfino i requisiti minimi della CPU.

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

    • kubelet sia attivo ed eseguito sulle macchine dei nodi.

    • containerd sia attivo ed eseguito sulle macchine dei nodi.

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

    • Il DNS (Domain Name System) funzioni correttamente. Se il cluster è configurato per l'esecuzione dietro un proxy, questo controllo viene ignorato.

    • I CIDR dei pod non si sovrappongono agli indirizzi IP delle macchine dei nodi.

    • Se il cluster è configurato per utilizzare un mirror del Registro di sistema, il mirror del Registro di sistema è raggiungibile.

  • Google Cloud controlla per ogni nodo e per il cluster:

    • La raggiungibilità di Container Registry, gcr.io, è controllata. Se il cluster è configurato per utilizzare un mirror del registry, questo controllo viene ignorato.

    • Le API di Google sono raggiungibili.

  • Controlli della rete del nodo (variano in base alla configurazione del bilanciamento del carico):

    • L'IP virtuale per il server API Kubernetes è accessibile.

    • I VIP del bilanciatore del carico sono accessibili.

    • I nodi possono comunicare sulle porte richieste.

    • È stato eseguito il provisioning dell'istanza di eventi etcd e i requisiti della porta sono soddisfatti.

Se tutti i controlli vengono superati, Google Distributed Cloud crea il cluster. Per ulteriori informazioni sui requisiti per la creazione di cluster, consulta la Panoramica dei prerequisiti per l'installazione.

Esegui controlli preflight on demand per la creazione del cluster

Puoi anche eseguire i controlli preflight in modo indipendente, prima di creare un cluster. Questa operazione può essere utile perché le principali operazioni del cluster, come la sua creazione, sono molto dispendiose in termini di tempo. Identificare e risolvere i problemi separatamente prima di iniziare un'operazione importante del cluster può aiutarti con la pianificazione.

Cluster autogestiti

  • Il seguente comando convalida il file di configurazione del cluster specificato, ma non tenta di creare il cluster stesso:

    bmctl check config --cluster CLUSTER_NAME

    Sostituisci CLUSTER_NAME con il nome del cluster associato al file di configurazione che stai controllando.

  • Questo comando verifica se le macchine e la rete sono pronte per la creazione del cluster:

    bmctl check preflight --cluster CLUSTER_NAME

    Sostituisci CLUSTER_NAME con il nome del cluster che stai controllando.

Cluster utenti

  • Il seguente comando convalida il file di configurazione del cluster specificato, ma non tenta di creare il cluster stesso:

    bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

    Sostituisci quanto segue:

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

  • Il seguente comando verifica se le macchine e la rete sono pronte per la creazione del cluster:

    bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

bmctl supporta l'utilizzo di --kubeconfig come alias per il flag--admin-kubeconfig.

Controlli preflight per gli upgrade dei cluster

Quando esegui l'upgrade dei cluster, Google Distributed Cloud esegue automaticamente i controlli preflight prima di apportare modifiche.

Cosa viene controllato?

I controlli preflight per gli upgrade dei cluster verificano quanto segue:

  • Controlli delle macchine dei nodi:

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

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

    • 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 il routing dei pacchetti al gateway predefinito è presente nei nodi.

    • Il DNS (Domain Name System) funzioni correttamente. Se il cluster è configurato per l'esecuzione dietro un proxy, questo controllo viene ignorato.

    • Se il cluster è configurato per utilizzare un mirror del Registro di sistema, il mirror del Registro di sistema è raggiungibile.

    * Nessun nodo del control plane o del bilanciatore del carico è in modalità di manutenzione.

  • Google Cloud controlla per ogni nodo e per il cluster:

    • La raggiungibilità di Container Registry, gcr.io, è controllata. Se il cluster è configurato per utilizzare un mirror del registry, questo controllo viene ignorato.

    • Le API di Google sono raggiungibili.

  • Controlli della macchina:

    • 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) è integro.

    • I CIDR dei pod non si sovrappongono agli indirizzi IP delle macchine dei nodi.

  • Controlli della rete del nodo (variano in base alla configurazione del bilanciamento del carico):

    • L'IP virtuale per il server API Kubernetes è accessibile.

    • I VIP del bilanciatore del carico sono accessibili.

    • I nodi possono comunicare sulle porte richieste.

    • È stato eseguito il provisioning dell'istanza di eventi etcd e i requisiti della porta sono soddisfatti.

Quando tutti i controlli vengono superati, Google Distributed Cloud esegue l'upgrade del cluster. Per ulteriori informazioni sull'upgrade dei cluster, consulta le best practice per gli upgrade dei cluster Google Distributed Cloud e Ciclo di vita e fasi degli upgrade dei cluster.

Esegui controlli preflight on demand per gli upgrade dei cluster

Il comando bmctl check preflight ti consente di eseguire un controllo preflight prima di eseguire l'upgrade del cluster. Puoi verificare se i cluster sono pronti per un upgrade eseguendo il seguente comando di controllo preflight prima di iniziare l'upgrade:

  1. Aggiorna la versione del cluster (anthosBareMetalVersion) nel file di configurazione del cluster.

  2. Utilizza il seguente comando per verificare se i cluster sono pronti per un upgrade ed eseguire un controllo preflight:

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster di cui eseguire l'upgrade.
    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    Quando crei il controllo preflight con questo comando per testare un upgrade del cluster, nel cluster di amministrazione viene creata una risorsa personalizzata PreflightCheck.

Controlli preflight interni sui cluster esistenti

Google Distributed Cloud esegue automaticamente i controlli preflight interni quando applichi le risorse Kubernetes a un cluster esistente. Se uno o più controlli non vanno a buon fine, Google Distributed Cloud non modifica nessuno dei nodi correlati, a meno che non aggiri i controlli esplicitamente.

Ignorare i controlli preflight quando si applicano le risorse Kubernetes

Per ignorare i controlli preliminari interni quando applichi le risorse ai cluster esistenti, devi impostare il campo BypassPreflightCheck su true nel file di configurazione del cluster.

Ecco parte di un file di configurazione del cluster che mostra il campo bypassPreflightCheck impostato su true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.31.0-gke.889
...

Esegui gli ultimi controlli preflight

I controlli preflight (e i controlli di integrità) 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 preflight --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 dover prima creare o eseguire l'upgrade del cluster.

Puoi anche eseguire gli ultimi controlli di integrità di un cluster attivo per determinare se funziona correttamente. Per ulteriori informazioni, consulta Eseguire i controlli di integrità più recenti.

Ignorare i risultati dei controlli preliminari automatici

Se esegui i controlli preflight su richiesta prima di creare o eseguire l'upgrade dei cluster, puoi bypassare i controlli preflight automatici. Per bypassare i controlli preflight automatici, utilizza il flag facoltativo --force quando esegui bmctl create cluster o bmctl upgrade cluster.

Passaggi successivi