Resolver problemas de escalonamento automático de clusters

Nesta página, mostramos como descobrir e resolver quando o escalonador automático do cluster não está escalonando verticalmente os nós em clusters do Google Kubernetes Engine (GKE).

Esta página é destinada a desenvolvedores de aplicativos que querem resolver uma situação inesperada ou negativa com o app ou serviço, além de administradores e operadores de plataforma que querem evitar interrupções na entrega de produtos e serviços.

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ó permite que o pod seja 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 do Google Cloud, acesse a página Cargas de trabalho.

    Acessar "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 ao 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 "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 pela ID do seu 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 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 mais ajuda.

Conferir 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 cluster no console do Google Cloud, siga estas etapas:

  1. No console do Google Cloud, acesse a página 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: um pod foi marcado como não programável na última hora. 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 contêm o pod que 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ê fez isso, tente encontrar um EventResult que contenha o mesmo eventId que o 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 a pesquisar 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, você analisa o manifesto do pod e descobre 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

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

Erros de ScaleUp

As mensagens de erro de eventos scaleUp podem ser encontradas no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

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 não foi possível devido ao tempo limite. IDs MIG com falha. 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 o procedimento não funcionar, entre em contato com o Cloud Customer Care para 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 há escalonamento vertical porque ele está em um período de espera (temporariamente bloqueado). Essa mensagem pode ocorrer durante eventos de escalonamento vertical com um grande número de pods. Essa mensagem deve ser temporária. Verifique esse erro após alguns minutos. Se a mensagem persistir, entre em contato com o Cloud Customer Care para 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 pelos quais o MIG foi ignorado (por exemplo, falta de um requisito do 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 pelos quais os predicados falharam. 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 ferramenta 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 do 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 incluem orientações para resolver erros em que as mitigações envolvem várias etapas e erros sem uma mensagem de evento de escalonador automático de clusters associada.

Problema: o pod não cabe no nó

O escalonador automático de clusters só programa um pod em um nó se há um nó com recursos suficientes, como GPUs, memória e armazenamento, para atender aos requisitos do pod. Para determinar se esse é o motivo pelo qual o escalonador automático de cluster não fez o escalonamento vertical, compare as solicitações de recursos com os recursos fornecidos.

O exemplo a seguir mostra como verificar os recursos de CPU, mas as mesmas etapas valem para GPUs, memória e armazenamento. Para comparar solicitações de CPU com CPUs provisionadas, siga estas etapas:

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

    Acessar "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 de detalhes do pod, acesse a guia Eventos.

  5. Na guia Eventos, acesse a guia YAML.

  6. Anote as solicitações de recursos de cada contêiner no pod para saber qual é 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"

  7. 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 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, acesse a guia Nós.

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

  9. 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 tiverem o tipo de máquina n1-standard-1, eles terão apenas uma vCPU. Com uma configuração como essa, o escalonador automático de cluster não acionaria o escalonamento vertical, porque, mesmo que adicione um novo nó, o pod não caberia nele. Se você quer saber mais sobre os tipos de máquinas disponíveis, consulte o guia de recursos e comparação de famílias de máquinas na documentação do Compute Engine.

Além disso, os recursos alocáveis de um nó são menores do que o total, já que uma parte é necessária para executar os componentes do sistema. Saiba como é feito esse cálculo em Recursos alocáveis de nó.

Para resolver esse problema, decida se as solicitações de recursos definidas para a carga de trabalho são adequadas para suas necessidades. Se não for possível mudar o tipo de máquina, crie um pool de nós com um tipo de máquina que ofereça suporte à solicitação vinda do pod. Se as solicitações de recursos do pod não forem precisas, atualize a definição do pod para que ele possa caber nos nós.

Problema: clusters não íntegros que impedem o escalonamento vertical

O escalonador automático de cluster poderá não realizar o escalonamento vertical se considerar que um cluster está inoperante. A falta de integridade do cluster não se baseia na integridade do plano de controle, mas na proporção de nós íntegros e prontos. Se 45% dos nós em um cluster estiverem com problemas ou não estiverem prontos, o escalonador automático de cluster vai interromper todas as operações.

Se esse for o motivo pelo qual o escalonador automático de cluster não está aumentando, haverá um evento no ConfigMap do escalonador automático de cluster com o tipo Warning e o motivo ClusterUnhealthy.

Para abrir o ConfigMap, execute o seguinte comando:

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

Para resolver esse problema, diminua o número de nós com problemas.

Também é possível que alguns nós estejam prontos, mas não sejam considerados prontos pelo escalonador automático de cluster. Isso acontece quando um taint com o prefixo ignore-taint.cluster-autoscaler.kubernetes.io/ está presente em um nó. O escalonador automático de cluster considera um nó como NotReady, desde que esse taint esteja presente.

Se o comportamento for causado pela presença de taint ignore-taint.cluster-autoscaler.kubernetes.io/.*, remova-o.

A seguir