Questa pagina mostra come diagnosticare e risolvere i problemi che impediscono all'autoscaler del cluster di ridurre i nodi Google Kubernetes Engine (GKE).
Questa pagina è rivolta agli sviluppatori di applicazioni che vogliono risolvere una situazione negativa o imprevista con la propria app o il proprio servizio, nonché agli amministratori e agli operatori della piattaforma che vogliono evitare interruzioni nell'erogazione di prodotti e servizi.
In che modo il gestore della scalabilità automatica del cluster esegue lo scale down dei nodi
Prima di procedere con i passaggi per la risoluzione dei problemi, può essere utile capire quando il gestore della scalabilità automatica del cluster tenta di fare lo scale down i nodi. È possibile che il gestore della scalabilità automatica dei cluster non abbia eseguito fare lo scale down perché non era necessario.
Il gestore della scalabilità automatica dei cluster determina se un nodo è sottoutilizzato e idoneo per il scale down calcolando un fattore di utilizzo. Il fattore di utilizzo viene calcolato dividendo le vCPU e la memoria richieste dai pod sul nodo per le vCPU e la memoria allocabili sul nodo.
Ogni 10 secondi, il gestore della scalabilità automatica del cluster controlla il fattore di utilizzo dei nodi per verificare se è inferiore alla soglia richiesta. Se utilizzi un balanced
profilo di scalabilità automatica,
la soglia del fattore di utilizzo è 0,5. Se utilizzi il profilo
optimize-utilization, il fattore di utilizzo varia. Quando il
fattore di utilizzo è inferiore alla soglia richiesta sia per le vCPU sia per la memoria,
il gestore della scalabilità automatica dei cluster considera il nodo sottoutilizzato.
Quando un nodo è sottoutilizzato, il gestore della scalabilità automatica dei cluster lo contrassegni per la rimozione e lo monitora per i 10 minuti successivi per assicurarsi che il fattore di utilizzo rimanga al di sotto della soglia richiesta. Se il nodo è ancora sottoutilizzato dopo 10 minuti, il gestore della scalabilità automatica del cluster dovrebbe rimuoverlo.
Esempio: calcolo del fattore di utilizzo
Hai un cluster con il gestore della scalabilità automatica del cluster abilitato e utilizzi il profilo di scalabilità automatica balanced. Per un nodo di questo cluster viene eseguito il provisioning con il tipo di macchina e2-standard-4, che offre 4 vCPU e 16 GB di memoria. Un
pod su questo nodo richiede 0,5 vCPU e 10 GB di memoria, quindi lo strumento di scalabilità automatica del cluster calcola i seguenti fattori di utilizzo:
- Fattore di utilizzo delle vCPU: 0,5 vCPU / 4 vCPU = 0,125
- Fattore di utilizzo della memoria: 10 GB / 16 GB = 0,625
In questo scenario, il gestore della scalabilità automatica dei cluster non considererebbe questo nodo sottoutilizzato perché il fattore di utilizzo della memoria (0,625) supera la soglia di 0,5. Anche se l'utilizzo delle vCPU è basso, l'utilizzo della memoria più elevato impedisce fare lo scale down per garantire che rimangano disponibili risorse sufficienti per il carico di lavoro del pod.
Controllare se il problema è causato da una limitazione
Se osservi un cluster con un utilizzo ridotto per più di 10 minuti e non viene eseguito il ridimensionamento verso il basso, assicurati che il problema non sia causato da uno dei limiti del gestore della scalabilità automatica dei cluster.
Visualizza errori
Se il problema non è stato causato da una limitazione, spesso puoi diagnosticarne la causa visualizzando i messaggi di errore:
Se hai già visualizzato un messaggio di errore, consulta la tabella dei messaggi di errore per ricevere consigli su come risolvere il problema.
Se non hai ancora visualizzato un messaggio, utilizza una delle seguenti opzioni:
- Problemi risalenti a meno di 72 ore fa: visualizza le notifiche di errore nella console Google Cloud.
- Problemi risalenti a più di 72 ore fa: visualizza gli errori negli eventi in Cloud Logging.
Visualizzare gli errori nelle notifiche
Se il problema che hai riscontrato si è verificato meno di 72 ore fa, visualizza le notifiche relative agli errori nella console Google Cloud. Queste notifiche forniscono informazioni preziose sul motivo per cui il gestore della scalabilità automatica dei cluster non ha eseguito fare lo scale down e offrono consigli su come risolvere l'errore e visualizzare i log pertinenti per ulteriori accertamenti.
Per visualizzare le notifiche nella console Google Cloud, completa i seguenti passaggi:
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Esamina la colonna Notifiche. Le seguenti notifiche sono associate a problemi di fare lo scale down:
Can't scale down nodesScale down blocked by pod
Fai clic sulla notifica pertinente per visualizzare un riquadro con i dettagli sulla causa del problema e le azioni consigliate per risolverlo.
(Facoltativo) Per visualizzare i log relativi a questo evento, fai clic su Log. Questa azione ti indirizza a Logs Explorer con una query precompilata per aiutarti a esaminare ulteriormente l'evento di scalabilità. Per scoprire di più sul funzionamento degli eventi di fare lo scale down, consulta Visualizzare gli eventi di scalabilità automatica del cluster.
Se i problemi persistono dopo aver esaminato i consigli riportati nella notification, consulta le tabelle dei messaggi di errore per ulteriore assistenza.
Visualizzare gli errori negli eventi
Se il problema che hai osservato si è verificato più di 72 ore fa, visualizza gli eventi in Cloud Logging. Quando si verifica un errore, spesso viene registrato in un evento.
Per visualizzare i log del gestore della scalabilità automatica dei cluster nella console Google Cloud, completa i seguenti passaggi:
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Seleziona il nome del cluster che vuoi esaminare per visualizzarne la pagina Dettagli cluster.
Nella pagina Dettagli cluster, fai clic sulla scheda Log.
Nella scheda Log, fai clic sulla scheda Log di Autoscaler per visualizzare i log.
(Facoltativo) Per applicare filtri più avanzati per restringere i risultati, fai clic sul pulsante con la freccia sul lato destro della pagina per visualizzare i log in Esplora log.
Per scoprire di più sul funzionamento degli eventi di fare lo scale down, consulta Visualizzare gli eventi di scalabilità automatica del cluster. Per un esempio di come utilizzare Cloud Logging, consulta il seguente esempio di risoluzione dei problemi.
Esempio: risolvere un problema risalente a più di 72 ore fa
L'esempio seguente mostra come esaminare e risolvere un problema relativo al ridimensionamento verso il basso di un cluster.
Scenario:
Una settimana fa, stavi esaminando la dashboard di GKE Enterprise e hai notato che il tuo cluster ha utilizzato solo il 10% della CPU e della memoria. Nonostante l'utilizzo ridotto, il gestore della scalabilità automatica dei cluster non ha eliminato il nodo come previsto. Quando guardi la dashboard, il problema sembra essere stato risolto, ma decidi di scoprire cosa è successo per evitare che si ripresenti.
Indagine:
- Poiché il problema si è verificato più di 72 ore fa, lo esamini utilizzando Cloud Logging anziché esaminare i messaggi di notifica.
- In Cloud Logging puoi trovare i dettagli di registrazione per gli eventi di scalabilità automatica del cluster, come descritto in Visualizzare gli errori negli eventi.
- Nel campo
nodesToBeRemoved, cerca gli eventiscaleDownche contengono i nodi appartenenti al cluster in cui stai eseguendo la ricerca. Puoi filtrare le voci di log, ad esempio in base a un determinato valore di campo JSON. Scopri di più nella sezione Query avanzate sui log. - Non trovi eventi
scaleDown. Tuttavia, se hai trovato un eventoscaleDown, puoi cercare un eventoeventResultcontenente ileventIdassociato. Puoi quindi cercare un errore nel campoerrorMsg. Decidi di continuare la tua indagine cercando gli eventi
noScaleDownche contengono il nodo che stai esaminando nel campo dei nodi.Trovi un evento
noScaleDownche contiene il motivo per cui il tuo nodo non è stato ridotto. L'ID messaggio è"no.scale.down.node.pod.not.backed.by.controller"e esiste un singolo parametro:"test-single-pod".
Risoluzione:
Consulta la tabella dei messaggi di errore e scopri che questo messaggio indica che il pod sta bloccando fare lo scale down perché non è supportato da un controller. Scopri che una soluzione è aggiungere un'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" al pod. Esamini test-single-pod e noti che un collega ha aggiunto l'annotazione e, dopo averla applicata, il gestore della scalabilità automatica dei cluster ha ridotto correttamente le dimensioni del cluster. Decidi di aggiungere l'annotazione a tutti gli altri pod in cui è possibile farlo in sicurezza per evitare che il problema si ripresenti.
Risolvere gli errori di fare lo scale down
Una volta identificato l'errore, utilizza le seguenti tabelle per capire cosa lo ha causato e come risolverlo.
Errori di riduzione
Puoi trovare i messaggi di eventi di errore per gli eventi scaleDown nell'evento eventResult corrispondente, nel campo resultInfo.results[].errorMsg.
| Messaggio di evento | Dettagli | Parametro | Attenuazione |
|---|---|---|---|
"scale.down.error.failed.to.mark.to.be.deleted" |
Non è stato possibile contrassegnare un nodo per l'eliminazione. | Nome del nodo con errori. | Questo messaggio dovrebbe essere transitorio. Se il problema persiste, contatta l'assistenza clienti Google Cloud per ulteriori accertamenti. |
"scale.down.error.failed.to.evict.pods" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down perché non è stato possibile rimuovere alcuni pod da un nodo. | Nome del nodo con errori. | Esamina PodDisruptionBudget per il pod e assicurati che le regole consentano l'eliminazione delle repliche dell'applicazione, se accettabile. Per approfondire, consulta Specificare un budget di interruzione per l'applicazione nella documentazione di Kubernetes. |
"scale.down.error.failed.to.delete.node.min.size.reached" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down perché non è stato possibile eliminare un nodo a causa delle dimensioni già minime del cluster. | Nome del nodo con errori. | Rivedi il valore minimo impostato per la scalabilità automatica pool di nodi e modifica le impostazioni in base alle esigenze. Per saperne di più, consulta la sezione Errore: i nodi del cluster hanno raggiunto le dimensioni minime. |
Motivi di un evento noScaleDown
Un evento noScaleDown viene emesso periodicamente quando esistono nodi la cui eliminazione è bloccata dal gestore della scalabilità automatica del cluster. Gli eventi noScaleDown sono di tipo best effort e non coprono tutti i casi possibili.
Motivi di primo livello di NoScaleDown
I messaggi di motivo di primo livello per gli eventi noScaleDown vengono visualizzati nel
noDecisionStatus.noScaleDown.reason campo. Il messaggio contiene un motivo di primo livello per cui il gestore della scalabilità automatica dei cluster non può eseguire lo scale down del cluster.
| Messaggio di evento | Dettagli | Attenuazione |
|---|---|---|
"no.scale.down.in.backoff" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down perché è in un periodo di backoff (bloccato temporaneamente). | Questo messaggio dovrebbe essere temporaneo e può verificarsi quando si è verificato un evento di ridimensionamento recente. Se il messaggio persiste, contatta l'assistenza clienti Google Cloud per ulteriori accertamenti. |
"no.scale.down.in.progress" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down perché era ancora in corso uno fare lo scale down precedente. |
Questo messaggio dovrebbe essere transitorio, poiché il pod verrà eventualmente rimosso. Se questo messaggio si verifica di frequente, controlla il periodo di tolleranza prima dell'interruzione per il blocco del ridimensionamento dei pod. Per velocizzare la risoluzione, puoi anche eliminare il pod se non è più necessario. |
Motivi a livello di nodo NoScaleDown
I messaggi di motivo a livello di nodo per gli eventi noScaleDown vengono visualizzati in
noDecisionStatus.noScaleDown.nodes[].reason field. Il messaggio contiene un motivo per cui il gestore della scalabilità automatica dei cluster non può rimuovere un determinato nodo.
| Messaggio di evento | Dettagli | Parametri | Attenuazione |
|---|---|---|---|
"no.scale.down.node.scale.down.disabled.annotation" |
Il gestore della scalabilità automatica del cluster non può rimuovere un nodo dal pool di nodi perché
il nodo è annotato con
cluster-autoscaler.kubernetes.io/scale-down-disabled: true.
|
N/D | Il gestore della scalabilità automatica dei cluster salta i nodi con questa annotazione senza considerare il loro utilizzo e questo messaggio viene registrato indipendentemente dal fattore di utilizzo del nodo. Se vuoi che il gestore della scalabilità automatica del cluster riduca questi nodi, rimuovi l'annotazione. |
"no.scale.down.node.node.group.min.size.reached" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down se la dimensione del gruppo di nodi ha superato il limite minimo. Questo accade perché la rimozione dei nodi violerebbe i limiti minimi di risorse a livello di cluster definiti nelle impostazioni di provisioning automatico dei nodi. |
N/D | Controlla il valore minimo impostato per la scalabilità automatica del pool di nodi. Se vuoi che il gestore della scalabilità automatica del cluster riduca questo nodo, modifica il valore minimo. |
"no.scale.down.node.minimal.resource.limits.exceeded" |
Il gestore della scalabilità automatica dei cluster non può fare lo scale down i nodi perché violerebbe i limiti minimi di risorse a livello di cluster. Questi sono i limiti di risorse impostati per il provisioning automatico dei nodi. |
N/D | Rivedi i limiti per la memoria e le vCPU e, se vuoi che il gestore della scalabilità automatica dei cluster fare lo scale down questo nodo, diminuisci i limiti. |
"no.scale.down.node.no.place.to.move.pods" |
Il gestore della scalabilità automatica dei cluster non può eseguire fare lo scale down perché non è possibile spostare i pod. | N/D | Se prevedi che il pod debba essere ripianificato, esamina i requisiti di pianificazione dei pod sul nodo sottoutilizzato per determinare se possono essere spostati in un altro nodo del cluster. Per approfondire, consulta Errore: nessun luogo per spostare i pod. |
"no.scale.down.node.pod.not.backed.by.controller" |
Il pod sta bloccando fare lo scale down perché non è supportato da un controller. Nello specifico, il gestore della scalabilità automatica dei cluster non è in grado di fare lo scale down di un nodo sottoutilizzato a causa di un pod che non dispone di un controller riconosciuto. I controller consentiti includono ReplicationController, DaemonSet, Job, StatefulSet o ReplicaSet. |
Nome del pod di blocco. | Imposta l'annotazione
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
per il pod o definisci un controller accettabile. |
"no.scale.down.node.pod.not.safe.to.evict.annotation" |
Un pod sul nodo ha l'annotazione safe-to-evict=false. |
Nome del pod di blocco. | Se il pod può essere rimosso in sicurezza, modifica il manifest del pod e
aggiorna l'annotazione su
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true". |
"no.scale.down.node.pod.kube.system.unmovable" |
Il pod sta bloccando fare lo scale down perché è un pod senza DaemonSet,
senza mirroring e senza PodDisruptionBudget nello
spazio dei nomi kube-system. |
Nome del pod di blocco. | Per impostazione predefinita, i pod nello spazio dei nomi Per risolvere il problema, aggiungi un PodDisruptionBudget
per i pod |
"no.scale.down.node.pod.not.enough.pdb" |
Il pod sta bloccando fare lo scale down perché non dispone di un PodDisruptionBudget sufficiente. | Nome del pod di blocco. | Rivedi il PodDisruptionBudget per il pod e valuta la possibilità di renderlo meno restrittivo. Per saperne di più, consulta Errore: PodDisruptionBudget non sufficiente. |
"no.scale.down.node.pod.controller.not.found" |
Il pod sta bloccando fare lo scale down perché non è possibile trovare il relativo controller (ad esempio un deployment o un set di repliche). | N/D | Per determinare quali azioni sono state intraprese che hanno lasciato il pod in esecuzione dopo la rimozione del relativo controller, esamina i log. Per risolvere il problema, elimina manualmente il pod. |
"no.scale.down.node.pod.unexpected.error" |
Il pod sta bloccando fare lo scale down a causa di un errore imprevisto. | N/D | La causa principale di questo errore è sconosciuta. Contatta l'assistenza clienti Google Cloud per ulteriori accertamenti. |
Eseguire ulteriori accertamenti
Le sezioni che seguono forniscono indicazioni su come utilizzare Esplora log e
gcpdiag per ottenere ulteriori informazioni sugli errori.
Esaminare gli errori in Esplora log
Se vuoi esaminare ulteriormente il messaggio di errore, puoi visualizzare i log specifici per l'errore:
Nella console Google Cloud, vai alla pagina Esplora log.
Nel riquadro delle query, inserisci la seguente query:
resource.type="k8s_cluster" log_id("container.googleapis.com/cluster-autoscaler-visibility") jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"Sostituisci
ERROR_MESSAGEcon il messaggio che vuoi esaminare. Ad esempio,scale.down.error.failed.to.delete.node.min.size.reached.Fai clic su Esegui query.
Eseguire il debug di alcuni errori con gcpdiag
gcpdiag è uno strumento open source creato con il supporto degli ingegneri tecnici di Google Cloud. Non è un prodotto Google Cloud supportato ufficialmente.
Se hai visualizzato uno dei seguenti messaggi di errore, puoi utilizzare
gcpdiag
per risolvere il problema:
scale.down.error.failed.to.evict.podsno.scale.down.node.node.group.min.size.reached
Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.
Risolvere errori di fare lo scale down complessi
Le sezioni seguenti forniscono indicazioni per la risoluzione degli errori in cui le mitigazioni richiedono più passaggi ed errori a cui non è associato un messaggio di evento di autoscaler del cluster.
Errore: i nodi del cluster hanno raggiunto la dimensione minima
Se vedi i seguenti errori, il gestore della scalabilità automatica dei cluster non è riuscito a eliminare un nodo perché il numero di nodi nel cluster era già di dimensioni minime:
Notifica
Lo scale down del nodo sottoutilizzato è bloccato perché sono stati raggiunti i limiti minimi di risorse del gestore della scalabilità automatica dei cluster.
Evento
"scale.down.error.failed.to.delete.node.min.size.reached"
Per risolvere il problema, rivedi e aggiorna i limiti minimi per la scalabilità automatica:
Nella console Google Cloud, vai alla pagina Cluster Kubernetes:
Fai clic sul nome del cluster identificato nella notifica o in Cloud Logging.
Nella pagina Dettagli cluster, vai alla scheda Nodi.
Esamina il valore nella colonna Numero di nodi e confrontalo con il numero minimo di nodi elencato nella colonna Scalabilità automatica. Per esempio, se nella colonna Scalabilità automatica sono elencati 4-6 nodi e il numero di nodi nel pool di nodi è 4, il numero di pool di nodi è già uguale alla dimensione minima, quindi il gestore della scalabilità automatica del cluster non può fare lo scale down ulteriore dei nodi.
Se la configurazione è corretta e il valore del numero di nodi è uguale al valore minimo definito per la scalabilità automatica, il gestore della scalabilità automatica del cluster funziona come previsto. Se il numero minimo di nodi è troppo elevato per le tue esigenze, riduci la dimensione minima in modo che i nodi possano essere fare lo scale down.
Errore: non c'è spazio per spostare i pod
Quando il gestore della scalabilità automatica dei cluster tenta di fare lo scale down un nodo, ma non ci riesce perché un pod su quel nodo non può essere spostato in un altro nodo, si verificano i seguenti errori:
Notifica
Lo scale down del nodo sottoutilizzato è bloccato perché è presente un pod che non può essere spostato in un altro nodo del cluster.
Evento
"no.scale.down.node.no.place.to.move.pods"
Se non vuoi che questo pod venga riprogrammato, questo messaggio è previsto e non sono necessarie modifiche. Se vuoi che il pod venga riprogrammato, esamina
le seguenti definizioni in pod.spec block nel manifest del pod:
- NodeAffinity: esamina i requisiti di pianificazione dei pod sul nodo sottoutilizzato. Puoi esaminare questi requisiti esaminando il manifest del pod e cercando eventuali regole NodeAffinity o NodeSelector. Se il pod ha un nodeSelector definito e non sono presenti altri nodi (di altri pool di nodi) nel cluster che corrispondono a questo selettore, il gestore della scalabilità automatica del cluster non è in grado di spostare il pod su un altro nodo, il che a sua volta impedisce di rimuovere i nodi sottoutilizzati.
maxPodConstraint: semaxPodConstraintè configurato su un altro numero diverso da quello predefinito 110, conferma se si tratta di una modifica voluta. La riduzione di questo valore aumenta la probabilità di problemi. Il gestore della scalabilità automatica dei cluster non può riprogrammare i pod su altri nodi se tutti gli altri nodi del cluster hanno già raggiunto il valore definito inmaxPodConstraint, senza lasciare spazio per la pianificazione di nuovi pod. L'aumento del valoremaxPodConstraintconsente di pianificare più pod sui nodi e il gestore della scalabilità automatica del cluster avrà spazio per riprogrammare i pod e fare lo scale down i nodi sottoutilizzati. Quando definiscimaxPodConstraint, tieni presente che su ogni nodo sono presenti circa 10 pod di sistema.hostPort: se specifichihostPortper il pod, significa che su quel nodo può essere eseguito un solo pod. Ciò può rendere difficile per il gestore della scalabilità automatica dei cluster ridurre il numero di nodi perché il pod potrebbe non essere in grado di spostarsi su un altro nodo se la porta del nodo è già in uso. Questo è un comportamento previsto.
Errore: pod kube-system non spostabile
Quando un pod di sistema impedisce fare lo scale down, si verificano i seguenti errori:
Notifica
Il pod sta bloccando fare lo scale down perché è un pod senza DaemonSet, senza mirroring e senza PodDisruptionBudget nello spazio dei nomi
kube-system.
Evento
"no.scale.down.node.pod.kube.system.unmovable"
Un pod nello spazio dei nomi kube-system è considerato un pod di sistema. Per impostazione predefinita, il gestore della scalabilità automatica dei cluster non rimuove i pod nello spazio dei nomi kube-system.
Per risolvere questo errore, scegli una delle seguenti risoluzioni:
Aggiungi un
PodDisruptionBudgetper i podkube-system. Per ulteriori informazioni sull'aggiunta manuale di unPodDisruptionBudgetper i podkube-system, consulta le domande frequenti sul gestore della scalabilità automatica dei cluster Kubernetes.La creazione di un PodDisruptionBudget potrebbe influire sulla disponibilità dei carichi di lavoro del sistema, causando un tempo di riposo del cluster. Il gestore della scalabilità automatica dei cluster riprogramma questi carichi di lavoro di sistema su diversi nodi worker durante il processo di fare lo scale down.
Utilizza una combinazione di incompatibilità e tolleranze dei pool di nodi per separare i pod
kube-systemdai pod dell'applicazione. Per saperne di più, consulta Provisioning automatico dei nodi in GKE.
Verifica che i nodi abbiano kube-system pod
Se non sai con certezza che i tuoi nodi eseguono pod kube-system e vuoi verificarlo, completa i seguenti passaggi:
Vai alla pagina Esplora log nella console Google Cloud.
Fai clic su Query Builder.
Utilizza la seguente query per trovare tutti i record dei log dei criteri di rete:
- resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility" jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"Sostituisci quanto segue:
CLUSTER_LOCATION: la regione in cui si trova il cluster.CLUSTER_NAME: il nome del cluster.PROJECT_ID: l'ID del progetto a cui appartiene il cluster.NODE_POOL_NAME: il nome del pool di nodi.
Se nel pool di nodi sono in esecuzione
kube-systempod, l'output include quanto segue:"no.scale.down.node.pod.kube.system.unmovable"
Errore: PodDisruptionBudget insufficiente
Quando PodDisruptionBudget impedisce lo scale down, si verificano i seguenti errori:
Notifica
Lo scale down del nodo sottoutilizzato è bloccato perché è in esecuzione un pod che non ha un budget di interruzione dei pod sufficiente per consentire l'eliminazione del pod.
Evento
NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"
Per verificare se un PodDisruptionBudget è troppo restrittivo, controllane le impostazioni:
kubectl get pdb --all-namespaces
L'output è simile al seguente:
NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
example-app-one one_pdb N/A 1 1 12d
example-app-two two_pdb N/A 0 0 12d
In questo esempio, tutti i pod corrispondenti al selettore di etichette two_pdb non verranno eliminati dal gestore della scalabilità automatica del cluster. L'impostazione maxUnavailable: 0 in questo
PodDisruptionBudget prevede che tutte le repliche debbano rimanere disponibili in qualsiasi
momento. Inoltre, disruptionsAllowed: 0 vieta qualsiasi interruzione di questi
Pod. Di conseguenza, non è possibile eseguire lo scale down dei nodi su cui sono in esecuzione questi pod, in quanto ciò causerebbe un'interruzione e violerebbe PodDisruptionBudget.
Se PodDisruptionBudget funziona come vuoi, non sono necessarie ulteriori azioni. Se vuoi modificare PodDisruptionBudget in modo da poter spostare i pod su un nodo sottoutilizzato, modifica il manifest di PodDisruptionBudget.
Ad esempio, se hai impostato maxUnavailable su 0, puoi modificarlo in 1 in modo che il gestore della scalabilità automatica del cluster possa eseguire fare lo scale down.
Problema: il nodo rimane nello stato in isolamento e non viene rimosso
Quando il gestore della scalabilità automatica dei cluster non riesce a ridurre le dimensioni del pool di nodi perché l'account di servizio Google non dispone del ruolo Editor, si verificano errori simili ai seguenti:
Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.
Un sintomo comune di questo problema si verifica quando lo strumento di scalabilità automatica del cluster tenta di ridurre le dimensioni del pool di nodi, ma lo stato del nodo non cambia.
Per risolvere il problema, controlla se l'account di servizio predefinito (PROJECT_NUMBER@cloudservices.gserviceaccount.com) ha il ruolo Editor (roles/editor) nel progetto. Se l'account di servizio non dispone di questo ruolo, aggiungilo. GKE utilizza questo account servizio per gestire le risorse del progetto. Per scoprire come eseguire questa operazione, consulta
Concedere o revocare un singolo ruolo
nella documentazione di IAM.
Passaggi successivi
Consulta le seguenti domande nelle domande frequenti sul gestore della scalabilità automatica dei cluster Kubernetes:
Guarda un video di YouTube sulla risoluzione dei problemi di scalabilità.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.