Configura la scalabilità automatica del pod verticale

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi di lancio.

La scalabilità automatica verticale dei pod automatizza l'impostazione delle richieste di risorse di CPU e memoria e dei limiti per i container all'interno dei pod Kubernetes. La scalabilità automatica pod verticale analizza l'utilizzo delle risorse storico e attuale per fornire consigli, che può visualizzare o applicare automaticamente aggiornando i pod. Questa funzionalità migliora la stabilità e l'efficienza in termini di costi dimensionando correttamente le allocazioni delle risorse.

Prima di iniziare

Prima di configurare Scalabilità automatica pod verticale, assicurati di soddisfare i seguenti prerequisiti:

• Hai un cluster bare metal in esecuzione.
• Hai accesso kubectl al cluster.
• Metrics Server è disponibile nel cluster. I cluster bare metal includono Metrics Server per impostazione predefinita.

Abilita scalabilità automatica pod verticale

Abilita la scalabilità automatica verticale dei pod sul cluster bare metal impostando un'annotazione di anteprima e configurando la specifica del cluster:

1. Aggiungi o aggiorna l'annotazione di anteprima nella risorsa personalizzata Cluster.

   Modifica direttamente la risorsa personalizzata del cluster o il file di configurazione del cluster e utilizza bmctl update.

   metadata:
     annotations:
       preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
   

2. Modifica spec della risorsa personalizzata Cluster per includere il campo verticalPodAutoscaling e specifica le modalità enableUpdater e enableMemorySaver:

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: cluster1
     namespace: cluster-cluster1
     annotations:
       preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
   spec:
     # ... other cluster spec fields
     verticalPodAutoscaling:
       enableUpdater: true       # Set to true for automated updates
       enableMemorySaver: true   # Set to true to reduce recommender memory usage
   

3. Se hai modificato il file di configurazione del cluster, applica le modifiche utilizzando il seguente comando:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del tuo cluster.

   • KUBECONFIG: il percorso del file kubeconfig del cluster.

Crea una risorsa personalizzata VerticalPodAutoscaler

Dopo aver abilitato la scalabilità automatica verticale dei pod sul cluster, definisci una risorsa personalizzata VerticalPodAutoscaler per scegliere come target workload specifici:

1. Definisci una risorsa VerticalPodAutoscaler nello stesso spazio dei nomi del workload di destinazione.

   Questa risorsa personalizzata specifica i pod di destinazione utilizzando targetRef e qualsiasi criterio delle risorse.

   apiVersion: "autoscaling.k8s.io/v1"
   kind: VerticalPodAutoscaler
   metadata:
     name: hamster-vpa
   spec:
     targetRef:
       apiVersion: "apps/v1"
       kind: Deployment
       name: hamster
     resourcePolicy:
       containerPolicies:
         -   containerName: '*'
           minAllowed:
             cpu: 100m
             memory: 50Mi
           maxAllowed:
             cpu: 1
             memory: 500Mi
           controlledResources: ["cpu", "memory"]
   

2. Applica il manifest VerticalPodAutoscaler utilizzando questo comando:

   kubectl apply -f VPA_MANIFEST \
       --kubeconfig KUBECONFIG
   

   Sostituisci quanto segue:

   • VPA_MANIFEST: il percorso del file manifest VerticalPodAutoscaler.

   • KUBECONFIG: il percorso del file kubeconfig del cluster.

Informazioni sulle modalità di scalabilità automatica del pod verticale

La scalabilità automatica verticale dei pod funziona in diverse modalità che controllano il modo in cui applica i suggerimenti per le risorse.

Modalità di suggerimento

In modalità di suggerimento, la scalabilità automatica verticale dei pod installa il componente di suggerimento. Questo componente analizza l'utilizzo delle risorse e pubblica i valori consigliati per le richieste e i limiti di CPU e memoria nella sezione di stato delle risorse personalizzate VerticalPodAutoscaler che crei.

Per visualizzare i suggerimenti relativi a richieste e limiti delle risorse, utilizza il seguente comando:

kubectl describe vpa VPA_NAME \
    --kubeconfig KUBECONFIG \
    -n CLUSTER_NAMESPACE

Replace the following:

*   `VPA_NAME`: the name of the `VerticalPodAutoscaler`
    that's targeting the workloads for which you are considering resource
    adjustments.

*   `KUBECONFIG`: the path of the cluster kubeconfig
    file.

*   `CLUSTER_NAMESPACE`: the name of the cluster that's
    running vertical Pod autoscaling.

