Attivazione della modalità di manutenzione dei nodi

Quando hai bisogno di riparare o gestire i nodi, devi prima attivare la modalità di manutenzione. In questo modo, i pod e i carichi di lavoro esistenti vengono svuotati automaticamente, esclusi i pod di sistema critici come il server API. La modalità di manutenzione impedisce anche al nodo di ricevere nuove assegnazioni pod. In modalità di manutenzione, puoi lavorare sui 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 saperne di più sul processo di upgrade, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Come funziona

Google Distributed Cloud consente di attivare la modalità di manutenzione dei nodi. Questo approccio consente agli altri componenti del cluster di sapere correttamente che il nodo è in modalità di manutenzione. Quando imposti un nodo in modalità di manutenzione, non è possibile pianificare pod aggiuntivi e i pod esistenti vengono arrestati.

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

Quando utilizzi il processo in modalità di manutenzione, Google Distributed Cloud esegue le seguenti operazioni:

1,29

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

• Google Distributed Cloud utilizza l'API Eviction per rimuovere ogni pod. Questo metodo di svuotamento dei nodi rispetta i PodDisruptionBudget (PDB). Puoi configurare i PBD per proteggere i carichi di lavoro specificando un livello tollerabile di interruzione per un insieme di pod utilizzando i campi minAvailable e maxUnavailable. In questo modo, lo svuotamento dei nodi offre una migliore protezione contro le interruzioni dei carichi di lavoro. Lo svuotamento dei nodi basato su eliminazione è disponibile in disponibilità generale 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 tutte le incompatibilità o se hanno finalizzatori. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il timeout viene superato, il nodo viene messo in modalità di manutenzione. Questo timeout impedisce ai pod in esecuzione di bloccare gli upgrade.

1.28 e precedenti

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

• Google Distributed Cloud aggiunge l'incompatibilità baremetal.cluster.gke.io/maintenance:NoExecute. In base all'incompatibilità 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 tutte le incompatibilità o se hanno finalizzatori. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il timeout viene superato, il nodo viene messo in modalità di manutenzione. Questo timeout impedisce ai pod in esecuzione di bloccare gli upgrade.

Drenaggio basato su espulsione

Non ci sono modifiche procedurali associate al passaggio allo svuotamento dei nodi basato su eliminazione dello svuotamento basato sull'incompatibilità. L'opzione influisce solo sulla logica di riconciliazione.

Questa funzionalità non si trova nella stessa fase di avvio per tutte le versioni supportate:

• 1.29: Disponibilità generale
• 1.28: Non disponibile
• 1.16: Non disponibile

Ordine di svuotamento

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

Ordine di svuotamento	i criteri dei pod (devono corrispondere a tutti)
1	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod senza spec.prorityClassName Pod che non corrispondono ad alcun nome CSI (Container Storage Interface) noto Pod che non appartengono a un DaemonSet
2	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod che appartengono a un oggetto DaemonSet I pod non hanno PriorityClass Pod che non corrispondono ad alcun nome CSI (Container Storage Interface) noto
3	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod con Spec.ProrityClassName Pod che non corrispondono ad alcun nome CSI (Container Storage Interface) noto L'ordine di eliminazione dei pod corrispondenti si basa su PriorityClass.value, dal più basso al più alto.
4	Attendi che CSI ripulisca i montaggi PV/PVC dopo che tutti i pod sono stati rimossi. Utilizza Node.Status.VolumesInUse per indicare che tutti i volumi vengono ripuliti.
5	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod che corrispondono a un nome CSI (Container Storage Interface) noto Questi pod devono comunque essere svuotati, perché kubelet non fornisce compatibilità con gli upgrade in loco.

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

Disabilita lo svuotamento dei nodi basato su eliminazione

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

Imposta un nodo in modalità di manutenzione

Scegli i nodi che vuoi attivare la 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 all'interno del cluster.

Per attivare la modalità di manutenzione dei nodi:

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

   Puoi modificare il file di configurazione con un editor di tua scelta oppure puoi modificare direttamente la risorsa personalizzata del cluster eseguendo questo 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 impostare in modalità di manutenzione.

   L'esempio seguente 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 questo comando per ottenere lo stato dei nodi nel tuo cluster:

   kubectl get nodes --kubeconfig=KUBECONFIG
   

   L'output è simile al seguente:

   NAME                       STATUS   ROLES           AGE     VERSION
   user-anthos-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-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 eventuali 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 avere un aspetto simile al seguente esempio:

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

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

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

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

