Rimozione dei nodi bloccati dal budget per l'interruzione dei pod

In determinate condizioni, i criteri di budget per l'interruzione dei pod (PDB) possono impedire la corretta rimozione dei nodi dai pool di nodi. In queste condizioni, lo stato del nodo segnala Ready,SchedulingDisabled nonostante sia stato rimosso.

Il budget per l'interruzione dei pod è in conflitto con il numero di pod disponibili

I criteri PDB contribuiscono a garantire le prestazioni dell'app evitando che i pod scendano contemporaneamente quando apporti modifiche al sistema. Di conseguenza, i criteri PDB limitano il numero di pod non disponibili simultaneamente in un'applicazione replicata.

Tuttavia, a volte il criterio PDB può impedire le eliminazioni dei nodi che vuoi apportare e, se rimuovi un nodo, lo violi.

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, il criterio PDB ha effetto e impedisce la rimozione del nodo.

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

Soluzione: disattivare e riattivare il criterio PDB

Per risolvere il conflitto, esegui il backup e poi rimuovi il criterio PDB. Una volta che il PDB è stato eliminato, il nodo si svuota e i pod associati vengono rimossi. Dopo aver apportato le modifiche desiderate, puoi riattivare il criterio PDB.

L'esempio seguente mostra come eliminare un nodo in questa condizione, che può interessare tutti i tipi di cluster Anthos su cluster bare metal: Amministrazione, Ibrido, Autonomo e Cluster 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 cluster di amministrazione, ibrido o autonomo) variano leggermente rispetto ai comandi per l'eliminazione di un nodo da un pool di nodi del cluster utente.

Varianti dei comandi per diversi tipi di cluster

Per facilitare la lettura, prendi nota del segnaposto ${KUBECONFIG} nei comandi seguenti. A seconda del tipo di cluster, esporta il percorso kubeconfig del cluster di amministrazione (ADMIN_KUBECONFIG) o del cluster utente kubeconfig (USER_CLUSTER_CONFIG) in $(KUBECONFIG) e segui i passaggi riportati di seguito.

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

  1. (Facoltativo) Se elimini un nodo da un pool di nodi del cluster utente, esegui questo comando per estrarre il file kubeconfig del cluster utente. Nota che la variabile ADMIN_KUBECONFIG specifica il percorso del cluster di amministrazione kubeconfig, mentre la variabile USER_CLUSTER_NAME specifica il nome del cluster:

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

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

    kubectl get nodes --kubeconfig ${KUBECONFIG}

    Lo stato del nodo è simile al seguente:

    NAME        STATUS                    ROLES      AGE      VERSION
abmnewCP2   Ready                     Master     11m      v.1.18.6-gke.6600
abmnewCP3   Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
abmnewCP4   Ready                     <none>     9m18s    v.1.18.6-gke.6600

  3. Controlla i PDB nel tuo cluster:

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

    Il sistema segnala i PDB simili a quelli mostrati di seguito:

    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
 ```

  4. Ispeziona il PDB. Devi trovare una corrispondenza tra l'etichetta del pod all'interno del PDB e i pod corrispondenti nel nodo. Questa corrispondenza garantisce la disabilitazione del PDB corretto per la rimozione del nodo:

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

    Il sistema restituisce i risultati corrispondenti all'etichetta nel criterio PDB:

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

  5. Trova i pod che corrispondono all'etichetta di criterio 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 che devi rimuovere:

    stackdriver-log-aggregator-0    abmnewCP3
stackdriver-log-aggregator-1    abmnewCP3

  6. Dopo aver confermato il pod interessato, crea una copia di backup del criterio PDB, in questo caso il criterio log-aggregator:

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

  7. Elimina il criterio PDB specifico, in questo caso il criterio log-aggregator:

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

    Una volta eliminato il criterio PDB, il nodo prosegue lo svuotamento. Tuttavia, potrebbe essere necessario del tempo (fino a 30 minuti) per l'eliminazione completa del nodo, quindi continua a controllare lo stato del nodo.

    Tieni presente che, se vuoi rimuovere definitivamente il nodo e anche le risorse di archiviazione associate al nodo, puoi farlo prima di ripristinare il criterio PDB. Vedi Rimozione delle risorse di archiviazione.

  8. Ripristina il criterio PDB dalla copia:

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

  9. Verifica che i pod eliminati vengano ricreati correttamente. In questo esempio, se sono presenti 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.

Rimozione delle risorse di archiviazione dai nodi eliminati definitivamente

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

Nei comandi seguenti, tieni presente le seguenti variabili:

  • ADMIN-KUBECONFIG specifica il percorso del cluster di amministrazione
  • USER_CLUSTER_CONFIG specifica il percorso del file YAML di configurazione del cluster.

  1. Controlla e ottieni 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 volume permanente associato al nodo:

    kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}