Resolver problemas com ComputeClass personalizados

Este documento ajuda a resolver problemas em que as cargas de trabalho do GKE não são programadas em nós definidos por uma ComputeClass personalizada ou quando o escalonador automático de cluster não provisiona os tipos de máquina esperados.

Este documento é destinado a desenvolvedores de aplicativos e administradores e operadores de plataforma que usam ComputeClasses personalizadas para gerenciar a programação de cargas de trabalho e a criação automática de pool de nós no GKE. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Cloud de Confiance by S3NS , consulte Tarefas e papéis de usuário comuns do GKE.

Principais conceitos

Para ajudar na solução de problemas, conheça os seguintes componentes e mecanismos do GKE:

• ComputeClass personalizada: um recurso específico do GKE que permite definir uma lista priorizada de configurações de nós para escalonamento automático. Para mais informações, consulte Sobre as ComputeClasses personalizadas.

• Escalonador automático de clusters: o componente que adiciona ou remove nós automaticamente no cluster com base na demanda da carga de trabalho. Para mais informações, consulte Sobre o escalonamento automático de clusters do GKE.

• Criação automática de pools de nós: o escalonador automático de cluster do GKE cria e gerencia pools de nós automaticamente com base nos requisitos da carga de trabalho. Para mais informações, consulte Sobre a criação automática de pools de nós.

• Lógica de substituição: o mecanismo em que o escalonador automático de clusters tenta provisionar nós que correspondem primeiro à regra de prioridade mais alta. Para mais informações, consulte Escolher as prioridades de computação substitutas.

Resolver problemas por sintomas

Este documento organiza as etapas de solução de problemas em sequência, desde verificações fundamentais até configurações mais avançadas. Para um diagnóstico mais abrangente, recomendamos seguir estas etapas em ordem. Como alternativa, se você estiver com problemas específicos, consulte os links relevantes na tabela a seguir:

Problemas fora do escopo

Este documento não aborda os seguintes problemas:

• Problemas gerais de rede do GKE, como conectividade de pod para pod ou balanceamento de carga de serviço.
• Problemas relacionados ao Escalonador automático horizontal de pods (HPA) ou ao Autoescalonador de Pods Vertical (VPA).
• Problemas não relacionados ao mecanismo de ComputeClass personalizada, como erros no nível do aplicativo ou problemas de PersistentVolume que não estão relacionados a restrições de programação.
• Problemas de cota ou indisponibilidade de recursos que não estão diretamente relacionados à lógica de fallback da ComputeClass.

Identificar variáveis de marcador de posição

Para personalizar os comandos neste documento, insira seus valores específicos na coluna Variable. Os valores editados são sincronizados automaticamente em todos os blocos de código e comandos.

Antes de começar

Para receber as permissões necessárias para realizar as tarefas neste documento, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto do Cloud de Confiance by S3NS :

• Para acessar clusters do GKE: Leitor de cluster do Kubernetes Engine (roles/container.viewer).
• Para ver os registros: Visualizador de registros (roles/logging.viewer).
• Para gerenciar clusters do GKE: administrador do Kubernetes Engine (roles/container.admin).

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Para configurar o kubectl para se comunicar com o cluster, execute o seguinte comando:

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

Realizar verificações de diagnóstico básicas

Verifique se os componentes principais estão configurados corretamente e se o cluster é compatível com ComputeClasses personalizadas.

Verificar o status e o seletor do pod

Confirme se o pod está no estado Pending e solicita corretamente a ComputeClass personalizada.

1. Liste os pods no estado Pending:

   kubectl get pods --all-namespaces -o wide | grep Pending
   

2. Inspecione a especificação do pod para o campo nodeSelector:

   kubectl get pod POD_NAME
       -n NAMESPACE
       -o jsonpath='{.spec.nodeSelector}'
   

Avaliar o resultado

• A saída mostra o rótulo:o campo nodeSelector está configurado corretamente com o rótulo cloud.google.com/compute-class.
• A saída não mostra o rótulo:
  • Interpretação:pode haver um campo nodeSelector incorreto ou ausente para o rótulo cloud.google.com/compute-class na configuração de implantação da carga de trabalho.
  • Resolução:modifique o arquivo YAML da sua carga de trabalho, como uma implantação ou um job, para incluir o campo nodeSelector na seção spec.template.spec.

Verificar a compatibilidade da versão do cluster

As ComputeClasses personalizadas exigem o GKE versão 1.30.3-gke.1451000 ou posterior. Verifique se o cluster está executando uma versão que oferece suporte a ComputeClasses personalizadas.

Verifique a versão do cluster:

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

Avaliar o resultado

• Versão 1.30.3-gke.1451000 ou mais recente:sua versão do cluster é compatível com ComputeClasses personalizadas.
• Versão anterior a 1.30.3-gke.1451000:
  • Interpretação:seu cluster não foi atualizado para uma versão que oferece suporte a ComputeClasses personalizados.
  • Resolução:faça upgrade do cluster para usar ComputeClasses personalizadas.

Verificar os nós provisionados para a ComputeClass personalizada

Para verificar se há nós no cluster associados à sua ComputeClass, liste os nós que correspondem ao rótulo da ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

Se a saída for No resources found, não haverá nós associados à ComputeClass. Verifique se as cargas de trabalho realmente selecionaram essa ComputeClass e confira os eventos de escalonamento automático para erros de escalonamento vertical.

Verificar configurações de ComputeClass personalizada

Configurações incorretas no recurso ComputeClass personalizado podem impedir a programação de pods ou o provisionamento correto de nós pelo GKE.

Verificar a integridade e o status da ComputeClass

Verifique se o GKE informa a ComputeClass personalizada como íntegra.

1. Liste todos os recursos ComputeClass:

   kubectl get computeclass
   

2. Descreva o recurso ComputeClass específico:

   kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME
   

Avaliar o resultado

• O status de integridade mostra True:a ComputeClass personalizada está íntegra. Veja a seguir um exemplo de uma ComputeClass personalizada íntegra:

  Status:
    Conditions:
      Last Transition Time:  2024-01-19T17:18:48Z
      Message:               CCC is healthy.
      Reason:                Health
      Status:                True
      Type:                  Health
  

• O status de integridade mostra False:

  • Interpretação:a ComputeClass personalizada não está íntegra. Analise os campos Message e Reason na saída para identificar o problema.
  • Resolução:execute a ação que corresponde ao campo Reason na saída:
    • NodePoolNotExist: verifique se o pool de nós referenciado existe ou atualize a ComputeClass para referenciar um pool de nós atual.
    • ReservationUnusable: verifique a configuração e o uso da reserva referenciada.
    • Invalid machine type: atualize a ComputeClass para usar um tipo de máquina compatível com a região ou zona do cluster.

Validar a política unsatisfiable

O campo whenUnsatisfiable determina o comportamento quando nenhuma regra de prioridade pode ser atendida.

Confira a política:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Inspecione o campo spec.whenUnsatisfiable na saída. Esse campo pode ter um dos seguintes valores:

• DoNotScaleUp: os pods vão permanecer no estado Pending se não for possível criar nós preferenciais.
• ScaleUpAnyway: os pods podem ser executados em tipos de nó padrão (como a série E2) se os nós preferenciais não estiverem disponíveis.

Avaliar o resultado

O efeito da política whenUnsatisfiable depende do valor dela:

• Se o valor for DoNotScaleUp:
  • Interpretação:esse é o comportamento esperado quando nenhuma regra de prioridade pode ser atendida, possivelmente devido à indisponibilidade de recursos ou aos limites de cota. Se os pods precisarem esperar por um hardware específico, esse valor estará correto.
  • Resolução:se a execução da carga de trabalho for mais importante do que a execução em um hardware específico, mude a política para ScaleUpAnyway.
• Se o valor for ScaleUpAnyway:
  • Interpretação:esse comportamento é esperado. O GKE está voltando aos tipos de nós padrão porque os nós preferenciais não estão disponíveis.
  • Resolução:se os pods não puderem ser executados em tipos de nó padrão, mude a política para DoNotScaleUp.
• Comportamento padrão:se você não especificou um valor para o campo whenUnsatisfiable e está usando uma versão do GKE anterior à 1.33, a política padrão é ScaleUpAnyway.

O exemplo a seguir mostra como atualizar a política editando o campo whenUnsatisfiable no manifesto do ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

Verificar as restrições de programação de pods

Verifique se a especificação do pod é compatível com os atributos dos nós provisionados pela ComputeClass personalizada.