La risposta deve contenere una sezione Status simile al seguente esempio:

Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi

I pod non vengono aggiornati automaticamente in questa modalità. Utilizza questi suggerimenti per aggiornare manualmente le configurazioni dei pod. Questo è il comportamento predefinito se enableUpdater non è impostato o è false.

Modalità di aggiornamento automatizzato

Quando imposti enableUpdater enableUpdater su true, i controller del ciclo di vita bare metal eseguono il deployment dei componenti di aggiornamento e controller di ammissione di Vertical Pod Autoscaler, oltre al sistema di suggerimenti. L'aggiornamento monitora i pod le cui richieste di risorse attuali si discostano in modo significativo dai consigli.

Il criterio di aggiornamento nella risorsa VerticalPodAutoscaler specifica il modo in cui lo strumento di aggiornamento applica i consigli. Per impostazione predefinita, la modalità di aggiornamento è Auto, che stabilisce che l'updater assegna le impostazioni delle risorse aggiornate alla creazione del pod. Il seguente esempio di VerticalPodAutoscaler mostra come impostare la modalità di aggiornamento su Initial:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
  updatePolicy:
    updateMode: "Initial"
    ...

L'utilità di aggiornamento supporta le seguenti cinque modalità:

• Auto: l'aggiornamento espelle il pod. Il controller di ammissione intercetta la richiesta di creazione del nuovo pod e la modifica in modo che utilizzi i valori consigliati per CPU e memoria forniti dal sistema di suggerimenti. L'aggiornamento delle risorse richiede la ricreazione del pod, che può causare interruzioni. Utilizza i Pod Disruption Budgets, che l'utilità di aggiornamento rispetta, per gestire la procedura di eliminazione. Questa modalità è equivalente a Recreate.

• Recreate: lo strumento di aggiornamento espelle i pod e assegna richieste e limiti di risorse consigliati quando il pod viene ricreato.

• InPlaceOrRecreate(alpha): lo strumento di aggiornamento tenta di eseguire aggiornamenti in loco nel miglior modo possibile, ma potrebbe ripristinare il pod se gli aggiornamenti in loco non sono possibili. Per saperne di più, consulta la documentazione relativa al ridimensionamento in loco dei pod.

• Initial: l'updater assegna le richieste di risorse solo al momento della creazione del pod e non le modifica mai in un secondo momento.

• Off: lo strumento di aggiornamento non modifica automaticamente i requisiti di risorse dei pod. I consigli vengono calcolati e possono essere esaminati nell'oggetto VerticalPodAutoscaler.

Per saperne di più sulla risorsa personalizzata VerticalPodAutoscaler, utilizza kubectl per recuperare la definizione della risorsa personalizzata verticalpodautoscalercheckpoints.autoscaling.k8s.io installata sul cluster versione 1.33.0 o successive.

Il seguente esempio mostra come potrebbero apparire i consigli sulle risorse nella sezione Status per il contenitore hamster. Il campione mostra anche un esempio di un evento di rimozione di un pod, che si verifica quando l'updater rimuove un pod prima di assegnare automaticamente la configurazione delle risorse consigliata al pod ricreato:

Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi
Events:
  Type    Reason      Age   From         Message
  ----    ------      ----  ----         -------
  Normal  EvictedPod  49s   vpa-updater  VPA Updater evicted Pod hamster-7cb59fb657-lkrk4 to apply resource recommendation.

Modalità Risparmio memoria

La modalità Risparmio memoria riduce l'impronta di memoria del componente di suggerimento della scalabilità automatica pod verticale. Quando imposti enableMemorySaver su true, il sistema di suggerimenti monitora e calcola solo le aggregazioni per i pod che hanno una risorsa personalizzata VerticalPodAutoscaler corrispondente.

Il compromesso è che quando crei una nuova risorsa personalizzata VerticalPodAutoscaler per un workload esistente, il recommender impiega un po' di tempo (fino a 24 ore) per raccogliere una cronologia sufficiente a fornire consigli accurati. Questa modalità è false per impostazione predefinita per la maggior parte dei tipi di cluster, ma è impostata su true per i cluster edge.

Utilizzare Prometheus come fornitore di cronologia permanente

Per impostazione predefinita, il componente Recommender mantiene in memoria la cronologia del consumo di risorse dei carichi di lavoro in esecuzione sul cluster e, periodicamente, salva il suo stato in una risorsa personalizzata VerticalPodAutoscalerCheckpoint in etcd per garantire la resilienza ai riavvii.

