Attivazione della modalità di manutenzione dei nodi

Quando devi riparare o eseguire la manutenzione dei nodi, devi prima metterli in modalità di manutenzione. In questo modo, i pod e i carichi di lavoro esistenti vengono drenati in modo corretto, esclusi i pod di sistema critici come il server API. La modalità di manutenzione impedisce inoltre al node di ricevere nuove assegnazioni di pod. In modalità di manutenzione, puoi lavorare sui tuoi nodi senza correre il rischio di interrompere il traffico dei pod.

Nota: quando esegui l'upgrade di un cluster, Google Distributed Cloud utilizza il flusso della modalità di manutenzione descritto in questa pagina per svuotare i nodi prima dell'upgrade. Per ulteriori informazioni sul processo di upgrade, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Come funziona

Google Distributed Cloud offre un modo per mettere i nodi in modalità di manutenzione. Questo approccio consente agli altri componenti del cluster di sapere correttamente che il nodo è in modalità di manutenzione. Quando un nodo viene messo in modalità di manutenzione, non è possibile pianificare altri pod sul nodo e i pod esistenti vengono interrotti.

Anziché utilizzare la modalità di manutenzione, puoi usare manualmente i comandi Kubernetes come kubectl cordon e kubectl drain su un nodo specifico.

Quando utilizzi la procedura della modalità di manutenzione, Google Distributed Cloud esegue quanto segue:

1,29

• Google Distributed Cloud aggiunge l'baremetal.cluster.gke.io/maintenance:NoSchedule incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• Google Distributed Cloud utilizza l'API Eviction per espellere ogni pod. Questo metodo di svuotamento dei nodi rispetta i PodDisruptionBudgets (PDB). Puoi configurare i PDB per proteggere i tuoi carichi di lavoro specificando un livello tollerabile di interruzione per un insieme di pod utilizzando i campi minAvailable e maxUnavailable. Lo svuotamento dei nodi in questo modo offre una protezione migliore contro le interruzioni del carico di lavoro. Lo svuotamento dei nodi in base all'espulsione è disponibile come versione GA per la release 1.29.

• Viene applicato un timeout di 20 minuti per garantire che i nodi non rimangano bloccati in attesa dell'arresto dei pod. I pod potrebbero non arrestarsi se sono configurati per tollerare tutti gli errori o se hanno finalizer. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il tempo di attesa viene superato, il nodo viene messo in modalità di manutenzione. Questo timeout impedisce ai pod in esecuzione di bloccare gli upgrade.

1.28 e versioni precedenti

• Google Distributed Cloud aggiunge l'baremetal.cluster.gke.io/maintenance:NoSchedule incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• Google Distributed Cloud aggiunge il marchio baremetal.cluster.gke.io/maintenance:NoExecute. Agendo sul marchio NoExecute, Google Distributed Cloud kube-scheduler arresta i pod e svuota il nodo. Questo metodo di svuotamento dei nodi non rispetta i PDB.

• Viene applicato un timeout di 20 minuti per garantire che i nodi non rimangano bloccati in attesa dell'arresto dei pod. I pod potrebbero non arrestarsi se sono configurati per tollerare tutti gli errori o se hanno finalizer. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il tempo di attesa viene superato, il nodo viene messo in modalità di manutenzione. Questo timeout impedisce ai pod in esecuzione di bloccare gli upgrade.

Drenaggio basato sullo sfratto

Non sono previste modifiche procedurali associate al passaggio allo svuotamento dei nodi basato sull'espulsione dallo svuotamento basato sull'inquinamento. L'opzione influisce solo sulla logica di riconciliazione.

Questa funzionalità non è nella stessa fase di lancio per tutte le versioni supportate:

• 1.29: GA
• 1.28: non disponibile
• 1.16: non disponibile

Ordine di svuotamento