Rimuovi 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 di tua scelta oppure puoi modificare direttamente la risorsa personalizzata del cluster eseguendo questo 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 oppure rimuovi la sezione maintenanceBlocks per rimuovere tutte le azioni dalla modalità di manutenzione.

3. Salva e applica la configurazione del cluster aggiornata.

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

Arresta e riavvia un cluster

Se è necessario arrestare un cluster completo, segui le istruzioni nelle sezioni seguenti per arrestare un cluster e ripristinarlo in modo sicuro.

Arresta un cluster

Se stai arrestando un cluster che gestisce i cluster utente, devi prima arrestare tutti i cluster utente gestiti. Le seguenti istruzioni 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 di STATUS per 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 arrestando 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 hanno una dipendenza dal cluster di amministrazione. Se 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 gli 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 per un pod non è Running, ti consigliamo vivamente di risolvere i problemi del pod e di procedere solo quando tutti i pod hanno lo stato Running.

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

   È importante eseguire un backup etcd prima di arrestare il cluster, in modo che possa essere ripristinato in caso di problemi al riavvio del cluster. Il danneggiamento dell'ETC, gli errori dell'hardware del nodo, i problemi di connettività di rete e potenzialmente altre condizioni possono impedire il corretto riavvio del cluster.

6. Se stai arrestando un cluster con nodi worker, metti i nodi worker in modalità di manutenzione.

   Questo passaggio riduce al minimo la quantità di scrittura in etcd, riducendo la probabilità che una grande quantità di scritture etcd debba essere riconciliata al riavvio del cluster.

7. Attiva la modalità di manutenzione per i nodi del piano di controllo.

   Questo passaggio previene le scritture danneggiate per i carichi di lavoro stateful durante l'arresto del nodo.

8. Spegni i nodi del cluster nella seguente sequenza:

   1. Nodi worker
   2. Nodi del bilanciatore del carico del piano di controllo

   3. I nodi del piano di controllo, iniziando con i follower etcd e terminano con il leader etcd

      Se disponi di un cluster ad alta disponibilità, puoi trovare il leader etcd utilizzando SSH per connetterti a ciascun nodo del piano di controllo ed eseguendo questo 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 nodo è la leader etcd.

   Nota: è previsto che il server API sia inattivo una volta che i follower etcd sono inattivi. Questo perché il server API non può gestire le richieste se il cluster etcd perde il quorum, come previsto al momento dell'arresto. Etcd riprende il quorum quando tutti i nodi del piano di controllo sono di nuovo online.

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

Riavvia il cluster

Per riavviare un cluster che è stato completamente spento, segui questi passaggi.

1. Attiva le macchine nodo nell'ordine inverso rispetto alla sequenza di spegnimento.

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

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

   Nota: non è necessario disattivare la modalità di manutenzione una alla volta delle macchine, ma è una buona idea iniziare con un singolo nodo, assicurarti che sia integro e 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 etcd arresto anomalo in loop, impedisce che il cluster si riavvii correttamente, prova a ripristinare il cluster dall'ultimo backup noto. Per le istruzioni, vedi Ripristinare un cluster.

Modalità di fatturazione e manutenzione

La fatturazione per Google Distributed Cloud si basa sul numero di vCPU presenti nel tuo cluster per i nodi in grado di eseguire carichi di lavoro. Quando imposti un nodo in modalità di manutenzione, le incompatibilità NoExecute e NoSchedule vengono aggiunte al nodo, ma non disattivano la fatturazione. Dopo aver attivato la modalità di manutenzione di un nodo, contrassegnalo come non pianificabile (kubectl cordon NODE_NAME). Quando un nodo è contrassegnato come non pianificabile, e le 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:

• Rimuovi un singolo nodo da un pool di nodi
• Rimuovi un pool di nodi dal cluster
• Attiva la modalità di manutenzione di un nodo e contrassegnalo come non pianificabile per renderlo non pianificabile

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

Per identificare il numero di vCPU per nodo per il tuo 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 cluster utente.