A partire dalla versione 1.34 di Google Distributed Cloud, puoi utilizzare la tua istanza di Prometheus come fornitore di cronologia persistente per i dati sul consumo di risorse, ovvero le metriche di utilizzo di CPU e memoria. Quando questa integrazione è abilitata, il sistema di suggerimenti può eseguire query sul server Prometheus all'avvio o al riavvio per recuperare i dati storici a lungo termine sull'utilizzo delle risorse per tutti i pod gestiti. Il recupero di questi dati consente al sistema di raccomandazione di creare immediatamente il proprio stato interno con un set di dati ricco, il che porta a raccomandazioni più informate e accurate fin dall'inizio.

L'utilizzo di Prometheus come fornitore di cronologia persistente offre i seguenti vantaggi:

• Ottimizzazione dell'utilizzo delle risorse:genera consigli ben informati e accurati non appena viene avviato, in modo da poter ottimizzare l'utilizzo delle risorse del cluster.

• Prevenzione degli errori di esaurimento della memoria (OOM):Prometheus elimina la necessità di archiviare lo stato interno del sistema di raccomandazione nelle risorse personalizzate (CR) VerticalPodAutoscalerCheckpoint, rendendo più efficiente l'utilizzo della memoria ETCD. Quando il componente del sistema di raccomandazione viene riavviato, perde i dati storici in memoria. Quando utilizzi Prometheus come fornitore di dati storici, il sistema di suggerimenti recupera le metriche storiche da Prometheus al riavvio, il che elimina la necessità del CR VerticalPodAutoscalerCheckpoint e salva la memoria ETCD.

Puoi attivare e disattivare l'utilizzo di Prometheus come fornitore di cronologia persistente in qualsiasi momento.

Prerequisiti per l'utilizzo di Prometheus con la scalabilità automatica verticale dei pod

Per utilizzare la tua istanza Prometheus come fornitore di dati storici per la scalabilità automatica pod verticale, devi configurarla per eseguire lo scraping delle metriche necessarie, il che comporta i seguenti passaggi:

1. Se necessario, esegui il deployment di Prometheus Operator nel cluster per cui vuoi utilizzarlo come fornitore di cronologia persistente per la scalabilità automatica verticale dei pod. Per saperne di più, consulta Come eseguire il deployment e configurare l'operatore Prometheus in Kubernetes.

2. Configura le autorizzazioni per lo scraping delle metriche.

   Per consentire a Prometheus di recuperare le metriche da cAdvisor utilizzando un file di configurazione, devi concedere autorizzazioni aggiuntive al account di servizio utilizzato dal server Prometheus. Crea o aggiorna un ClusterRole contenente queste regole e assicurati che sia associato al account di servizio Prometheus corretto utilizzando un ClusterRoleBinding:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
      name: prometheus-role
      labels:
         app: prometheus-server
   rules:
      - apiGroups: [""]
        resources:
          - nodes
        verbs:
          - get
          - list
          - watch
      - apiGroups: [""]
        resources:
          - nodes/proxy
          - nodes/metrics
        verbs:
          - get
       ---
   
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: prometheus-binding
     labels:
       app: prometheus-server
   subjects:
     - kind: ServiceAccount
       name: prometheus-server        # Service account being used by prometheus
       namespace: prometheus          # Service account's namespace
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: prometheus-role            # Name of the ClusterRole created above
   

3. Aggiorna il file di configurazione di Prometheus per estrarre le seguenti metriche da cAdvisor:

   • container_cpu_usage_seconds_total
   • container_memory_working_set_bytes

   Le seguenti righe definiscono i dettagli dello scraping per le metriche cAdvisor:

   - job_name: 'kubernetes-cadvisor'
     scheme: https
     tls_config:
       ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
     bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
     kubernetes_sd_configs:
       - role: node
     relabel_configs:
       - action: labelmap
         regex: __meta_kubernetes_node_label_(.+)
       - target_label: __address__
         replacement: kubernetes.default.svc:443
       - source_labels: [__meta_kubernetes_node_name]
         regex: (.+)
         target_label: __metrics_path__
         replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
   
     metric_relabel_configs:
     # Keep only the metrics VPA uses to save disk space
       - source_labels: [__name__]
         regex: (container_cpu_usage_seconds_total|container_memory_working_set_bytes)
         action: keep
   