Prima della release 1.29, lo svuotamento dei nodi basato su contaminazione eseguito da Google Distributed Cloud kube-scheduler non utilizza un algoritmo specifico per svuotare i pod da un nodo. Con lo svuotamento dei nodi in base all'espulsione, i pod vengono espulsi in un ordine specifico in base alla priorità. La priorità di espulsione è associata a criteri specifici del pod, come mostrato nella tabella seguente:

Ordine di svuotamento	Criteri del pod (devono corrispondere a tutti) e
1	I pod che soddisfano i seguenti criteri vengono espulsi: Pod senza spec.prorityClassName Pod che non corrispondono a nessun nome conosciuto di Container Storage Interface (CSI) Pod che non appartengono a un DaemonSet
2	I pod che soddisfano i seguenti criteri vengono espulsi: Pod che appartengono a un DaemonSet I pod non hanno PriorityClass Pod che non corrispondono a nessun nome conosciuto di Container Storage Interface (CSI)
3	I pod che soddisfano i seguenti criteri vengono espulsi: Pod con Spec.ProrityClassName Pod che non corrispondono a nessun nome conosciuto di Container Storage Interface (CSI) L'ordine di espulsione per i pod corrispondenti si basa su PriorityClass.value, dal più basso al più alto.
4	Attendi che CSI ripulisca i mount PV/PVC dopo che tutti i pod sono stati espulsi. Utilizza Node.Status.VolumesInUse per indicare che tutti i volumi sono stati ripuliti.
5	I pod che soddisfano i seguenti criteri vengono espulsi: Pod che corrispondono a un nome CSI (Container Storage Interface) conosciuto Questi pod devono ancora essere svuotati perché kubelet non fornisce la compatibilità con l'upgrade in situ.

Poiché lo svuotamento dei nodi basato sull'espulsione rispetta i PDB, le impostazioni dei PDB potrebbero bloccare lo svuotamento dei nodi in alcune circostanze. Per informazioni sulla risoluzione dei problemi relativi allo svuotamento del pool di nodi, consulta Verificare il motivo per cui lo stato di un nodo è in corso di svuotamento da molto tempo.

Disattivare lo svuotamento dei nodi basato sull'espulsione

Lo svuotamento dei nodi basato sull'espulsione è abilitato per impostazione predefinita per i cluster con versione secondaria 1.29 o per i cluster di cui è in corso l'upgrade alla versione secondaria 1.29. Se lo svuotamento dei nodi basato sull'espulsione causa problemi con gli upgrade o la manutenzione del cluster, puoi ripristinare lo svuotamento dei nodi basato sull'alterazione aggiungendo l'annotazione baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true alla risorsa del cluster.

Mettere un nodo in modalità di manutenzione

Scegli i nodi da mettere in modalità di manutenzione specificando gli intervalli IP per i nodi selezionati in maintenanceBlocks nel file di configurazione del cluster. I nodi che scegli devono essere in stato pronto e funzionare nel cluster.

Per attivare la modalità di manutenzione dei nodi:

1. Modifica il file di configurazione del cluster per selezionare i nodi da mettere in modalità di manutenzione.

   Puoi modificare il file di configurazione con un editor a tua scelta oppure puoi modificare direttamente la risorsa personalizzata del cluster eseguendo il seguente comando:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   Sostituisci quanto segue:

   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
   • CLUSTER_NAME: il nome del cluster.

2. Aggiungi la sezione maintenanceBlocks al file di configurazione del cluster per specificare un singolo indirizzo IP o un intervallo di indirizzi per i nodi da mettere in modalità di manutenzione.

   L'esempio riportato di seguito mostra come selezionare più nodi specificando un intervallo di indirizzi IP:

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. Salva e applica la configurazione del cluster aggiornata.

   Google Distributed Cloud inizia a mettere i nodi in modalità di manutenzione.

