Attivazione della modalità di manutenzione dei nodi

Quando hai bisogno di riparare o mantenere i nodi, devi prima metterli in modalità di manutenzione. Questo svuota regolarmente i pod e i carichi di lavoro esistenti, escludendo di sistema importanti come il server API. La modalità di manutenzione impedisce anche al nodo di ricevere nuove assegnazioni pod. In modalità di manutenzione, puoi lavorare i nodi senza correre il rischio di interrompere il traffico dei pod.

Nota: quando esegui l'upgrade di un cluster, Google Distributed Cloud utilizza la modalità di manutenzione descritto in questa pagina per svuotare i nodi prima di eseguirne l'upgrade. Per ulteriori informazioni informazioni sul processo di upgrade, consulta Ciclo di vita e fasi del cluster .

Come funziona

Google Distributed Cloud consente di attivare la modalità di manutenzione dei nodi. Questo consente agli altri componenti del cluster di sapere correttamente che il nodo si trova modalità di manutenzione. Quando imposti un nodo in modalità di manutenzione, nessun pod aggiuntivo possono essere pianificati 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 in modalità di manutenzione, Google Distributed Cloud esegue le seguenti:

1,29

• Google Distributed Cloud aggiunge baremetal.cluster.gke.io/maintenance:NoSchedule incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• Google Distributed Cloud utilizza lo strumento Eviction API per rimuovere ogni pod. Questo metodo di svuotamento dei nodi rispetta i PodDisruptionBudget (PDB). Puoi configurare PDB per proteggere i carichi di lavoro specificando un livello tollerabile di interruzione per un insieme di pod utilizzando i campi minAvailable e maxUnavailable. Lo svuotamento dei nodi in questo modo offre una migliore protezione contro i carichi di lavoro o interruzioni del servizio. Lo svuotamento dei nodi basato su eliminazione è disponibile come GA per il rilascio 1,29.

• Viene applicato un timeout di 20 minuti per garantire che i nodi non rimangano bloccati in attesa per l'arresto dei pod. I pod potrebbero non arrestarsi se sono configurati tollerano tutte le incompatibilità o se hanno finalizzatori. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il timeout è superato, viene attivata la modalità di manutenzione del nodo. 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 incompatibilità ai nodi specificati per impedire la pianificazione di nuovi pod sul nodo.

• Google Distributed Cloud aggiunge Incompatibilità: baremetal.cluster.gke.io/maintenance:NoExecute. Seguendo le 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 per l'arresto dei pod. I pod potrebbero non arrestarsi se sono configurati tollerano tutte le incompatibilità o se hanno finalizzatori. Google Distributed Cloud tenta di arrestare tutti i pod, ma se il timeout è superato, viene attivata la modalità di manutenzione del nodo. Questo timeout impedisce ai pod in esecuzione di bloccare gli upgrade.

Drenaggio basato su espulsione

Non sono presenti modifiche procedurali associate al passaggio all'applicazione basata sull'eliminazione lo svuotamento dei nodi basato sull'incompatibilità. L'opzione influisce 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 versione 1.29, lo svuotamento dei nodi basato su incompatibilità eseguito Google Distributed Cloud kube-scheduler non utilizza un particolare per svuotare i pod da un nodo. Con lo svuotamento dei nodi basato su eliminazione, i pod vengono rimosse in un ordine specifico in base alla priorità. La priorità dell'eliminazione è associati a criteri specifici del 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: Pod senza spec.prorityClassName Pod che non corrispondono a nessuna interfaccia CSI (Container Storage Interface) nota nome Pod che non appartengono a un oggetto DaemonSet
2	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod che appartengono a un oggetto DaemonSet I pod non hanno PriorityClass Pod che non corrispondono a nessuna interfaccia CSI (Container Storage Interface) nota nome
3	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod con Spec.ProrityClassName Pod che non corrispondono a nessuna interfaccia CSI (Container Storage Interface) nota nome L'ordine di eliminazione per i pod corrispondenti si basa su PriorityClass.value, dal più basso al più alto.
4	Attendi che CSI ripulisca i montaggi PV/PVC dopo che i pod sono tutti rimosso. Utilizza Node.Status.VolumesInUse per indicare tutti vengono ripuliti.
5	I pod che corrispondono ai seguenti criteri vengono rimossi: Pod che corrispondono a un'interfaccia CSI (Container Storage Interface) nota nome Questi pod devono comunque essere svuotati, perché kubelet non fornisce e la compatibilità dell'upgrade in loco.

Poiché lo svuotamento dei nodi basato su eliminazione rispetta i PDB, le impostazioni di PDB potrebbero bloccare il nodo in alcune circostanze. Per informazioni sulla risoluzione dei problemi sul pool di nodi svuotamento, consulta Controllare perché un nodo è rimasto in stato di svuotamento per molto tempo volta.

Disabilita lo svuotamento dei nodi basato su eliminazione

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

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 nella configurazione del cluster . I nodi che scegli devono essere in stato pronto e funzionare nel in un cluster Kubernetes.

Per attivare la modalità di manutenzione dei nodi:

