In determinate condizioni, i criteri PodDisruptionBudgets (PDB)
possono impedire la rimozione dei nodi dai nodepool.
In queste condizioni, lo stato del nodo indica Ready,SchedulingDisabled
nonostante sia stato rimosso. Questo documento mostra come rimuovere i nodi dai cluster Google Distributed Cloud attualmente bloccati da problemi di PDB.
Questa pagina è rivolta ad amministratori, architetti e operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante e rispondono agli avvisi e alle pagine quando gli obiettivi del livello di servizio (SLO) non vengono raggiunti o le applicazioni non funzionano. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud
Il PDB è in conflitto con il numero di pod disponibili
I criteri PDB contribuiscono a garantire le prestazioni delle app impedendo l'arresto dei pod contemporaneamente quando apporti modifiche al sistema. Di conseguenza, i criteri PDB limitano il numero di pod non disponibili contemporaneamente in un'applicazione replicata.
Tuttavia, a volte il criterio PDB può impedire le eliminazioni dei nodi che vuoi eseguire se violeresti il criterio rimuovendo un nodo.
Ad esempio, un criterio 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, viene applicata la norma PDB e la rimozione del nodo viene impedita.
Analogamente, quando il criterio PDB definisce che nessun pod deve essere non disponibile
(.spec.maxUnavailable
è 0), il criterio impedisce anche l'eliminazione di eventuali nodi associati. Anche se provi a rimuovere un singolo pod alla volta, il criterio PDB
ti impedisce di eliminare il nodo interessato.
Disattivare e riattivare il criterio PDB
Per risolvere un conflitto PDB, esegui il backup e poi rimuovi la policy PDB. Una volta eliminato il PDB, il nodo viene svuotato e i pod associati vengono rimossi. A questo punto, puoi apportare le modifiche che preferisci e riattivare il criterio PDB.
Il seguente esempio mostra come eliminare un nodo in questa condizione, che può influire su 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 eliminare un nodo da un nodepool del cluster di amministrazione (per cluster di amministrazione, ibridi o autonomi) variano leggermente rispetto ai comandi per eliminare un nodo da un nodepool del cluster utente.
Per facilitare la lettura, la variabile
${KUBECONFIG}
viene utilizzata nei seguenti comandi.A seconda del tipo di cluster, esporta il percorso di kubeconfig del cluster di amministrazione (
ADMIN_KUBECONFIG
) o 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 il nodo da un cluster di amministrazione, imposta
export KUBECONFIG=ADMIN_KUBECONFIG
.
- Per eliminare un nodo da un cluster utente, imposta
(Facoltativo) Se stai eliminando un nodo da un pool di nodi del 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 il tuo ambiente cluster:
ADMIN_KUBECONFIG
: il percorso del file kubeconfig del cluster di amministrazione.CLUSTER_NAME
: il nome del cluster di cui vuoi creare uno snapshot.USER_CLUSTER_CONFIG
: il percorso del file di configurazione del cluster utente.
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 all'output di esempio riportato di seguito:
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
Controlla i PDB nel tuo cluster:
kubectl get pdb --kubeconfig ${KUBECONFIG} -A
Il sistema segnala PDB simili a quelli mostrati nell'output dell'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
Controlla il PDB. Trova una corrispondenza tra l'etichetta del pod all'interno del PDB e i pod corrispondenti nel nodo. Questa corrispondenza ti consente di disattivare il 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 nelle norme PDB:
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
Trova i pod che corrispondono all'etichetta delle norme 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 PDB e verifica il criterio PDB da rimuovere:
stackdriver-log-aggregator-0 CP3 stackdriver-log-aggregator-1 CP3
Dopo aver confermato il pod interessato, crea una copia di backup del criterio PDB. L'esempio seguente esegue il backup del criterio
log-aggregator
:kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system \ -o yaml >> log-aggregator.yaml
Elimina il criterio PDB specifico. Anche in questo caso, i seguenti esempi eliminano il criterio
log-aggregator
:kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
Dopo aver eliminato la policy PDB, il nodo procede allo svuotamento. Tuttavia, l'eliminazione completa del nodo può richiedere fino a 30 minuti. Continua a controllare lo stato del nodo per confermare che la procedura sia stata completata correttamente.
Se vuoi rimuovere definitivamente il nodo e anche le risorse di archiviazione associate al nodo, puoi farlo prima di ripristinare il criterio PDB. Per ulteriori informazioni, vedi Rimuovere le risorse di archiviazione.
Ripristina il criterio PDB dalla tua copia:
kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}
Verifica che i pod eliminati vengano ricreati correttamente. In questo esempio, se esistono due pod
stackdriver-log-aggregator-x
, vengono ricreati:kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
Se vuoi ripristinare il nodo, modifica la configurazione del pool di nodi 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.
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}'
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 la sezione Richiedere 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.