4. Esegui il seguente comando per ottenere lo stato dei nodi del cluster:

   kubectl get nodes --kubeconfig=KUBECONFIG

   L'output è simile al seguente:

   NAME                STATUS   ROLES           AGE     VERSION
   user-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   Tieni presente che i nodi sono ancora pianificabili, ma le incompatibilità impediscono la pianificazione di qualsiasi pod (senza una tolleranza appropriata) sul nodo.

5. Esegui questo comando per ottenere il numero di nodi in modalità di manutenzione:

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   La risposta dovrebbe essere simile al seguente esempio:

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   La colonna UNDERMAINTENANCE in questo esempio indica che un nodo è in modalità di manutenzione.

   Google Distributed Cloud aggiunge inoltre i seguenti taint ai nodi quando vengono messi in modalità di manutenzione:

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

Rimuovere un nodo dalla modalità di manutenzione

Per rimuovere i nodi dalla modalità di manutenzione:

1. Modifica il file di configurazione del cluster per cancellare i nodi da rimuovere dalla modalità di manutenzione.

   Puoi modificare il file di configurazione con un editor a tua scelta oppure puoi modificare direttamente la risorsa personalizzata del cluster eseguendo il seguente comando:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   Sostituisci quanto segue:

   • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
   • CLUSTER_NAME: il nome del cluster.

2. Modifica gli indirizzi IP per rimuovere nodi specifici dalla modalità di manutenzione o rimuovi la sezione maintenanceBlocks Rimuovi tutti i nodi dalla modalità di manutenzione.

3. Salva e applica la configurazione del cluster aggiornata.

4. Utilizza i comandi kubectl per controllare lo stato dei tuoi nodi.

Arresta e riavvia un cluster

Se è necessario arrestare un cluster completo, segui le istruzioni riportate nelle sezioni seguenti per arrestare un cluster e riavviarlo in sicurezza.

Arrestare un cluster

Se stai spegnendo un cluster che gestisce i cluster utente, devi prima spegnere tutti i cluster utente gestiti. Le istruzioni riportate di seguito si applicano a tutti i tipi di cluster Google Distributed Cloud.

1. Controlla lo stato di tutti i nodi del cluster:

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster.

   L'output è simile al seguente:

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   Se il valore STATUS di un nodo non è Ready, ti consigliamo vivamente di risolvere i problemi del nodo e di procedere solo quando tutti i nodi sono Ready.

2. Se stai spegnendo un cluster utente, controlla lo stato dei nodi del cluster di amministrazione:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Sostituisci ADMIN_KUBECONFIG con il percorso del file kubeconfig per il cluster di gestione.

   I passaggi successivi dipendono dal cluster di amministrazione. Se il valore STATUS per un nodo non è Ready, ti consigliamo vivamente di risolvere i problemi relativi al nodo e di procedere solo quando tutti i nodi sono Ready.

3. Controlla l'integrità del cluster che vuoi arrestare:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster che stai controllando.

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig per il cluster di gestione.

   Correggi eventuali problemi segnalati prima di procedere.

4. Per il cluster che stai arrestando, assicurati che tutti i pod etcd siano in esecuzione:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster.

   L'output è simile al seguente:

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   Se il valore STATUS di un pod non è Running, ti consigliamo vivamente di risolvere i problemi del pod e di procedere solo quando tutti i pod sono Running.

5. Esegui un backup come descritto in Eseguire il backup di un cluster.

   È importante eseguire il backup di etcd prima di arrestare il cluster in modo che possa essere ripristinato in caso di problemi durante il riavvio. La corruzione di Etcd, i guasti hardware dei nodi, i problemi di connettività di rete e potenzialmente altre condizioni possono impedire il riavvio corretto del cluster.

6. Se stai spegnendo un cluster con nodi worker, impostali in modalità di manutenzione.

   Questo passaggio riduce al minimo la quantità di scrittura in etcd, il che riduce la probabilità che sia necessario riconciliare una grande quantità di scritture in etcd al riavvio del cluster.

