Condividi tramite

Opzioni di ridimensionamento per le applicazioni nel servizio Azure Kubernetes

Quando si eseguono applicazioni nel servizio Azure Kubernetes, potrebbe essere necessario aumentare o ridurre attivamente la quantità di risorse di calcolo nel cluster. Quando si modifica il numero di istanze dell'applicazione disponibili, potrebbe essere necessario modificare il numero di nodi Kubernetes sottostanti. Potrebbe anche essere necessario effettuare il provisioning di un numero elevato di altre istanze dell'applicazione.

Questo articolo presenta i concetti di base relativi al ridimensionamento delle applicazioni nel servizio Azure Kubernetes, tra cui il ridimensionamento manuale di pod o nodi, l'uso del ridimensionamento automatico orizzontale dei pod, l'uso del ridimensionamento automatico del cluster e l'integrazione con Istanze di Azure Container.

Ridimensionare manualmente i pod o i nodi

È possibile ridimensionare manualmente le repliche (pod) e i nodi per verificare come risponde l'applicazione a una modifica delle risorse disponibili e dello stato. Il ridimensionamento manuale delle risorse consente di definire una quantità di risorse impostata da usare, ad esempio il numero di nodi, per mantenere un costo fisso. Per ridimensionare manualmente, si definisce un conteggio di repliche o nodi. L'API Kubernetes pianifica quindi la creazione di più pod o lo svuotamento dei nodi in base al numero di repliche o nodi.

Quando si riducono i nodi, l'API Kubernetes chiama l'API di Azure Compute pertinente, collegata al tipo di calcolo utilizzato dal cluster. Ad esempio, per i cluster basati su set di scalabilità di macchine virtuali, l'API dei set di scalabilità di macchine virtuali determina quali nodi rimuovere. Per altre informazioni su come vengono selezionati i nodi per la rimozione durante la riduzione delle prestazioni, vedere Domande frequenti sui set di scalabilità di macchine virtuali.

Per iniziare a ridimensionare manualmente i nodi, vedere Ridimensionare manualmente i nodi in un cluster del servizio Azure Kubernetes. Per ridimensionare manualmente il numero di pod, vedere il comando kubectl scale.

Utilità di scalabilità automatica orizzontale dei pod

Kubernetes usa l'utilità di ridimensionamento automatico orizzontale dei pod (HPA) per monitorare la richiesta di risorse e adattare automaticamente il numero di pod. Per impostazione predefinita, HPA controlla l'API Metrica ogni 15 secondi per eventuali modifiche necessarie nel numero di repliche, mentre l'API Metrica recupera i dati da Kubelet ogni 60 secondi. Di conseguenza, HPA viene aggiornato ogni 60 secondi. Quando sono necessarie modifiche, il numero di repliche viene ridimensionato di conseguenza. HPA funziona con i cluster AKS che hanno distribuito Metrics Server per Kubernetes versione 1.8 e successive.

Ridimensionamento automatico orizzontale dei pod Kubernetes

Quando si configura HPA per una distribuzione specifica, si definisce il numero minimo e massimo di repliche che può essere eseguito. È anche possibile definire la metrica per monitorare e basare le decisioni di ridimensionamento, ad esempio l'utilizzo della CPU.

Per informazioni introduttive sul ridimensionamento automatico orizzontale dei pod in servizio Azure Kubernetes, vedere Scalare automaticamente i pod.

Raffreddamento degli eventi di ridimensionamento

Poiché HPA viene aggiornato in modo efficace ogni 60 secondi, gli eventi di scalabilità precedenti potrebbero non essere stati completati correttamente prima di eseguire un altro controllo. A causa di questo comportamento, l'utilità HPA potrebbe modificare il numero di repliche prima che l'evento di ridimensionamento precedente riceva il carico di lavoro dell'applicazione e le richieste di risorse, in modo da adattarsi di conseguenza.

