Scalabilità automatica verticale dei pod

Questa pagina spiega come analizzare e ottimizzare l'allocazione delle risorse per migliorare l'efficienza dei workload in Google Kubernetes Engine (GKE) utilizzando la scalabilità automatica verticale dei pod. Analizzando l'utilizzo delle risorse del tuo workload nel tempo, puoi ricevere suggerimenti di ottimizzazione e regolare automaticamente le richieste di CPU e memoria, nonché i limiti per i container all'interno dei pod.

In questa pagina scoprirai come funziona la scalabilità automatica verticale dei pod, i suoi vantaggi e i suoi limiti, le best practice per utilizzarla e come accedere ai riferimenti API per la risorsa personalizzata VerticalPodAutoscaler e i tipi correlati.

Questa pagina è rivolta agli operatori e agli sviluppatori che eseguono il provisioning e la configurazione delle risorse cloud, il deployment dei workload e la gestione della scalabilità delle applicazioni. Per scoprire di più sui ruoli comuni, consulta Ruoli e attività utente GKE comuni.

Prima di leggere questa pagina, assicurati di avere familiarità con le richieste e i limiti delle risorse in Kubernetes.

Per esigenze di scalabilità rapida in risposta a un utilizzo improvviso delle risorse, utilizza Horizontal Pod Autoscaler.

Per scoprire le best practice per la scalabilità automatica, consulta Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Perché utilizzare la scalabilità automatica verticale dei pod

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

• Impostare richieste e limiti di risorse corretti per i tuoi workload migliora la stabilità e l'efficienza in termini di costi. Se le dimensioni delle risorse dei pod sono inferiori a quelle richieste dai workload, l'applicazione può essere limitata o non riuscire a causa di errori di memoria esaurita. Se le dimensioni delle risorse sono troppo grandi, si verificano sprechi e, di conseguenza, fatture più elevate.
• I nodi del cluster vengono utilizzati in modo efficiente perché i pod utilizzano esattamente ciò di cui hanno bisogno.
• I pod vengono pianificati sui nodi che hanno le risorse appropriate disponibili.
• Non devi eseguire attività di benchmarking che richiedono molto tempo per determinare i valori corretti per le richieste di CPU e memoria.
• Puoi ridurre i tempi di manutenzione perché il gestore della scalabilità automatica può regolare le richieste di CPU e memoria nel tempo senza alcun intervento da parte tua.
• La scalabilità automatica verticale dei pod funziona meglio con workload omogenei a lunga esecuzione.

La scalabilità automatica verticale dei pod di GKE offre i seguenti vantaggi rispetto al gestore della scalabilità automatica di Kubernetes open source:

• Tiene conto delle dimensioni massime dei nodi e delle quote delle risorse quando determina il target dei suggerimenti.
• Invia una notifica al gestore della scalabilità automatica dei cluster per regolare la capacità del cluster.
• Utilizza i dati storici, incluse le metriche raccolte prima dell'attivazione di VerticalPodAutoscaler.
• Esegue i pod VerticalPodAutoscaler come processi del control plane, anziché come deployment sui nodi worker.

Come funziona la scalabilità automatica verticale dei pod

La scalabilità automatica verticale dei pod consente di analizzare e impostare le risorse di CPU e memoria richieste dai pod. Anziché dover impostare richieste e limiti di CPU e richieste e limiti di memoria aggiornati per i container nei pod, puoi configurare la scalabilità automatica verticale dei pod in modo che fornisca valori consigliati per richieste e limiti di CPU e memoria che puoi utilizzare per aggiornare manualmente i pod oppure puoi configurare la scalabilità automatica verticale dei pod in modo che aggiorni automaticamente i valori.

La scalabilità automatica verticale dei pod è abilitata per impostazione predefinita nei cluster Autopilot.

Relazione con VerticalPodAutoscaler open source di Kubernetes

