Resolver problemas de escalonamento automático vertical de pods

Quando o escalonamento automático vertical de pods não funciona como esperado no Google Kubernetes Engine (GKE), as cargas de trabalho podem não ser escalonadas corretamente. Esses problemas podem impedir que os aplicativos processem a carga, o que pode causar problemas de desempenho ou interrupções. É possível que os pods não sejam reiniciados com novas recomendações de recursos ou que as recomendações não correspondam ao uso real.

Use este documento para resolver problemas comuns com a configuração do VerticalPodAutoscaler ou recomendações inesperadas. Seguir estas etapas de solução de problemas pode ajudar seus aplicativos a serem escalonados de maneira eficiente e confiável com base na demanda.

Essas informações são importantes para desenvolvedores de aplicativos que configuram recursos do VerticalPodAutoscaler e precisam garantir que os aplicativos sejam escalonados corretamente. Elas também ajudam os administradores e operadores de plataforma a resolver problemas com a configuração do cluster que afetam cargas de trabalho com escalonamento automático. Para mais informações sobre as funções comuns e tarefas de exemplo que referenciamos no Cloud de Confiance by S3NS content, consulte Funções e tarefas comuns do usuário do GKE.

Diagnosticar problemas do VerticalPodAutoscaler

Para diagnosticar problemas com um VerticalPodAutoscaler, inspecione o status e a configuração usando kubectl ou o Cloud de Confiance console.

Descrever o VerticalPodAutoscaler

Para conferir cálculos em tempo real e decisões de escalonamento recentes, use o comando kubectl describe vpa:

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

Substitua:

• VPA_NAME: o nome do VerticalPodAutoscaler.
• NAMESPACE_NAME: o namespace do VerticalPodAutoscaler.

O resultado será assim:

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>

Na saída, revise estas seções principais:

• Spec: mostra detalhes da configuração, incluindo o campo targetRef (a carga de trabalho de destino) e o campo updatePolicy (como as atualizações são aplicadas).
• Status: mostra a seção Conditions (integridade operacional) e a seção Recommendation (valores de recursos de CPU e memória gerados para cada contêiner).
• Events: lista ações ou erros recentes relacionados ao objeto VerticalPodAutoscaler.

Conferir o manifesto do VerticalPodAutoscaler

Para conferir a configuração e o estado completos de um VerticalPodAutoscaler, inspecione o manifesto YAML usando kubectl ou o Cloud de Confiance console:

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

Verificar o status do VerticalPodAutoscaler no Cloud de Confiance console

Para inspecionar o status do VerticalPodAutoscaler das cargas de trabalho no Cloud de Confiance console:

1. Acesse a página Cargas de trabalho.

   Acesse "Cargas de trabalho"

2. Clique no nome da carga de trabalho.

3. Acesse a guia Detalhes e localize a seção Escalonador automático.

4. Revise a linha Escalonador automático vertical de pods para conferir mensagens de status sobre a coleta de métricas e a integridade da configuração.

Coletar registros de decisões

Para insights detalhados sobre os cálculos e decisões do VerticalPodAutoscaler, ative os registros de decisões do escalonador automático vertical de pods (visualização) no Cloud Logging.

Esses registros capturam eventos como UPDATE_RECOMMENDATION, EVICT_POD, APPLY_RECOMMENDATION_IN_PLACE e APPLY_RECOMMENDATION_ON_EVICTION.

Para ativar e inspecionar os registros de decisões, consulte Coletar registros de eventos do escalonador automático vertical de pods.

Resolver problemas com recomendações do VerticalPodAutoscaler

As seções a seguir abordam problemas em que um VerticalPodAutoscaler não gera recomendações ou gera recomendações diferentes das expectativas.

Um VerticalPodAutoscaler não está fornecendo recomendações

Sintomas:

• O campo Status.Recommendation no manifesto do VerticalPodAutoscaler está vazio.
• As condições no manifesto do VerticalPodAutoscaler mostram as condições de status NoPodsMatched, FetchingHistory ou LowConfidence.

Causa:

• Destino incorreto: o campo spec.targetRef no manifesto do VerticalPodAutoscaler não aponta para uma carga de trabalho existente no mesmo namespace.
• Coleta de métricas inicial: o VerticalPodAutoscaler foi criado recentemente e ainda está coletando dados históricos de uso de recursos.
• Problemas de componentesmetrics-server: o VerticalPodAutoscaler depende de métricas do componente metrics-server. Se o componente metrics-server não estiver funcionando corretamente, o VerticalPodAutoscaler não poderá recuperar os dados de uso.
• Nenhum pod em execução: a carga de trabalho de destino não tem pods em execução ou prontos para o VerticalPodAutoscaler observar.

Resolução:

• Verifique o campo targetRef: confira os valores dos campos kind, name, e apiVersion na seção spec.targetRef. Verifique se todos os valores correspondem à carga de trabalho de destino. Para confirmar se a carga de trabalho existe, execute:

  kubectl get KIND WORKLOAD_NAME \
      -n NAMESPACE_NAME
  

  Substitua:

  • KIND: o tipo de carga de trabalho, por exemplo, deployment ou statefulset.
  • WORKLOAD_NAME: o nome da carga de trabalho.
  • NAMESPACE_NAME: o namespace da carga de trabalho.

