Panoramica della scalabilità automatica del cluster nel servizio Azure Kubernetes (AKS)

Per tenere il passo delle richieste delle applicazioni nel servizio Azure Kubernetes (AKS), potresti aver bisogno di regolare il numero di nodi che eseguono i carichi di lavoro. Il componente di scalabilità automatica del cluster può cercare i pod del cluster che non possono essere pianificati a causa di vincoli delle risorse. Quando la scalabilità automatica del cluster rileva pod non pianificati, aumenta il numero di nodi nel pool di nodi per soddisfare la richiesta dell'applicazione. Controlla anche la presenza di nodi sottoutilizzati e riduce i nodi idonei quando i carichi di lavoro possono essere riprogrammati in modo sicuro.

Questo articolo ti aiuta a comprendere come funziona il ridimensionamento automatico del cluster in AKS. Fornisce anche indicazioni, procedure consigliate e considerazioni per la configurazione del ridimensionamento automatico del cluster per i carichi di lavoro in AKS. Se vuoi abilitare, disabilitare o aggiornare il ridimensionamento automatico del cluster per i tuoi carichi di lavoro AKS, vedi Usare il ridimensionamento automatico del cluster in AKS.

Informazioni sul componente di scalabilità automatica

Per adattarsi alle variazioni delle richieste delle applicazioni, ad esempio tra l’orario lavorativo diurno e serale o del fine settimana, è spesso necessario trovare il modo di adattare automaticamente i cluster. I cluster AKS possono essere ridimensionati nei modi seguenti:

• Il componente di scalabilità automatica controlla periodicamente i pod che non possono essere pianificati nei nodi a causa di vincoli delle risorse. Il cluster aumenta quindi automaticamente il numero di nodi. Il ridimensionamento manuale è disabilitato quando si utilizza l'autoscaler del cluster. Per altre informazioni, vedere Come funziona l'aumento delle prestazioni?
• L’Horizontal Pod Autoscaler utilizza il Server delle Metriche in un cluster Kubernetes per monitorare la domanda di risorse dei pod. Se un'applicazione richiede più risorse, il numero di pod viene aumentato automaticamente per soddisfare la domanda.
• L’utilità di scalabilità automatica orizzontale dei pod imposta automaticamente le richieste di risorse e limiti per i contenitori per carico di lavoro in base all'utilizzo passato per garantire che i pod siano pianificati in nodi che hanno le risorse di CPU e memoria necessarie.

È pratica comune abilitare l’utilità di scalabilità automatica del cluster per i nodi e l’utilità di scalabilità automatica verticale dei pod o l’utilità di scalabilità automatica orizzontale dei pod per i pod. Quando abiliti la scalabilità automatica del cluster, questa applica le regole di ridimensionamento specificate quando le dimensioni del pool di nodi sono inferiori al conteggio minimo dei nodi, fino al conteggio massimo. L’utilità di scalabilità automatica del cluster aspetta di avere effetto finché non è necessario un nuovo nodo nel pool di nodi o finché un nodo non può essere eliminato in modo sicuro dal pool di nodi corrente. Per ulteriori informazioni, vedi Come funziona la scalabilità verso il basso (scale down)?

Procedure consigliate e considerazioni

• Quando si implementano zone di disponibilità con il ridimensionamento automatico del cluster, usare un singolo pool di nodi per ogni zona. Impostare il --balance-similar-node-groups parametro su True per mantenere una distribuzione bilanciata dei nodi tra le zone per i carichi di lavoro durante le operazioni di aumento delle prestazioni. Se non si usa questo approccio, le operazioni di riduzione delle prestazioni possono compromettere il bilanciamento dei nodi tra zone. Per i pool di nodi multizona, è possibile anche lasciare che AKS selezioni dinamicamente le zone usando il posizionamento automatico nelle zone (--zones auto), che colloca i nodi nelle zone che hanno capacità disponibile applicando una percentuale massima di istanze del 50% per zona. È possibile usare il posizionamento automatico della zona quando si crea un pool di nodi o si aggiorna un pool di nodi esistente.

  Annotazioni

  Il componente di scalabilità automatica del cluster non è consapevole delle zone e i set di scalabilità di macchine virtuali sottostanti gestiscono l'allocazione tra zone. La procedura consigliata precedente diventa ancora più rilevante quando si usano vincoli di distribuzione della topologia dei pod basati su zona in un singolo pool di nodi multi-zona, poiché i vincoli restrittivi possono lasciare i pod in sospeso, soprattutto nelle aree a capacità limitata o durante scenari di mancata disponibilità della zona.