La scalabilità automatica verticale dei pod di GKE si basa sull'API Kubernetes open source VerticalPodAutoscaler, ma è un'implementazione separata, esclusiva di GKE. L'implementazione di GKE è progettata per la scalabilità con il proprio motore per suggerimenti, ma mantiene gli stessi tipi e campi dell'API VerticalPodAutoscaler definiti nella versione open source.

Per saperne di più, consulta la documentazione di Kubernetes sulla scalabilità automatica verticale dei pod.

Modalità di scalabilità automatica verticale dei pod

Puoi configurare il modo in cui la scalabilità automatica verticale dei pod applica le modifiche alle risorse applicando diverse modalità di aggiornamento.

Modalità Auto (Recreate)

In modalità Recreate, la scalabilità automatica verticale dei pod evita un pod se deve modificare le richieste di risorse del pod. L'espulsione è necessaria perché, a causa delle limitazioni di Kubernetes nelle versioni precedenti alla 1.33, l'unico modo per modificare le richieste di risorse di un pod in esecuzione è ricrearlo.

Per limitare la quantità di ricreazioni dei pod, utilizza un budget per l'interruzione dei pod . Per assicurarti che il cluster possa gestire le nuove dimensioni dei workload, utilizza il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi.

La scalabilità automatica verticale dei pod invia una notifica al gestore della scalabilità automatica dei cluster prima dell'aggiornamento e fornisce le risorse necessarie per il workload ridimensionato prima di ricrearlo, in modo da ridurre al minimo i tempi di interruzione.

Modalità Initial

Con Initial abilitato, la scalabilità automatica verticale dei pod assegna le richieste di risorse solo al momento della creazione dei pod e non le modifica mai in un secondo momento.

Modalità InPlaceOrRecreate

La modalità InPlaceOrRecreate mira a ridurre l'interruzione del servizio tentando di aggiornare le risorse dei pod senza ricrearli.

Per utilizzare la modalità InPlaceOrRecreate, imposta il campo spec.updatePolicy.updateMode su "InPlaceOrRecreate" nell'oggetto VerticalPodAutoscaler. Questa modalità si basa sul campo resizePolicy definito nel manifest del workload per determinare se una modifica della risorsa richiede un riavvio. Se il campo resizePolicy non è definito, il valore predefinito è NotRequired per CPU e memoria, il che significa che vengono tentati aggiornamenti in loco.

Se un container termina a causa di un evento OOM (Out of Memory), la scalabilità automatica verticale dei pod in modalità InPlaceOrRecreate agisce in modo simile alla modalità Auto: impara dall'errore. Al momento della successiva ricreazione del pod attivata dall'arresto anomalo, la scalabilità automatica verticale dei pod applica un suggerimento che include un buffer di sicurezza (in genere il 20% di memoria aggiuntiva o 100 MB, a seconda di quale sia il valore maggiore) per impedire la ripetizione immediata dell'errore OOM.

La modalità InPlaceOrRecreate è disponibile con Kubernetes versione 1.34.0-gke.2201000 e successive.

Scenari di riserva per la modalità InPlaceOrRecreate

Se la scalabilità automatica verticale dei pod determina che un aggiornamento in loco non è possibile, viene ripristinato il comportamento della modalità Recreate, che espelle e ricrea il pod per applicare le modifiche. Alcuni scenari comuni in cui la scalabilità automatica verticale dei pod esegue il fallback alla nuova creazione includono:

• Capacità del nodo insufficiente: la richiesta di risorse aggiornata supera la capacità allocabile del nodo corrente e l'aggiornamento non può essere pianificato in loco (stato "non fattibile" o "differito" per un periodo di tempo superiore a un timeout).
• Modifica della classe QoS: l'aggiornamento della risorsa modificherebbe la classe Quality of Service (QoS) del pod, ad esempio da Burstable a Guaranteed.
• Policy RestartContainer:il campo resizePolicy del pod è impostato su RestartContainer per una risorsa che la scalabilità automatica verticale dei pod sta tentando di modificare.
• Timeout: una richiesta di aggiornamento in loco rimane in stato di attesa per troppo tempo.

