Attivazione della modalità di manutenzione dei nodi

La modalità di manutenzione ti consente di riparare e sottoporre a manutenzione i nodi con interruzioni minime dei tuoi workload. Quando aggiungi nodi alla sezione maintenanceBlocks della configurazione del cluster, Google Distributed Cloud svuota i workload in modo controllato e impedisce la pianificazione di nuovi pod su questi nodi. Quando devi portare offline un intero cluster, puoi anche arrestarlo e riavviarlo in sicurezza.

Durante gli upgrade del cluster, Google Distributed Cloud utilizza automaticamente la modalità di manutenzione per svuotare i nodi prima dell'upgrade. Per saperne di più sulla procedura di upgrade, consulta Ciclo di vita e fasi degli upgrade dei cluster.

Come funziona

Google Distributed Cloud offre un modo per 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 altri pod sul nodo 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 la procedura della modalità di manutenzione, Google Distributed Cloud esegue le seguenti operazioni:

1,29

  • Google Distributed Cloud aggiunge l'incompatibilità baremetal.cluster.gke.io/maintenance:NoSchedule 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 budget di interruzione dei pod (PDB). Puoi configurare i PDB per proteggere i tuoi workload specificando un livello di interruzione tollerabile 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 workload. Lo svuotamento dei nodi basato sull'espulsione è disponibile in 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 i taint o se hanno finalizzatori. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il timeout viene superato, il nodo viene impostato 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'incompatibilità baremetal.cluster.gke.io/maintenance:NoSchedule ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

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

Draining basato sull'espulsione

Non sono previste modifiche procedurali associate al passaggio dallo svuotamento dei nodi basato su taint a quello basato su espulsione. 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 taint eseguito da Google Distributed Cloud kube-scheduler non utilizza un algoritmo specifico per svuotare i pod da un nodo. Con lo svuotamento dei nodi basato sull'eliminazione, i pod vengono eliminati in un ordine specifico in base alla priorità. La priorità di espulsione è associata a criteri specifici dei pod, come mostrato nella tabella seguente:

Ordine di svuotamento Criteri dei pod (devono corrispondere tutti) e
1

I pod che soddisfano i seguenti criteri vengono espulsi:

  • Pod senza spec.prorityClassName
  • Pod che non corrispondono a nessun nome di Container Storage Interface (CSI) noto
  • 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 di Container Storage Interface (CSI) noto
3

I pod che soddisfano i seguenti criteri vengono espulsi:

  • Pod con Spec.ProrityClassName
  • Pod che non corrispondono a nessun nome di Container Storage Interface (CSI) noto

L'ordine di espulsione per i pod corrispondenti si basa su PriorityClass.value, dal valore più basso a quello più alto.
4

Attendi che CSI esegua la pulizia dei montaggi PV/PVC dopo l'espulsione di tutti i pod. 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 Container Storage Interface (CSI) noto

Questi pod devono comunque essere svuotati, perché kubelet non fornisce la compatibilità con l'upgrade in loco.

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

Scadenza per lo svuotamento basato sull'espulsione

Quando attivi la modalità di manutenzione sui nodi, il sistema applica un timeout predefinito di 20 minuti (1200 secondi) per lo svuotamento dei nodi. Allo scadere del timeout, tutti i pod che non tollerano la modalità di manutenzione vengono espulsi e il nodo viene impostato in modalità di manutenzione. A partire dalla versione 1.16, puoi aggiungere l'annotazione baremetal.cluster.gke.io/maintenance-mode-deadline-seconds alla risorsa del cluster per regolare la durata del timeout. Ad esempio, per modificare il timeout impostandolo su 10 minuti, aggiungi l'annotazione baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600" alla risorsa del cluster.

A volte lo svuotamento basato sull'espulsione può superare la scadenza specificata da maintenance-mode-deadline-seconds. Se i pod rimangono bloccati in uno stato di terminazione dopo il superamento della scadenza, non utilizzare kubectl con i flag --grace-period=0 --force per eliminarli forzatamente, in quanto ciò può causare il danneggiamento dei dati o problemi di split-brain per le applicazioni stateful. Riavvia invece i nodi con pod stateful bloccati.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.

Disattiva lo svuotamento dei nodi basato sull'eliminazione

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

Per ripristinare il comportamento predefinito di svuotamento dei nodi basato sull'espulsione, rimuovi completamente l'annotazione. L'impostazione dell'annotazione su false non riattiva il comportamento predefinito.

Attiva la modalità di manutenzione di un nodo

Scegli i nodi che vuoi mettere in modalità di manutenzione specificando gli intervalli IP per i nodi selezionati in maintenanceBlocks nel file di configurazione del cluster. I nodi scelti devono essere in stato pronto e funzionanti 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 di tua scelta o 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 che vuoi mettere 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 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 mostra che un nodo è in modalità di manutenzione.

    Google Distributed Cloud aggiunge anche i seguenti taint 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 di tua scelta o 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 o rimuovi la sezione maintenanceBlocks per rimuovere 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 nodi.

Arresta e riavvia un cluster

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

Arresta un cluster

Se stai disattivando un cluster che gestisce i cluster utente, devi prima disattivare 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 del 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 disattivando 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 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.

  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 del 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 Esegui il backup di un cluster.

    È importante eseguire un backup di etcd prima di arrestare il cluster, in modo che possa essere ripristinato se riscontri 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 arrestando un cluster con nodi worker, metti i nodi worker in modalità di manutenzione.

    Questo passaggio riduce al minimo la quantità di scritture in etcd, il che riduce la probabilità che un numero elevato di scritture in etcd debba essere riconciliato al riavvio del cluster.

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

    Questo passaggio impedisce scritture danneggiate per i workload 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 control plane

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

      Se hai un cluster ad alta affidabilità (HA), puoi trovare il leader etcd utilizzando SSH per connetterti a ogni nodo del control plane 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 nodo è il 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

Segui questi passaggi per riavviare un cluster che è stato completamente spento.

  1. Accendi i computer nodo nell'ordine inverso rispetto alla sequenza di spegnimento.

  2. Rimuovi i nodi del control plane dalla modalità di manutenzione.

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

  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 crashlooping di etcd, impedisce il riavvio corretto del cluster, prova a ripristinarlo dall'ultimo backup valido noto. Per istruzioni, vedi Ripristina un cluster.

Fatturazione e modalità di manutenzione

La fatturazione di Google Distributed Cloud si basa sul numero di vCPU del cluster per i nodi in grado di eseguire workload. Quando metti un nodo in modalità di manutenzione, i taint NoExecute e NoSchedule vengono aggiunti al nodo, ma non disattivano la fatturazione. Dopo aver attivato la modalità di manutenzione di un nodo, isolalo (kubectl cordon NODE_NAME) per contrassegnarlo come non pianificabile. Una volta che un nodo è contrassegnato come non pianificabile, il nodo e le vCPU associate vengono esclusi dalla fatturazione.

Come descritto nella pagina dei prezzi, puoi utilizzare kubectl per visualizzare la capacità della vCPU (utilizzata per la fatturazione) per ognuno dei tuoi cluster utente. Il comando non tiene conto del fatto che il nodo sia pianificabile o meno, ma fornisce solo un conteggio delle 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 del tuo cluster utente.