Attivazione della modalità di manutenzione dei nodi

Quando hai bisogno di riparare o gestire i nodi, devi prima metterli in modalità di manutenzione. Questo svuota in modo controllato i pod e i carichi di lavoro esistenti, escludendo i pod di sistema critici come il server API. Inoltre, la modalità di manutenzione impedisce al nodo 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, GKE su Bare Metal 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

GKE su Bare Metal 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 sul nodo e i pod esistenti vengono arrestati.

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

Quando utilizzi il processo della modalità di manutenzione, GKE su Bare Metal esegue le seguenti operazioni:

1,29

• GKE su Bare Metal aggiunge l'baremetal.cluster.gke.io/maintenance:NoSchedule incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• GKE su Bare Metal utilizza l'API Eviction per rimuovere 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 di interruzione tollerabile per un insieme di pod utilizzando i campi minAvailable e maxUnavailable. Lo svuotamento dei nodi in questo modo fornisce una migliore protezione contro le interruzioni dei carichi di lavoro. Lo svuotamento dei nodi basato sulla rimozione è 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 dispongono di finalizzatori. GKE su Bare Metal 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 versioni precedenti

• GKE su Bare Metal aggiunge l'baremetal.cluster.gke.io/maintenance:NoSchedule incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• GKE su Bare Metal aggiunge l'incompatibilità baremetal.cluster.gke.io/maintenance:NoExecute. Grazie all'incompatibilità NoExecute, l'kube-scheduler di GKE su Bare Metal ferma 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 dispongono di finalizzatori. GKE su Bare Metal 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 sgombero

Non sono presenti modifiche procedurali associate al passaggio allo svuotamento dei nodi basato sull'eliminazione. L'opzione interessa solo la logica di riconciliazione.

Questa funzionalità non si trova nella stessa fase di avvio 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 sull'incompatibilità eseguito da GKE su Bare Metal kube-scheduler non utilizza un algoritmo particolare per lo svuotamento dei 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 rimozione è associata a criteri specifici dei pod, come mostrato nella seguente tabella:

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

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

Disabilita lo svuotamento dei nodi basato sull'eliminazione

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

Attiva la modalità di manutenzione per un nodo

Scegli i nodi che vuoi attivare 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 sui nodi:

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

   Puoi modificare il file di configurazione con un editor a tua scelta oppure 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 che vuoi attivare in modalità di manutenzione.

   Il seguente esempio 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 aggiornata del cluster.

   GKE su Bare Metal 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).

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 all'esempio seguente:

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

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

   GKE su Bare Metal aggiunge anche 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 che vuoi rimuovere dalla modalità di manutenzione.

   Puoi modificare il file di configurazione con un editor a tua scelta oppure 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 tutto dalla modalità di manutenzione.

3. Salva e applica la configurazione aggiornata del cluster.

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

Arresta e riavvia un cluster

Se è necessario arrestare un cluster completo, segui le istruzioni riportate 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 istruzioni seguenti si applicano a tutti i tipi di cluster GKE su Bare Metal.

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 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 STATUS per 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 Effettuare il backup di un cluster.

   È importante eseguire un backup etcd prima di arrestare il cluster, in modo che possa essere ripristinato se si verificano problemi al riavvio del cluster. Il danneggiamento di Etcd, gli errori dell'hardware dei nodi, 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, imposta i nodi worker in modalità di manutenzione.

   Questo passaggio riduce al minimo la quantità di scrittura in etcd, riducendo così 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 impedisce le scritture danneggiate dei carichi di lavoro stateful durante l'arresto del nodo.

8. Spegni i nodi cluster nella seguente sequenza:

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

   3. Nodi del piano di controllo, a partire dai follower etcd fino al leader etcd

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

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

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

Riavvia il cluster

Per riavviare un cluster completamente arrestato, segui la procedura riportata di seguito.

1. Attiva le macchine nodo in 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 le macchine in modalità di manutenzione una alla volta, ma è consigliabile iniziare con un singolo nodo, assicurarsi che sia integro e poi 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, come l'arresto anomalo etcd, impedisce il corretto riavvio del cluster, prova a ripristinare il cluster dall'ultimo backup noto. Per le istruzioni, consulta Ripristinare un cluster.

Modalità di fatturazione e manutenzione

La fatturazione per GKE su Bare Metal si basa sul numero di vCPU del tuo cluster per i nodi in grado di eseguire carichi di lavoro. Quando metti un nodo in modalità di manutenzione, le incompatibilità NoExecute e NoSchedule vengono aggiunte al nodo, ma non disattivano la fatturazione. Dopo aver attivato un nodo in modalità di manutenzione, contrassegna il nodo come non pianificabile (kubectl cordon NODE_NAME) non pianificabile. Quando un nodo viene 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:

• Rimuovi un singolo nodo da un pool di nodi
• Rimuovi un pool di nodi dal cluster
• Attiva la modalità di manutenzione per un nodo 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 ciascuno dei tuoi cluster utente. Il comando non prende in considerazione se il nodo è pianificabile o meno, fornisce solo un conteggio 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 tuo cluster utente.