Modalità Off

In modalità Off, la scalabilità automatica verticale dei pod non applica automaticamente alcuna modifica a un pod. Puoi comunque visualizzare i valori consigliati per le richieste e i limiti di CPU e memoria in base all'utilizzo storico, ma questi suggerimenti non vengono applicati. Se necessario, puoi applicare manualmente i valori consigliati ai pod.

Burst di CPU all'avvio

L'avvio della CPU all'avvio accelera l'avvio dell'applicazione e migliora l'efficienza in termini di costi aumentando temporaneamente le richieste di CPU durante l'inizializzazione e ridimensionandole ai livelli di base in loco.

Per saperne di più su come configurare l'aumento della CPU all'avvio, consulta Accelera l'avvio delle applicazioni con l'aumento della CPU all'avvio.

Come funziona il bursting della CPU all'avvio

L'avvio CPU temporaneo calcola un aumento temporaneo delle risorse in base alla richiesta di CPU di base del container. Il pod torna a questo livello di richiesta di base dopo la fase di avvio.

Il boost aumenta questa richiesta di base di un moltiplicatore o di una quantità fissa. Questa richiesta elevata rimane attiva finché il pod non è pronto, dopodiché GKE ripristina la richiesta di CPU al livello di base.

Informazioni sul ciclo di vita del boost

Il processo di avvio rapido è costituito da tre fasi:

1. Fase di ammissione: durante l'ammissione dei pod, il webhook di ammissione VPA intercetta la richiesta e inserisce i valori della CPU potenziata prima che GKE pianifichi il pod.
2. Fase di avvio: l'applicazione viene inizializzata utilizzando l'allocazione della CPU temporaneamente elevata per evitare la limitazione dell'inizializzazione.
3. Fase di unboosting: dopo che il pod raggiunge lo stato Ready e il periodo durationSeconds è trascorso, VPA riduce in loco la richiesta di CPU al valore di base.

Scegli una modalità di aggiornamento per i workload con scaling

Puoi configurare l'avvio CPU temporaneo con o senza la gestione continua delle risorse di VPA. La gestione continua delle risorse di VPA regola automaticamente le richieste di risorse dei pod al termine della fase di avvio. Per scegliere la tua preferenza, imposta il campo updateMode nell'oggetto VPA. Per saperne di più sulle modalità di aggiornamento di VPA, consulta Modalità di scalabilità automatica verticale dei pod.

• updateMode: "Off": VPA gestisce solo l'incremento iniziale durante l'ammissione del pod (una fase della creazione del pod) e il successivo scale down dopo l'avvio. Non modifica le richieste di risorse in stato stabile del container.
• updateMode: "Auto", "Recreate" o "InPlaceOrRecreate": VPA gestisce l'avvio rapido e continua ad adeguare automaticamente le richieste di risorse del pod in base all'utilizzo in corso.

Come viene calcolata l'allocazione delle risorse di CPU Boost

GKE calcola la richiesta di CPU con scalabilità temporanea nel seguente modo:

1. Determina la CPU di base: la richiesta di CPU di base dipende dal campo updateMode del VPA:

   • Auto, Recreate o InPlaceOrRecreate: la richiesta di CPU di base è il suggerimento di VPA. Se non esiste alcun suggerimento, GKE utilizza la richiesta di CPU definita nella specifica del pod.
   • Off: la richiesta di CPU di base è il valore della richiesta dalla specifica del pod.

2. Calcola la CPU con boost: il calcolo dipende dal metodo di calcolo specificato nel campo type della configurazione del boost:

   • Factor: applica un moltiplicatore alla richiesta di CPU di base:

     CPU con boost  =  CPU di base × factor

   • Quantity: aggiunge una quantità di CPU assoluta alla richiesta di CPU di base:

     CPU con boosting  =  CPU di base + quantity