Per ridurre al minimo gli eventi di race condition, viene impostato un valore di ritardo. Questo valore definisce il tempo di attesa da parte dell'utilità HPA dopo un evento di ridimensionamento prima che possa essere attivato un altro evento di ridimensionamento. Questo comportamento consente al nuovo numero di repliche di diventare effettivo e all'API Metriche di rispecchiare il carico di lavoro distribuito. Non è previsto alcun ritardo per gli eventi di aumento delle prestazioni a partire da Kubernetes 1.12. Tuttavia, il ritardo predefinito per gli eventi di riduzione delle prestazioni è di 5 minuti.

Ridimensionamento automatico del cluster

Per rispondere alle variazioni della domanda di pod, l'utilità di scalabilità automatica del cluster di Kubernetes regola il numero di nodi in base alle risorse di calcolo richieste nel pool di nodi. Per impostazione predefinita, l'utilità di scalabilità automatica del cluster controlla il server API Metriche ogni 10 secondi per verificare se sono presenti eventuali modifiche necessarie nel numero di nodi. Se l'utilità di scalabilità automatica del cluster determina che è necessaria una modifica, il numero di nodi nel cluster servizio Azure Kubernetes viene aumentato o ridotto di conseguenza. L'utilità di scalabilità automatica del cluster funziona con i cluster servizio Azure Kubernetes abilitati per il Controllo degli accessi in base al ruolo che eseguono Kubernetes 1.10.x o versione successiva.

Ridimensionamento automatico del cluster Kubernetes

L'utilità di scalabilità automatica del cluster viene in genere usata insieme all'utilità di scalabilità automatica orizzontale dei pod. Se vengono usate insieme, l'utilità di scalabilità automatica orizzontale dei pod aumenta o diminuisce il numero di pod in base alla domanda dell'applicazione e l'utilità di scalabilità automatica del cluster regola il numero di nodi per l'esecuzione di più pod.

Per informazioni introduttive sul ridimensionamento automatico del cluster nel servizio Azure Kubernetes, vedere Ridimensionamento automatico del cluster nel servizio Azure Kubernetes.

Eventi di aumento del numero di istanze

Se un nodo non ha risorse di calcolo sufficienti per eseguire un pod richiesto, quel pod non può procedere nel processo di pianificazione. Il pod non può iniziare a meno che non vengano rese disponibili più risorse di calcolo all'interno del pool di nodi.

Quando il ridimensionamento automatico del cluster rileva pod non pianificabili a causa dei vincoli di risorse del pool di nodi, il numero di nodi all'interno del pool viene aumentato per fornire risorse di calcolo aggiuntive. Dopo la distribuzione corretta di tali nodi e quando sono disponibili per l'uso all'interno del pool di nodi, i pod vengono quindi pianificati per l'esecuzione su tali nodi.

Se l'applicazione deve essere ridimensionata rapidamente, alcuni pod potrebbero rimanere in attesa di essere programmati fino a quando un numero maggiore di nodi distribuiti dall'autoscaler del cluster può accettare i pod programmati. Per le applicazioni con richieste burst elevate, è possibile gestire il ridimensionamento con nodi virtuali e Istanze di Azure Container.

Eventi di riduzione del numero di istanze

L'utilità di scalabilità automatica del cluster esegue anche il monitoraggio dello stato di pianificazione dei pod per i nodi che non hanno ricevuto di recente nuove richieste di pianificazione. Questo scenario indica che il pool di nodi ha più risorse di calcolo del necessario e il numero di nodi può essere ridotto. Per impostazione predefinita, i nodi che superano una soglia di non essere più necessari per 10 minuti vengono pianificati per l'eliminazione. Quando si verifica questa situazione, i pod vengono pianificati per l'esecuzione su altri nodi all'interno del pool di nodi e il ridimensionamento automatico del cluster riduce il numero di nodi.

Le applicazioni potrebbero riscontrare alcuni problemi mentre i pod vengono pianificati per nodi diversi quando il ridimensionamento automatico del cluster riduce il numero di nodi. Per ridurre al minimo i disagi, evitare le applicazioni che usano una singola istanza di pod.

KEDA (Event-Driven AutoScaling) di Kubernetes.

La scalabilità automatica basata su eventi di Kubernetes è un componente open source per la scalabilità automatica basata su eventi dei carichi di lavoro. Ridimensiona i carichi di lavoro in modo dinamico in base al numero di eventi ricevuti. KEDA estende Kubernetes con una definizione di risorsa personalizzata (CRD), denominata ScaledObject, per descrivere come le applicazioni devono essere ridimensionate in risposta a traffico specifico.

