Attivazione della modalità di manutenzione dei nodi

Quando devi riparare o eseguire la manutenzione dei nodi, devi prima impostarli in modalità di manutenzione. Esegue il graceful drain dei pod e dei carichi di lavoro esistenti, escludendo i pod di sistema critici come il server API. La modalità di manutenzione impedisce inoltre al nodo di ricevere nuove assegnazioni di 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 che venga eseguito l'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 metti 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 di espulsione 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. L'eliminazione dei nodi in questo modo offre una protezione migliore contro le interruzioni dei carichi di lavoro. Lo svuotamento dei nodi basato sull'espulsione è disponibile come 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 tutte le contaminazioni 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 l'incompatibilità baremetal.cluster.gke.io/maintenance:NoSchedule ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• Google Distributed Cloud aggiunge la 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 tutte le contaminazioni 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 sull'espulsione

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

Questa funzionalità non si trova 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 versione 1.29, lo svuotamento dei nodi basato su taint 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'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 eliminati: Pod senza spec.prorityClassName Pod che non corrispondono ad alcun nome di Container Storage Interface (CSI) noto Pod che non appartengono a un DaemonSet
2	I pod che soddisfano i seguenti criteri vengono eliminati: Pod appartenenti a un DaemonSet I pod non hanno PriorityClass Pod che non corrispondono ad alcun nome di Container Storage Interface (CSI) noto
3	I pod che soddisfano i seguenti criteri vengono eliminati: Pod con Spec.ProrityClassName Pod che non corrispondono ad alcun nome di Container Storage Interface (CSI) noto L'ordine di espulsione per i pod corrispondenti si basa su PriorityClass.value, dal più basso al più alto.
4	Attendi che CSI pulisca i montaggi PV/PVC dopo che tutti i pod sono stati rimossi. Utilizza Node.Status.VolumesInUse per indicare che tutti i volumi sono stati puliti.
5	I pod che soddisfano i seguenti criteri vengono eliminati: Pod che corrispondono a un nome Container Storage Interface (CSI) noto Questi pod devono ancora essere svuotati, perché kubelet non fornisce compatibilità con l'upgrade in loco.

Poiché lo svuotamento dei nodi basato sull'espulsione rispetta i budget per l'interruzione dei pod, in alcune circostanze le impostazioni dei budget per l'interruzione dei pod potrebbero bloccare lo svuotamento dei nodi. Per informazioni sulla risoluzione dei problemi relativi allo svuotamento del pool di nodi, vedi Controllare perché lo stato di un nodo è in fase di svuotamento da molto tempo.

Disabilita 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 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 del cluster o la manutenzione del cluster, puoi ripristinare lo svuotamento dei nodi basato sul 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. Se imposti l'annotazione su false, il comportamento predefinito non viene riattivato.

Attivare la modalità di manutenzione di un nodo

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 la risorsa personalizzata del cluster direttamente 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 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 a quella dell'esempio seguente:

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

   Questa 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 inseriti 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 disattivare la modalità di manutenzione dei nodi che vuoi rimuovere.

   Puoi modificare il file di configurazione con un editor a tua scelta oppure puoi modificare la risorsa personalizzata del cluster direttamente 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 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.

Arrestare e riavviare un cluster

Se diventa necessario spegnere un intero cluster, utilizza le istruzioni nelle sezioni seguenti per spegnere un cluster e riavviarlo in sicurezza.

Arrestare un cluster

Se chiudi un cluster che gestisce i cluster utente, devi prima chiudere 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 lo stato 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 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 dipendono dal cluster di amministrazione. Se lo stato 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.

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 lo stato STATUS di un pod non è Running, ti consigliamo vivamente di risolvere i problemi del pod e procedere solo quando tutti i pod sono Running.

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

   È importante eseguire un backup di etcd prima di arrestare il cluster in modo che possa essere ripristinato in caso di problemi durante il riavvio. Il danneggiamento 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 scrittura in etcd, il che riduce la probabilità che sia necessario riconciliare una grande quantità di scritture etcd al riavvio del cluster.

7. Attiva la modalità di manutenzione dei nodi del control plane.

   Questo passaggio impedisce scritture corrotte 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 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 etcd utilizzando SSH per connetterti a ogni nodo del control plane 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 di etcd.

   Nota: è previsto che il server API non sia disponibile una volta che i follower etcd non sono disponibili. Questo perché il server API non può gestire le richieste se il cluster etcd perde il quorum, il che è previsto durante l'arresto. Etcd riacquisisce il quorum una volta che tutti i nodi del control plane 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.

Riavvia il cluster

Per riavviare un cluster completamente spento, segui questi passaggi.

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, vedi Rimuovere un nodo dalla modalità di manutenzione.

   Nota: non è necessario disattivare la modalità di manutenzione delle macchine 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 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 arresti anomali di etcd, impedisce il riavvio corretto del cluster, prova a ripristinarlo dall'ultimo backup valido noto. Per istruzioni, vedi Ripristinare un cluster.

Modalità di fatturazione e manutenzione

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

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

• Rimuovi un singolo nodo da unpool di nodil
• Rimuovi un node pool dal cluster.
• Attiva la modalità di manutenzione di 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 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 per il cluster utente.