La richiesta di CPU finale dipende dalla modalità del cluster:

• Cluster Standard: la richiesta di CPU finale è il valore della CPU con boost.
• Cluster Autopilot: la richiesta di CPU finale è il valore della CPU con boost, limitato dalla CPU massima consentita per la memoria del pod allocata.

Comprendi il comportamento del limite di CPU durante un boost

Il modo in cui GKE gestisce i limiti della CPU dipende dall'impostazione controlledValues in containerResourcePolicy:

• RequestsAndLimits (predefinito): GKE aumenta sia la richiesta sia il limite della CPU, mantenendo il rapporto originale per preservare la classe Quality of Service (QoS) del container.
• RequestsOnly: GKE aumenta solo la richiesta di CPU. GKE limita la richiesta con scalabilità appena al di sotto di qualsiasi limite di CPU definito per preservare la QoS.

Considerazioni per i cluster Autopilot

Poiché GKE Autopilot applica intervalli di rapporto CPU/memoria specifici e dimensioni minime dei pod, GKE valuta i boost durante l'ammissione dei pod per garantire la conformità. Un boost potrebbe essere modificato o ignorato nei seguenti scenari:

• Minimi di Autopilot: se la richiesta con boost è inferiore ai requisiti minimi della CPU per i workload Autopilot (ad esempio, 50 m per i pod per uso generico), GKE non applica il boost e applica i minimi standard.
• Limitazione del rapporto (boost parziali o saltati): se la richiesta di CPU con boost supera l'intervallo del rapporto CPU/memoria richiesto, GKE limita il boost al valore più alto che rispetta la memoria allocata. Se la richiesta del pod originale utilizza già il rapporto CPU/memoria massimo consentito, GKE salta l'incremento per evitare il ridimensionamento della memoria.
• Scale-Out ComputeClass: Scale-Out ComputeClass applica un rapporto rigoroso di 1:4 (CPU:memoria). Se provi a eseguire lo scale out della CPU su un pod con scale out senza aumentarne la memoria, GKE potrebbe ignorare il boost.

Policy delle risorse

Puoi utilizzare ContainerResourcePolicy per personalizzare il modo in cui la scalabilità automatica verticale dei pod genera i suggerimenti per container specifici. Questa policy ti consente di impostare vincoli e controllare quali risorse vengono scalate.

Limiti minimi e massimi

Puoi specificare i valori minimi (minAllowed) e massimi (maxAllowed) delle risorse per un container.

• minAllowed: la scalabilità automatica verticale dei pod non consiglierà un valore inferiore a questo limite. Questo limite è utile perché contribuisce a garantire un livello di prestazioni di base o a soddisfare i requisiti specifici dell'applicazione.
• maxAllowed: la scalabilità automatica verticale dei pod non consiglierà un valore superiore a questo limite. Questo limite è utile per controllare i costi o impedire a un singolo container di consumare troppe risorse del nodo.

Risorse controllate

Per impostazione predefinita, la scalabilità automatica verticale dei pod calcola i suggerimenti sia per la CPU sia per la memoria. Puoi utilizzare il campo controlledResources per specificare le risorse da scalare automaticamente. Ad esempio, puoi configurare il gestore della scalabilità automatica in modo che fornisca suggerimenti solo per la memoria, lasciando invariate le richieste di CPU.

Limitazioni

