Questa pagina è stata tradotta dall'API Cloud Translation.

Rimuovi i nodi bloccati da PodDisruptionBudget

In determinate condizioni, i criteri di PodDisruptionBudget (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. Questo documento mostra come rimuovere dai tuoi cluster Google Distributed Cloud i nodi attualmente bloccati da problemi di PDB.

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

Conflitto tra PDB e il numero di pod disponibili

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

Tuttavia, a volte il criterio PDB può impedire le eliminazioni dei nodi che vuoi effettuare in caso di violazione del criterio rimuovendo un nodo.

Ad esempio, un criterio PDB può definire che nel sistema dovrebbero 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 diventa effettivo e impedisce la rimozione del nodo.

Analogamente, quando il criterio PDB definisce che nessun pod deve essere non disponibile (.spec.maxUnavailable è 0), 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.

Disattiva e riattiva il criterio PDB

Per risolvere un conflitto PDB, esegui il backup e rimuovi il criterio PDB. Dopo aver eliminato il PDA, il nodo viene svuotato e i pod associati vengono rimossi. Puoi quindi apportare le modifiche desiderate e riattivare il criterio 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 eliminare un nodo da un pool di nodi del cluster di amministrazione (per cluster di amministrazione, ibridi o autonomi) sono leggermente diversi da quelli per eliminare un nodo da un pool di nodi del cluster utente.

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

A seconda del tipo di cluster, esporta il percorso kubeconfig (ADMIN_KUBECONFIG) del cluster utente kubeconfig (USER_CLUSTER_CONFIG) del cluster di amministrazione 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.
(Facoltativo) Se elimini un nodo da un pool di nodi del cluster utente, esegui questo comando 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 voci seguenti 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 eseguire uno snapshot.
- USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

Dopo aver rimosso il nodo dal pool di nodi, controllane lo stato. 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

Controlla i PDB nel tuo cluster:

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

Il sistema genera report 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

Esamina il PDB. Trova una corrispondenza tra l'etichetta del pod all'interno del PDB e i pod corrispondenti nel nodo. Questa corrispondenza garantisce di disabilitare il PDB corretto per rimuovere correttamente il nodo:
```
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
```
Il sistema restituisce i risultati di etichette corrispondenti nel criterio PDB:
```
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
```

Trova i pod che corrispondono all'etichetta del 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    CP3
stackdriver-log-aggregator-1    CP3

Dopo aver confermato il pod interessato, esegui 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 il criterio 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 il processo è stato completato correttamente.

Se vuoi rimuovere il nodo in modo permanente 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 appropriata del pool di nodi 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 tuo sistema, puoi anche eliminare le risorse di archiviazione associate a quel nodo.

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}'

Elimina il volume permanente 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 aiuto, contatta l'assistenza clienti Google Cloud.