Risolvere i problemi di scale down del gestore della scalabilità automatica dei cluster

Questa pagina mostra come diagnosticare e risolvere i problemi che impediscono allo strumento di scalabilità automatica del cluster di ridurre le dimensioni dei nodi Google Kubernetes Engine (GKE).

Questa pagina è rivolta agli sviluppatori di applicazioni che vogliono risolvere una situazione imprevista o negativa con la propria app o il proprio servizio e agli amministratori e agli operatori della piattaforma che vogliono evitare interruzioni nella fornitura di prodotti e servizi.

Informazioni su quando il gestore della scalabilità automatica dei cluster riduce il numero di 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 difare lo scale downe il numero di nodi. Potrebbe essere 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 allo scale down calcolando un fattore di utilizzo. Il fattore di utilizzo viene calcolato dividendo la vCPU e la memoria richieste dai pod sul nodo per la 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 la vCPU che per la memoria, il gestore della scalabilità automatica del cluster considera il nodo sottoutilizzato.

Quando un nodo è sottoutilizzato, il gestore della scalabilità automatica dei cluster lo contrassegna 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 deve rimuoverlo.

Esempio: calcolo del fattore di utilizzo

Hai un cluster con il gestore della scalabilità automatica del cluster abilitato e stai utilizzando il profilo di scalabilità automatica balanced. Un nodo di questo cluster viene sottoposto a 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 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 della vCPU è basso, l'utilizzo di memoria più elevato impedisce lafare lo scale downe per garantire che rimangano disponibili risorse sufficienti per il workload del pod.

Controllare se il problema è causato da una limitazione

Se osservi un cluster con un utilizzo basso per più di 10 minuti e non viene eseguito lo scale down, assicurati che il problema non sia causato da una delle limitazioni del gestore della scalabilità automatica del cluster.

Visualizza errori

Se il problema non è 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 suggerimenti sulla risoluzione dell'errore.

• Se non hai ancora ricevuto un messaggio, utilizza una delle seguenti opzioni:

  • Problemi riscontrati nelle ultime 72 ore: visualizza le notifiche di errore nella Google Cloud console.
  • Problemi più vecchi di 72 ore: visualizza gli errori negli eventi in Cloud Logging.

Visualizzare gli errori nelle notifiche

Se il problema che hai osservato si è verificato meno di 72 ore fa, visualizza le notifiche relative agli errori nella Google Cloud console. Queste notifiche forniscono informazioni preziose sul motivo per cui il gestore della scalabilità automatica dei cluster non ha eseguitofare lo scale downn e offrono consigli su come risolvere l'errore e visualizzare i log pertinenti per ulteriori indagini.

Per visualizzare le notifiche nella console Google Cloud , completa i seguenti passaggi:

1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Controlla la colonna Notifiche. Le seguenti notifiche sono associate a problemi di fare lo scale down:

   • Can't scale down nodes
   • Scale down blocked by pod

3. Fai clic sulla notifica pertinente per visualizzare un riquadro con i dettagli sulla causa del problema e le azioni consigliate per risolverlo.

4. (Facoltativo) Per visualizzare i log di questo evento, fai clic su Log. Questa azione ti porta a Esplora log 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 continui a riscontrare problemi dopo aver esaminato i suggerimenti nella notifica, 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:

1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Seleziona il nome del cluster che vuoi esaminare per visualizzare la pagina Dettagli cluster.

3. Nella pagina Dettagli cluster, fai clic sulla scheda Log.

4. Nella scheda Log, fai clic sulla scheda Log di scalabilità automatica per visualizzare i log.

