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

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

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.

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è l’esperienza AKS predefinita consigliata. AKS Automatic è pronto per l’uso in produzione per impostazione predefinita e include VPA come funzionalità del cluster preconfigurata. In AKS Standard, si configura e si gestisce VPA in modo esplicito.

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 gli altri pod e contribuisce a garantire un utilizzo efficace dei cluster AKS. Il Vertical Pod Autoscaler fornisce raccomandazioni per l'ottimizzazione dell'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.

Per altre informazioni sul servizio Azure Kubernetes automatico, vedere Che cos'è Servizio Azure Kubernetes (AKS) automatico?

VPA nel servizio Azure Kubernetes automatico e nel servizio Azure Kubernetes standard

VPA è disponibile in entrambe le modalità del cluster AKS, ma la configurazione differisce:

• AKS Automatic: VPA è preconfigurato.
• AKS Standard: VPA è opzionale e configurata esplicitamente.

Per la maggior parte degli scenari di produzione, inizia con AKS Automatic per usare impostazioni predefinite adatte all'uso in produzione e ridurre il sovraccarico operativo.

Vantaggi

Vertical Pod Autoscaler offre i vantaggi seguenti:

• Analizza e regola le risorse di processore e memoria, in modo da dimensionare correttamente le applicazioni. VPA non consente solo l'incremento delle risorse ma anche la loro riduzione in base all'uso delle risorse 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 garantisce un supporto ottimale per un massimo di 1.000 pod per ogni cluster associato agli VerticalPodAutoscaler oggetti. Man mano che il numero di pod monitorati aumenta, il consumo di memoria aumenta in tutti i componenti VPA, in particolare per il consigliatore, che potrebbe influire sulla scalabilità.
• 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. È supportato avere un modulo di raccomandazione aggiuntivo o personalizzato.
• I contenitori Windows AKS 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 loro controller in base all'attività dello strumento di aggiornamento.

Controller di ammissione VPA

Il controller di ammissione VPA è un binario che si autoregistra come Webhook di ammissione mutante. 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 Vertical Pod Autoscaler, in genere una distribuzione, viene inserita per ogni controller di cui si vuole calcolare automaticamente i requisiti di risorse.

Esistono quattro modalità di funzionamento di VPA:

• 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 InPlaceOrRecreate la modalità , che sfrutta gli aggiornamenti senza riavvio quando possibile.
• InPlaceOrRecreate: In modalità InPlaceOrRecreate, VPA tenta di aggiornare le richieste di risorse del Pod e i limiti senza riavviare il Pod quando possibile. Tuttavia, se gli aggiornamenti sul posto non possono essere eseguiti per una determinata modifica della risorsa, VPA torna a sfrattare il Pod (simile alla modalità Ricrea) e consente al controller del carico di lavoro di creare un Pod sostitutivo con risorse aggiornate. Questa modalità è disponibile nel servizio Azure Kubernetes 1.34+.
  • Per provare InPlaceOrRecreate la modalità, seguire le istruzioni dettagliate.
  • In questa modalità, il programma di aggiornamento applica direttamente le raccomandazioni utilizzando la funzione di ridimensionamento delle risorse del contenitore in loco.
  • Per altre informazioni, vedere la documentazione degli Aggiornamenti sul posto a monte.
• 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 di 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, usare il modello di distribuzione seguente durante lo sviluppo di applicazioni per identificare le caratteristiche di utilizzo univoco delle risorse di ogni applicazione, testare la VPA per verificare che funzioni correttamente e testare insieme ad altri componenti Kubernetes per ottimizzare l'utilizzo delle risorse 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 effettivi sull'utilizzo delle risorse in un determinato periodo di tempo. Questi dati di telemetria consentono di comprendere il comportamento e i segni di problemi derivanti dalle risorse contenitore e pod influenzati dai carichi di lavoro in esecuzione su tali contenitori e pod.
3. Acquisire familiarità con i dati di monitoraggio per comprendere le caratteristiche delle prestazioni. In base a queste informazioni, impostare le richieste/i limiti desiderati e nella distribuzione o nell'aggiornamento successivo.
4. Impostare il valore updateMode su Recreate, InPlaceOrRecreate o Initial a seconda delle esigenze.

In AKS Automatic, VPA è già disponibile come funzionalità preconfigurata, quindi è opportuno concentrarsi sull'ottimizzazione dei criteri e della modalità. In AKS Standard, completare la configurazione di VPA prima di applicare lo schema di rollout.

Contenuti correlati

• Creare un cluster automatico Servizio Azure Kubernetes (AKS)
• Usare il controller di scalabilità automatica verticale dei pod nel servizio Azure Kubernetes