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.
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
emaxUnavailable
. 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 Cloudkube-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:
|
2 |
I pod che corrispondono ai seguenti criteri vengono rimossi:
|
3 |
I pod che corrispondono ai seguenti criteri vengono rimossi:
L'ordine di eliminazione dei pod corrispondenti si basa su
|
4 |
Attendi che CSI ripulisca i montaggi PV/PVC dopo che tutti i pod sono stati rimossi. Utilizza |
5 |
I pod che corrispondono ai seguenti criteri vengono rimossi:
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:
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.
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
Salva e applica la configurazione del cluster aggiornata.
Google Distributed Cloud inizia a mettere i nodi in modalità di manutenzione.
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.
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:
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.
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.Salva e applica la configurazione del cluster aggiornata.
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.
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 sonoReady
.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 sonoReady
.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.
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 statoRunning
.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.
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.
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.
Spegni i nodi del cluster nella seguente sequenza:
- Nodi worker
- Nodi del bilanciatore del carico del piano di controllo
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 restituiscetrue
se il nodo è la leader etcd.
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.
Attiva le macchine nodo nell'ordine inverso rispetto alla sequenza di spegnimento.
Rimuovi i nodi del piano di controllo dalla modalità di manutenzione.
Per le istruzioni, consulta Rimuovere un nodo dalla modalità di manutenzione.
Rimuovi i nodi worker dalla modalità di manutenzione.
Esegui i controlli di integrità del cluster per assicurarti che funzioni correttamente:
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
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.
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.