5. (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 del gestore della scalabilità automatica del cluster. Per un esempio di come utilizzare Cloud Logging, consulta il seguente esempio di risoluzione dei problemi.

Esempio: risoluzione di un problema risalente a più di 72 ore prima

L'esempio seguente mostra come esaminare e risolvere un problema con un cluster che non viene ridimensionato.

Scenario:

Una settimana fa, stavi esaminando la dashboard GKE Enterprise e hai notato che il tuo cluster ha utilizzato solo il 10% della CPU e della memoria. Nonostante il basso utilizzo, il gestore della scalabilità automatica del cluster non ha eliminato il nodo come previsto. Quando ora guardi la dashboard, il problema sembra essere stato risolto, ma decidi di scoprire cosa è successo per evitare che si ripeta.

Indagine:

1. Poiché il problema si è verificato più di 72 ore fa, lo esamini utilizzando Cloud Logging anziché esaminare i messaggi di notifica.
2. In Cloud Logging, trovi i dettagli di logging per gli eventi del gestore della scalabilità automatica del cluster, come descritto in Visualizzare gli errori negli eventi.
3. Cerchi gli eventi scaleDown che contengono i nodi appartenenti al cluster che stai esaminando nel campo nodesToBeRemoved. Puoi filtrare le voci di log, incluso il filtro in base a un determinato valore del campo JSON. Scopri di più in Query avanzate sui log.
4. Non trovi eventi scaleDown. Tuttavia, se hai trovato un evento scaleDown, puoi cercare un evento eventResult che contenga il eventId associato. A questo punto, puoi cercare un errore nel campo errorMsg.

5. Decidi di continuare l'indagine cercando eventi noScaleDown che hanno il nodo che stai esaminando nel campo dei nodi.

   Trovi un evento noScaleDown che contiene un motivo per cui il nodo non viene ridotto. L'ID messaggio è "no.scale.down.node.pod.not.backed.by.controller" e c'è un solo parametro: "test-single-pod".

Risoluzione:

Consulti la tabella dei messaggi di errore e scopri che questo messaggio significa che il pod sta bloccandofare lo scale downn 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 vedi 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 è sicuro farlo per evitare che il problema si ripresenti.

Risolvere gli errori di fare lo scale down

Dopo aver identificato l'errore, utilizza le tabelle seguenti per capire la causa dell'errore e come risolverlo.

Errori di riduzione delle dimensioni

Puoi trovare i messaggi di evento di errore per gli eventi scaleDown nell'evento eventResult corrispondente, nel campo resultInfo.results[].errorMsg.

Motivi di un evento noScaleDown

Un evento noScaleDown viene emesso periodicamente quando ci sono nodi la cui eliminazione è bloccata dal gestore della scalabilità automatica del cluster. Gli eventi noScaleDown sono basati sul principio del "best effort" e non coprono tutti i casi possibili.

Motivi di primo livello di NoScaleDown

I messaggi relativi al motivo principale per gli eventi noScaleDown vengono visualizzati nel campo noDecisionStatus.noScaleDown.reason. Il messaggio contiene un motivo di primo livello per cui il gestore della scalabilità automatica dei cluster non può ridurre le dimensioni del cluster.

Motivi a livello di nodo di NoScaleDown

I messaggi relativi al 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.

Esegui 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:

1. Nella console Google Cloud , vai alla pagina Esplora log.

   Vai a Esplora log

2. Nel riquadro 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_MESSAGE con il messaggio che vuoi esaminare. Ad esempio, scale.down.error.failed.to.delete.node.min.size.reached.

3. Fai clic su Esegui query.

Eseguire il debug di alcuni errori con gcpdiag

gcpdiag è uno strumento open source creato con il supporto di ingegneri tecnici di Google Cloud. Non è un prodotto Google Cloud supportato ufficialmente.

Se hai riscontrato uno dei seguenti messaggi di errore, puoi utilizzare gcpdiag per risolvere il problema:

• scale.down.error.failed.to.evict.pods
• no.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 risolvere gli errori in cui le mitigazioni comportano più passaggi e gli errori a cui non è associato un messaggio di evento di scalabilità automatica del cluster.

Errore: i nodi del cluster hanno raggiunto la dimensione minima

Se visualizzi i seguenti errori, il gestore della scalabilità automatica dei cluster non è riuscito a eliminare un nodo perché il numero di nodi nel cluster aveva già raggiunto le dimensioni minime:

"scale.down.error.failed.to.delete.node.min.size.reached"

Per risolvere il problema, rivedi e aggiorna i limiti minimi per la scalabilità automatica:

1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes:

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster identificato nella notifica o in Cloud Logging.

3. Nella pagina Dettagli cluster, vai alla scheda Nodi.

4. Esamina il valore nella colonna Numero di nodi e confrontalo con il numero minimo di nodi elencato nella colonna Scalabilità automatica. Ad esempio, se nella colonna Scalabilità automatica sono elencati 4-6 nodi e il numero di nodi nel pool di nodi è 4, il numero di node pool è già uguale alla dimensione minima, quindi il gestore della scalabilità automatica del cluster non può fare lo scale down ulteriormente i nodi.

5. Se la configurazione è corretta e il valore per il numero di nodi è uguale al 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

Si verificano i seguenti errori quando il gestore della scalabilità automatica dei cluster tenta di fare lo scale down le dimensioni di un nodo ma non riesce perché un pod su quel nodo non può essere spostato in un altro nodo:

"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 ci sono 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 in un altro nodo, il che a sua volta impedisce la rimozione di eventuali nodi sottoutilizzati.
• maxPodConstraint: se maxPodConstraint è configurato su un numero diverso da quello predefinito 110, verifica se la modifica è intenzionale. Se riduci questo valore, la probabilità di problemi aumenta. 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 in maxPodConstraint, lasciando spazio per la pianificazione di nuovi pod. L'aumento del valore di maxPodConstraint consente di pianificare più pod sui nodi e il gestore della scalabilità automatica del cluster avrà spazio per riprogrammare i pod fare lo scale downwn dei nodi sottoutilizzati. Quando definisci maxPodConstraint, tieni presente che su ogni nodo sono presenti circa 10 pod di sistema.
• hostPort: se specifichi un hostPort per il pod, solo un pod può essere eseguito su quel nodo. 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 di quel nodo è già in uso. Questo è un comportamento previsto.
• Archiviazione temporanea: i pod si basano sull'archiviazione temporanea per i dati temporanei. Lo spazio di archiviazione temporanea insufficiente sui nodi può ostacolare la pianificazione dei pod e impedire lo scale down dei nodi sottoutilizzati. Esempio: un pod che richiede 6 GB di spazio di archiviazione temporanea non può essere pianificato su nodi con meno di 6 GB di spazio di archiviazione temporanea libero, anche se dispone di risorse di CPU e memoria sufficienti. Per ridurre le limitazioni dello spazio di archiviazione temporanea, aumenta la capacità di spazio di archiviazione temporanea di cui è stato eseguito il provisioning per i tuoi nodi. Ciò garantisce una capacità sufficiente per le operazioni di scalabilità e riposizionamento dei pod.

Errore: il pod kube-system non può essere spostato

Si verificano i seguenti errori quando un pod di sistema impedisce fare lo scale down:

"no.scale.down.node.pod.kube.system.unmovable"

I pod nello spazio dei nomi kube-system sono considerati pod di sistema. In GKE versione 1.32.4-gke.1236000 e successive, il gestore della scalabilità automatica dei cluster può fare lo scale down dei nodi eseguendo l'espulsione dei pod di sistema in esecuzione da almeno un'ora. Nelle versioni precedenti di GKE, il gestore della scalabilità automatica dei cluster non rimuove i pod nello spazio dei nomi kube-system, il che può impedire fare lo scale down a tempo indeterminato.

Per risolvere questo errore, scegli una delle seguenti soluzioni:

• Aggiungi un PodDisruptionBudget per i pod kube-system. Per ulteriori informazioni sull'aggiunta manuale di un PodDisruptionBudget per i pod kube-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 di sistema, il che può causare tempi di inattività sul cluster. Il gestore della scalabilità automatica dei cluster riprogramma questi carichi di lavoro di sistema su nodi worker diversi durante la procedura di fare lo scale down.

• Utilizza una combinazione di incompatibilità e tolleranze dei pool di nodi per separare i pod kube-system dai pod dell'applicazione. Per maggiori informazioni, consulta Provisioning automatico dei nodi in GKE.

Verifica che i nodi abbiano pod kube-system

Se non hai la certezza che i tuoi nodi eseguano pod kube-system e vuoi verificarlo, completa i seguenti passaggi:

1. Vai alla pagina Esplora log nella console Google Cloud .

   Vai a Esplora log

2. Fai clic su Query Builder.

3. Utilizza la seguente query per trovare tutti i record di 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 tuo pool di nodi.

   Se nel pool di nodi sono in esecuzione kube-system pod, l'output include quanto segue:

   "no.scale.down.node.pod.kube.system.unmovable"
   

Errore: PodDisruptionBudget insufficiente

Si verificano i seguenti errori quando PodDisruptionBudget impedisce lo scale down:

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Per verificare se un PodDisruptionBudget è troppo restrittivo, esamina le relative 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 rimossi dal gestore della scalabilità automatica del cluster. L'impostazione maxUnavailable: 0 in questo PodDisruptionBudget stabilisce che tutte le repliche devono rimanere disponibili in qualsiasi momento. Inoltre, disruptionsAllowed: 0 vieta qualsiasi interruzione di questi Pod. Di conseguenza, i nodi che eseguono questi pod non possono essere ridimensionati, in quanto ciò causerebbe un'interruzione e violerebbe il PodDisruptionBudget.

Se il PodDisruptionBudget funziona come previsto, non sono necessarie ulteriori azioni. Se vuoi modificare il PodDisruptionBudget in modo che i pod su un nodo sottoutilizzato possano essere spostati, modifica il manifest del PodDisruptionBudget. Ad esempio, se avevi impostato maxUnavailable su 0, potresti modificarlo in 1 in modo che il gestore della scalabilità automatica dei cluster possa eseguire fare lo scale down.

Problema: il nodo rimane nello stato Cordoned e non viene rimosso

Si verificano errori simili ai seguenti quando il gestore della scalabilità automatica dei cluster non riesce a ridurre le dimensioni del pool di nodi perché il account di servizio Google non dispone del ruolo Editor:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Un sintomo comune di questo problema si verifica quando la 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 il account di servizio predefinito (PROJECT_NUMBER@cloudservices.gserviceaccount.com) ha il ruolo Editor (roles/editor) nel progetto. Se il account di servizio non dispone di questo ruolo, aggiungilo. GKE utilizza questo service account per gestire le risorse del progetto. Per scoprire come fare, consulta la sezione Concedere o revocare un singolo ruolo nella documentazione di IAM.

Passaggi successivi

• Leggi le seguenti domande nelle domande frequenti sul gestore della scalabilità automatica dei cluster Kubernetes:

  • Come funziona lo scale-down?
  • Il gestore della scalabilità automatica dei cluster funziona con PodDisruptionBudget durante la riduzione della scalabilità?
  • Quali tipi di pod possono impedire al gestore della scalabilità automatica dei cluster di rimuovere un nodo?

• Guarda un video di YouTube sulla risoluzione dei problemi di scalabilità.

• Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

  • Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
  • Ricevere assistenza dalla community ponendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ulteriore assistenza della community.
  • Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.