Risolvi i problemi relativi allo scale down del gestore della scalabilità automatica dei cluster

Questa pagina mostra come diagnosticare e risolvere i problemi che impediscono ai cluster al gestore della scalabilità automatica non dovrà fare lo scale down dei nodi Google Kubernetes Engine (GKE).

Questa pagina è rivolta agli sviluppatori di applicazioni che vogliono risolvere un problema imprevisto o situazione negativa relativa alla loro app o al loro servizio e agli amministratori e agli operatori della piattaforma che vogliono evitare l'interruzione della fornitura di prodotti e servizi.

Scopri quando il gestore della scalabilità automatica dei cluster fa 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 ridurre i nodi. È possibile che il gestore della scalabilità automatica dei cluster non abbia eseguito lo scale down perché non era necessario.

Il gestore della scalabilità automatica dei cluster determina se un nodo è sottoutilizzato e idoneo alla scalabilità calcolando un fattore di utilizzo. Il fattore di utilizzo viene calcolato dividendo la vCPU e la memoria richieste dai pod sul nodo per e memoria allocabili sul nodo.

Ogni 10 secondi il gestore della scalabilità automatica dei cluster controlla il fattore di utilizzo dei nodi per vedere se è al di sotto della soglia richiesta. Se utilizzi un balanced profilo di scalabilità automatica, la soglia del fattore di utilizzo è 0,5. Se utilizzi profilo optimize-utilization, il fattore di utilizzo varia. Quando è inferiore alla soglia richiesta sia per vCPU che per memoria, il gestore della scalabilità automatica dei cluster considera il nodo sottoutilizzato.

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

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. Viene eseguito il provisioning di un nodo in questo cluster con tipo di macchina e2-standard-4, che offre 4 vCPU e 16 GB di memoria. R Il pod su questo nodo richiede 0,5 vCPU e 10 GB di memoria, quindi il gestore della scalabilità automatica dei 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 prenderà in considerazione questo nodo è sottoutilizzato perché il fattore di utilizzo della memoria (0,625) supera le di 0,5. Anche se l'utilizzo delle vCPU è basso, l'utilizzo della memoria più elevato impedisce il ridimensionamento per garantire che rimangano disponibili risorse sufficienti per il carico di lavoro del pod.

Controllare se il problema è causato da una limitazione

Se noti un cluster con utilizzo ridotto per più di 10 minuti e non si stia effettuando lo scale down, assicurati che il problema non sia causato da una delle limitazioni per il gestore della scalabilità automatica dei cluster.

Visualizza errori

Se il tuo problema non è causato da una limitazione, spesso puoi diagnosticare la causa utilizzando visualizzazione dei messaggi di errore:

Visualizzare gli errori nelle notifiche

Se il problema riscontrato si è verificato meno di 72 ore fa, visualizza le notifiche sugli errori nella console Google Cloud. Queste notifiche forniscono informazioni preziose sul motivo per cui il gestore della scalabilità automatica dei cluster non ha eseguito 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 passaggi:

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

    Vai ai cluster Kubernetes

  2. Esamina la colonna Notifiche. Le seguenti Le 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 il problema e le azioni consigliate per risolverlo.

  4. (Facoltativo) Per visualizzare i log per questo evento, fai clic su Log. Questa azione porta a Esplora log con una query precompilata per aiutarti ulteriormente analizza l'evento di scalabilità. Per saperne di più sugli eventi di fare lo scale down lavoro, vedi Visualizza gli eventi del gestore della scalabilità automatica dei 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 il 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 visualizzarne la pagina Dettagli cluster.

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

  4. Nella scheda Log, fai clic sulla scheda Log del gestore della 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 il gestore della scalabilità automatica dei cluster eventi. Per uno esempio di come utilizzare Cloud Logging, consulta la seguente risoluzione dei problemi esempio.

Esempio: risolvere un problema risalente a più di 72 ore fa

L'esempio seguente mostra come potresti esaminare e risolvere un problema con un cluster che non fa lo scale down.

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. Osservando la dashboard, sembra che il problema risolto, ma decidi di scoprire cosa è successo per evitare e succederà di nuovo.

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, troverai i dettagli di logging per il cluster degli eventi del gestore della scalabilità automatica, come descritto Visualizza gli errori negli eventi.
  3. Cerchi scaleDown eventi che contengono i nodi che appartengono al cluster che stai esaminando nel campo nodesToBeRemoved. 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.
  4. Non trovi eventi scaleDown. Tuttavia, se hai trovato un evento scaleDown, puoi cercare un evento eventResult contenente il eventId associato. Puoi quindi cercare un errore nel campo errorMsg.

  5. Decidi di continuare la tua indagine cercando gli eventi noScaleDown che contengono il nodo che stai esaminando nel campo dei nodi.

    Trovi un evento noScaleDown che 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 questo messaggio significa che il pod sta bloccando fare lo scale down perché non è supportato da una un controller di deployment. Scopri che una soluzione è aggiungere un Annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" per all'interno del 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 puoi farlo in modo sicuro per evitare che il problema si ripresenti.

