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), suas 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. Talvez você veja pods que não estão reiniciando com novas recomendações de recursos ou recomendações que não correspondem 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 escalonar 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. Ele também ajuda os administradores e operadores da plataforma a resolver problemas com a configuração do cluster que afetam as cargas de trabalho com escalonamento automático. Para mais informações sobre as funções comuns e as tarefas de exemplo referenciadas no conteúdo do Cloud de Confiance by S3NS , consulte Funções e tarefas de usuário comuns do GKE.

Diagnosticar problemas do VerticalPodAutoscaler

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

Descrever o VerticalPodAutoscaler

Para conferir os cálculos em tempo real e as 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á o seguinte:

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 ver a configuração e o estado completos de um VerticalPodAutoscaler, inspecione o manifesto YAML dele usando kubectl ou o console do Cloud de Confiance :

Console

  1. No console do Cloud de Confiance , acesse a página Navegador de objetos.

    Acessar o navegador de objetos

  2. Clique na lista de filtros Tipo de objeto.

  3. Limpe as seleções atuais.

  4. Selecione VerticalPodAutoscaler e clique em OK.

  5. Na lista filtrada, selecione o grupo de APIs autoscaling.k8s.io.

  6. Selecione o tipo de objeto VerticalPodAutoscaler.

  7. Clique no nome do VerticalPodAutoscaler que você quer inspecionar.

kubectl

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

Substitua:

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

Verificar o status do VerticalPodAutoscaler no console do Cloud de Confiance

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

  1. Acesse a página Cargas de trabalho.

    Acesse "Cargas de trabalho"

  2. Clique no nome da sua carga de trabalho.

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

  4. Revise a linha Autoescalonador de Pods Vertical para ver mensagens de status sobre a coleta de métricas e a integridade da configuração.

Coletar registros de decisões

Para insights detalhados sobre cálculos e decisões do VerticalPodAutoscaler, ative os registros de decisões do Autoescalonador de Pods Vertical (prévia) 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 de 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 esperadas.

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

Sintomas:

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

Causa:

  • Destino incorreto: o campo spec.targetRef no manifesto VerticalPodAutoscaler não aponta para uma carga de trabalho existente no mesmo namespace.
  • Coleta inicial de métricas: o VerticalPodAutoscaler foi criado recentemente e ainda está coletando dados históricos de uso de recursos.
  • Problemas no componente metrics-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 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: os 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 um número alto de reinicializações, verifique os registros dele:

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

      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: confira 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 estão mais altos ou mais baixos do que o esperado.
  • As recomendações não estão alinhadas com o consumo de recursos observado da carga de trabalho.

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 podem ainda não estar refletidas.
  • Características da carga de trabalho: jobs de curta duração ou cargas de trabalho com padrões de uso altamente irregulares 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:

  • Permita um tempo de ajuste: dê tempo para o VerticalPodAutoscaler aprender novos padrões de uso após as mudanças no aplicativo.
  • Avalie a adequação: determine se um VerticalPodAutoscaler ou um Escalonador automático horizontal de pods é mais adequado para o tipo de carga de trabalho.
  • Verifique se há recursos VerticalPodAutoscaler conflitantes:

    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 do pod

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

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

Sintomas:

  • O manifesto 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 campo spec.updatePolicy.updateMode 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.
  • Aumentar 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 de contêineres 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 do redimensionamento adiado e a capacidade do nó:

    Se o redimensionamento permanecer adiado por mais de cinco minutos, o VerticalPodAutoscaler vai 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 anotação vpaInPlaceUpdated 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 adiado:

      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 seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: