Questa pagina spiega come analizzare e ottimizzare l'allocazione delle risorse per migliorare l'efficienza dei carichi di lavoro in Google Kubernetes Engine (GKE) utilizzando la scalabilità automatica verticale dei pod. Analizzando l'utilizzo delle risorse del tuo carico di lavoro nel tempo, puoi ricevere consigli per l'ottimizzazione e regolare automaticamente le richieste e i limiti di CPU e memoria per i container all'interno dei pod.
In questa pagina scopri come funziona la scalabilità automatica verticale dei pod, i suoi vantaggi e limiti, le best practice per utilizzarla e accedi ai Riferimenti API per la risorsa personalizzata VerticalPodAutoscaler e i tipi correlati.
Questa pagina è rivolta a operatori e sviluppatori che eseguono il provisioning e la configurazione delle risorse cloud, il deployment dei workload e la gestione dello scaling delle applicazioni. Per scoprire di più sui ruoli comuni, consulta Ruoli utente e attività comuni di GKE.
Prima di leggere questa pagina, assicurati di avere familiarità con richieste e 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 del pod sono inferiori a quelle richieste dai tuoi workload, l'applicazione può essere limitata o non funzionare a causa di errori di esaurimento della memoria. Se le dimensioni delle risorse sono troppo grandi, si verificano sprechi e, di conseguenza, le fatture sono più alte.
- 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 dispongono delle risorse appropriate.
- 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 di lunga durata.
La scalabilità automatica verticale dei pod 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 di risorse quando determina la destinazione del consiglio.
- Notifica al gestore della scalabilità automatica dei cluster di modificare 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 ti consente di analizzare e impostare le risorse di CPU e memoria richieste dai pod. Anziché dover configurare 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 per fornire valori consigliati per le richieste e i limiti di CPU e memoria che puoi utilizzare per aggiornare manualmente i pod oppure puoi configurare la scalabilità automatica verticale dei pod per aggiornare 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 univoca per 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 la modalità di applicazione delle modifiche alle risorse da parte della scalabilità automatica verticale dei pod applicando diverse modalità di aggiornamento.
Modalità Auto (Recreate)
In modalità Recreate, la scalabilità automatica verticale dei pod
espelle 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 il numero di ricreazioni dei pod, utilizza un budget di interruzione dei pod . Per assicurarti che il cluster possa gestire le nuove dimensioni dei tuoi workload, utilizza il gestore della scalabilità automatica del cluster e il provisioning automatico dei nodi.
La scalabilità automatica verticale dei pod invia una notifica al gestore della scalabilità automatica del cluster prima dell'aggiornamento e fornisce le risorse necessarie per il workload ridimensionato prima di ricrearlo, in modo da ridurre al minimo il tempo di interruzione.
Modalità Initial
Con Initial abilitato, la scalabilità automatica verticale dei pod assegna le richieste di risorse solo al momento della creazione del pod e non le modifica mai in seguito.
Modalità InPlaceOrRecreate
La modalità InPlaceOrRecreate mira a ridurre l'interruzione del servizio tentando di aggiornare le risorse del pod senza ricrearlo.
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 viene terminato a causa di un evento OOM (Out of Memory), la scalabilità automatica verticale dei pod in modalità InPlaceOrRecreate si comporta in modo simile alla modalità Auto: apprende 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 maggiore) per impedire l'immediata ripetizione dell'errore
OOM.
La modalità InPlaceOrRecreate è disponibile con Kubernetes versione
1.34.0-gke.2201000 e successive.
Scenari di fallback per la modalità InPlaceOrRecreate
Se la scalabilità automatica verticale dei pod determina che un aggiornamento in loco non è possibile,
torna al 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 torna alla ricreazione includono:
- Capacità del nodo insufficiente: la richiesta di risorse aggiornata supera la capacità allocabile del nodo corrente e l'aggiornamento non può essere pianificato sul posto (stato "non fattibile" o "posticipato" per un periodo di tempo superiore a un timeout).
- Modifica della classe QoS: l'aggiornamento della risorsa modificherebbe la classe Qualità del servizio (QoS) del pod, ad esempio da
BurstableaGuaranteed. - Criterio
RestartContainer:il camporesizePolicydel pod è impostato suRestartContainerper una risorsa che la scalabilità automatica verticale dei pod sta tentando di modificare. - Timeout:una richiesta di aggiornamento sul posto rimane in stato di attesa troppo a lungo.
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 automaticamente. Se necessario, puoi
applicare manualmente i valori consigliati ai tuoi Pod.
Boosting della CPU all'avvio
Il boost all'avvio della CPU accelera l'avvio dell'applicazione e migliora l'efficienza in termini di costi aumentando temporaneamente le richieste di CPU durante l'inizializzazione e ridimensionandole di nuovo ai livelli di base in loco.
Per ulteriori informazioni su come configurare il boosting della CPU all'avvio, consulta Accelerare l'avvio dell'applicazione con il boosting della CPU all'avvio.
Come funziona il boost della CPU all'avvio
L'avvio rapido della CPU 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.
L'incremento 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
La procedura di potenziamento delle startup è costituita da tre fasi:
- Fase di ammissione: durante l'ammissione del pod, l'webhook di ammissione VPA intercetta la richiesta e inserisce i valori della CPU aumentati prima che GKE pianifichi il pod.
- Fase di avvio: l'applicazione viene inizializzata utilizzando l'allocazione di CPU temporaneamente aumentata per evitare la limitazione dell'inizializzazione.
- Fase di riduzione: dopo che il pod raggiunge lo stato
Readye il periododurationSecondsè trascorso, VPA riduce la richiesta di CPU sul posto al valore di base.
Scegli una modalità di aggiornamento per i workload potenziati
Puoi configurare l'incremento dell'avvio della CPU con o senza la gestione continua delle risorse di VPA. La gestione continua delle risorse di VPA regola automaticamente le richieste di risorse del 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 la successiva riduzione dopo l'avvio. Non modifica le richieste di risorse in stato stazionario del container.updateMode: "Auto","Recreate"o"InPlaceOrRecreate": VPA gestisce l'incremento all'avvio e continua a modificare le richieste di risorse del pod automaticamente in base all'utilizzo in corso.
Come viene calcolata l'allocazione delle risorse di aumento della CPU
GKE calcola la richiesta temporanea di CPU aumentata nel seguente modo:
Determina la CPU di base: la richiesta di CPU di base dipende dal campo VPA
updateMode:Auto,RecreateoInPlaceOrRecreate: la richiesta di CPU di base è il suggerimento di VPA. Se non esiste alcun suggerimento, GKE torna alla richiesta di CPU definita nella specifica del pod.Off: la richiesta di CPU di base è il valore della richiesta della specifica del pod.
Calcola la CPU potenziata: il calcolo dipende dal metodo di calcolo specificato nel campo
typedella configurazione boost:Factor: applica un moltiplicatore alla richiesta di base della CPU:CPU con boost = CPU di base ×
factorQuantity: aggiunge una quantità assoluta di CPU alla richiesta di CPU di base:CPU potenziata = CPU di base +
quantity
La richiesta finale di CPU dipende dalla modalità del cluster:
- Cluster standard: la richiesta di CPU finale è il valore della CPU aumento.
- Cluster Autopilot: la richiesta di CPU finale è il valore della CPU aumentato, limitato dalla CPU massima consentita per la memoria pod allocata.
Comprendere il comportamento del limite della CPU durante un boost
Il modo in cui GKE gestisce i limiti della CPU dipende dall'impostazione controlledValues
nel tuo containerResourcePolicy:
RequestsAndLimits(impostazione predefinita): GKE aumenta sia la richiesta che il limite di 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 aumentata appena al di sotto di qualsiasi limite di CPU definito per preservare la qualità del servizio.
Considerazioni per i cluster Autopilot
Poiché GKE Autopilot applica intervalli specifici del rapporto CPU/memoria e dimensioni minime dei pod, GKE valuta gli incrementi durante l'ammissione dei pod per garantire la conformità. Un boost potrebbe essere modificato o ignorato nei seguenti scenari:
- Valori minimi di Autopilot: se la richiesta di boost è inferiore ai requisiti minimi di CPU per i carichi di lavoro Autopilot (ad esempio, 50 m per i pod di uso generico), GKE non applica il boost e applica i valori minimi standard.
- Limitazione del rapporto (boost parziali o ignorati): 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 di pod originale utilizza già il rapporto CPU/memoria massimo consentito, GKE salta l'aumento per evitare il ridimensionamento della memoria.
- Scale-Out ComputeClass: Scale-Out ComputeClass impone un rapporto rigoroso di 1:4 (CPU:memoria). Se provi ad aumentare la CPU di un pod di scalabilità orizzontale senza aumentare la memoria, GKE ignorerà l'aumento.
Policy delle risorse
Puoi utilizzare ContainerResourcePolicy per personalizzare il modo in cui Vertical Pod
Autoscaler genera consigli per container specifici. Questa policy ti consente di impostare vincoli e controllare le risorse di cui viene eseguito lo scale.
Limiti minimi e massimi
Puoi specificare i valori minimo (minAllowed) e massimo (maxAllowed) delle risorse per un container.
minAllowed: la scalabilità automatica verticale dei pod non consiglia un valore inferiore a questo limite. Questo limite è utile perché contribuisce a garantire un livello di prestazioni di base o a soddisfare 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
consigli 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 corretto 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
minReplicasnel campo PodUpdatePolicy. - Se utilizzi la modalità di aggiornamento
InPlaceOrRecreatedella scalabilità automatica verticale dei pod e un aggiornamento in loco non è possibile (ad esempio, quando aumenti le dimensioni 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 ricreazione si verificano anche per i pod che hanno un camporesizePolicyimpostato nella specifica per evitare ricreazioni. Questo comportamento si verifica per le richieste di ridimensionamento di Autopilot, anche quando vengono applicati vincoli di risorse minime e 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 ReplicationController. Non puoi utilizzare la scalabilità automatica verticale dei pod con i pod autonomi perché è necessario un controller del carico di lavoro per gestire il processo di ricreazione dei pod.
Best practice
- Limita il numero di oggetti
VerticalPodAutoscaler. Per evitare interruzioni dell'aggiornamento del cluster, devi mantenere il numero di oggettiVerticalPodAutoscalerper cluster inferiore a 1000. - La scalabilità automatica verticale dei pod funziona al meglio con workload omogenei a lunga esecuzione.
- A lunga esecuzione:workload eseguiti per almeno 24 ore. La scalabilità automatica verticale dei pod richiede
una quantità significativa di dati storici per generare suggerimenti
con un alto livello di confidenza. In modalità
AutooRecreate, gli aggiornamenti vengono in genere eseguiti dopo che un pod ha almeno 24 ore, il che contribuisce a evitare riavvii e churn frequenti dei pod. - Omogenei:i pod di destinazione di un singolo oggetto
VerticalPodAutoscaler(ad esempio tutte le repliche in un deployment) devono mostrare pattern di consumo delle risorse simili. Il gestore di scalabilità automatica pod verticale genera consigli aggregando i dati di utilizzo in tutti i pod di destinazione. Se le tue repliche hanno un utilizzo eterogeneo, ad esempio alcuni pod sono inattivi e altri sono molto carichi, il gestore della scalabilità automatica pod verticale potrebbe fornire un suggerimento che esegue il provisioning eccessivo dei pod inattivi o il provisioning insufficiente di quelli occupati.
- A lunga esecuzione:workload eseguiti per almeno 24 ore. La scalabilità automatica verticale dei pod richiede
una quantità significativa di dati storici per generare suggerimenti
con un alto livello di confidenza. In modalità
- Utilizza la scalabilità automatica orizzontale dei pod per i carichi di lavoro con picchi improvvisi di domanda. La scalabilità automatica verticale dei pod è progettata per il dimensionamento in stato stazionario e non è una soluzione per picchi di risorse improvvisi e di breve durata. Per i carichi di lavoro con rapide fluttuazioni del traffico o della domanda di CPU o memoria, utilizza il gestore della scalabilità automatica orizzontale dei pod invece.
- Sfrutta la protezione OOM. Sebbene il gestore della scalabilità automatica pod verticale sia reattivo, include la protezione automatica dagli eventi di esaurimento della memoria (OOM). Se un pod è
OOMKilled, il gestore della scalabilità automatica verticale dei pod 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 più alto) per migliorare la stabilità quando il pod viene ricreato. Per saperne di più sugli eventi OOM, vedi Risolvere i problemi relativi agli eventi OOM.
Riferimento API
Questo è il riferimento API v1. Ti consigliamo vivamente di utilizzare questa versione dell'API.
VerticalPodAutoscaler v1 autoscaling.k8s.io
| Campi | |
|---|---|
|
Gruppo, versione e tipo di API. |
metadata |
Metadati dell'oggetto standard. |
spec |
Il comportamento di |
status |
Lo stato osservato più di recente di |
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| Campi | |
|---|---|
targetRef |
Riferimento al controller che gestisce l'insieme di pod da
controllare per il gestore della scalabilità automatica, ad esempio un deployment o un StatefulSet.
Puoi puntare un |
updatePolicy |
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 |
Specifica le norme per la modalità di aggiustamento delle richieste di CPU e memoria per i singoli container. Il criterio delle risorse può essere utilizzato per impostare vincoli sui consigli 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 |
Il motore per suggerimenti responsabile della generazione dei suggerimenti per questo oggetto VPA. Lascia vuoto per utilizzare il sistema di suggerimenti predefinito fornito da GKE. In caso contrario, l'elenco può contenere esattamente una voce per un motore per suggerimenti alternativo fornito dall'utente. Supportato a partire da GKE 1.22. |
VerticalPodAutoscalerList v1 autoscaling.k8s.io
| Campi | |
|---|---|
|
Gruppo, versione e tipo di API. |
metadata |
Metadati dell'oggetto standard. |
items |
Un elenco di oggetti |
PodUpdatePolicy v1 autoscaling.k8s.io
| Campi | |
|---|---|
updateMode |
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:
|
minReplicas |
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 è |
PodResourcePolicy v1 autoscaling.k8s.io
| Campi | |
|---|---|
containerPolicies |
Un array di criteri delle risorse per i singoli container. Può essere presente al massimo una voce per ogni container denominato e, facoltativamente, una singola voce jolly con `containerName = '*'`, che gestisce tutti i container che non hanno policy individuali. |
ContainerResourcePolicy v1 autoscaling.k8s.io
| Campi | |
|---|---|
containerName |
Il nome del container a cui si applica la policy. Se non specificato, il criterio funge da criterio predefinito. |
mode |
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, il valore predefinito è "Auto". |
minAllowed |
Specifica la richiesta minima di CPU e memoria consentita per il container. Per impostazione predefinita, non viene applicato alcun limite minimo. |
maxAllowed |
Specifica la richiesta massima di CPU e di memoria consentita per il container. Per impostazione predefinita, non viene applicato alcun limite massimo. |
controlledResources |
Specifica il tipo di consigli che verranno calcolati (e
possibilmente applicati) da |
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| Campi | |
|---|---|
name |
Nome del motore per suggerimenti responsabile della generazione del suggerimento per questo oggetto. |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| Campi | |
|---|---|
recommendation |
Le richieste di CPU e memoria consigliate più di recente. |
conditions |
Descrive lo stato attuale di |
RecommendedPodResources v1 autoscaling.k8s.io
| Campi | |
|---|---|
containerRecommendations |
Un array di consigli sulle risorse per i singoli container. |
RecommendedContainerResources v1 autoscaling.k8s.io
| Campi | |
|---|---|
containerName |
Il nome del contenitore a cui si applica il consiglio. |
target |
La richiesta di CPU e la richiesta di memoria consigliate per il container. |
lowerBound |
La richiesta di CPU e memoria minima consigliata per il container. Non è garantito che questo importo sia sufficiente per la stabilità dell'applicazione. L'esecuzione con richieste di CPU e memoria più piccole probabilmente avrà un impatto significativo sulle prestazioni o sulla disponibilità. |
upperBound |
La richiesta di CPU e memoria massima consigliata per il container. È probabile che le richieste di CPU e memoria superiori a questi valori vengano sprecate. |
uncappedTarget |
Il consiglio sulle risorse più recente calcolato dallo strumento di scalabilità automatica, in base all'utilizzo effettivo delle risorse, senza tenere conto di ContainerResourcePolicy. Se l'utilizzo effettivo delle risorse fa sì che il target violi il ContainerResourcePolicy, questo valore potrebbe essere diverso dal consiglio vincolato. Questo campo non influisce sull'assegnazione effettiva delle risorse. Viene utilizzato solo come indicatore di stato. |
VerticalPodAutoscalerCondition v1 autoscaling.k8s.io
| Campi | |
|---|---|
type |
Il tipo di condizione descritta. I valori possibili sono "RecommendationProvided", "LowConfidence", "NoPodsMatched" e "FetchingHistory". |
status |
Lo stato della condizione. I valori possibili sono True, False e Unknown. |
lastTransitionTime |
L'ultima volta che la condizione è passata da uno stato all'altro. |
reason |
Il motivo dell'ultima transizione da uno stato all'altro. |
message |
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 dimensionare correttamente i workload HPA con VPA.
- Scopri come accelerare l'avvio delle applicazioni utilizzando il boost di avvio della CPU.
- Scopri di più sulla scalabilità automatica orizzontale dei pod.
- Scopri di più sul gestore della scalabilità automatica dei cluster.