Verificar solicitações de recursos de pods

Verifique se as solicitações de CPU, memória e GPU do pod podem ser atendidas por pelo menos um dos tipos de máquina definidos no campo priorities da ComputeClass personalizada.

1. Receba solicitações de recursos de pods:

   kubectl get pod POD_NAME
       -n NAMESPACE
       -o jsonpath='{.spec.containers[*].resources.requests}'
   

   Inspecione a saída de cpu, memory e solicitações de GPU, como nvidia.com/gpu.

2. Compare essas solicitações com os tipos de máquina definidos no campo priorities da ComputeClass personalizada:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
       -o jsonpath='{.spec.priorities}'
   

   Inspecione a saída dos campos machineType ou machineFamily. Para cada tipo de máquina na ComputeClass personalizada, confira as especificações na documentação sobre tipos de máquinas e verifique se os recursos alocáveis são maiores do que as solicitações do pod.

Avaliar o resultado

• Recursos compatíveis:as solicitações de recursos do pod são menores ou iguais aos recursos alocáveis de pelo menos um tipo de máquina na ComputeClass.

• Os recursos excedem a capacidade:

  • Interpretação:o pod não pode ser programado porque nenhum tipo de máquina na ComputeClass fornece CPU, memória ou GPU suficientes. Isso também pode acontecer se o campo nodePoolAutoCreation estiver definido como true e a solicitação de memória do pod exceder os limites dos pools de nós criados automaticamente.
  • Resolução:ajuste as solicitações de recursos do pod ou os tipos de máquina da ComputeClass personalizada:
    • Reduza as solicitações de recursos do pod: se as solicitações de recursos forem altas, diminua os valores de cpu, memory ou gpu no arquivo YAML da carga de trabalho.
    • Mudar para tipos de máquina maiores: se as solicitações do pod forem justificadas, modifique o campo spec.priorities no manifesto da ComputeClass personalizada para incluir opções maiores de machineType ou machineFamily que possam atender às demandas do pod. Exemplo:

  spec:
    priorities:
    - machineType: n2d-highmem-96 # A larger machine type
      spot: true
    # ... other priorities
  

Verificar se há taints e tolerâncias conflitantes

Os nós criados para uma ComputeClass personalizada têm o taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. O GKE adiciona essa tolerância aos pods automaticamente.

No entanto, hardwares especializados, como GPUs, têm taints adicionais, como o taint nvidia.com/gpu=present:NoSchedule. Se a ComputeClass usar nós com hardware especializado, os pods precisam ter uma tolerância para esses taints para serem programados nesses nós.

Verifique o campo tolerations do pod:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

Avaliar o resultado

• Tolerâncias corretas:as restrições e tolerâncias estão configuradas corretamente.

• Tolerâncias ausentes:

  • Interpretação:a falta de tolerâncias impede que o pod seja programado em nós com taints de hardware especializados. Por exemplo, se a ComputeClass usar nós de GPU, o pod pode não ter a tolerância nvidia.com/gpu=present:NoSchedule. Para requisitos específicos da GPU, consulte Verificar a configuração da GPU.

  • Resolução:no campo tolerations da especificação do pod, adicione as tolerâncias necessárias para corresponder aos taints nos nós definidos pela ComputeClass. Por exemplo, para nós de GPU, adicione uma tolerância ao taint nvidia.com/gpu=present:NoSchedule da seguinte maneira:

    spec:
    template:
    spec:
    tolerations:
    - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
    # ... other tolerations and Pod spec
    

Analisar a métrica de pods pendentes do escalonador automático de clusters

Versões aplicáveis do GKE: 1.37 e mais recentes

Para entender por que os pods que solicitam uma ComputeClass específica estão pendentes, use a métrica kubernetes.io/autoscaler/cluster_pending_pods_per_ccc no Cloud Monitoring. Essa métrica ajuda a identificar se o problema é a falta de nós adequados para a ComputeClass, um problema com o provisionamento ou algo inerente à configuração do pod. Essa métrica mostra o número de pods que o escalonador automático de cluster está processando, dividido por ComputeClass, o motivo de estar pendente e se é um pod do sistema ou do usuário.

Etapas para consultar

Para consultar a métrica no console do Cloud de Confiance , siga estas etapas:

