Risoluzione dei problemi relativi alla scalabilità automatica verticale dei pod

Quando la scalabilità automatica verticale dei pod non funziona come previsto in Google Kubernetes Engine (GKE), i tuoi carichi di lavoro potrebbero non scalare correttamente. Questi problemi possono impedire alle applicazioni di gestire il carico, il che potrebbe causare problemi di prestazioni o interruzioni. Potresti notare che i pod non si riavviano con i nuovi suggerimenti sulle risorse o che i suggerimenti non corrispondono all'utilizzo effettivo.

Utilizza questo documento per risolvere i problemi comuni relativi alla configurazione di VerticalPodAutoscaler o ai suggerimenti imprevisti. Seguendo questi passaggi per la risoluzione dei problemi, puoi aiutare le tue applicazioni a scalare in modo efficiente e affidabile in base alla domanda.

Queste informazioni sono importanti per gli sviluppatori di applicazioni che configurano le risorse VerticalPodAutoscaler e devono assicurarsi che le loro applicazioni vengano scalate correttamente. Inoltre, aiuta gli amministratori e gli operatori della piattaforma a risolvere i problemi di configurazione del cluster che influiscono sui workload con scalabilità automatica. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Cloud de Confiance by S3NS , consulta Ruoli utente e attività comuni di GKE.

Diagnostica dei problemi di VerticalPodAutoscaler

Per diagnosticare i problemi relativi a un VerticalPodAutoscaler, esamina lo stato e la configurazione utilizzando kubectl o la console Cloud de Confiance .

Descrivi il VerticalPodAutoscaler

Per visualizzare i calcoli in tempo reale e le decisioni di scalabilità recenti, utilizza il comando kubectl describe vpa:

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

Sostituisci quanto segue:

  • VPA_NAME: il nome del tuo VerticalPodAutoscaler.
  • NAMESPACE_NAME: lo spazio dei nomi di VerticalPodAutoscaler.

L'output è simile al seguente:

Name:         sample-deployment-vpa
Namespace:    default
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
# Multiple lines are omitted here
Spec:
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         sample-deployment
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-10-09T10:00:00Z
    Message:               VPA is fetching history in order to provide recommendation
    Reason:                FetchingHistory
    Status:                True
    Type:                  FetchingHistory
    Last Transition Time:  2025-10-09T10:05:00Z
    Message:               VPA pod metrics aren't available yet
    Reason:                NoMetrics
    Status:                True
    Type:                  LowConfidence
    Last Transition Time:  2025-10-09T10:10:00Z
    Message:               VPA is able to provide a recommendation
    Reason:                RecommendationProvided
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  sample-container
      Lower Bound:
        Cpu:     100m
        Memory:  128Mi
      Target:
        Cpu:     200m
        Memory:  256Mi
      Upper Bound:
        Cpu:     500m
        Memory:  512Mi
Events:          <none>

Nell'output, esamina queste sezioni principali:

  • Spec: mostra i dettagli della configurazione, inclusi il campo targetRef (il workload di destinazione) e il campo updatePolicy (la modalità di applicazione degli aggiornamenti).
  • Status: mostra la sezione Conditions (integrità operativa) e la sezione Recommendation (valori delle risorse CPU e memoria generati per ogni container).
  • Events: elenca le azioni o gli errori recenti relativi all'oggetto VerticalPodAutoscaler.

Visualizza il manifest VerticalPodAutoscaler

Per visualizzare la configurazione e lo stato completi di un VerticalPodAutoscaler, esamina il relativo manifest YAML utilizzando kubectlo la console Cloud de Confiance :

Console

  1. Nella console Cloud de Confiance , vai alla pagina Visualizzatore oggetti.

    Vai a Esplora oggetti

  2. Fai clic sull'elenco dei filtri Tipo di oggetto.

  3. Cancella le selezioni esistenti.

  4. Seleziona VerticalPodAutoscaler e fai clic su Ok.

  5. Nell'elenco filtrato, seleziona il gruppo API autoscaling.k8s.io.

  6. Seleziona il tipo di oggetto VerticalPodAutoscaler.

  7. Fai clic sul nome di VerticalPodAutoscaler che vuoi ispezionare.

kubectl

kubectl get vpa VPA_NAME \
    -n NAMESPACE_NAME \
    -o yaml

