Rimozione dei nodi bloccati da PodDisruptionBudgets

La risoluzione dei conflitti di PodDisruptionBudget (PDB) consente di completare le rimozioni dei nodi dai cluster Google Distributed Cloud quando le eliminazioni sono bloccate. Quando un PDB impedisce l'espulsione dei pod, il nodo non può essere svuotato e rimane nel cluster con lo stato Ready,SchedulingDisabled, anche se lo hai rimosso dalla configurazione del pool di nodi. Per completare la rimozione del nodo, puoi identificare e disattivare temporaneamente la policy in conflitto.

Il PDB è in conflitto con il numero di pod disponibili

Le policy PDB contribuiscono a garantire le prestazioni dell'app impedendo l'interruzione dei pod contemporaneamente quando apporti modifiche al sistema. Di conseguenza, le policy PDB limitano il numero di pod non disponibili contemporaneamente in un'applicazione replicata.

Tuttavia, la policy PDB a volte può impedire le eliminazioni dei nodi che vuoi eseguire se la rimozione di un nodo viola la policy.

Ad esempio, una policy PDB può definire che nel sistema devono essere sempre disponibili due pod (.spec.minAvailable è 2). Tuttavia, se hai solo due pod e provi a rimuovere il nodo che ne contiene uno, la policy PDB entra in vigore e impedisce la rimozione del nodo.

Analogamente, quando la policy PDB definisce che nessun pod deve essere non disponibile (.spec.maxUnavailable è 0), la policy impedisce anche l'eliminazione di tutti i nodi associati. Anche se provi a rimuovere un singolo pod alla volta, la policy PDB ti impedisce di eliminare il nodo interessato.

Disattiva e riattiva la policy PDB

Per risolvere un conflitto di PDB, esegui il backup e poi rimuovi la policy PDB. Dopo l'eliminazione del PDB, il nodo viene svuotato e i pod associati vengono rimossi. Puoi quindi apportare le modifiche che vuoi e riattivare la policy PDB.

L'esempio seguente mostra come eliminare un nodo in questa condizione, che può interessare tutti i tipi di cluster Google Distributed Cloud: cluster di amministrazione, ibridi, autonomi e utente.

La stessa procedura generale funziona per tutti i tipi di cluster. Tuttavia, i comandi specifici per l'eliminazione di un nodo da un pool di nodi del cluster di amministrazione (per i cluster di amministrazione, ibridi o autonomi) variano leggermente rispetto ai comandi per l'eliminazione di un nodo da un pool di nodi del cluster utente.

1. Per facilitare la lettura, nei seguenti comandi viene utilizzata la variabile ${KUBECONFIG}.

   A seconda del tipo di cluster, esporta il percorso kubeconfig del cluster di amministrazione (ADMIN_KUBECONFIG) o kubeconfig del cluster utente (USER_CLUSTER_CONFIG) in $(KUBECONFIG) e completa i seguenti passaggi:

   • Per eliminare un nodo da un cluster utente, imposta export KUBECONFIG=USER_CLUSTER_CONFIG
   • Per eliminare un nodo da un cluster di amministrazione, imposta export KUBECONFIG=ADMIN_KUBECONFIG.

2. (Facoltativo) Se stai eliminando un nodo da un pool di nodi di un cluster utente, esegui il comando seguente per estrarre il file kubeconfig del cluster utente:

   kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
     get secret USER_CLUSTER_NAME-kubeconfig  \
     -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
   

   Sostituisci le seguenti voci con informazioni specifiche per l'ambiente del tuo cluster:

   • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
   • CLUSTER_NAME: il nome del cluster di cui vuoi acquisire uno snapshot.
   • USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

3. Dopo aver rimosso il nodo dal pool di nodi, controlla lo stato del nodo. Il nodo interessato segnala Ready, SchedulingDisabled:

   kubectl get nodes --kubeconfig ${KUBECONFIG}
   

   Lo stato del nodo è simile al seguente output di esempio:

   NAME   STATUS                    ROLES      AGE      VERSION
   CP2    Ready                     Master     11m      v.1.18.6-gke.6600
   CP3    Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
   CP4    Ready                     <none>     9m18s    v.1.18.6-gke.6600
   

4. Controlla i PDB nel tuo cluster:

   kubectl get pdb --kubeconfig ${KUBECONFIG} -A
   

   Il sistema segnala PDB simili a quelli mostrati nell'output di esempio seguente:

   NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
   gke-system    istio-ingress    1                N/A               1                     19m
   gke-system    istiod           1                N/A               1                     19m
   kube-system   coredns          1                N/A               0                     19m
   kube-system   log-aggregator   N/A              0                 0                     19m
   kube-system   prometheus       N/A              0                 0                     19m
   

5. Ispeziona il PDB. Trova una corrispondenza tra l'etichetta del pod all'interno del PDB e i pod corrispondenti nel nodo. Questa corrispondenza garantisce la disattivazione del PDB corretto per rimuovere il nodo correttamente:

   kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
   

   Il sistema restituisce i risultati delle etichette corrispondenti nella policy PDB:

   {"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
   

6. Trova i pod che corrispondono all'etichetta della policy PDB:

   kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
     -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'
   

   Il comando restituisce un elenco di pod che corrispondono all'etichetta del PDB e verifica la policy del PDB che devi rimuovere:

   stackdriver-log-aggregator-0    CP3
   stackdriver-log-aggregator-1    CP3
   

7. Dopo aver confermato il pod interessato, esegui una copia di backup della policy PDB. L'esempio seguente esegue il backup della policy log-aggregator:

   kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
     -o yaml >> log-aggregator.yaml
   

8. Elimina la policy PDB specifica. Anche in questo caso, gli esempi seguenti eliminano la policy log-aggregator:

   kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
   

   Dopo aver eliminato la policy PDB, il nodo procede con lo svuotamento. Tuttavia, l'eliminazione completa del nodo può richiedere fino a 30 minuti. Continua a controllare lo stato del nodo per confermare che il processo sia stato completato correttamente.

   Se vuoi rimuovere definitivamente il nodo e anche le risorse di archiviazione associate, puoi farlo prima di ripristinare la policy PDB. Per saperne di più, consulta Rimuovi le risorse di archiviazione.

9. Ripristina la policy PDB dalla tua copia:

   kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}
   

10. Verifica che i pod eliminati vengano ricreati correttamente. In questo esempio, se erano presenti due pod stackdriver-log-aggregator-x, vengono ricreati:

    kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
    

11. Se vuoi ripristinare il nodo, modifica la configurazione del nodepool appropriata e ripristina l'indirizzo IP del nodo.

Rimuovi le risorse di archiviazione dai nodi eliminati definitivamente

Se elimini definitivamente un nodo e non vuoi ripristinarlo nel sistema, puoi anche eliminare le risorse di archiviazione associate a quel nodo.

1. Controlla e recupera il nome del volume permanente (PV) associato al nodo:

   kubectl get pv --kubeconfig ${KUBECONFIG}  \
     -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t"}  \
     {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'
   

2. Elimina il PV associato al nodo:

   kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
   

   Sostituisci PV_NAME con il nome del volume permanente da eliminare.

Passaggi successivi

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.