4. Aggiorna il file di configurazione di Prometheus per eseguire lo scraping della seguente metrica dal servizio kube-state-metrics:

   • kube_pod_labels

   1. Esegui il deployment di un servizio kube-state-metrics sul tuo cluster.

      Nota: sebbene un servizio kube-state-metrics sia installato per impostazione predefinita sui cluster bare metal, non espone la metrica kube_pod_labels necessaria.

      Puoi utilizzare i seguenti comandi Helm per installare il nuovo servizio:

      helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
      helm repo update
      

   2. Crea un file ksm-values.yaml con il seguente contenuto:

      fullnameOverride: vpa-kube-state-metrics
      metricAllowlist:
        - kube_pod_labels
      metricLabelsAllowlist:
        - "pods=[*]"
      

   3. Installa un grafico Helm in base al file di valori del passaggio precedente:

      helm install vpa-ksm prometheus-community/kube-state-metrics \
          -f ksm-values.yaml --namespace kube-system
      

   4. Aggiungi le seguenti righe al file di configurazione di Prometheus per eseguire lo scraping della metrica kube_pod_labels dal servizio kube-state-metrics installato:

      - job_name: 'kube-state-metrics'
        static_configs:
          - targets: ['vpa-kube-state-metrics.kube-system.svc.cluster.local:8080']
        metric_relabel_configs:
          - source_labels: [ __name__ ]
            regex: 'kube_pod_labels'
            action: keep
      

Abilitare e utilizzare Prometheus

La scalabilità automatica pod verticale supporta sia l'autenticazione di base sia quella basata su token di autenticazione per la connessione a Prometheus. Quando utilizzi l'autenticazione, devi creare un Secret contenente le credenziali necessarie nello spazio dei nomi del cluster. Il controller inoltra questo secret al cluster di destinazione e lo monta come volume o variabile di ambiente nel pod di suggerimento. Puoi anche utilizzare Prometheus senza autenticazione.

Per abilitare e utilizzare la tua istanza Prometheus con la scalabilità automatica pod verticale, devi configurare la sezione verticalPodAutoscaling nella specifica del cluster con i dettagli per la connessione alla tua istanza Prometheus.

Ecco un esempio della configurazione nella specifica del cluster da utilizzare con un token di autenticazione:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vertical Pod autoscaling configurations ...
    # Add this new section to configure the vpa to use prometheus using bearer token authentication as history provider
    prometheus:
      url: "http://prometheus.prometheus.monitoring.svc.cluster.local:9090"
      auth:
        bearerTokenAuth:
            name: prom-bearer-creds
            key: bearertoken

Per abilitare Prometheus per l'utilizzo con la scalabilità automatica verticale dei pod:

1. Assicurati che l'istanza Prometheus sia configurata per estrarre le metriche richieste come descritto in Prerequisiti per l'utilizzo di Prometheus con la scalabilità automatica verticale dei pod.

2. Aggiorna la risorsa personalizzata Cluster spec in modo che il campo verticalPodAutoscaling.prometheus specifichi le impostazioni di connessione per il server Prometheus.

3. Aggiungi url alla sezione prometheus e impostalo sul nome di dominio completo (FQDN) per la connessione a Prometheus dall'interno del cluster:

   spec:
     # ... other existing cluster configurations ...
     verticalPodAutoscaling:
       # ... other vpa configurations ...
       # Add this new section to configure the vpa to use prometheus as history provider
       prometheus:
         # Required: The URL of the Prometheus server
         url: "http://prometheus.prometheus.svc.cluster.local:9090"
   