Sostituisci quanto segue:

  • VPA_NAME: il nome del tuo VerticalPodAutoscaler.
  • NAMESPACE_NAME: lo spazio dei nomi del tuo VerticalPodAutoscaler.

Controlla lo stato di VerticalPodAutoscaler nella console Cloud de Confiance

Per esaminare lo stato di VerticalPodAutoscaler per i tuoi workload nella console Cloud de Confiance :

  1. Vai alla pagina Workload.

    Vai a Carichi di lavoro

  2. Fai clic sul nome del workload.

  3. Vai alla scheda Dettagli e individua la sezione Autoscaler.

  4. Esamina la riga Vertical Pod Autoscaler per i messaggi di stato relativi alla raccolta delle metriche e all'integrità della configurazione.

Raccogliere i log delle decisioni

Per informazioni dettagliate sui calcoli e sulle decisioni di VerticalPodAutoscaler, abilita i log delle decisioni del gestore della scalabilità automatica verticale dei pod (anteprima) in Cloud Logging.

Questi log acquisiscono eventi come UPDATE_RECOMMENDATION, EVICT_POD, APPLY_RECOMMENDATION_IN_PLACE e APPLY_RECOMMENDATION_ON_EVICTION.

Per abilitare e ispezionare i log delle decisioni, consulta Raccogli i log eventi di Vertical Pod Autoscaler.

Risolvere i problemi relativi ai suggerimenti di VerticalPodAutoscaler

Le sezioni seguenti riguardano i problemi in cui un VerticalPodAutoscaler non riesce a generare suggerimenti o genera suggerimenti diversi dalle aspettative.

Un VerticalPodAutoscaler non fornisce suggerimenti

Sintomi:

  • Il campo Status.Recommendation nel manifest VerticalPodAutoscaler è vuoto.
  • Le condizioni nel manifest VerticalPodAutoscaler mostrano le condizioni di stato NoPodsMatched, FetchingHistory o LowConfidence.

Causa:

  • Destinazione errata: il campo spec.targetRef nel manifest VerticalPodAutoscaler non punta a un workload esistente nello stesso spazio dei nomi.
  • Raccolta iniziale delle metriche: VerticalPodAutoscaler è stato creato di recente e sta ancora raccogliendo dati storici sull'utilizzo delle risorse.
  • Problemi dei componenti metrics-server: VerticalPodAutoscaler si basa sulle metriche del componente metrics-server. Se il componente metrics-server non funziona correttamente, VerticalPodAutoscaler non può recuperare i dati di utilizzo.
  • Nessun pod in esecuzione: il workload di destinazione non ha pod in esecuzione o pronti per essere osservati da VerticalPodAutoscaler.

Risoluzione:

  • Verifica il campo targetRef: controlla i valori dei campi kind, name e apiVersion nella sezione spec.targetRef. Assicurati che tutti i valori corrispondano al workload di destinazione. Per confermare che il workload esiste, esegui:

    kubectl get KIND WORKLOAD_NAME \
    -n NAMESPACE_NAME

    Sostituisci quanto segue:

    • KIND: il tipo di workload, ad esempio deployment o statefulset.
    • WORKLOAD_NAME: il nome del tuo workload.
    • NAMESPACE_NAME: lo spazio dei nomi del workload.

  • Concedi il tempo necessario per la raccolta delle metriche: le nuove risorse VerticalPodAutoscaler richiedono tempo per raccogliere i dati. Monitora il campo Status.Conditions per una transizione alla condizione di stato RecommendationProvided.

  • Controlla il componente metrics-server:

    1. Verifica che il pod per il componente metrics-server sia in esecuzione:

      kubectl get pods -n kube-system | grep metrics-server

    2. Se il pod non è in esecuzione o ha un numero elevato di riavvii, controlla i relativi log:

      kubectl logs -n kube-system -l k8s-app=metrics-server

      Le voci di log contenenti parole come error, failed o unable to fetch indicano problemi con la raccolta delle metriche.

  • Assicurati che i pod siano in esecuzione: verifica che il workload di destinazione abbia almeno un pod in esecuzione e pronto.

I suggerimenti di VerticalPodAutoscaler non sono previsti

Sintomi:

  • I valori di CPU o memoria nella sezione Status.Recommendation sono superiori o inferiori al previsto.
  • I suggerimenti non sono in linea con il consumo di risorse osservato del workload.

