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 o agendamento de cargas de trabalho e a criação automática de pool de nós no GKE. Para mais informações sobre as funções comuns e exemplos de tarefas referenciadas no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Principais conceitos

Para ajudar na solução de problemas, confira se você conhece 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ó para escalonamento automático. Para mais informações, consulte Sobre as ComputeClasses personalizadas.

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

  • Criação automática de pool de nós: o escalonador automático de cluster do GKE cria e gerencia automaticamente pools de nós 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 fallback: o mecanismo em que o escalonador automático de cluster tenta provisionar primeiro os nós que correspondem à sua regra de maior prioridade. 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 na ordem. Como alternativa, se você estiver com problemas específicos, consulte os links relevantes na tabela a seguir:

Sintoma Etapas da solução de problemas
O pod que solicita uma ComputeClass personalizada está travado no estado Pending
O escalonador automático de cluster não está criando novos nós que correspondem à ComputeClass personalizada
O escalonador automático de cluster cria tipos de máquinas padrão em vez de tipos especializados Analisar o comportamento de fallback do escalonador automático
A saída do comando kubectl describe computeclass mostra um status não íntegro Verificar configurações personalizadas de ComputeClass
As cargas de trabalho não estão migrando para nós de prioridade mais alta Verificar a integridade geral do escalonador automático de cluster
As cargas de trabalho de VMs de GPU ou spot têm problemas de programação

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 personalizado do ComputeClass, 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.

Variável Descrição
PROJECT_ID O ID do projeto do Google Cloud .
LOCATION A região ou zona do Compute Engine em que o cluster está localizado.
CLUSTER_NAME O nome do cluster.
NODE_POOL_NAME O nome do pool de nós a ser inspecionado (se aplicável a clusters padrão).
CUSTOM_COMPUTECLASS_NAME O nome da ComputeClass personalizada solicitada pelo pod.
NAMESPACE O namespace do pod que não está sendo programado.
POD_NAME O nome do pod que não está sendo programado.

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 papéis do IAM a seguir no seu projeto Google Cloud :

  • Para acessar clusters do GKE: Leitor de clusters 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 aceita 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 no campo nodeSelector:

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

Avalie 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 marcador:
    • 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 sua 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)"

Avalie o resultado

  • Versão 1.30.3-gke.1451000 ou mais recente:a 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 personalizadas.
    • Resolução:faça upgrade do cluster para usar ComputeClasses personalizadas.

Verificar configurações personalizadas de ComputeClass

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. Listar 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. Confira a seguir um exemplo de 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 permanecem no estado Pending se não for possível criar nós preferenciais.
  • ScaleUpAnyway: os pods podem ser executados em tipos de nós padrão (como a série E2) se os nós preferenciais não estiverem disponíveis.

Avalie 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 aguardar 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 é o 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ós 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 a 1.33, a política usa ScaleUpAnyway por padrão.

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

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. Receber solicitações de recursos de pods:

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

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

Avalie 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.
      • Mude para tipos de máquina maiores: se as solicitações do pod forem justificadas, modifique o campo spec.priorities no manifesto personalizado do ComputeClass 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 a restrição cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. O GKE adiciona essa tolerância aos pods automaticamente.

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

Verifique o campo tolerations do pod:

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

Avalie 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 poderá não ter a tolerância nvidia.com/gpu=present:NoSchedule. Para requisitos específicos de 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

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 rótulos 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)"

Avalie 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 uma restrição de nós:

        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 do pool de nós

Nos clusters do Autopilot e do Standard com nodePoolAutoCreation definido como true, a criação automática de pool de nós precisa estar 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.

Avalie o resultado

  • Criação automática de pool de nós ativada:na ComputeClass, o campo nodePoolAutoCreation.enabled é 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 é 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 pool de nós tem limites em todo o cluster para CPU e memória. 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 vai 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 sua ComputeClass personalizada. Confira as especificações de CPU e memória na documentação sobre tipos de máquinas.

  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.

Avalie o resultado

  • Capacidade suficiente:o cluster tem capacidade suficiente de CPU e memória dentro dos limites de recursos para que a criação automática do 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. Atualize 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 cluster pode estar ignorando opções preferenciais e usando substitutos ou não conseguindo fazer escalonar verticalmente.

As ComputeClasses personalizadas usam lógica de substituição com prioridade. Se um pod não estiver sendo programado em nós que correspondem à regra de maior prioridade, isso geralmente ocorre devido a restrições como indisponibilidade de recursos ou cotas de projeto. Quando o GKE não consegue provisionar nós que correspondem 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 cluster tenta imediatamente a próxima regra na lista priorities. Não há período de espera antes de o GKE voltar para a próxima prioridade, exceto ao usar TPUs ou o modelo de provisionamento de início flexível, que oferecem suporte a um atraso configurável.

Verificar a indisponibilidade de recursos

Verifique se os recursos estão indisponíveis na zona especificada conferindo os registros do escalonador automático de cluster 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 cluster

No console Google Cloud , 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 Google Cloud ou usando uma consulta do Cloud Logging.

  • Usando o console do Google Cloud :

    1. No console Google Cloud , 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 uma consulta do Cloud Logging:

    1. No console do Google Cloud , acesse Cloud Logging > Explorador 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")

Avalie 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 no escalonamento.

  • 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 do 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 você pode melhorar a resiliência adicionando flexibilidade à sua configuração:

      • Diversifique os tipos de máquina: 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 cluster 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 cotas de projeto

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

  1. Verifique os registros do escalonador automático para ver se há 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 de erros relacionados a cotas da MIG:

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

  2. Revise as cotas no console do Google Cloud :

    1. No console do Google Cloud , 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á. Verifique se o uso atual não está no limite.

Avalie o resultado

  • Cota abaixo dos limites:se o uso da cota estiver abaixo dos limites e nenhum erro QUOTA_EXCEEDED for encontrado nos registros, os limites da 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.

Configurações avançadas

Configurações como GPUs, Spot VMs 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 de 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 em busca de 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.

Avalie o resultado

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

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

  • GPU mal configurada:

    • 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 no campo da GPU ou a versão do GKE pode não processar a configuração da 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 estiver com problemas e o problema estiver relacionado a 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 do Spot

Se você usa VMs do 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 valor de referência 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.

Avalie o resultado

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

  • Falha ao programar VMs spot:

    • Interpretação:os pods que exigem VMs do Spot podem não ser programados em VMs do Spot devido à indisponibilidade de recursos na zona de destino ou porque o escalonador automático de cluster 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 se um recurso está indisponível.

      • Para controlar a seleção de VMs spot, liste explicitamente as entradas machineType no campo priorities, da mais barata à mais cara para sua região. Essa abordagem dá a você 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

Integridade geral do escalonador automático de clusters

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

Verificar operações simultâneas

Verifique se nenhuma outra operação de cluster ou pool de nós está em andamento simultaneamente. Normalmente, o GKE permite apenas uma operação por vez, 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.

Avalie 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, pode 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 com:

      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 a 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 estiverem 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 do ComputeClass no campo spec.activeMigration.optimizeRulePriority.

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Avalie 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 prioridade mais alta quando eles estiverem disponíveis.

  • Migração ativa desativada ou ineficaz:

    • Interpretação:se o campo activeMigration.optimizeRulePriority for false ou 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 maior prioridade, 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:

A seguir