4. Specifica i dettagli della connessione:

   La scalabilità automatica del pod verticale supporta i seguenti tre metodi di connessione:

   • Nessuna autenticazione
   • Autenticazione di base (nome utente, password)

   • Autenticazione con token di connessione

   Nessuna autenticazione

   Se la tua istanza Prometheus non richiede l'autenticazione, hai finito. La sezione prometheus deve includere solo un campo url.

   Autenticazione di base

   Per specificare l'autenticazione di base per Prometheus:

   1. Crea un secret che contenga un nome utente e una password nella sezione stringData e nell'annotazione baremetal.cluster.gke.io/mark-source: "true".

      L'esempio seguente mostra un secret che supporta l'autenticazione di base:

      apiVersion: v1
      kind: Secret
      metadata:
        name: prom-basic-creds
        namespace: <cluster-namespace>
        annotations:
          baremetal.cluster.gke.io/mark-source: "true"
      type: Opaque
      stringData:
        username: admin
        password: pwd
      

      L'annotazione è necessaria per garantire che il secret di origine e il secret nel cluster di destinazione siano sempre sincronizzati. Il secret viene aggiornato quando viene aggiornato il secret di origine.

      Nota: ogni volta che esegui la rotazione delle credenziali, devi aggiornare questo segreto.

   2. Aggiorna la sezione prometheus.auth.basicAuth della specifica del cluster in modo che faccia riferimento al nome utente e alla password del campo data nel secret.

      L'esempio seguente mostra una sezione basicAuth che fa riferimento al nome utente e alla password nel secret del passaggio precedente:

      # ... other vpa configurations ...
      prometheus:
        url: "http://prometheus.prometheus.svc.cluster.local:9090"
        auth:
          basicAuth:
            usernameRef:
              name: prom-basic-creds
              key: username
            passwordRef:
              name: prom-basic-creds
              key: password
      

      Il nome utente e la password devono trovarsi nello stesso secret. Le chiavi devono essere chiavi valide del campo data del secret.

   L'istanza Prometheus dovrebbe iniziare a funzionare come fornitore di cronologia per la scalabilità automatica verticale dei pod quando viene aggiornata la risorsa personalizzata del cluster.

   Autenticazione con token di connessione

   Per specificare l'autenticazione con token di autenticazione per Prometheus:

   1. Crea un secret che contenga un token di autenticazione nella sezione stringData e nell'annotazione baremetal.cluster.gke.io/mark-source: "true".

      L'esempio seguente mostra un secret che supporta l'autenticazione con token di autenticazione:

      apiVersion: v1
      kind: Secret
      metadata:
        name: prom-bearer-creds
        namespace: <cluster-namespace>
        annotations:
          baremetal.cluster.gke.io/mark-source: "true"
      type: Opaque
      stringData:
        bearertoken: "SAMPLE_TOKEN"
      

      L'annotazione è necessaria per garantire che il secret di origine e il secret nel cluster di destinazione siano sempre sincronizzati. Il secret viene aggiornato quando viene aggiornato il secret di origine.

      Nota: ogni volta che esegui la rotazione delle credenziali, devi aggiornare questo segreto.

   2. Aggiorna la sezione prometheus.auth.bearerTokenAuth della specifica del cluster in modo che faccia riferimento al token di autenticazione dal campo data nel secret.

      L'esempio seguente mostra una sezione bearerTokenAuth che fa riferimento al token di autenticazione nel segreto del passaggio precedente:

      # ... other vertical Pod autoscaling configurations ...
      prometheus:
        url: "http://prometheus.prometheus.svc.cluster.local:9090"
        auth:
          bearerTokenAuth:
              name: prom-bearer-creds
              key: bearertoken
      

      La chiave deve essere una chiave valida del campo data del secret.

   L'istanza Prometheus dovrebbe iniziare a funzionare come provider di cronologia per la scalabilità automatica verticale dei pod quando viene aggiornata la risorsa personalizzata del cluster.

Disabilita l'utilizzo di Prometheus

Per disattivare l'utilizzo di Prometheus con la scalabilità automatica verticale dei pod, rimuovi la sezione prometheus dalla sezione verticalPodAutoscaling della risorsa personalizzata Cluster.

Disabilita la scalabilità automatica del pod verticale

Disattiva la scalabilità automatica verticale dei pod rimuovendo le relative risorse personalizzate e la relativa configurazione dal cluster:

1. Elimina tutte le risorse personalizzate VerticalPodAutoscaler che hai creato.

2. Modifica la risorsa personalizzata del cluster e rimuovi l'intera sezione verticalPodAutoscaling da spec.

   Puoi modificare direttamente la risorsa personalizzata Cluster o modificare il file di configurazione del cluster e utilizzare bmctl update.

3. Rimuovi l'annotazione preview.baremetal.cluster.gke.io/vertical-pod-autoscaler dalla risorsa personalizzata del cluster.

Limitazioni

Tieni presenti le seguenti limitazioni quando utilizzi Scalabilità automatica pod verticale:

• La scalabilità automatica pod verticale non è pronta per l'uso con i workload basati su JVM a causa della visibilità limitata sull'utilizzo effettivo della memoria del workload.
• L'aggiornamento richiede un minimo di due repliche di pod per i deployment per sostituire i pod con valori di risorse rivisti.
• L'updater non aggiorna rapidamente i pod che vanno in crash a causa di errori di memoria insufficiente (OOM).
• Il criterio di aggiornamento InPlaceOrRecreate per i pod è una funzionalità alpha all'interno della scalabilità automatica verticale dei pod. Tenta di eseguire aggiornamenti in loco con il massimo impegno, ma potrebbe tornare alla ricreazione del pod se gli aggiornamenti in loco non sono possibili.

Passaggi successivi

• Esplora i budget di interruzione dei pod.