Risolvi gli errori di fare lo scale down

Dopo aver identificato l'errore, utilizza le seguenti tabelle per capire cosa ha causato l'errore e come risolverlo.

Errori di scaledown

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 lo scale down perché non è stato possibile rimuovere alcuni pod da un nodo. Nome del nodo in errore. Rivedi il PodDisruptionBudget per il pod e assicurati che le regole consentono l'eliminazione delle repliche delle applicazioni 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ò fare lo scale down perché non è stato possibile eliminare un nodo poiché le dimensioni del cluster sono già minime. Nome del nodo con errori. Esamina il valore minimo impostato per la scalabilità automatica del pool di nodi e modifica le impostazioni in base alle tue 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. noScaleDown eventi sono con il criterio del "best effort" e non copriamo 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 una motivo per cui il gestore della scalabilità automatica dei cluster non può fare 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 lo scale down perché è in un periodo di backoff (bloccato temporaneamente).

Questo messaggio deve essere temporaneo e può si verificano quando si è verificato un recente evento di scale up.

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ò fare lo scale down a causa di un precedente scale down era ancora in corso.

 Questo messaggio dovrebbe essere transitorio, poiché il pod verrà eventualmente rimosso. Se questo messaggio appare di frequente, rivedi le periodo di tolleranza per l'arresto per i pod che bloccano fare lo scale down. Per velocizzare la risoluzione, puoi anche eliminare il pod se non è più necessario.

Motivi a livello di nodo NoScaleDown

I messaggi del motivo a livello di nodo per noScaleDown eventi vengono visualizzati nel noDecisionStatus.noScaleDown.nodes[].reason field. Il messaggio contiene motivo per cui il gestore della scalabilità automatica dei cluster non può rimuovere un nodo specifico.

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 fare lo scale down di questi nodi, rimuovi l'annotazione.
"no.scale.down.node.node.group.min.size.reached"

Il gestore della scalabilità automatica dei cluster non può eseguire lo scale down se la dimensione del gruppo di nodi ha superato il limite minimo.

Ciò accade perché la rimozione dei nodi violerebbe limiti minimi di risorse a livello di cluster definiti nel nodo le impostazioni di provisioning automatico.

 N/D Controlla il valore minimo impostato per la scalabilità automatica del pool di nodi. Se vuoi gestore della scalabilità automatica dei cluster per fare lo scale down di questo nodo, il valore minimo.
"no.scale.down.node.minimal.resource.limits.exceeded"

Il gestore della scalabilità automatica dei cluster non può ridurre i nodi perché violerebbe i limiti minimi di risorse a livello di cluster.

Questi sono i limiti delle risorse impostati per il provisioning automatico dei nodi.

 N/D Rivedi i limiti di memoria e vCPU e, se vuoi cluster gestore della scalabilità automatica per fare lo scale down di questo nodo, aumenta limiti.
"no.scale.down.node.no.place.to.move.pods" Il gestore della scalabilità automatica dei cluster non può eseguire 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. A per saperne di più, consulta Errore: Non c'è posto in cui spostare i pod.
"no.scale.down.node.pod.not.backed.by.controller"

Il pod sta bloccando 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 nodo sottoutilizzato a causa di un pod privo di 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.has.local.storage" Il pod sta bloccando lo scale down perché dispone di archiviazione locale. Nome del pod di blocco. Imposta un'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" per il pod se i dati nello spazio di archiviazione locale del pod non sono critici. Questo errore si verifica solo per i cluster che utilizzano una versione precedente alla 1.22.
"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 file manifest del pod aggiorna l'annotazione in "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" Il pod sta bloccando 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 kube-system non vengono rimossi gestore della scalabilità automatica dei cluster.

Per risolvere il problema, aggiungi un PodDisruptionBudget per i pod kube-system o utilizza una combinazione di incompatibilità e tolleranze per separare i pod kube-system dal tuo dei pod dell'applicazione. Per saperne di più, vedi Errore: pod kube-system non spostabile.
"no.scale.down.node.pod.not.enough.pdb" Il pod sta bloccando 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 realizzarlo meno restrittiva. Per saperne di più, consulta Errore: PodDisruptionBudget insufficiente.
"no.scale.down.node.pod.controller.not.found" Il pod sta bloccando 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 e che hanno lasciato il Esamina i log del pod in esecuzione dopo la rimozione del relativo controller. Da risolvere per questo problema, elimina manualmente il pod.
"no.scale.down.node.pod.unexpected.error" Il pod sta bloccando 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 indagini.

Condurre ulteriori indagini

Le sezioni seguenti 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 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_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 degli ingegneri tecnici di Google Cloud. Non è un prodotto Google Cloud supportato ufficialmente.