1. Modifica il file di configurazione del cluster per selezionare i nodi in cui inserire modalità di manutenzione.

   Puoi modificare il file di configurazione con un editor di tua scelta oppure può modificare direttamente la risorsa personalizzata del cluster eseguendo questo :

   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 a specificare un singolo indirizzo IP o un intervallo di indirizzi per i nodi che attivare la modalità di manutenzione.

   L'esempio seguente mostra come selezionare più nodi specificando un 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 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à mantengono tutti i pod (senza una tolleranza appropriata) dalla pianificazione 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 avere un aspetto simile al seguente esempio:

   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.

   Google Distributed Cloud aggiunge inoltre le seguenti incompatibilità ai nodi quando attiva la 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 da rimuovere dalla modalità di manutenzione.

   Puoi modificare il file di configurazione con un editor di tua scelta oppure può modificare direttamente la risorsa personalizzata del cluster eseguendo questo :

   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 rimuovi tutte le attività dalla 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 si rende necessario disattivare un cluster completo, segui le istruzioni riportate di seguito. 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 arrestare per prima cosa tutti i cluster utente gestiti. Le seguenti istruzioni valgono per tutti 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 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 STATUS per un nodo non è Ready, ti consigliamo vivamente di farlo risolvi i problemi del nodo e procedi solo quando tutti i nodi sono Ready.

2. Se stai arrestando un cluster utente, controlla lo stato dell'amministratore nodi cluster:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Sostituisci ADMIN_KUBECONFIG con il percorso del kubeconfig per il cluster di gestione.

   I passaggi successivi hanno una dipendenza dal cluster di amministrazione. Se STATUS per nodo non è Ready, ti consigliamo vivamente di risolvere i problemi e procedi 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 controllare.

   • 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 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 farlo risolvi i problemi del pod e procedi solo quando tutti i pod sono Running.

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

   È importante eseguire un backup etcd prima di arrestare il cluster, che il cluster possa essere ripristinato se si verificano problemi durante al riavvio del cluster. Etcd danneggiato, errori hardware del nodo, rete problemi di connettività e potenzialmente altre condizioni possono impedire che il cluster si riavvii correttamente.

6. Se stai arrestando un cluster con nodi worker, posiziona i nodi worker in modalità di manutenzione.

   Questo passaggio riduce al minimo la quantità di scrittura in etcd, riducendo al minimo la probabilità che una grande quantità di scritture etcd debba essere riconciliata quando il cluster viene riavviato.

7. Inserisci i nodi del piano di controllo modalità di manutenzione.

   Questo passaggio previene le scritture danneggiate per i carichi di lavoro stateful durante l'arresto del nodo verso il basso.

8. Spegni i nodi del cluster nella seguente sequenza:

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

   3. Nodi del piano di controllo, che iniziano con i follower etcd e terminano con leader etcd

      Se disponi di un cluster ad alta disponibilità, puoi trovare il comando etcd utilizzando SSH per connettersi 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 restituisce true se la Node è il leader etcd.

   Nota. È previsto che il server API sia inattivo una volta che i follower etcd verso il basso. Questo perché il server API non può soddisfare le richieste se l'elemento etcd perde il quorum, come previsto al momento dell'arresto. Etcd recupera quorum quando tutti i nodi del piano di controllo sono di nuovo online.

A questo punto, il cluster è completamente arrestato. Dopo aver eseguito di manutenzione, puoi riavviare il cluster come descritto .

Riavvia il cluster

Segui questi passaggi per riavviare un cluster completamente alimentato verso il basso.

1. Accendi le macchine nodo nell'ordine inverso dopo l'interruzione dell'alimentazione sequenza.

2. Rimuovi i nodi del piano di controllo dalla modalità di manutenzione.

   Per istruzioni, consulta Rimuovere un nodo dalla manutenzione .

   Nota: non è necessario disattivare la modalità di manutenzione delle macchine ma è una buona idea iniziare con un singolo nodo, assicurati che integro, per 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, ad esempio etcd arresti anomali, impedisce al cluster di riavviare correttamente, prova a ripristinare il cluster dall'ultimo prodotto noto backup. Per le istruzioni, consulta Ripristinare un cluster.

Modalità di fatturazione e manutenzione

La fatturazione per Google Distributed Cloud si basa sul numero di vCPU nel tuo cluster per i nodi in grado di eseguire carichi di lavoro. Quando metti un nodo in manutenzione modalità, le incompatibilità NoExecute e NoSchedule vengono aggiunte al nodo, ma non disattiva la fatturazione. Dopo aver attivato un nodo in modalità di manutenzione, contrassegnalo come non pianificabile (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 billing.

Importante: lo spegnimento di un nodo non ne modifica la 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
• Metti un nodo in manutenzione e contrassegnarla come non pianificabile

Come descritto nella pagina dei prezzi, puoi utilizzare kubectl per visualizzare la capacità vCPU (utilizzata per la fatturazione) di ciascuno dei tuoi utenti cluster. Il comando non considera se il nodo è pianificabili, 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 tuo nel cluster utente.