La scalabilità KEDA è utile negli scenari in cui i carichi di lavoro ricevono picchi di traffico o gestiscono volumi elevati di dati. KEDA è diverso da Horizontal Pod Autoscaler perché KEDA è basato sugli eventi e ridimensiona in base al numero di eventi, mentre HPA è basato sulle metriche in base all'utilizzo delle risorse (ad esempio, CPU e memoria).

Per iniziare a usare il componente aggiuntivo KEDA nel servizio Azure Kubernetes, vedere panoramica di KEDA.

Provisioning automatico dei nodi

Il provisioning automatico dei nodi (anteprima) usa il progetto Karpenter open source che distribuisce, configura e gestisce Karpenter automaticamente sul cluster di Azure Kubernetes Service. NAP effettua dinamicamente il provisioning dei nodi in base ai requisiti delle risorse dei pod in sospeso; sceglierà automaticamente lo SKU e la quantità ottimali della macchina virtuale, per soddisfare la domanda in tempo reale.

NAP utilizza un elenco predefinito di SKU di macchine virtuali come punto di partenza per determinare quale SKU sia più adatto per i carichi di lavoro in sospeso. Per un controllo più preciso, gli utenti possono definire i limiti superiori delle risorse usate da un pool di nodi e le preferenze di dove pianificare i carichi di lavoro se sono presenti più pool di nodi.

Ridimensionamento burst in Istanze di Azure Container

Per ridimensionare rapidamente il cluster del servizio Azure Kubernetes, è possibile ricorrere all'integrazione con Istanze di Azure Container. Kubernetes include componenti predefiniti per modificare il numero di repliche e di nodi. Tuttavia, se l'applicazione deve essere ridimensionata rapidamente, l'utilità di scalabilità automatica orizzontale dei pod potrebbe pianificare più pod rispetto alle risorse di calcolo esistenti che il pool di nodi può supportare. Se configurato, questo scenario attiverà quindi il ridimensionamento automatico del cluster per distribuire più nodi nel pool di nodi, ma potrebbero essere necessari alcuni minuti prima che tali nodi eseguano correttamente il provisioning e consentano all'utilità di pianificazione Kubernetes di eseguire pod su di essi.

Ridimensionamento burst di Kubernetes in Istanze di contenitore di Azure

Istanze di Azure Container consente di distribuire rapidamente istanze di contenitore senza sovraccarico aggiuntivo per l'infrastruttura. Quando ci si connette con il servizio Azure Kubernetes, Istanze di Azure Container diventa un'estensione logica protetta del cluster servizio Azure Kubernetes. Il componente nodi virtuali, basato su Kubelet virtuale, viene installato nel cluster del servizio Azure Kubernetes che presenta Istanze di Azure Container come nodo Kubernetes virtuale. Kubernetes può quindi pianificare i pod che vengono eseguiti come istanze di Istanze di Azure Container tramite i nodi virtuali e non come pod sui nodi macchina virtuale direttamente nel cluster del servizio Azure Kubernetes.

L'applicazione non richiede modifiche per l'uso dei nodi virtuali. Le distribuzioni possono essere ridimensionate tra il servizio Azure Kubernetes e Istanze di Azure Container e senza alcun ritardo perché utilità di scalabilità automatica del cluster distribuisce nuovi nodi nel cluster del servizio Azure Kubernetes.

I nodi virtuali vengono distribuiti in un'altra subnet nella stessa rete virtuale del cluster del servizio Azure Kubernetes. Questa configurazione di rete virtuale protegge il traffico tra Istanze di Azure Container e servizio Azure Kubernetes. Come un cluster del servizio Azure Kubernetes, un'istanza di Istanze di Azure Container è una risorsa di calcolo logica e sicura isolata dagli altri utenti.

Passaggi successivi

Per iniziare a ridimensionare le applicazioni, vedere le risorse seguenti:

Per altre informazioni sui concetti fondamentali di Kubernetes e del servizio Azure Kubernetes, vedere gli articoli seguenti: