Resolver problemas de escalonamento automático de clusters

Quando os pods no Google Kubernetes Engine (GKE) ficam presos em um estado Pending e novos nós não são adicionados, isso geralmente indica um problema com a funcionalidade de escalonamento vertical do escalonador automático de cluster. Esse problema pode impedir que seus aplicativos sejam escalonados para atender à demanda, atrasar implantações e afetar a disponibilidade do serviço.

Use esta página para diagnosticar e resolver problemas comuns que impedem o escalonador automático de clusters de adicionar novos nós. A correção desses problemas permite que o programador do Kubernetes coloque suas cargas de trabalho imediatamente e ajuda o cluster a se adaptar ao aumento da carga.

Essas informações são importantes para desenvolvedores de aplicativos, que precisam que os aplicativos e serviços sejam programados e executados de maneira confiável, e para administradores e operadores de plataforma, que são responsáveis por garantir que o cluster possa provisionar recursos dinamicamente para atender aos requisitos de carga de trabalho e manter níveis de serviço. Para mais informações sobre as funções comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Entender quando o escalonador automático de cluster escalona verticalmente os nós

Antes de prosseguir para as etapas de solução de problemas, é útil entender quando o escalonador automático de cluster tenta escalonar verticalmente os nós. O escalonador automático de cluster só adiciona nós quando os recursos atuais são insuficientes.

A cada 10 segundos, o escalonador automático de cluster verifica se há pods não programáveis. Um pod se torna não programável quando o programador do Kubernetes não consegue colocá-lo em nenhum nó atual porque não há recursos suficientes, há restrições no nó ou o nó não cumpre os requisitos do pod.

Quando o escalonador automático de cluster encontra pods não programáveis, ele avalia se a adição de um nó permitiria que o pod fosse programado. Se a adição de um nó permitir que um pod seja programado, o escalonador automático de cluster vai adicionar um novo nó ao grupo gerenciado de instâncias (MIG). O programador do Kubernetes poderá programar o pod no nó recém-provisionado.

Verificar se há pods não programáveis

Para determinar se o cluster precisa de escalonamento vertical, verifique se há pods não programados:

  1. No console Google Cloud , acesse a página Cargas de trabalho.

    Acesse "Cargas de trabalho"

  2. No campo Filtro , digite unschedulable e pressione Enter.

    A lista vai mostrar os pods não programáveis, caso haja algum. Para solucionar problemas com pods não programáveis, consulte Erro: o pod não pode ser programado. Quando o problema que impede a programação dos pods é resolvido, geralmente o escalonador automático de cluster consegue fazer o escalonamento vertical. Para identificar e resolver erros específicos do escalonador automático de cluster, consulte as seções a seguir.

    Se nenhum pod foi exibido, o escalonador automático de cluster não precisa de escalonamento e está funcionando corretamente.

Verifique se havia pods não programáveis antes

Se você estiver investigando o que causou a falha do escalonador automático de cluster no passado, verifique se havia pods não programáveis antes:

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar a Análise de registros

  2. Especifique um período para mostrar as entradas de registro.

  3. No painel de consulta, digite a seguinte consulta:

    logName="projects/PROJECT_ID/logs/events"
jsonPayload.source.component="default-scheduler"
jsonPayload.reason="FailedScheduling"

    Substitua PROJECT_ID pelo ID do projeto.

  4. Clique em Executar consulta.

    Se algum resultado apareceu, significa que havia pods não programáveis no período especificado.

Verificar se o problema é causado por uma limitação

Depois de confirmar que há pods não programados, verifique se o problema com o escalonador automático de cluster é causado por uma das limitações dele.

Conferir erros

Muitas vezes, é possível diagnosticar a causa dos problemas de escalonamento vertical ao consultar mensagens de erro:

Conferir erros nas notificações

Se o problema observado ocorreu há menos de 72 horas, confira as notificações sobre erros no console do Google Cloud . As notificações indicam por que o escalonador automático de cluster não fez o escalonamento vertical, além de incluir recomendações para resolver o erro e conferir os registros relevantes para uma investigação mais detalhada.

Para conferir as notificações no console do Google Cloud , siga estas etapas:

  1. No console do Google Cloud , acesse a página de clusters do Kubernetes.

    Acessar clusters do Kubernetes

  2. Confira a coluna Notificações. Estas notificações estão associadas a problemas de escalonamento vertical:

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

  3. Clique na notificação relevante para abrir um painel com detalhes sobre o que causou o problema e as ações recomendadas para resolvê-lo.

  4. Opcional: para conferir os registros do evento, clique em Registros. A Análise de registros será aberta com uma consulta já preenchida para você investigar melhor o evento de escalonamento. Para saber mais sobre como os eventos de escalonamento vertical funcionam, consulte Visualizar eventos do escalonador automático de clusters.

Se você ainda tiver problemas depois de analisar as orientações na notificação, consulte as tabelas de mensagens de erro para receber mais ajuda.

Ver erros em eventos

Se o problema observado ocorreu há mais de 72 horas, confira os eventos no Cloud Logging. Quando ocorre um erro, ele geralmente é registrado em um evento.

Para conferir os registros do escalonador automático de clusters no console do Google Cloud , siga estas etapas:

  1. No console do Google Cloud , acesse a página de clusters do Kubernetes.

    Acessar clusters do Kubernetes

  2. Selecione o nome do cluster que você quer investigar para acessar a página Detalhes do cluster.

  3. Na página Detalhes do cluster, clique na guia Registros.

  4. Na guia Registros, clique em Registros do escalonador automático para ver os registros.

  5. Opcional: para aplicar filtros mais avançados para restringir os resultados, clique no botão com a seta no lado direito da página para abrir os registros na Análise de registros.

Para saber mais sobre como os eventos de escalonamento vertical funcionam, consulte Visualizar eventos do escalonador automático de clusters. Para um exemplo de como usar o Cloud Logging, consulte o exemplo de solução de problemas a seguir.

Exemplo: resolver um problema com mais de 72 horas

O exemplo a seguir mostra como investigar e resolver um problema com um cluster que não está sendo escalonado verticalmente.

Cenário: há uma hora, um pod foi marcado como não programável. O escalonador automático de cluster não provisionou novos nós para programar o pod.

Solução:

  1. Como o problema ocorreu há mais de 72 horas, você investiga o problema usando o Cloud Logging em vez de analisar as mensagens de notificação.
  2. No Cloud Logging, você encontra os detalhes de registro dos eventos do escalonador automático de clusters, conforme descrito em Conferir erros em eventos.

  3. Você pesquisa eventos scaleUp que contenham o pod que você está investigando no campo triggeringPods. Para filtrar as entradas de registro, inclua a filtragem por um valor de campo JSON específico. Saiba mais em Consultas de registros avançados.

  4. Você não encontra eventos de escalonamento vertical. No entanto, se você encontrou, tente encontrar um EventResult que contenha o mesmo eventId do evento scaleUp. Você poderia conferir o campo errorMsg e consultar a lista de possíveis mensagens de erro scaleUp.

  5. Como você não encontrou nenhum evento scaleUp, continue pesquisando eventos noScaleUp e analise os seguintes campos:

    • unhandledPodGroups: contém informações sobre o pod (ou o controlador do pod).
    • reason: fornece motivos globais que indicam que o escalonamento vertical pode ser bloqueado.
    • skippedMigs: mostra os motivos pelos quais alguns MIGs foram ignorados.

  6. Você encontra um evento noScaleUp no pod, e todos os MIGs no campo rejectedMigs têm o mesmo ID de mensagem de motivo, "no.scale.up.mig.failing.predicate", com dois parâmetros: "NodeAffinity" e "node(s) did not match node selector".

Resolução:

Depois de consultar a lista de mensagens de erro, você descobre que o escalonador automático de cluster não pode escalonar verticalmente um pool de nós porque há uma falha no predicado de programação dos pods pendentes. Os parâmetros são o nome do predicado com falha e o motivo da falha.

Para resolver o problema, revise o manifesto do pod e descubra que ele tem um seletor de nós que não corresponde a nenhum MIG no cluster. Exclua o seletor do manifesto do pod e recrie o pod. O escalonador automático de cluster adiciona um novo nó, e o pod é programado.

Resolver erros de escalonamento vertical

Se você estiver usando ComputeClasses personalizadas e os problemas de escalonamento vertical estiverem relacionados às configurações de nós específicas definidas na sua ComputeClass, consulte Solucionar problemas de ComputeClass personalizadas.

Depois de identificar o erro, use as tabelas a seguir para entender a causa e a solução.

Erros de ScaleUp

As mensagens de evento de erro para eventos scaleUp estão no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Quando uma operação de escalonamento vertical falha por exceder uma cota, é um erro de criação de nó que aciona um período de espera do sistema, que pode durar até 30 minutos. Para mais informações, consulte Períodos de backoff.

Mensagem Detalhes Parâmetros Mitigação
"scale.up.error.out.of.resources" Erros de recurso ocorrem quando você tenta solicitar novos recursos em uma zona que não pode acomodar a solicitação devido à indisponibilidade atual de um recurso do Compute Engine, como GPUs ou CPUs. IDs MIG com falha. Siga as etapas de solução de problemas de disponibilidade de recursos na documentação do Compute Engine.
"scale.up.error.quota.exceeded" O evento scaleUp falhou porque não foi possível aumentar alguns dos MIGs devido ao excesso da cota do Compute Engine. IDs MIG com falha. Verifique a guia Erros do MIG no console do Google Cloud para ver qual quota está sendo excedida. Depois de saber qual cota foi excedida, siga as instruções para solicitar um aumento da cota.
"scale.up.error.waiting.for.instances.timeout" O escalonamento vertical do grupo gerenciado de instâncias falhou devido ao tempo limite. IDs MIG com falha. Se as instâncias forem inicializadas, mas não forem registradas no plano de controle, siga as etapas de solução de problemas de registro de instâncias. Essa mensagem deve ser temporária. Se o problema persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"scale.up.error.ip.space.exhausted" Não foi possível escalonar verticalmente porque as instâncias de alguns dos grupos gerenciados de instâncias ficaram sem IPs. Isso significa que o cluster não tem espaço de endereços IP não alocado suficiente para adicionar novos nós ou pods. IDs MIG com falha. Siga as etapas de solução de problemas em Não há espaço de endereços IP suficiente para o pod.
"scale.up.error.service.account.deleted" Não foi possível escalonar verticalmente porque a conta de serviço foi excluída. IDs MIG com falha. Tente cancelar a exclusão da conta de serviço. Se esse procedimento não funcionar, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

Motivos para um evento noScaleUp

Um evento noScaleUp é emitido periodicamente quando há pods não programáveis no cluster e o escalonador automático de cluster não consegue escalonar verticalmente o cluster para acomodar os pods. Os eventos noScaleUp não cobrem todos os casos possíveis.

Motivos de nível superior NoScaleUp

Mensagens de motivo de nível superior para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.reason. A mensagem contém um motivo de nível superior com o motivo pelo qual o escalonador automático de cluster não pode escalonar o cluster.

Mensagem Detalhes Mitigação
"no.scale.up.in.backoff" Não é possível escalonar verticalmente porque o escalonamento está em um período de espera (temporariamente bloqueado). Essa mensagem pode ocorrer durante eventos escalonar verticalmente com um grande número de pods. Essa mensagem deve ser temporária. Verifique esse erro depois de alguns minutos. Se a mensagem persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

Motivos de provisionamento automático de nós de nível superior NoScaleUp

Mensagens com o motivo de provisionamento automático de nós de nível superior para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.napFailureReason. A mensagem contém um motivo de nível superior com o motivo pelo qual o escalonador automático de cluster não pode provisionar novos pools de nós.

Mensagem Detalhes Mitigação
"no.scale.up.nap.disabled"

O provisionamento automático de nós não foi escalonado verticalmente porque não está ativado no nível do cluster.

Se o provisionamento automático de nós estiver desativado, os novos nós não serão provisionados automaticamente se o pod pendente tiver requisitos que não podem ser atendidos por nenhum dos pools de nós atuais.

 Verifique a configuração do cluster e consulte Como ativar o provisionamento automático de nós.

Motivos no nível MIG NoScaleUp

As mensagens de motivo no nível MIG de eventos noScaleUp aparecem nos campos noDecisionStatus.noScaleUp.skippedMigs[].reason e noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode aumentar o tamanho de um MIG específico.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.mig.skipped" Não é possível escalonar verticalmente um MIG porque ele foi ignorado durante a simulação. Motivos para o MIG ter sido ignorado (por exemplo, falta de um requisito de pod). Avalie os parâmetros incluídos na mensagem de erro e verifique por que o MIG foi ignorado.
"no.scale.up.mig.failing.predicate" Não é possível escalonar verticalmente um pool de nós porque há falha em um predicado de programação dos pods pendentes. Nome do predicado com falha e motivos da falha. Verifique os requisitos de pod, como regras de afinidade, taints ou tolerâncias, e os recursos necessários.

Motivos de provisionamento automático de nós no nível do grupo de pods NoScaleUp

As mensagens com o motivo do provisionamento automático de nós no nível do grupo de pods dos eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode provisionar um novo pool de nós para programar um determinado grupo de pods.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.nap.pod.gpu.no.limit.defined" O provisionamento automático de nós não pôde provisionar nenhum grupo de nós porque um pod pendente tem uma solicitação de GPU, mas os limites de recursos da GPU não estão definidos no nível do cluster. Tipo de GPU solicitada. Avalie a solicitação de GPU pendente do pod e atualize a configuração de limites de GPU do provisionamento automático de nós no nível do cluster.
"no.scale.up.nap.pod.gpu.type.not.supported" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod porque ele tem solicitações para um tipo de GPU desconhecido. Tipo de GPU solicitada. Na configuração do pod pendente, verifique se o tipo de GPU informado é um dos tipos com suporte.
"no.scale.up.nap.pod.zonal.resources.exceeded" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod nesta zona porque isso violaria os limites máximos de recursos em todo o cluster, excederia os recursos disponíveis na zona ou não é um tipo de máquina capaz de atender à solicitação. Nome da zona considerada. Avalie e atualize os limites máximos de recursos de todo o cluster, as solicitações de recursos do pod ou as zonas disponíveis para provisionamento automático de nós.
"no.scale.up.nap.pod.zonal.failing.predicates" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod nessa zona por causa de predicados com falha. Nome da zona considerada e motivos da falha dos predicados. Verifique os requisitos pendentes do pod, como regras de afinidade, taints, tolerâncias ou recursos necessários.

Realizar uma investigação mais detalhada

Nas seções a seguir, apresentamos orientações sobre como usar a Análise de registros e o gcpdiag para ter mais insights sobre os erros.

Investigar erros na Análise de registros

Se você quiser investigar melhor a mensagem de erro, confira os registros específicos do erro:

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar a Análise de registros

  2. No painel de consulta, digite a seguinte consulta:

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    Substitua ERROR_MESSAGE pela mensagem que você quer investigar. Por exemplo, scale.up.error.out.of.resources.

  3. Clique em Executar consulta.

Depurar alguns erros com o gcpdiag

O gcpdiag é uma ferramenta de código aberto criada com a participação de engenheiros técnicos do Google Cloud. Não é um produto Google Cloud com suporte oficial.

Se você receber uma das seguintes mensagens de erro, use gcpdiag para resolver o problema:

  • scale.up.error.out.of.resources
  • scale.up.error.quota.exceeded
  • scale.up.error.waiting.for.instances.timeout
  • scale.up.error.ip.space.exhausted
  • scale.up.error.service.account.deleted

Confira a descrição de todas as flags da ferramenta gcpdiag nas instruções de uso do gcpdiag.

Resolver erros complexos de escalonamento vertical

As seções a seguir ajudam você a resolver erros que exigem várias etapas ou não têm uma mensagem de evento associada do escalonador automático de cluster.

O pod não cabe no nó

Sintomas:

Seus pods permanecem no estado Pending com a mensagem de erro PodUnschedulable, ou o cluster mostra a mensagem de erro Pods unschedulable, e o escalonador automático de cluster não escalonar verticalmente para adicionar nós.

Causa:

O escalonador automático de cluster só adiciona nós a um pool de nós se o tipo de máquina fornecer recursos suficientes, como CPUs, GPUs, memória e armazenamento, para um pod pendente. Se as solicitações de recursos de um pod excederem os recursos de um único nó, o escalonador automático de cluster não vai escalonar verticalmente porque o pod ainda não caberá em um novo nó.

Além disso, os recursos alocáveis de um nó são menores do que o total, porque os componentes do sistema reservam uma parte deles. Para mais informações sobre como o GKE calcula os recursos alocáveis, consulte Recursos alocáveis de nó.

Resolução:

Para verificar se as solicitações de recursos de um pod excedem os recursos fornecidos pelos nós e resolver o problema, siga estas etapas. Este exemplo verifica os recursos de CPU, mas as mesmas etapas se aplicam a GPUs, memória e armazenamento:

  1. No console Google Cloud , acesse a página Cargas de trabalho.

    Acesse "Cargas de trabalho"

  2. Clique na mensagem de erro PodUnschedulable.

  3. No painel Detalhes, clique no nome do pod. Se houver vários pods, comece com o primeiro e repita o processo a seguir para cada um deles.

  4. Na página Detalhes do pod, clique na guia YAML.

  5. Anote as solicitações de recursos de cada contêiner no pod para saber o total de recursos solicitados. Por exemplo, na configuração de pod a seguir, o pod precisa de duas vCPUs:

    resources:
  limits:
    cpu: "3"
  requests:
    cpu: "2"

  6. Confira os detalhes do pool de nós do cluster com o pod não programado:

    1. No console do Google Cloud , acesse a página de clusters do Kubernetes.

      Acessar clusters do Kubernetes

    2. Clique no nome do cluster que tem a mensagem de erro Pods unschedulable.

    3. Na página Detalhes do cluster, clique na guia Nós.

    4. Na seção Pools de nós, anote o valor na coluna Tipo de máquina, por exemplo, n1-standard-1.

  7. Compare a solicitação de recurso com as vCPUs fornecidas pelo tipo de máquina. Por exemplo, se um pod solicitar duas vCPUs, mas os nós disponíveis usarem o tipo de máquina n1-standard-1, os nós terão apenas uma vCPU. Com uma configuração como essa, o escalonador automático de cluster não aciona um escalonamento vertical porque o pod ainda não cabe em um novo nó. Para mais informações sobre os tipos de máquinas disponíveis, consulte o guia de comparação e recursos para famílias de máquinas na documentação do Compute Engine.

  8. Resolva a incompatibilidade com base nas necessidades da sua carga de trabalho:

    • Se o pod precisar dos recursos solicitados: crie um pool de nós com um tipo de máquina que possa atender às solicitações de recursos do pod.
    • Se as solicitações de recursos do pod não forem precisas: atualize a definição do pod para que ele possa ser executado nos nós atuais.

Clusters não íntegros impedem o escalonamento vertical

Sintomas:

O escalonador automático de cluster interrompe todas as operações de escalonamento, e o ConfigMap cluster-autoscaler-status contém um evento com o tipo Warning e ClusterUnhealthy listado como o motivo.

Para conferir o ConfigMap cluster-autoscaler-status, execute o seguinte comando:

kubectl describe configmap cluster-autoscaler-status -n kube-system

Causa:

O escalonador automático de cluster não faz o escalonar verticalmente se considerar que um cluster está inoperante. O escalonador automático de cluster determina a integridade do cluster com base na proporção de nós íntegros e prontos, não na integridade do plano de controle. Se 45% dos nós em um cluster estiverem em estado ruim ou não estiverem prontos, o escalonador automático de cluster vai interromper todas as operações.

O escalonador automático de clusters também considera um nó pronto como NotReady quando ele tem um taint com o prefixo ignore-taint.cluster-autoscaler.kubernetes.io/. O escalonador automático de clusters trata o nó como NotReady enquanto esse taint estiver presente.

Resolução:

Para resolver esse problema, diminua o número de nós não íntegros fazendo uma ou ambas as ações a seguir:

  • Investigue e corrija nós não íntegros ou NotReady para que menos de 45% dos nós do cluster estejam em estado não íntegro.
  • Se os nós prontos tiverem uma restrição com o prefixo ignore-taint.cluster-autoscaler.kubernetes.io/, remova a restrição.

A seguir