Causa:

  • Modifiche al comportamento del carico di lavoro: i suggerimenti di VerticalPodAutoscaler si basano sull'utilizzo storico. I recenti cambiamenti nei modelli di consumo delle applicazioni potrebbero non essere ancora stati presi in considerazione.
  • Caratteristiche del workload: i job o i workload di breve durata con pattern di utilizzo molto irregolari potrebbero non ricevere suggerimenti ottimali.
  • Risorse VerticalPodAutoscaler in conflitto: potrebbero essere configurate più risorse VerticalPodAutoscaler per avere come target lo stesso workload.

Risoluzione:

  • Concedi il tempo necessario per l'aggiustamento: concedi a VerticalPodAutoscaler il tempo necessario per apprendere nuovi pattern di utilizzo dopo le modifiche all'applicazione.
  • Valuta l'idoneità: valuta se un gestore della scalabilità automatica verticale dei pod o un Horizontal Pod Autoscaler è più adatto al tipo di workload.

  • Verifica la presenza di risorse VerticalPodAutoscaler in conflitto:

    1. Elenca tutte le risorse VerticalPodAutoscaler nel cluster:

      kubectl get vpa --all-namespaces

    2. Esamina il campo spec.targetRef per ogni risorsa. Se più risorse VerticalPodAutoscaler hanno come target lo stesso workload, rimuovi o modifica le risorse in conflitto in modo che solo una risorsa VerticalPodAutoscaler abbia come target un determinato workload.

Risolvere i problemi relativi agli aggiornamenti delle risorse Pod

Le sezioni seguenti riguardano i problemi in cui i suggerimenti esistono, ma non vengono applicati ai pod di destinazione.

Le richieste di risorse dei pod non vengono aggiornate

Sintomi:

  • Il manifest VerticalPodAutoscaler mostra i suggerimenti nella sezione Status, ma il campo resources.requests nel manifest del pod non viene aggiornato.
  • I pod non vengono riavviati per applicare i consigli quando utilizzi la modalità di aggiornamento Auto o Recreate.

Causa:

  • Il campo updateMode è Off: quando il campo spec.updatePolicy.updateMode è impostato su Off, VerticalPodAutoscaler genera consigli ma non li applica.
  • Il workload ha una sola replica: nella modalità di aggiornamento Auto o Recreate, VerticalPodAutoscaler evita di rimuovere i workload a replica singola per evitare tempi di inattività.

Risoluzione:

  • Controlla il campo updateMode: modifica il manifest VerticalPodAutoscaler per impostare il campo spec.updatePolicy.updateMode su Auto, Recreate o InPlaceOrRecreate.
  • Aumenta il numero di repliche: per i workload che utilizzano la modalità di aggiornamento Auto o Recreate, assicurati che il deployment o StatefulSet abbia più di una replica.

Gli aggiornamenti in loco non riescono o rimangono posticipati

Sintomi:

  • Il ridimensionamento in loco del container non viene completato o rimane posticipato.

Causa:

  • Capacità del nodo insufficiente: se il nodo non dispone di capacità sufficiente per le richieste di risorse aggiornate, l'operazione di ridimensionamento in loco viene posticipata.

Risoluzione:

  • Verifica lo stato del ridimensionamento posticipato e la capacità dei nodi:

    Se il ridimensionamento rimane posticipato per più di cinque minuti, VerticalPodAutoscaler torna a eliminare e ricreare il pod per applicare il suggerimento. Per controllare lo stato dell'aggiornamento differito, procedi nel seguente modo:

    1. Ispeziona le annotazioni del pod per verificare se l'annotazione vpaInPlaceUpdated è impostata su "true":

      metadata:
  annotations:
    vpaInPlaceUpdated: "true"
    vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'

    2. Controlla lo stato posticipato esaminando il campo status.conditions per gli eventi di ridimensionamento posticipati:

      status:
  conditions:
  - type: PodResizePending
    status: "True"
    reason: Deferred
    message: "Node didn't have enough resource: ..."

    3. Ispeziona gli eventi Kubernetes per il pod:

      kubectl get events -n NAMESPACE_NAME --field-selector involvedObject.kind=Pod,involvedObject.name=POD_NAME

      Sostituisci quanto segue:

      • NAMESPACE_NAME: lo spazio dei nomi del tuo pod.
      • POD_NAME: il nome del pod.

      Cerca gli eventi con uno dei seguenti motivi: ResizedPod (aggiornamento in loco riuscito) o EvictedByVPA (fallback alla ricreazione).

Passaggi successivi