Scalabilità automatica verticale dei pod nel servizio Azure Kubernetes (AKS)

Questo articolo offre una panoramica sull’utilizzo di Scalabilità automatica verticale dei pod (VPA) nel servizio Azure Kubernetes (AKS), che si basa sulla versione open source di Kubernetes.

Una volta configurato, VPA imposta automaticamente le richieste di risorse e i limiti dei contenitori per carico di lavoro in base all'utilizzo passato. VPA libera CPU e Memoria per altri pod e contribuisce a garantire un utilizzo efficace del cluster del servizio Azure Kubernetes. La Scalabilità automatica verticale dei pod fornisce raccomandazioni per l'utilizzo delle risorse nel tempo. Per gestire gli aumenti improvvisi dell'utilizzo delle risorse, usare Horizontal Pod Autoscaler, che ridimensiona il numero di repliche pod in base alle esigenze.

Vantaggi

La Scalabilità automatica verticale dei pod offre i vantaggi seguenti:

• Analizza e regola le risorse di processore e memoria, in modo da dimensionare correttamente le applicazioni. VPA non è responsabile solo dell'aumento, ma anche della riduzione delle risorse in base all'uso nel tempo.
• Un pod con una modalità di scalabilità impostata su auto o recreate viene rimosso se deve modificare le proprie richieste di risorse.
• È possibile impostare vincoli di CPU e memoria per singoli contenitori specificando un criterio di risorsa.
• Assicura che i nodi dispongano di risorse corrette per la pianificazione dei pod.
• Offre la possibilità di registrare in modo configurabile eventuali rettifiche apportate alle risorse del processore o della memoria.
• Migliora l'utilizzo delle risorse del cluster e libera CPU e memoria per altri pod.

Limitazioni e considerazioni

Quando si usa la Scalabilità automatica verticale dei pod, tenere presenti le limitazioni e le considerazioni seguenti:

• VPA supporta un massimo di 1.000 pod associati a oggetti VerticalPodAutoscaler per cluster.
• VPA potrebbe raccomandare l’utilizzo di più risorse rispetto a quelle disponibili nel cluster, impedendo così che il pod venga assegnato a un nodo ed eseguito a causa di risorse insufficienti. È possibile superare questa limitazione impostando LimitRange sul numero massimo di risorse disponibili per spazio dei nomi, che garantisce che i pod non richiedano più risorse di quanto specificato. È inoltre possibile impostare le raccomandazioni relative alle risorse massime consentite per pod in un oggetto VerticalPodAutoscaler. VPA non può superare completamente un problema dovuto all'insufficienza delle risorse del nodo. L'intervallo del limite è fisso, ma l'utilizzo delle risorse del nodo viene modificato in modo dinamico.
• Non è consigliabile usare VPA con la Scalabilità automatica orizzontale dei pod (HPA),che ridimensiona in base alle stesse metriche di utilizzo della CPU e della memoria.
• Il Sistema di raccomandazione di VPA archivia solo fino a otto giorni di dati cronologici.
• VPA non supporta carichi di lavoro basati su JVM a causa di una visibilità limitata sull'utilizzo effettivo della memoria del carico di lavoro.
• VPA non supporta l'esecuzione di una propria implementazione di VPA ad esso abbinata. È tuttavia supportato avere un modulo di raccomandazione aggiuntivo o personalizzato.
• I contenitori Windows del servizio Azure Kubernetes non sono supportati.

Panoramica di VPA

L'oggetto VPA è costituito da tre componenti:

• Sistema di raccomandazione: il sistema di raccomandazione monitora l'utilizzo delle risorse corrente e passato, tra cui la cronologia delle metriche, gli eventi di memoria esaurita (OOM) e le specifiche di distribuzione di VPA, quindi utilizza le informazioni raccolte per fornire valori consigliati per le richieste/limiti di CPU e Memoria del contenitore.
• Strumento di aggiornamento: lo strumento di aggiornamento monitora i pod gestiti per assicurarsi che le richieste di risorse siano impostate correttamente. In caso contrario, rimuove i pod in modo che i controller possano ricrearli con le richieste aggiornate.
• Controller di ammissione VPA: Il controller di ammissione VPA imposta le richieste di risorse corrette nei nuovi pod creati o ricreati dal controller in base all'attività dello Strumento di aggiornamento.

Controller di ammissione VPA

Il controller di ammissione VPA è un binario che si registra come Webhook di ammissione in mutazione. Quando viene creato un nuovo pod, il controller di ammissione VPA riceve una richiesta dal server API e valuta se è presente una configurazione VPA corrispondente o ne trova una, quindi utilizza la raccomandazione corrente per impostare le richieste di risorse nel pod.

Un processo autonomo denominato overlay-vpa-cert-webhook-check viene eseguito all'esterno del controller di ammissione VPA. Il processo overlay-vpa-cert-webhook-check crea e rinnova i certificati e registra il controller di ammissione VPA come MutatingWebhookConfiguration.

Modalità operative dell'oggetto VPA

Una risorsa di Scalabilità automatica verticale dei pod, in genere una distribuzione, viene inserita per ogni controller di cui si vuole calcolare automaticamente i requisiti delle risorse.

Esistono quattro modalità di funzionamento di VPA:

• Auto: VPA assegna le richieste di risorse durante la creazione del pod e aggiorna i pod esistenti tramite il meccanismo di aggiornamento preferito. Auto, che è equivalente a Recreate, rappresenta la modalità predefinita. Dopo il riavvio gratuito o sul posto, che può essere usato come meccanismo di aggiornamento preferito dalla modalità Auto, sono disponibili gli aggiornamenti delle richieste di pod. Attraverso la modalità Auto, VPA rimuove un pod se è necessario modificare le relative richieste di risorse. Ciò potrebbe causare il riavvio di tutti i pod contemporaneamente, il che può causare incoerenze dell'applicazione. È possibile limitare i riavvii e mantenere la coerenza in questa situazione tramite un PodDisruptionBudget.
• Recreate: VPA assegna le richieste di risorse durante la creazione del pod e aggiorna i pod esistenti, rimuovendoli quando le risorse richieste differiscono in modo significativo rispetto alle nuove raccomandazioni, rispettando in tal modo PodDisruptionBudget, se definito. È consigliabile usare questa modalità solo se è necessario garantire che i pod vengano riavviati ogni volta che la richiesta di risorse cambia. In caso contrario, è consigliabile usare la modalità Auto, che sfrutta gli aggiornamenti senza riavvio, una volta disponibili.
• Initial: VPA assegna le richieste di risorse solo durante la creazione del pod. Inoltre, non aggiorna i pod esistenti. Questa modalità è utile per testare e comprendere il comportamento di VPA senza influire sui pod in esecuzione.
• Off: VPA non modifica automaticamente i requisiti delle risorse dei pod. Le raccomandazioni vengono calcolate e possono essere esaminate nell'oggetto VPA.

Modello di distribuzione per lo sviluppo di applicazioni

Se non si ha familiarità con VPA, è consigliabile seguire il modello di distribuzione seguente durante lo sviluppo dell’applicazione per identificare le caratteristiche di utilizzo peculiari della risorsa, testare VPA per verificarne il corretto funzionamento e provarlo insieme ad altri componenti di Kubernetes, in modo da ottimizzare l'utilizzo della risorsa del cluster:

1. Impostare UpdateMode = "Off" nel cluster di produzione ed eseguire VPA in modalità di raccomandazione per testare e acquisire familiarità con VPA. UpdateMode = "Off" consente di evitare l'introduzione di una configurazione errata che può causare un'interruzione.
2. Stabilire prima l'osservabilità raccogliendo i dati di telemetria sull'utilizzo effettivo delle risorse in un determinato periodo di tempo, per comprendere il comportamento e gli eventuali indicatori di problemi delle risorse di contenitore e pod influenzati dai carichi di lavoro in esecuzione su di essi.
3. Acquisire familiarità con i dati di monitoraggio per comprendere le caratteristiche delle prestazioni. In base a queste informazioni, impostare le richieste/limiti desiderati di conseguenza e quindi nella distribuzione o aggiornamento successivo.
4. Impostare il valore updateMode su Auto, Recreate o Initial a seconda delle esigenze.

Passaggi successivi

Per informazioni su come configurare la Scalabilità automatica verticale dei pod nel cluster del servizio Azure Kubernetes, vedere Usare la Scalabilità automatica verticale dei pod nel servizio Azure Kubernetes.