1. No console Cloud de Confiance , acesse a página do Metrics Explorer.
2. Selecione o Tipo de recurso:k8s_entity.
3. Selecione a Métrica:kubernetes.io/autoscaler/cluster_pending_pods_per_ccc.
4. Adicione um filtro:entity_type = ComputeClass.
5. Adicione um Filtro para sua ComputeClass específica: entity_name = "COMPUTECLASS_NAME".
   • Para ver os pods que não estão usando nenhuma ComputeClass, filtre com entity_name = "".
6. Agrupe por metric.labels.reason para ver os estados do escalonador automático desses pods. Também é possível agrupar pods usando o rótulo de chave metric.labels.type.

Exemplo de consulta PromQL

Para encontrar o status dos pods de usuário pendentes que solicitam a ComputeClass "COMPUTECLASS_NAME", use a seguinte consulta do PromQL:

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

Motivos de métricas

A saída do rótulo da chave metric.labels.reason pode incluir o seguinte:

• unable_to_provision: o escalonador automático de cluster está bloqueado. Os pods nesse estado para uma ComputeClass não podem ser programados porque não é possível criar novos nós. Verifique os registros do escalonador automático de cluster no plano de controle para mais detalhes sobre falta de estoque, cotas ou configurações incorretas na definição da ComputeClass. Revise também os eventos de visibilidade do escalonador automático de clusters.

• provisioning_in_progress: um escalonamento vertical foi acionado para nós que precisam corresponder aos requisitos da ComputeClass. Se os pods permanecerem aqui, pode haver atrasos na criação ou prontidão do nó.

• unprocessed: o escalonador automático de cluster ainda não avaliou esses pods. Um número alto persistente pode indicar um atraso no escalonador automático.

• no_action_taken: o escalonador automático de clusters decidiu não escalonar esses pods. Esse comportamento pode ser resultado de restrições de pod que não podem ser atendidas pelos tipos de nó da ComputeClass ou por outros limites no nível do cluster. Examine a especificação do pod (kubectl describe pod) e os registros do escalonador automático de cluster.

Analisar falhas de provisionamento de nós

Versões do GKE aplicáveis: 1.37 e mais recentes

Para verificar o status de integridade atual de uma ComputeClass, consulte Verificar a integridade da ComputeClass. Se você observar que os pods associados a uma ComputeClass estão em um estado unable_to_provision, o escalonador automático de clusters não está provisionando novos nós que atendam aos requisitos da ComputeClass. Use a métrica do Cloud Monitoring kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc para diagnosticar a causa raiz.

1. No console do Cloud de Confiance , acesse Monitoring e Metrics Explorer.
2. Selecione o Tipo de recurso como k8s_entity.
3. Selecione a Métrica como kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc.
4. Adicione um Filtro: resource.labels.entity_type = ComputeClass.
5. Adicione um filtro para sua ComputeClass específica: entity_name = "CUSTOM_COMPUTECLASS_NAME".
   • Para ver os pods que não usam nenhuma ComputeClass, filtre com entity_name = "".
6. Na seção Agrupar por, selecione metric.labels.reason e resource.labels.entity_name.
7. Escolha um Agregador, como rate ou delta.

A taxa ou mudança nas falhas é exibida, dividida por motivo.

Interpretar motivos de falha

O campo metric.labels.reason fornece insights sobre por que a criação de nós está falhando. Ao identificar os principais motivos da falha, você pode tomar medidas corretivas.

Os possíveis motivos incluem:

Configuração do pool de nós (clusters padrão)

Nos clusters do GKE Standard, os pools de nós criados manualmente precisam ser rotulados e corrompidos para funcionar com uma ComputeClass personalizada.

Verificar identificadores e taints do pool de nós

1. Identifique os pools de nós na sua ComputeClass personalizada. Se a ComputeClass personalizada usar o campo nodePools, anote os nomes dos pools de nós listados:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. Para cada pool de nós identificado, verifique a configuração:

   gcloud container node-pools describe NODE_POOL_NAME
       --cluster CLUSTER_NAME
       --location LOCATION
       --format="yaml(config.labels, config.taints)"
   

Avaliar o resultado

• Pool de nós configurado corretamente:o pool de nós tem o rótulo cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME e o taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

• Pool de nós configurado incorretamente:

  • Interpretação:o pool de nós não foi configurado com o rótulo e o taint necessários para associá-lo à ComputeClass personalizada.

  • Resolução:atualize o pool de nós para adicionar o rótulo e o taint:

    1. Adicione ou atualize o rótulo do nó:

       gcloud container node-pools update NODE_POOL_NAME \
           --cluster=CLUSTER_NAME --location=LOCATION \
           --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME
       

    2. Adicione ou atualize o taint do nó:

       gcloud container node-pools update NODE_POOL_NAME \
           --cluster=CLUSTER_NAME --location=LOCATION \
           --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule
       

Verificar a configuração de criação automática de pool de nós

Para clusters do Autopilot e do Standard com nodePoolAutoCreation definido como true, a criação automática de pool de nós precisa ser configurada corretamente.

Verificar se a criação automática de pool de nós está ativada

1. Verifique se o campo nodePoolAutoCreation.enabled na ComputeClass personalizada está definido como true:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. Verifique se a criação automática de pool de nós está ativada no cluster:

   gcloud container clusters describe CLUSTER_NAME
       --location LOCATION
       --format="value(autoscaling.enableNodeAutoprovisioning)"
   

Se um deles estiver desativado, a criação automática de pool de nós não vai criar novos pools para sua ComputeClass personalizada.

Avaliar o resultado

• Criação automática de pool de nós ativada:na ComputeClass, o campo nodePoolAutoCreation.enabled está definido como true, e o provisionamento automático de nós está ativado no nível do cluster.

• Criação automática de pool de nós desativada:

  • Interpretação:a criação automática de pool de nós será desativada se o valor do campo nodePoolAutoCreation.enabled for false ou estiver ausente na ComputeClass ou se o provisionamento automático de nós no nível do cluster estiver desativado.

  • Resolução:ative a criação automática de pool de nós:

    1. Edite o arquivo YAML da ComputeClass personalizada para incluir nodePoolAutoCreation: enabled: true:

       spec:
         # ... priorities
         nodePoolAutoCreation:
           enabled: true
       

    2. Ative a criação automática de pool de nós no nível do cluster e configure os limites de recursos:

       gcloud container clusters update CLUSTER_NAME --location LOCATION \
         --enable-autoprovisioning \
         --autoprovisioning-min-cpu=MIN_CPU \
         --autoprovisioning-max-cpu=MAX_CPU \
         --autoprovisioning-min-memory=MIN_MEMORY \
         --autoprovisioning-max-memory=MAX_MEMORY
       

Verificar os limites de recursos para a criação automática de pool de nós

A criação automática de pools de nós tem limites de CPU e memória para todo o cluster. Se o uso atual do cluster mais os recursos de um novo nó excederem esses limites, a criação automática de pool de nós não provisionará novos nós.

1. Confira os limites de recursos:

   gcloud container clusters describe CLUSTER_NAME
       --location LOCATION
   --format="value(autoscaling.resourceLimits)"
   

   A saída lista os campos resourceType, minimum e maximum para CPU e memória (em GB).

2. Revise os tipos de máquina nas prioridades da ComputeClass personalizada. Confira as especificações de CPU e memória na documentação sobre tipos de máquina.

3. Determine a capacidade total atual de CPU e memória de todos os nós no cluster. A soma da capacidade atual mais os recursos de um possível novo nó não pode exceder o limite máximo para a criação automática de pool de nós.

Avaliar o resultado

• Capacidade suficiente:o cluster tem capacidade de CPU e memória suficiente dentro dos limites de recursos para que a criação automática de pool de nós provisione um novo nó.

• Limites excedidos:

  • Interpretação:a criação automática de pool de nós não pode provisionar novos nós porque o cluster atingiu os limites de CPU ou memória, ou os limites foram definidos muito baixos para os tipos de máquina na ComputeClass.

  • Resolução:aumente os limites de recursos para a criação automática de pool de nós:

    1. Determine novos limites máximos que considerem o uso atual e o crescimento futuro, incluindo os maiores tipos de máquina na ComputeClass personalizada.

    2. Atualizar os limites de recursos para a criação automática de pool de nós de nós. É possível definir vários recursos em um comando:

       gcloud container clusters update CLUSTER_NAME --location LOCATION \
         --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
         --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB
       

Analisar o comportamento de fallback do escalonador automático

Esta seção ajuda você a investigar fatores externos para entender por que o escalonador automático de clusters pode estar ignorando as opções preferidas e usando substitutos ou não conseguindo fazer escalonar verticalmente.

As ComputeClasses personalizadas usam uma lógica de substituição priorizada. Se um pod não estiver sendo programado em nós que correspondem à regra de maior prioridade, isso geralmente se deve a restrições como indisponibilidade de recursos ou cotas de projeto. Quando o GKE não consegue provisionar nós que correspondam a uma regra de prioridade específica, por exemplo, devido a um erro ZONE_RESOURCE_POOL_EXHAUSTED ou QUOTA_EXCEEDED do Compute Engine, o escalonador automático de clusters tenta imediatamente a próxima regra na lista priorities. Não há período de espera antes que o GKE volte para a próxima prioridade, exceto ao usar TPUs ou o modelo de provisionamento de início flexível, que aceitam um atraso configurável.

Verificar se há indisponibilidade de recursos

Verifique se os recursos estão indisponíveis na zona especificada conferindo os registros do escalonador automático de clusters ou os erros do grupo gerenciado de instâncias (MIG) do Compute Engine.

Opção 1: verificar eventos de visibilidade do escalonador automático de clusters

No console do Cloud de Confiance , acesse Cloud Logging > Análise de registros e execute a seguinte consulta para encontrar eventos do escalonador automático que possam indicar indisponibilidade de recursos:

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

Opção 2: verificar erros do MIG

É possível verificar erros de MIG no console Cloud de Confiance ou usando uma consulta do Cloud Logging.

• Usando o console do Cloud de Confiance :

  1. No console do Cloud de Confiance , acesse Compute Engine > Grupos de instâncias.
  2. Encontre o MIG correspondente ao pool de nós que não está sendo escalonar verticalmente.
  3. Clique no nome do MIG e acesse a guia Erros. Procure mensagens que indiquem esgotamento de recursos.

• Usando a consulta do Cloud Logging:

  1. No console do Cloud de Confiance , acesse Cloud Logging > Análise de registros.
  2. Execute a consulta a seguir para verificar se há erros de esgotamento de recursos do MIG:

  resource.type="gce_instance"
  log_id("cloudaudit.googleapis.com/activity")
  protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")
  

Avaliar o resultado

• Os recursos estão disponíveis:se os registros não mostrarem as mensagens ZONE_RESOURCE_POOL_EXHAUSTED, é improvável que a indisponibilidade de recursos seja a causa da falha de escalonamento vertical.

• Os recursos não estão disponíveis:

  • Interpretação:o provisionamento de nós falha devido a uma alta demanda temporária por um tipo de máquina específico (especialmente VMs spot ou GPUs) nessa zona ou porque um pod está restrito pela afinidade do PersistentVolume a uma zona que está passando por indisponibilidade de recursos.

  • Resolução:a indisponibilidade de recursos é temporária, mas é possível melhorar a resiliência adicionando flexibilidade à configuração:

    • Diversifique os tipos de máquinas: verifique se o campo spec.priorities na ComputeClass personalizada contém vários tipos ou famílias de máquinas como substitutos:

      spec:
        priorities:
        - machineFamily: c3  # Highest priority
        - machineFamily: n2d # Fallback option
        - machineFamily: e2  # Lowest priority
      

    • Use clusters regionais: se o cluster for zonal, ele estará vulnerável à indisponibilidade de recursos nessa única zona. O uso de clusters regionais permite que o escalonador automático de clusters tente provisionar nós em outras zonas da região em que a capacidade pode estar disponível.

    • Use reservas do Compute Engine: para cargas de trabalho críticas que não podem tolerar atrasos, crie reservas do Compute Engine para garantir a capacidade de tipos de máquinas específicos.

Verificar as cotas do projeto

Confirme se o projeto tem cota suficiente para os recursos, como CPUs, GPUs e endereços IP exigidos pelos novos nós.

1. Verifique os registros do escalonador automático para encontrar erros de cota. Use o Cloud Logging para pesquisar mensagens de erro relacionadas a cotas nos eventos de visibilidade do escalonador automático:

   resource.type="k8s_cluster"
   resource.labels.location="LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   log_id("container.googleapis.com/cluster-autoscaler-visibility")
   jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"
   

   Como alternativa, use a seguinte consulta do Cloud Logging para verificar os registros em busca de erros relacionados a cotas do MIG:

   resource.type="gce_instance"
   protoPayload.methodName:"compute.instances.insert"
   protoPayload.status.message:"QUOTA_EXCEEDED"
   severity=ERROR
   

