Attivazione della modalità di manutenzione dei nodi

Quando devi riparare o eseguire la manutenzione dei nodi, devi prima metterli in modalità di manutenzione. In questo modo, i pod e i workload esistenti vengono svuotati in modo controllato, ad eccezione dei 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 dell'upgrade. Per saperne di più sul processo di upgrade, vedi 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 ad 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 adds the baremetal.cluster.gke.io/maintenance:NoSchedule 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 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 dei workload. Lo svuotamento dei nodi basato sulla rimozione è 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 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 versioni precedenti

• Google Distributed Cloud adds the baremetal.cluster.gke.io/maintenance:NoSchedule 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. Agendo sull'incompatibilità NoExecute, kube-scheduler di Google Distributed Cloud 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.

Svuotamento basato sulla rimozione

Non sono previste modifiche procedurali associate al passaggio dallo svuotamento dei nodi basato sull'incompatibilità allo svuotamento basato sulla rimozione. Il passaggio 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 sull'incompatibilità eseguito da kube-scheduler di Google Distributed Cloud non utilizza un algoritmo specifico per svuotare i pod da un nodo. Con lo svuotamento dei nodi basato sulla rimozione, 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 tabella seguente:

Ordine di svuotamento	Criteri dei pod (devono corrispondere a tutti) e
1	Vengono rimossi i pod che soddisfano i seguenti criteri: 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	Vengono rimossi i pod che soddisfano i seguenti criteri: 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	Vengono rimossi i pod che soddisfano i seguenti criteri: Pod con Spec.ProrityClassName Pod che non corrispondono a nessun nome di Container Storage Interface (CSI) noto L'ordine di rimozione per i pod corrispondenti si basa su PriorityClass.value, dal più basso al più alto.
4	Attendi che CSI liberi spazio sui montaggi PV/PVC dopo la rimozione di tutti i pod Utilizza Node.Status.VolumesInUse per indicare che tutti i101 volumi sono stati puliti.
5	Vengono rimossi i pod che soddisfano i seguenti criteri: Pod che corrispondono a un nome di 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 sulla rimozione rispetta i PDB, le impostazioni dei PDB potrebbero bloccare lo svuotamento dei nodi in alcune circostanze. Per informazioni sulla risoluzione dei problemi relativi allo svuotamento pool di nodi, vedi Controllare perché un nodo è in stato di svuotamento da molto tempo.

Scadenza per lo svuotamento basato sulla rimozione

Quando metti i nodi in modalità di manutenzione, il sistema applica un timeout predefinito di 20 minuti (1200 secondi) per lo svuotamento dei nodi. Al termine del timeout, tutti i pod che non tollerano la modalità di manutenzione vengono rimossi e il nodo viene messo 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 a 10 minuti, aggiungi l'annotazione alla risorsa del cluster.baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600"

Lo svuotamento basato sulla rimozione a volte può superare la scadenza specificata da maintenance-mode-deadline-seconds. Se i pod rimangono bloccati in uno stato di arresto 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 con stato. Riavvia invece i nodi con i pod con stato bloccati.

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

• Requisiti per l'apertura di una richiesta di assistenza.
• Strumenti per la risoluzione dei problemi, come la configurazione dell'ambiente, i log e le metriche.
• Componenti supportati.

Disabilitare lo svuotamento dei nodi basato sulla rimozione

Lo svuotamento dei nodi basato sulla rimozione è abilitato per impostazione predefinita per i cluster con versione secondaria 1.29 e successive o per i cluster di cui è stato eseguito l'upgrade alla versione secondaria 1.29 e successive. Se lo svuotamento dei nodi basato sulla rimozione 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: "" alla risorsa del cluster.

Per ripristinare il comportamento predefinito dello svuotamento dei nodi basato sulla rimozione, rimuovi completamente l'annotazione. Se imposti l'annotazione su false, il comportamento predefinito non viene riattivato.

Mettere un nodo in modalità di manutenzione

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 scelti devono essere in stato pronto e funzionare nel cluster.

Per mettere i nodi in modalità di manutenzione:

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 direttamente la risorsa personalizzata del cluster eseguendo il comando seguente:

   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 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 il comando seguente per visualizzare 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 eventuali pod (senza una tolleranza appropriata) sul nodo.

5. Esegui il comando seguente per visualizzare 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 in questo esempio mostra che un nodo è in modalità di manutenzione.

   Google Distributed Cloud 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

Rimuovere 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 a tua scelta oppure puoi modificare direttamente la risorsa personalizzata del cluster eseguendo il comando seguente:

   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 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 arrestare un cluster completo, segui le istruzioni nelle sezioni seguenti per arrestare un cluster e riavviarlo in modo sicuro.

Arrestare 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 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 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 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 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 Eseguire il backup di un cluster.

   È importante eseguire un backup di etcd prima di arrestare il cluster, in modo che il cluster 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. Metti i nodi del control plane in modalità di manutenzione.

   Questo passaggio impedisce scritture danneggiate per i workload con stato durante l'arresto dei nodi.

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 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 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, cosa prevista durante l'arresto. Etcd riacquista il quorum quando tutti i nodi del control plane 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.

Riavviare il cluster

Segui questi passaggi per riavviare un cluster completamente spento.

1. Accendi le macchine dei nodi 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 rimuovere le macchine dalla 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 il cluster funzioni correttamente:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Se un problema, ad esempio il crashloop di etcd, impedisce il riavvio corretto del cluster, prova a ripristinare il cluster dall'ultimo backup valido noto. Per istruzioni, vedi Ripristinare 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 i workload. Quando metti un nodo in modalità di manutenzione, vengono aggiunte le incompatibilità NoExecute e NoSchedule, ma la fatturazione non viene disattivata. Dopo aver messo un nodo in modalità di manutenzione, contrassegnalo come non pianificabile (kubectl cordon NODE_NAME). Una volta che un nodo è contrassegnato come non pianificabile, il nodo 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:

• Rimuovere un singolo nodo da un pool di nodi
• Rimuovere un node pool dal cluster
• Mettere un nodo in modalità di manutenzione e contrassegnarlo come non pianificabile

Come descritto nella pagina dei prezzi, puoi utilizzare kubectl per visualizzare la capacità della vCPU (utilizzata per la fatturazione) di 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 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.