7. Metti i nodi del control plane in modalità di manutenzione.

   Questo passaggio impedisce le scritture danneggiate per i carichi di lavoro con stato durante l'arresto del nodo.

8. Spegni i nodi del cluster nella seguente sequenza:

   1. Nodi worker
   2. Nodi del bilanciatore del carico del control plane

   3. Nodi del control plane, a partire dai follower etcd e terminando con il leader etcd

      Se hai un cluster ad alta disponibilità (HA), puoi trovare il leader di etcd utilizzando SSH per connetterti a ogni nodo del piano di controllo ed eseguendo il seguente comando etcdctl:

      ETCDCTL_API=3 etcdctl \
          --cacert /etc/kubernetes/pki/etcd/ca.crt \
          --cert /etc/kubernetes/pki/etcd/server.crt \
          --key /etc/kubernetes/pki/etcd/server.key \
          --write-out=table endpoint status
      

      La risposta include una colonna IS LEADER, che restituisce true se il node è il leader etcd.

   Nota: è normale che il server API non sia attivo quando i follower etcd non sono attivi. Questo accade perché il server API non può gestire le richieste se il cluster etcd perde il quorum, il che è normale durante l'arresto. Etcd recupera il quorum quando tutti i nodi del piano di controllo sono di nuovo online.

A questo punto, il cluster è completamente spento. Dopo aver eseguito la manutenzione necessaria, puoi riavviare il cluster come descritto nella sezione successiva.

Riavviare il cluster

Per riavviare un cluster completamente spento, segui questi passaggi.

1. Accendi le macchine dei nodi nell'ordine inverso rispetto alla sequenza di spegnimento.

2. Rimuovi i nodi del piano di controllo dalla modalità di manutenzione.

   Per le istruzioni, vedi Rimuovere un nodo dalla modalità di manutenzione.

   Nota: non è necessario rimuovere le macchine dalla modalità di manutenzione una alla volta, ma è buona prassi iniziare con un singolo nodo, assicurarsi che sia in stato di salute, quindi aumentare lentamente il numero di nodi nel tempo.

3. Rimuovi i nodi worker dalla modalità di manutenzione.

4. Esegui i controlli di integrità del cluster per assicurarti che funzioni correttamente:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Se un problema, ad esempio un ciclo di arresto anomalo di etcd, impedisce il riavvio corretto del cluster, prova a ripristinarlo dall'ultimo backup valido. Per le istruzioni, vedi Ripristinare un cluster.

Modalità di fatturazione e manutenzione

La fatturazione di Google Distributed Cloud si basa sul numero di vCPU del tuo cluster per i nodi in grado di eseguire i carichi di lavoro. Quando attivi la modalità di manutenzione di un nodo, vengono aggiunti i taint NoExecute e NoSchedule, ma la fatturazione non viene disattivata. Dopo aver attivato la modalità di manutenzione di un nodo, contrassegnalo come non pianificabile (kubectl cordon NODE_NAME). Una volta contrassegnato come non pianificabile, il nodo e le relative vCPU associate vengono esclusi dalla fatturazione.

Importante: lo spegnimento di un nodo non ne modifica lo stato di fatturazione. Per escludere un nodo dalla fatturazione, esegui una delle seguenti azioni:

• Rimuovere un singolo nodo da un pool di nodi
• Rimuovi un node pool dal cluster
• Metti un nodo in modalità di manutenzione e contrassegnalo come non pianificabile

Come descritto nella pagina dei prezzi, puoi utilizzare kubectl per visualizzare la capacità della vCPU (utilizzata per la fatturazione) di ognuno dei tuoi cluster utente. Il comando non tiene conto del fatto che il nodo sia schedulabile o meno, ma fornisce solo un conteggio delle vCPU per nodo.

Per identificare il numero di vCPU per nodo per il cluster utente:

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

Sostituisci USER_KUBECONFIG con il percorso del file kubeconfig per il tuo cluster di utenti.