2. Analise as cotas no console do Cloud de Confiance :

   1. No console do Cloud de Confiance , acesse IAM e administrador > Cotas.
   2. Filtre pelo serviço API Compute Engine.
   3. Verifique o uso de métricas relevantes, como CPUs, GPUs (todos os tipos) e endereços IP em uso na região em que o cluster do GKE está localizado. Verifique se o uso atual não está no limite.

Avaliar o resultado

• Cota abaixo dos limites:se o uso da cota estiver abaixo dos limites e não houver erros QUOTA_EXCEEDED nos registros, os limites de cota não vão bloquear o escalonamento vertical.
• Cota excedida:
  • Interpretação:o provisionamento de nós falha devido à cota insuficiente para recursos como CPUs, GPUs, endereços IP ou MIGs.
  • Resolução:se o projeto atingiu um limite de cota, solicite um aumento de cota.

Configurações avançadas

Configurações como GPUs, VMs spot e reservas do Compute Engine têm requisitos específicos e possíveis pontos de falha que precisam ser verificados.

Verificar a configuração da GPU

Para ComputeClasses personalizadas que provisionam nós de GPU, valide a configuração da GPU na ComputeClass personalizada e verifique se o pod tem a tolerância nvidia.com/gpu obrigatória.

1. Verifique o YAML da ComputeClass personalizada para um bloco gpu em uma regra de prioridade:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

   O bloco gpu precisa especificar um campo type e um campo count. Por exemplo:

   priorities:
   - machineType: a2-highgpu-1g
     gpu:
       type: nvidia-tesla-a100
       count: 1
   

2. Inspecione o pod para verificar a tolerância da GPU. Qualquer pod que precise ser programado em um nó de GPU precisa ter a tolerância nvidia.com/gpu, mesmo que o pod não solicite uma GPU.

   kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
   

   Verifique a tolerância no campo spec.tolerations.

Avaliar o resultado

• GPU configurada corretamente:se a ComputeClass definir a GPU type e count, e os pods incluírem a tolerância nvidia.com/gpu, a configuração da GPU estará correta. Veja a tolerância necessária:

  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
  

• GPU configurada incorretamente:

  • Interpretação:o pod pode não ter a tolerância nvidia.com/gpu necessária, a ComputeClass pode estar em estado ruim devido a incompatibilidades de campo de GPU ou a versão do GKE pode não processar a configuração de GPU corretamente.
  • Resolução:execute uma das seguintes ações:
    • Modifique o arquivo YAML da carga de trabalho para incluir a tolerância obrigatória de GPU e reaplique o arquivo YAML.
    • Faça upgrade do cluster do GKE. Se a ComputeClass personalizada não estiver íntegra e o problema estiver relacionado aos campos de GPU, verifique se há problemas conhecidos e faça upgrade para uma versão corrigida do GKE, por exemplo, 1.31.8-gke.1045000 ou mais recente.

Verificar a configuração das VMs spot

Se você usar VMs spot, verifique se a configuração spot: true está nas regras de prioridade corretas no manifesto da ComputeClass. Além disso, entenda a lógica de preços do escalonador automático de cluster.

Inspecione o manifesto ComputeClass:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Na saída, procure spot: true no campo spec.priorities. Por exemplo:

priorities:
- machineFamily: n2d
  spot: true

O escalonador automático de clusters pode usar dados de preços de us-central1 como base ao comparar o custo de diferentes tipos de VMs spot, o que pode levar a escolhas aparentemente não ideais em outras regiões. Esse é um comportamento conhecido.

Avaliar o resultado

• VMs spot configuradas corretamente:se o campo spot: true for especificado e o escalonador automático de cluster provisionar VMs spot, a configuração vai funcionar conforme o esperado.