Se è stato visualizzato uno dei seguenti messaggi di errore, puoi utilizzare gcpdiag per aiutarti a 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 complessi di fare lo scale down

Le sezioni seguenti forniscono indicazioni per risolvere gli errori in cui le mitigazioni prevedono più passaggi ed errori che non hanno un cluster messaggio di evento del gestore della scalabilità automatica associato.

Errore: i nodi del cluster hanno raggiunto la dimensione minima

Se visualizzi i seguenti errori, il gestore della scalabilità automatica dei cluster non ha potuto eliminare un nodo perché il numero di nodi nel cluster era già al minimo dimensioni:

Notifica

Lo scale down del nodo sottoutilizzato è bloccato perché il gestore della scalabilità automatica dei cluster vengono raggiunti i limiti minimi di risorse.

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:

  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. 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 alle dimensioni minime, pertanto il gestore della scalabilità automatica del cluster non può ridurre ulteriormente il numero di nodi.

  5. 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 ridotti.

Errore: nessuna posizione in cui spostare i pod

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

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 il pod venga ripianificato, viene restituito questo messaggio. non è necessario apportare modifiche. Se vuoi che il pod venga riprogrammato, esamina le seguenti definizioni in pod.spec block nel manifest del pod:

  • NodeAffinity: rivedi i requisiti di pianificazione dei pod nella sottoutilizzato. Puoi rivedere questi requisiti esaminando il pod e alla ricerca di eventuali regole NodeAffinity o NodeSelector. Se il pod ha un nodeSelector definito e non ci sono altri nodi (di altri nodi pool) nel cluster che corrispondono a questo selettore, il gestore della scalabilità automatica dei cluster non è in grado di spostare il pod su un altro nodo, impedendogli di farlo a sua volta rimuovendo tutti i nodi sottoutilizzati.
  • maxPodConstraint: se maxPodConstraint è configurato su qualsiasi altro diverso da quello predefinito di 110, verifica se si tratta di un la modifica voluta. Se questo valore viene abbassato, 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, senza lasciare spazio per la pianificazione di nuovi pod. In aumento il valore maxPodConstraint consente di pianificare più pod sui nodi il gestore della scalabilità automatica dei cluster avrà spazio per riprogrammare i pod e fare lo scale down di nodi sottoutilizzati. Quando definisci maxPodConstraint, tieni presente che su ogni nodo sono presenti circa 10 pod di sistema.
  • hostPort: se specifichi hostPort per il pod, solo un pod può 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.

Errore: pod kube-system non spostabile

Quando un pod di sistema impedisce lo scale down, si verificano i seguenti errori:

Notifica

Il pod sta bloccando 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 l'errore, scegli una delle seguenti soluzioni:

  • Aggiungi un PodDisruptionBudget per i pod kube-system. Per maggiori informazioni informazioni sull'aggiunta manuale di un PodDisruptionBudget per kube-system pod, consulta 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 ridimensionamento.

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

Verifica che i nodi abbiano kube-system pod

Se non hai la certezza che i tuoi nodi eseguano pod kube-system e vuoi verifica, 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 tuo 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

Quando il PodDisruptionBudget impedisce la scalabilità, si verificano i seguenti errori verso il basso:

Notifica

Lo scale down del nodo sottoutilizzato è bloccato perché ha un pod in esecuzione che non dispone di un budget di interruzione dei pod sufficiente per consentire l'eliminazione all'interno 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 indica che tutte le repliche devono rimanere disponibili volte. Inoltre, disruptionsAllowed: 0 vieta qualsiasi interruzione di questi Pod. Di conseguenza, non è possibile fare lo scale down dei nodi che eseguono questi pod, poiché potrebbe causare un'interruzione e violare PodDisruptionBudget.

Se il tuo PodDisruptionBudget funziona come previsto, non dovrai fare nient'altro obbligatorio. Se vuoi regolare il tuo PodDisruptionBudget in modo che i pod puoi spostare il nodo sottoutilizzato, modificare il manifest di PodDisruptionBudget. Ad esempio, se hai impostato maxUnavailable su 0, puoi modificarlo a 1 per consentire lo fare lo scale down del gestore della scalabilità automatica dei cluster.

Problema: il nodo rimane in stato non pianificabile e non viene rimosso

Errori simili ai seguenti si verificano quando il gestore della scalabilità automatica dei cluster non può ridurre il dimensione del pool di nodi perché l'account di servizio Google non ha l'Editor ruolo:

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

Un sintomo comune di questo problema è quando il gestore della scalabilità automatica dei cluster cerca 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 ha questo ruolo, aggiungilo. GKE utilizza questo account servizio per gestire le risorse del progetto. Per scoprire come fare, consulta Concedere o revocare un singolo ruolo nella documentazione di IAM.

Passaggi successivi