Configura la scalabilità automatica verticale dei pod

La scalabilità automatica verticale dei pod automatizza l'impostazione delle richieste e dei limiti delle risorse di CPU e memoria per i container all'interno dei pod Kubernetes. La scalabilità automatica verticale dei pod analizza l'utilizzo delle risorse storico e attuale per fornire suggerimenti, 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 verticale dei pod

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 sulla risorsa personalizzata Cluster.

    Modifica direttamente la risorsa personalizzata Cluster o modifica 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 specificare 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 indirizzare carichi di lavoro specifici:

  1. Definisci una risorsa VerticalPodAutoscaler nello stesso spazio dei nomi del carico di lavoro 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 il seguente 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 verticale dei pod

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

Modalità di suggerimento

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

Per visualizzare i suggerimenti relativi alle richieste e ai 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

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

Modalità di aggiornamento automatico

Quando imposti enableUpdater enableUpdater su true, i controller del ciclo di vita bare metal eseguono il deployment dei componenti di aggiornamento e del controller di ammissione della scalabilità automatica pod verticale , oltre al componente di suggerimento. Il programma di aggiornamento monitora i pod le cui richieste di risorse attuali si discostano in modo significativo dai suggerimenti.

Il criterio di aggiornamento nella risorsa VerticalPodAutoscaler specifica il modo in cui il programma di aggiornamento applica i suggerimenti. Per impostazione predefinita, la modalità di aggiornamento è Auto, il che significa che il programma di aggiornamento assegna le impostazioni delle risorse aggiornate al momento della 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"
    ...

Il programma di aggiornamento supporta le seguenti cinque modalità:

  • Auto: l'aggiornamento elimina il pod. Il controller di ammissione intercetta la richiesta di creazione del nuovo pod e la modifica in modo da utilizzare i valori di CPU e memoria consigliati forniti dal motore per suggerimenti. L'aggiornamento delle risorse richiede la ricreazione del pod, che può causare interruzioni. Utilizza i budget di interruzione dei pod (PDB), che il programma di aggiornamento rispetta, per gestire il processo di eliminazione. Questa modalità è equivalente a Recreate.

  • Recreate: l'aggiornamento elimina i pod e assegna le richieste e i limiti delle risorse consigliati quando il pod viene ricreato.

  • InPlaceOrRecreate(alpha): il programma di aggiornamento tenta di eseguire aggiornamenti in loco con il massimo impegno, ma potrebbe ricorrere alla ricreazione del pod se gli aggiornamenti in loco non sono possibili. Per ulteriori informazioni, consulta la documentazione sul ridimensionamento dei pod in loco.

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

  • Off: Il programma di aggiornamento non modifica automaticamente i requisiti delle risorse dei pod. I suggerimenti vengono calcolati e possono essere esaminati nell'oggetto VerticalPodAutoscaler.

Per ulteriori informazioni 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.

L'esempio seguente mostra come potrebbero apparire i suggerimenti sulle risorse nella sezione Status per il container hamster. L'esempio mostra anche un evento di eliminazione del pod, che si verifica quando il programma di aggiornamento elimina 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 il footprint della memoria del componente motore per suggerimenti della scalabilità automatica verticale dei pod. Quando imposti enableMemorySaver su true, il motore per suggerimenti tiene traccia e calcola le aggregazioni solo per i pod che hanno una risorsa personalizzata VerticalPodAutoscaler corrispondente.

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

Utilizza Prometheus come provider di cronologia persistente

Per impostazione predefinita, il motore per suggerimenti 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 provider di cronologia persistente per i dati di consumo delle risorse, ovvero le metriche di utilizzo di CPU e memoria utilizzata. Quando questa integrazione è abilitata, il motore per suggerimenti può fare 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 motore per suggerimenti di creare immediatamente il suo stato interno con un set di dati completo, fornendo fin da subito suggerimenti più informati e accurati.

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

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

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

Puoi abilitare e disabilitare l'utilizzo di Prometheus come provider di cronologia persistente in qualsiasi momento.

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

Per utilizzare la tua istanza di Prometheus come provider di cronologia per la scalabilità automatica pod verticale, devi configurarla in modo da eseguire lo scraping delle metriche necessarie, seguendo questi passaggi:

  1. Se necessario, esegui il deployment dell'operatore Prometheus nel cluster per il quale vuoi utilizzarlo come provider di cronologia persistente per la scalabilità automatica pod verticale. Per ulteriori informazioni, consulta la pagina 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 eseguire lo scraping delle 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 eseguire lo scraping delle 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 cluster.

      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 i seguenti contenuti:

      fullnameOverride: vpa-kube-state-metrics
      metricAllowlist:
        - kube_pod_labels
      metricLabelsAllowlist:
        - "pods=[*]"
      
    3. Installa un grafico Helm basato sul file dei 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
      

Abilita e utilizza Prometheus

La scalabilità automatica verticale dei pod supporta sia l'autenticazione di base sia l'autenticazione basata su token di connessione 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 del motore per suggerimenti. Puoi anche utilizzare Prometheus senza autenticazione.

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

Ecco un esempio della configurazione nella specifica del cluster per l'utilizzo 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 la tua istanza di Prometheus sia configurata per eseguire lo scraping delle metriche richieste come descritto in Prerequisiti per l'utilizzo di Prometheus con la scalabilità automatica pod verticale automatica.

  2. Aggiorna la risorsa personalizzata Cluster spec in modo che il verticalPodAutoscaling.prometheus campo 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 verticale dei pod supporta i seguenti tre metodi di connessione:

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

    Nessuna autenticazione

    Se la tua istanza di 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 contenente un nome utente e una password nella stringData sezione e l'baremetal.cluster.gke.io/mark-source: "true" annotazione.

      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 assicurarsi 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.

    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 essere nello stesso secret. Le chiavi devono essere chiavi valide del campo data del secret.

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

    Autenticazione con token di autenticazione

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

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

      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 assicurarsi 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.

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

      L'esempio seguente mostra una sezione bearerTokenAuth che fa riferimento al token di autenticazione nel secret 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 di Prometheus dovrebbe iniziare a funzionare come provider di cronologia per la scalabilità automatica verticale dei pod quando la risorsa personalizzata Cluster viene aggiornata.

Disabilita l'utilizzo di Prometheus

Per disabilitare 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 verticale dei pod

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

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

  2. Modifica la risorsa personalizzata 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 Cluster.

Limitazioni

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

  • La scalabilità automatica verticale dei pod non è pronta per l'uso con i carichi di lavoro basati su JVM a causa della visibilità limitata sulla memoria utilizzata effettiva del carico di lavoro.
  • L'aggiornamento richiede un minimo di due repliche di pod per i deployment per sostituire i pod con valori delle risorse rivisti.
  • L'aggiornamento non aggiorna rapidamente i pod che si trovano in un loop di arresto anomalo a causa di errori di memoria insufficiente (OOM).
  • Il criterio di aggiornamento InPlaceOrRecreate per i pod è una funzionalità alfa all'interno della scalabilità automatica verticale dei pod. Tenta di eseguire aggiornamenti in loco con il massimo impegno, ma potrebbe ricorrere alla ricreazione del pod se gli aggiornamenti in loco non sono possibili.

Passaggi successivi