• Falha ao programar VMs spot:

  • Interpretação:os pods que exigem VMs spot podem não ser programados nelas devido à indisponibilidade de recursos na zona de destino ou porque o escalonador automático de clusters pode estar escolhendo um tipo de VM diferente com base no modelo de preços us-central1.

  • Resolução:

    • Se você suspeitar que um recurso está indisponível, consulte Verificar a indisponibilidade de recursos.

    • Para controlar a seleção de VMs spot, liste explicitamente as entradas machineType no campo priorities, da mais barata para a mais cara na sua região. Essa abordagem oferece controle direto sobre a ordem de substituição. Exemplo:

      spec:
        priorities:
        - machineType: t2d-standard-48 # Cheapest in this region
          spot: true
        - machineType: n2d-standard-48 # Fallback Spot option
          spot: true
        - machineType: n2d-standard-48 # On-demand fallback
          spot: false
      

Saúde geral do escalonador automático de clusters

Esta seção ajuda a verificar problemas que podem não estar diretamente relacionados à configuração personalizada do ComputeClass, mas que podem estar afetando a operação.

Verificar operações simultâneas

Verifique se não há outras operações de cluster ou pool de nós em andamento simultaneamente. O GKE tem limites para operações simultâneas, o que pode bloquear o escalonamento automático.

Liste as operações em andamento que não estão no estado DONE:

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

Se o comando retornar alguma operação, uma ação como um upgrade de cluster, a criação de um pool de nós ou outra modificação pode estar em andamento. Os eventos de escalonamento automático podem ser bloqueados até que essa operação seja concluída.

Avaliar o resultado

• Nenhuma operação simultânea:se o comando list retornar uma lista vazia, o escalonador automático de cluster não será bloqueado por nenhuma operação.

• Operações simultâneas encontradas:

  • Interpretação:se o comando listar operações com status RUNNING ou PENDING, uma operação simultânea, como um upgrade de cluster ou uma modificação de pool de nós, poderá estar em andamento e bloqueando o escalonamento automático.

  • Resolução:aguarde a conclusão da operação em andamento. É possível monitorar o status usando um ID de operação:

    gcloud container operations wait OPERATION_ID --location LOCATION
    

    Substitua OPERATION_ID pelo ID da saída do comando list. Depois que a operação de bloqueio for concluída, o escalonador automático de cluster vai retomar a função normal.

Analisar migração ativa

Se você observar que as cargas de trabalho permanecem em nós de prioridade mais baixa quando nós de prioridade mais alta estão disponíveis, verifique se a migração ativa está ativada. Se o campo activeMigration.optimizeRulePriority estiver definido como false ou omitido na ComputeClass, o GKE não moverá automaticamente as cargas de trabalho para nós de maior prioridade quando eles ficarem disponíveis.

1. Para verificar as tolerâncias do pod, revise o campo spec.tolerations. Se o pod tiver tolerâncias que correspondam a taints em vários pools de nós de prioridades diferentes, o programador poderá colocá-lo em um nó de prioridade mais baixa se ele estiver disponível primeiro.

   kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
   

2. Para verificar se a migração ativa está ativada, inspecione o manifesto ComputeClass para o campo spec.activeMigration.optimizeRulePriority.

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

Avaliar o resultado

• Migração ativa ativada:se o campo activeMigration.optimizeRulePriority for true, o GKE tentará mover as cargas de trabalho para nós de maior prioridade quando eles estiverem disponíveis.

• Migração ativa desativada ou ineficaz:

  • Interpretação:se o campo activeMigration.optimizeRulePriority for false ou for omitido, ou se as tolerâncias do pod forem muito amplas, as cargas de trabalho vão permanecer em nós de prioridade mais baixa quando nós de prioridade mais alta estiverem disponíveis. Essa abordagem permite que as cargas de trabalho sejam programadas em nós de prioridade mais baixa que ficam disponíveis primeiro.

  • Resolução:se você quiser que as cargas de trabalho sejam movidas para nós de prioridade mais alta, execute uma das seguintes ações:

    • Use restrições de programação mais específicas, como nodeAffinity, para preferir pools de nós de maior prioridade.

    • Edite o manifesto do ComputeClass para definir activeMigration.optimizeRulePriority: true e aplique o arquivo YAML:

      spec:
        activeMigration:
          optimizeRulePriority: true
      

Receber suporte

• 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:

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

A seguir

• Leia as práticas recomendadas para ComputeClasses
• Aplicar ComputeClasses aos pods por padrão
• Configurar a separação de cargas de trabalho no GKE
• Resolver problemas de escalonamento horizontal do escalonamento automático de clusters