• Per i cluster con più di 400 nodi, usare Azure CNI o Azure overlay CNI.

• Per eseguire in modo efficace i carichi di lavoro contemporaneamente sia nei pool di nodi Spot che su richiesta, è consigliabile usare espansori con priorità. Un espansore di priorità usa le priorità e i modelli dei nomi del pool di nodi in ConfigMap per selezionare un pool di nodi durante l'aumento cluster-autoscaler-priority-expander delle prestazioni. La configurazione seguente illustra questa configurazione.

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: cluster-autoscaler-priority-expander
    namespace: kube-system
  data:
    priorities: |-
      10:
        - .*spotpool1.*
        - .*spotpool2.*
      50:
        - .*ondemandpool1.*
  

• Prestare attenzione quando si assegnano richieste di CPU e memoria nei pod. L'autoscaler del cluster scala verso l'alto in base ai pod in attesa anziché alla pressione su CPU o memoria nei nodi.

• Per i cluster che ospitano contemporaneamente sia carichi di lavoro a esecuzione prolungata, come le applicazioni Web, sia carichi di lavoro brevi o con picchi improvvisi, separateli in pool di nodi distinti con regole di affinità o expander.

• Usare PodDisruptionBudget per evitare operazioni di svuotamento o riduzione dei nodi non necessarie. Specificando l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict: "false" nella specifica del Pod si impedisce anche che i pod vengano sfrattati. Usa questa annotazione con cautela, poiché potrebbe causare problemi a Cluster Autoscaler quando svuota un nodo con un Pod in esecuzione che include questa annotazione.

• In un pool di nodi abilitato per la scalabilità automatica non modificare manualmente il numero di nodi corrente. Per modificare l'intervallo di scalabilità consentito, aggiornare il numero minimo e massimo di nodi di scalabilità automatica del cluster dopo aver valutato i requisiti di carico di lavoro e capacità.

• I nodi non si espandono se i pod hanno un valore di PriorityClass inferiore a -10. La priorità -10 è riservata ai pod di provisioning eccessivo. Per ulteriori informazioni, vedi Uso del ridimensionamento automatico del cluster con priorità e prelazione pod.

• Non combinare altri meccanismi di scalabilità automatica dei nodi, come ad esempio gli autoscaler dei set di scalabilità di macchine virtuali, con l’autoscaler del cluster.

• L’utilità di scalabilità automatica del cluster potrebbe non essere in grado di effettuare la riduzione qualora non fosse possibile spostare i pod, ad esempio nelle situazioni seguenti:

  • Un pod creato direttamente e non supportato da un oggetto controller, come Deployment o ReplicaSet.
  • Un budget di interruzione dei pod (PDB) troppo restrittivo e che non permette la riduzione del numero di pod sotto una determinata soglia.
  • Un pod che utilizza selettori di nodo o anti-affinità impossibili da rispettare se pianificati in un nodo diverso. Per ulteriori informazioni, vedi Quali tipi di pod possono impedire all’unità di scalabilità automatica del cluster di rimuovere un nodo?.

• La scalabilità automatica del cluster non è responsabile dell'applicazione di un "numero massimo di nodi" in un pool di nodi del cluster indipendentemente dalle considerazioni sulla pianificazione dei pod. Se un attore di scalabilità automatica non cluster imposta il conteggio dei pool di nodi su un numero superiore al massimo configurato dal ridimensionamento automatico del cluster, il ridimensionamento automatico del cluster non rimuove automaticamente i nodi. I comportamenti di riduzione della scalabilità automatica del cluster rimangono limitati per rimuovere i nodi sottoutilizzati. L'unico scopo della configurazione del numero massimo di nodi dell'autoscaler del cluster è imporre un limite superiore alle operazioni di scalabilità verso l'alto. Non ha alcun effetto sulle considerazioni di riduzione delle prestazioni.

Profilo di scalabilità automatica del cluster

Il profilo dell'utilità di scalabilità automatica del cluster è un set di parametri che controllano il comportamento dell'utilità di scalabilità automatica del cluster. Puoi configurare il profilo dell'utilità di scalabilità automatica del cluster quando crei un cluster o aggiorni un cluster esistente.

Ottimizzazione del profilo dell'utilità di scalabilità automatica del cluster

Dovresti affinare le impostazioni del profilo dell'autoscaler del cluster in base agli specifici scenari di carico di lavoro, tenendo conto anche del bilanciamento tra prestazioni e costi. In questa sezione vengono forniti esempi che illustrano tali compromessi.

È importante notare che le impostazioni del profilo dell'autoscaler del cluster sono valide per l'intero cluster e applicate a tutti i pool di nodi con scalabilità automatica abilitata. Tutte le azioni di ridimensionamento eseguite in un pool di nodi possono influire sul comportamento di scalabilità automatica di altri pool di nodi, causando risultati imprevisti. Assicurati di applicare configurazioni del profilo coerenti e sincronizzate in tutti i pool di nodi pertinenti per avere la certezza di ottenere i risultati desiderati.

Esempio 1: Ottimizzazione delle prestazioni

Per i cluster che gestiscono carichi di lavoro consistenti e soggetti a picchi, con particolare attenzione alle prestazioni, usare un valore scan-interval breve in modo che l'autoscaler del cluster rivaluti frequentemente il cluster. L'aumento di questo intervallo riduce la frequenza di rivalutazione e l'attività API correlata, ma aumenta il tempo prima che il ridimensionamento automatico del cluster reagisca. Ridurre scale-down-utilization-threshold per ridurre l'idoneità allo scale down dei nodi sottoutilizzati. Inoltre, aumentare ok-total-unready-count e max-total-unready-percentage.

Per i cluster con pod DaemonSet, impostare ignore-daemonsets-utilization su true in modo che le richieste di risorse dei pod DaemonSet non vengano incluse quando l'autoscaler del cluster calcola l'utilizzo dei nodi ai fini del ridimensionamento verso il basso. Questa impostazione può aumentare la probabilità che i nodi scendano al di sotto di scale-down-utilization-threshold e diventino idonei al ridimensionamento verso il basso. Vedere Configurare il profilo di scalabilità automatica del cluster per carichi di lavoro con picchi.

Esempio 2: Ottimizzazione dei costi

Se si vuole un profilo ottimizzato per i costi, è consigliabile impostare le configurazioni dei parametri seguenti:

• Ridurre scale-down-unneeded-time, ovvero la quantità di tempo per cui un nodo non deve essere necessario prima che sia idoneo per eseguire lo scale down.
• Ridurre scale-down-delay-after-add, ovvero la quantità di tempo di attesa dopo l'aggiunta di un nodo prima di considerarlo per eseguire lo scale down.
• Aumentare scale-down-utilization-threshold, ovvero la soglia di utilizzo per la rimozione dei nodi.
• Aumentare max-empty-bulk-delete, ovvero il numero massimo di nodi che possono essere eliminati in una singola chiamata.
• Impostare skip-nodes-with-local-storage su False.
• Aumentare ok-total-unready-count e max-total-unready-percentage.

Problemi comuni e raccomandazioni per la mitigazione

Visualizzare gli errori di scalabilità e aumentare le prestazioni degli eventi non attivati tramite l'interfaccia della riga di comando o il portale.

Non attivazione delle operazioni di ampliamento

Errori nelle operazioni di ampliamento

Errori delle operazioni di scale down

Altri problemi

Pool di nodi nel backoff

Il pool di nodi nel backoff è stato introdotto nella versione 0.6.2 e fa sì che l'utilità di scalabilità automatica del cluster esegua il dimensionamento di un pool di nodi dopo un errore.

A seconda del tempo in cui si sono verificati errori nelle operazioni di ridimensionamento, il ridimensionamento automatico potrebbe attendere fino a 30 minuti prima di eseguire un altro tentativo. È possibile reimpostare lo stato di backoff del pool di nodi disabilitando e poi riabilitando la scalabilità automatica.