• Per utilizzare la scalabilità automatica verticale dei pod con la scalabilità automatica orizzontale dei pod sulla CPU, utilizza il dimensionamento ottimale di HPA con VPA (anteprima) o la scalabilità automatica multidimensionale dei pod. Puoi anche utilizzare la scalabilità automatica verticale dei pod con la scalabilità automatica orizzontale dei pod su metriche personalizzate ed esterne.
• La scalabilità automatica verticale dei pod non è pronta per l'uso con i workload basati su JVM a causa della visibilità limitata sulla memoria utilizzata effettiva del workload.
• In GKE versione 1.35.1 e precedenti, la scalabilità automatica verticale dei pod ha un'impostazione predefinita di due repliche minime per i deployment per sostituire i pod con valori delle risorse rivisti. Nella versione 1.35.2 e successive, il valore predefinito è una replica minima. Nella versione 1.22 e successive, puoi eseguire l'override di questa impostazione specificando un valore per il campo minReplicas nel campo PodUpdatePolicy.
• Se utilizzi la modalità di aggiornamento InPlaceOrRecreate della scalabilità automatica verticale dei pod e non è possibile eseguire un aggiornamento in loco (ad esempio, quando esegui lo scale up del pod oltre la capacità del nodo), la scalabilità automatica verticale dei pod espelle e ricrea il pod per applicare il suggerimento. L'espulsione e la nuova creazione avvengono anche per i pod che hanno un campo resizePolicy impostato nella specifica per evitare nuove creazioni. Questo comportamento si verifica per le richieste di ridimensionamento di Autopilot, anche quando si applicano vincoli relativi alle risorse minime e al rapporto CPU:memoria.
• La scalabilità automatica verticale dei pod richiede un oggetto workload che gestisca i pod, ad esempio un Deployment, un StatefulSet, un ReplicaSet o un ReplicationController. Non puoi utilizzare la scalabilità automatica verticale dei pod con i pod autonomi perché è necessario un controller del workload per gestire il processo di ricreazione dei pod.
• La scalabilità automatica verticale dei pod genera suggerimenti e applica aggiornamenti solo alle richieste e ai limiti delle risorse a livello di container (spec.containers[].resources). La scalabilità automatica verticale dei pod non supporta le specifiche delle risorse a livello di pod (spec.resources).

Best practice

• Limita il numero di oggetti VerticalPodAutoscaler. Per evitare interruzioni degli aggiornamenti del cluster, devi mantenere il numero di oggetti VerticalPodAutoscaler per cluster inferiore a 1000.
• La scalabilità automatica verticale dei pod funziona meglio con workload omogenei a lunga esecuzione.
  • La scalabilità automatica verticale dei pod richiede una quantità significativa di dati storici per generare suggerimenti ad alta affidabilità. In modalità Auto o Recreate, gli aggiornamenti di solito vengono eseguiti dopo che un pod ha almeno 24 ore, il che aiuta a evitare frequenti riavvii e abbandoni dei pod.
  • Omogeneità: i pod scelti come target da un singolo oggetto VerticalPodAutoscaler (ad esempio tutte le repliche in un deployment) devono mostrare pattern di consumo delle risorse simili. Il Vertical Pod Autoscaler genera suggerimenti aggregando i dati di utilizzo di tutti i pod target. Se le repliche hanno un utilizzo eterogeneo, ad esempio alcuni pod sono inattivi e altri sono molto carichi, il Vertical Pod Autoscaler potrebbe fornire un suggerimento che esegue l'overprovisioning dei pod inattivi o l'underprovisioning di quelli occupati.
• Utilizza la scalabilità automatica orizzontale dei pod per i workload con picchi improvvisi di domanda. La scalabilità automatica verticale dei pod è progettata per il dimensionamento ottimale in stato stabile e non è una soluzione per picchi di risorse improvvisi e di breve durata. Per i workload con fluttuazioni rapide del traffico o della domanda di CPU o memoria, utilizza invece il gestore della scalabilità automatica orizzontale dei pod.
• Sfrutta la protezione OOM. Sebbene il Vertical Pod Autoscaler sia reattivo, include una protezione automatizzata contro gli eventi di memoria esaurita (OOM). Se un pod è OOMKilled, Vertical Pod Autoscaler osserva immediatamente l'evento e aumenta il suggerimento per la memoria di circa il 20% (o 100 MB, a seconda di quale sia il valore maggiore) per migliorare la stabilità quando il pod viene ricreato. Per saperne di più sugli eventi OOM, consulta Risolvi i problemi relativi agli eventi OOM.