• Aguarde a coleta de métricas: novos recursos do VerticalPodAutoscaler precisam de tempo para coletar dados. Monitore o campo Status.Conditions para uma transição para a condição de status RecommendationProvided.

• Verifique o componente metrics-server:

  1. Verifique se o pod do componente metrics-server está em execução:

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

  2. Se o pod não estiver em execução ou tiver uma contagem alta de reinicializações, confira os registros dele:

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

     As entradas de registro que contêm palavras como error, failed ou unable to fetch indicam problemas com a coleta de métricas.

• Verifique se os pods estão em execução: verifique se a carga de trabalho de destino tem pelo menos um pod em execução e pronto.

As recomendações do VerticalPodAutoscaler são inesperadas

Sintomas:

• Os valores de CPU ou memória na seção Status.Recommendation são maiores ou menores do que o esperado.
• As recomendações não estão alinhadas ao consumo de recursos da carga de trabalho observada.

Causa:

• Mudanças no comportamento da carga de trabalho: as recomendações do VerticalPodAutoscaler são baseadas no uso histórico. As mudanças recentes nos padrões de consumo de aplicativos ainda não foram refletidas.
• Características da carga de trabalho: jobs de curta duração ou cargas de trabalho com padrões de uso altamente instáveis podem não receber recomendações ideais.
• Recursos conflitantes do VerticalPodAutoscaler: vários recursos do VerticalPodAutoscaler podem ser configurados para segmentar a mesma carga de trabalho.

Resolução:

• Aguarde o tempo de ajuste: dê ao VerticalPodAutoscaler tempo para aprender novos padrões de uso após as mudanças no aplicativo.
• Avalie a adequação: avalie se um VerticalPodAutoscaler ou um escalonador automático horizontal de pods é mais adequado para o tipo de carga de trabalho.

• Verifique se há recursos conflitantes do VerticalPodAutoscaler:

  1. Liste todos os recursos do VerticalPodAutoscaler no cluster:

     kubectl get vpa --all-namespaces
     

  2. Examine o campo spec.targetRef de cada recurso. Se vários recursos do VerticalPodAutoscaler segmentarem a mesma carga de trabalho, remova ou ajuste os recursos conflitantes para que apenas um VerticalPodAutoscaler segmente uma determinada carga de trabalho.

Resolver problemas com atualizações de recursos de pods

As seções a seguir abordam problemas em que as recomendações existem, mas não são aplicadas aos pods de destino.

As solicitações de recursos de pods não são atualizadas

Sintomas:

• O manifesto do VerticalPodAutoscaler mostra recomendações na seção Status, mas o campo resources.requests no manifesto do pod não é atualizado.
• Os pods não são reiniciados para aplicar recomendações ao usar o modo de atualização Auto ou Recreate.

Causa:

• O campo updateMode é Off: quando o spec.updatePolicy.updateMode campo está definido como Off, o VerticalPodAutoscaler gera recomendações, mas não as aplica.
• A carga de trabalho tem apenas uma réplica: no modo de atualização Auto ou Recreate, o VerticalPodAutoscaler evita remover cargas de trabalho de réplica única para evitar inatividade.

Resolução:

• Verifique o campo updateMode: modifique o manifesto do VerticalPodAutoscaler para definir o campo spec.updatePolicy.updateMode como Auto, Recreate ou InPlaceOrRecreate.
• Aumente a contagem de réplicas: para cargas de trabalho que usam o modo de atualização Auto ou Recreate, verifique se a implantação ou o StatefulSet tem mais de uma réplica.

As atualizações no local falham ou permanecem adiadas

Sintomas:

• O redimensionamento do contêiner no local não é concluído ou permanece adiado.

Causa:

• Capacidade insuficiente do nó: se o nó não tiver capacidade para as solicitações de recursos atualizadas, a operação de redimensionamento no local será adiada.

Resolução:

• Verifique o status de redimensionamento adiado e a capacidade do nó:

  Se o redimensionamento permanecer adiado por mais de cinco minutos, o VerticalPodAutoscaler voltará a remover e recriar o pod para aplicar a recomendação. Para verificar o status da atualização adiada, faça o seguinte:

  1. Inspecione as anotações do pod para verificar se a vpaInPlaceUpdated anotação está definida como "true":

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

  2. Verifique o status adiado inspecionando o campo status.conditions para eventos de redimensionamento adiados:

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

  3. Inspecione os eventos do Kubernetes para o pod:

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

     Substitua:

     • NAMESPACE_NAME: o namespace do pod.
     • POD_NAME: o nome do pod.

     Procure eventos com um dos seguintes motivos: ResizedPod (atualização no local bem-sucedida) ou EvictedByVPA (reversão para recriação).

A seguir

• Se você não encontrar uma solução para o problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos:

  • Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
  • Receber suporte da comunidade fazendo perguntas no StackOverflow e usando a google-kubernetes-engine tag para pesquisar problemas semelhantes. Você também pode participar do #kubernetes-engine canal do Slack para mais suporte da comunidade.
  • Abrir problemas ou solicitações de recursos usando o Issue Tracker público.