Riferimento API

Questo è il riferimento API di v1. Ti consigliamo vivamente di utilizzare questa versione dell'API.

VerticalPodAutoscaler v1 autoscaling.k8s.io

Campi
	TypeMeta Gruppo, versione e tipo di API.
metadata	ObjectMeta Metadati degli oggetti standard.
spec	VerticalPodAutoscalerSpec Il comportamento di VerticalPodAutoscaler.
status	VerticalPodAutoscalerStatus Lo stato osservato più di recente di VerticalPodAutoscaler.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

Campi
targetRef	CrossVersionObjectReference Riferimento al controller che gestisce l'insieme di pod che il gestore della scalabilità automatica deve controllare, ad esempio un deployment o un set di repliche. Puoi indirizzare un VerticalPodAutoscaler a qualsiasi controller che abbia una risorsa secondaria Scale. In genere, VerticalPodAutoscaler recupera il set di pod da ScaleStatus del controller. Per alcuni controller noti, ad esempio DaemonSet, VerticalPodAutoscaler recupera il set di pod dalla specifica del controller.
updatePolicy	PodUpdatePolicy Specifica se gli aggiornamenti consigliati vengono applicati all'avvio di un pod e se vengono applicati durante il ciclo di vita di un pod.
resourcePolicy	PodResourcePolicy Specifica le policy per la regolazione delle richieste di CPU e memoria per i singoli container. La policy delle risorse può essere utilizzata per impostare vincoli sui suggerimenti per i singoli container. Se non specificato, il gestore della scalabilità automatica calcola le risorse consigliate per tutti i container nel pod, senza vincoli aggiuntivi.
recommenders	VerticalPodAutoscalerRecommenderSelector array Il motore per suggerimenti responsabile della generazione dei suggerimenti per questo oggetto VPA. Lascia vuoto per utilizzare il motore per suggerimenti predefinito fornito da GKE. In caso contrario, l'elenco può contenere esattamente una voce per un suggeritore alternativo fornito dall'utente. Supportato a partire da GKE 1.22.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

Campi
	TypeMeta Gruppo, versione e tipo di API.
metadata	ObjectMeta Metadati degli oggetti standard.
items	VerticalPodAutoscaler array Un elenco di oggetti VerticalPodAutoscaler.

PodUpdatePolicy v1 autoscaling.k8s.io

Campi
updateMode	string Specifica se gli aggiornamenti consigliati vengono applicati all'avvio di un pod e se vengono applicati durante il ciclo di vita di un pod. I valori possibili sono i seguenti: "Off": gli aggiornamenti consigliati vengono generati, ma non vengono applicati automaticamente al pod. "Initial": gli aggiornamenti consigliati vengono applicati solo al primo avvio di un pod. Gli aggiornamenti che si verificano mentre il pod è già in esecuzione non vengono applicati automaticamente. "Recreate": gli aggiornamenti consigliati vengono applicati ricreando il pod. Il pod esistente viene terminato e viene creato un nuovo pod con la configurazione aggiornata. "Auto": il valore predefinito che applica essenzialmente la modalità "Recreate". "InPlaceOrRecreate": gli aggiornamenti consigliati vengono applicati senza ricreare il pod, se possibile.
minReplicas	int32 Il numero minimo di repliche che devono essere attive per tentare l'eliminazione dei pod (in attesa di altri controlli come il budget di interruzione dei pod). Sono consentiti solo valori positivi. Il valore predefinito è 1 in GKE versione 1.35.2 e successive e 2 nella versione 1.35.1 e precedenti. Supportato a partire da GKE 1.22.

PodResourcePolicy v1 autoscaling.k8s.io

Campi
containerPolicies	ContainerResourcePolicy array Un array di policy delle risorse per i singoli container. Può essere presente al massimo una voce per ogni container denominato e, facoltativamente, una singola voce con carattere jolly con "containerName = '*'", che gestisce tutti i container che non hanno policy individuali.

ContainerResourcePolicy v1 autoscaling.k8s.io

Campi
containerName	string Il nome del container a cui si applica la policy. Se non specificata, la policy funge da policy predefinita.
mode	ContainerScalingMode Specifica se gli aggiornamenti consigliati vengono applicati al container all'avvio e se vengono applicati durante la durata del container. I valori possibili sono "Off" e "Auto". Se non specifichi un valore, l'impostazione predefinita è"Auto".
minAllowed	ResourceList Specifica la richiesta minima di CPU e memoria consentita per il container. Per impostazione predefinita, non viene applicato alcun limite minimo.
maxAllowed	ResourceList Specifica la richiesta di CPU e la richiesta di memoria massime consentite per il container. Per impostazione predefinita, non viene applicato alcun limite massimo.
controlledResources	[]ResourceName Specifica il tipo di suggerimenti che verranno calcolati (ed eventualmente applicati) da VerticalPodAutoscaler. Se il campo è vuoto, viene utilizzato il valore predefinito [ResourceCPU, ResourceMemory].

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

Campi
name	string Nome del motore per suggerimenti responsabile della generazione del suggerimento per questo oggetto.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

Campi
recommendation	RecommendedPodResources Le richieste di CPU e memoria consigliate più di recente.
conditions	VerticalPodAutoscalerCondition array Descrive lo stato attuale di VerticalPodAutoscaler.

RecommendedPodResources v1 autoscaling.k8s.io

Campi
containerRecommendations	RecommendedContainerResources array Un array di suggerimenti sulle risorse per i singoli container.

RecommendedContainerResources v1 autoscaling.k8s.io

Campi
containerName	string Il nome del container a cui si applica il suggerimento.
target	ResourceList La richiesta di CPU e la richiesta di memoria consigliate per il container.
lowerBound	ResourceList La richiesta di CPU e la richiesta di memoria minime consigliate per il container. Non è garantito che questo importo sia sufficiente per la stabilità dell'applicazione. L'esecuzione con richieste di CPU e memoria inferiori potrebbe avere un impatto significativo sulle prestazioni o sulla disponibilità.
upperBound	ResourceList La richiesta di CPU e la richiesta di memoria massime consigliate per il container. Le richieste di CPU e memoria superiori a questi valori potrebbero essere sprecate.
uncappedTarget	ResourceList Il suggerimento più recente sulle risorse calcolato dal gestore della scalabilità automatica, in base all'utilizzo effettivo delle risorse, senza tenere conto di ContainerResourcePolicy. Se l'utilizzo effettivo delle risorse fa sì che la destinazione violi ContainerResourcePolicy, questo valore potrebbe essere diverso dal suggerimento limitato. Questo campo non influisce sull'assegnazione effettiva delle risorse. Viene utilizzato solo come indicazione dello stato.

VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

Campi
type	VerticalPodAutoscalerConditionType Il tipo di condizione descritta. I valori possibili sono "RecommendationProvided", "LowConfidence", "NoPodsMatched" e "FetchingHistory".
status	ConditionStatus Lo stato della condizione. I valori possibili sono True, False e Unknown.
lastTransitionTime	Time L'ultima volta che la condizione ha eseguito una transizione da uno stato a un altro.
reason	string Il motivo dell'ultima transizione da uno stato all'altro.
message	string Una stringa leggibile che fornisce dettagli sull'ultima transizione da uno stato all'altro.

Passaggi successivi

• Scopri come configurare la scalabilità automatica verticale dei pod.
• Scopri come ridimensionare in modo ottimale i workload HPA con VPA.
• Scopri come accelerare l'avvio delle applicazioni utilizzando l'avvio della CPU.
• Scopri di più sulla scalabilità automatica orizzontale dei pod.
• Scopri di più sul gestore della scalabilità automatica dei cluster.