Resolva problemas com o redimensionador automático de clusters que não está a aumentar recursos

Quando os seus pods no Google Kubernetes Engine (GKE) estão bloqueados num estado Pending e não são adicionados novos nós, isto indica frequentemente um problema com a funcionalidade de expansão automática do escalador automático do cluster. Este problema pode impedir que as suas aplicações sejam dimensionadas para satisfazer a procura, atrasar as implementações e afetar a disponibilidade do serviço.

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

Estas informações são importantes para os programadores de aplicações, que precisam que as respetivas aplicações e serviços sejam agendados e executados de forma fiável, e para os administradores e os operadores da plataforma, que são responsáveis por garantir que o cluster pode aprovisionar dinamicamente recursos para cumprir os requisitos da carga de trabalho e manter os níveis de serviço. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Trusted Cloud by S3NS conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Saiba quando o escalamento automático do cluster aumenta os seus nós

Antes de avançar para os passos de resolução de problemas, pode ser útil compreender quando o redimensionador automático de clusters tenta aumentar a escala dos seus nós. O redimensionador automático de clusters só adiciona nós quando os recursos existentes são insuficientes.

A cada 10 segundos, o redimensionador automático de clusters verifica se existem Pods que não podem ser agendados. Um pod torna-se não agendável quando o agendador do Kubernetes não o consegue colocar em nenhum nó existente devido a recursos insuficientes, restrições de nós ou requisitos de pods não cumpridos.

Quando o redimensionador automático de clusters encontra pods não agendáveis, avalia se a adição de um nó permitiria agendar o pod. Se a adição de um nó permitir que um pod seja agendado, o escalador automático do cluster adiciona um novo nó ao grupo de instâncias gerido (MIG). Em seguida, o programador do Kubernetes pode agendar o pod no nó aprovisionado recentemente.

Verifique se tem pods não agendáveis

Para determinar se o cluster tem de ser aumentado, verifique se existem pods não agendados:

  1. Na Trusted Cloud consola, aceda à página Workloads.

    Aceda a Cargas de trabalho

  2. No campo Filtrar, introduza unschedulable e prima Enter.

    Se existirem Pods listados, significa que tem Pods não agendáveis. Para resolver problemas com pods não agendáveis, consulte o artigo Erro: pod não agendável. A resolução da causa subjacente dos pods não agendáveis pode, muitas vezes, permitir que o escalador automático do cluster aumente a escala. Para identificar e resolver erros específicos do escalador automático de clusters, explore as secções seguintes.

    Se não forem apresentados Pods, o redimensionador automático de clusters não precisa de aumentar a escala e está a funcionar conforme esperado.

Verifique se tinha anteriormente pods não agendáveis

Se estiver a investigar o que causou a falha do redimensionador automático de clusters no passado, verifique se existem pods não agendáveis anteriormente:

  1. Na Trusted Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. Especifique um intervalo de tempo para as entradas do registo que quer ver.

  3. No painel de consultas, introduza a seguinte consulta:

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

    Substitua PROJECT_ID pelo ID do seu projeto.

  4. Clique em Executar consulta.

    Se forem apresentados resultados, significa que tinha pods não agendáveis no intervalo de tempo especificado.

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

Depois de confirmar que tem pods não agendados, certifique-se de que o problema com o escalador automático de clusters não é causado por uma das limitações do escalador automático de clusters.

Ver erros

Muitas vezes, pode diagnosticar a causa dos problemas de expansão através da visualização de mensagens de erro:

Veja erros nas notificações

Se o problema que observou ocorreu há menos de 72 horas, veja as notificações sobre erros na Trusted Cloud consola. Estas notificações fornecem estatísticas valiosas sobre o motivo pelo qual o redimensionador automático de clusters não aumentou os recursos e oferecem sugestões sobre como resolver o erro e ver registos relevantes para uma investigação mais detalhada.

Para ver as notificações na Trusted Cloud consola, conclua os seguintes passos:

  1. Na Trusted Cloud consola, aceda à página Clusters do Kubernetes.

    Aceda aos clusters do Kubernetes

  2. Reveja a coluna Notificações. As seguintes notificações estão associadas a problemas de expansão:

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

  3. Clique na notificação relevante para ver um painel com detalhes sobre a causa do problema e ações recomendadas para o resolver.

  4. Opcional: para ver os registos deste evento, clique em Registos. Esta ação direciona para o Explorador de registos com uma consulta pré-preenchida para ajudar a investigar mais o evento de escalamento. Para saber como funcionam os eventos de expansão, consulte o artigo Veja os eventos do redimensionador automático de clusters.

Se continuar a ter problemas depois de rever as sugestões na notificação, consulte as tabelas de mensagens de erro para obter mais ajuda.

Veja erros em eventos

Se o problema que observou ocorreu há mais de 72 horas, veja os eventos no Cloud Logging. Quando ocorre um erro, este é frequentemente registado num evento.

Para ver os registos do escalador automático de clusters na Trusted Cloud consola, conclua os seguintes passos:

  1. Na Trusted Cloud consola, aceda à página Clusters do Kubernetes.

    Aceda aos clusters do Kubernetes

  2. Selecione o nome do cluster que quer investigar para ver a respetiva página de detalhes do cluster.

  3. Na página Detalhes do cluster, clique no separador Registos.

  4. No separador Registos, clique no separador Registos do dimensionamento automático para ver os registos.

  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 ver os registos no Logs Explorer.

Para saber mais sobre como funcionam os eventos de expansão, consulte o artigo Veja os eventos do escalador automático de clusters. Para ver um exemplo de como usar o Cloud Logging, consulte o seguinte exemplo de resolução de problemas.

Exemplo: resolva um problema com mais de 72 horas

O exemplo seguinte mostra como pode investigar e resolver um problema com um cluster que não está a ser dimensionado.

Cenário: durante a última hora, um Pod foi marcado como não agendável. O escalador automático do cluster não aprovisionou novos nós para agendar o pod.

Solução:

  1. Como o problema ocorreu há mais de 72 horas, investiga o problema através do Cloud Logging em vez de analisar as mensagens de notificação.
  2. No Cloud Logging, encontra os detalhes de registo dos eventos do redimensionador automático de clusters, conforme descrito em Ver erros em eventos.

  3. Pesquisa scaleUpeventos que contêm o Pod que está a investigar no campo triggeringPods. Pode filtrar as entradas do registo, incluindo a filtragem por um valor de campo JSON específico. Saiba mais em Consultas de registos avançados.

  4. Não encontra eventos de aumento da escala. No entanto, se o fizesse, podia tentar encontrar um EventResult que contenha o mesmo eventId que o evento scaleUp. Em seguida, pode consultar o campo errorMsg e consultar a lista de possíveis mensagens de erro de aumento de escala.

  5. Como não encontrou eventos scaleUp, continua a pesquisar eventos noScaleUp e revê os seguintes campos:

    • unhandledPodGroups: contém informações sobre o Pod (ou o controlador do Pod).
    • reason: fornece motivos globais que indicam que a expansão pode ser bloqueada.
    • skippedMigs: indica os motivos pelos quais algumas MIGs podem ser ignoradas.

  6. Encontra um evento noScaleUp para o seu Pod e todos os MIGs no campo rejectedMigs têm o mesmo ID da mensagem de motivo de "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, descobre que o redimensionador automático de clusters não consegue aumentar os recursos de um conjunto de nós devido a um predicado de agendamento com falhas para os pods pendentes. Os parâmetros são o nome do predicado com falhas e o motivo da falha.

Para resolver o problema, reveja o manifesto do pod e descubra que tem um seletor de nós que não corresponde a nenhum MIG no cluster. Elimina o seletor do manifesto do pod e recria o pod. O redimensionador automático de cluster adiciona um novo nó e o pod é agendado.

Resolva erros de expansão

Depois de identificar o erro, use as tabelas seguintes para ajudar a compreender a causa do erro e como o resolver.

Erros do ScaleUp

Pode encontrar mensagens de erro de eventos para eventos scaleUp no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Quando uma operação de expansão falha porque excede uma quota, trata-se de um erro de criação de nós que aciona um período de recuo do sistema, que pode durar até 30 minutos. Para mais informações, consulte a secção Períodos de retirada.

Mensagem Detalhes Parâmetros Mitigação
"scale.up.error.out.of.resources" Os erros de recursos ocorrem quando tenta pedir novos recursos numa zona que não pode satisfazer o seu pedido devido à indisponibilidade atual de um recurso do Compute Engine, como GPUs ou CPUs. IDs MIG com falhas. Siga os passos de resoluçã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 à quota do Compute Engine excedida. IDs MIG com falhas. Consulte o separador Erros do MIG na Trusted Cloud consola para ver que quota está a ser excedida. Depois de saber qual é a quota que está a ser excedida, siga as instruções para pedir um aumento da quota.
"scale.up.error.waiting.for.instances.timeout" A expansão do grupo de instâncias gerido não foi possível devido ao limite de tempo. IDs MIG com falhas. Esta mensagem deve ser transitória.
"scale.up.error.ip.space.exhausted" Não é possível aumentar a escala porque as instâncias em alguns dos grupos de instâncias geridos ficaram sem IPs. Isto significa que o cluster não tem espaço de endereço IP não atribuído suficiente para usar para adicionar novos nós ou pods. IDs MIG com falhas. Siga os passos de resolução de problemas no artigo Não existe espaço de endereço IP livre suficiente para pods.
"scale.up.error.service.account.deleted" Não é possível aumentar a escala porque a conta de serviço foi eliminada. IDs MIG com falhas. Tente anular a eliminação da conta de serviço.

Motivos para um evento noScaleUp

Um evento noScaleUp é emitido periodicamente quando existem pods não agendáveis no cluster e o redimensionador automático de cluster não consegue aumentar a escala do cluster para agendar os pods. Os eventos noScaleUp são a melhor tentativa possível e não abrangem todos os casos possíveis.

Motivos de nível superior de noScaleUp

As 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 que explica por que motivo o redimensionador automático de clusters não consegue aumentar os recursos do cluster.

Mensagem Detalhes Mitigação
"no.scale.up.in.backoff" Não é possível aumentar a escala porque o aumento da escala está num período de recuo (bloqueado temporariamente). Esta mensagem pode ocorrer durante eventos de expansão com um grande número de pods. Esta mensagem deve ser transitória. Verifique este erro após alguns minutos.

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

As mensagens de motivo do aprovisionamento automático do nó de nível superior para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.napFailureReason. A mensagem contém um motivo de nível superior pelo qual o redimensionador automático de clusters não consegue aprovisionar novos conjuntos de nós.

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

Não foi possível aumentar a escala do aprovisionamento automático de nós porque o aprovisionamento automático de nós não está ativado ao nível do cluster.

Se o aprovisionamento automático de nós estiver desativado, os novos nós não são aprovisionados automaticamente se o pod pendente tiver requisitos que não possam ser satisfeitos por nenhum conjunto de nós existente.

 Reveja a configuração do cluster e considere ativar o aprovisionamento automático de nós.

Motivos ao nível do MIG para noScaleUp

As mensagens de motivos ao nível do MIG para eventos noScaleUp aparecem nos campos noDecisionStatus.noScaleUp.skippedMigs[].reason e noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. A mensagem contém um motivo pelo qual o redimensionador automático de clusters não consegue aumentar o tamanho de um MIG específico.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.mig.skipped" Não é possível aumentar a escala de um MIG porque foi ignorado durante a simulação. Motivos pelos quais o MIG foi ignorado (por exemplo, não cumprir um requisito do agrupamento). Reveja os parâmetros incluídos na mensagem de erro e resolva o motivo pelo qual o MIG foi ignorado.
"no.scale.up.mig.failing.predicate" Não é possível aumentar a escala de um conjunto de nós devido a um predicado de agendamento com falhas para os pods pendentes. Nome do predicado com falha e motivos da falha. Reveja os requisitos do pod, como: regras de afinidade, manchas ou tolerâncias e requisitos de recursos.

Motivos de aprovisionamento automático de nós ao nível do grupo de pods noScaleUp

As mensagens de motivo de aprovisionamento automático de nós ao nível do grupo de pods para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. A mensagem contém um motivo pelo qual o escalador automático do cluster não consegue aprovisionar um novo conjunto de nós para agendar um grupo de pods específico.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.nap.pod.gpu.no.limit.defined" A administração de contas automática de nós não conseguiu aprovisionar nenhum grupo de nós porque um pod pendente tem um pedido de GPU, mas os limites de recursos de GPU não estão definidos ao nível do cluster. Tipo de GPU pedido. Reveja o pedido de GPU do pod pendente e atualize a configuração do aprovisionamento automático de nós para limites de GPU ao nível do cluster.
"no.scale.up.nap.pod.gpu.type.not.supported" A Administração de contas automática de nós não aprovisionou nenhum grupo de nós para o pod porque tem pedidos para um tipo de GPU desconhecido. Tipo de GPU pedido. Verifique a configuração do pod pendente para o tipo de GPU para garantir que corresponde a um tipo de GPU suportado.
"no.scale.up.nap.pod.zonal.resources.exceeded" O aprovisionamento automático de nós não aprovisionou nenhum grupo de nós para o pod nesta zona porque, se o fizesse, violaria os limites máximos de recursos ao nível do cluster, excederia os recursos disponíveis na zona ou não existe nenhum tipo de máquina que se adequasse ao pedido. Nome da zona considerada. Reveja e atualize os limites máximos de recursos ao nível do cluster, os pedidos de recursos de pods ou as zonas disponíveis para o aprovisionamento automático de nós.
"no.scale.up.nap.pod.zonal.failing.predicates" A Administração de contas automática de nós não aprovisionou nenhum grupo de nós para o pod nesta zona devido a predicados com falhas. Nome da zona considerada e motivos pelos quais os predicados falharam. Reveja os requisitos do pod pendentes, como regras de afinidade, manchas, tolerâncias ou requisitos de recursos.

Realizar uma investigação mais aprofundada

As secções seguintes fornecem orientações sobre como usar o Explorador de registos e o gcpdiag para obter estatísticas adicionais sobre os seus erros.

Investigue erros no Explorador de registos

Se quiser investigar mais a fundo a sua mensagem de erro, veja os registos específicos do erro:

  1. Na Trusted Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. No painel de consultas, introduza 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 quer investigar. Por exemplo, scale.up.error.out.of.resources.

  3. Clique em Executar consulta.

Depure alguns erros com o gcpdiag

gcpdiag é uma ferramenta de código aberto criada com o apoio de Trusted Cloud by S3NS engenheiros técnicos. Não é um produto Trusted Cloud by S3NS suportado oficialmente.

Se recebeu uma das seguintes mensagens de erro, pode usar a gcpdiag para ajudar a 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

Para ver uma lista e uma descrição de todas as flags da ferramenta gcpdiag, consulte as gcpdiag instruções de utilização.

Resolva erros de expansão complexos

As secções seguintes oferecem orientações sobre a resolução de erros em que as mitigações envolvem vários passos e erros que não têm uma mensagem de evento do redimensionador automático de clusters associada.

Problema: o pod não se encaixa no nó

O redimensionador automático de cluster só agenda um pod num nó se existir um nó com recursos suficientes, como GPUs, memória e armazenamento, para satisfazer os requisitos do pod. Para determinar se é por este motivo que o redimensionador automático de clusters não aumentou a escala, compare os pedidos de recursos com os recursos fornecidos.

O exemplo seguinte mostra como verificar os recursos da CPU, mas os mesmos passos aplicam-se aos recursos de GPUs, memória e armazenamento. Para comparar os pedidos de CPU com as CPUs aprovisionadas, conclua os seguintes passos:

  1. Na Trusted Cloud consola, aceda à página Workloads.

    Aceda a Cargas de trabalho

  2. Clique na mensagem de erro PodUnschedulable.

  3. No painel Detalhes, clique no nome do Pod. Se existirem vários Pods, comece pelo primeiro e repita o seguinte processo para cada Pod.

  4. Na página de detalhes do pod, aceda ao separador Eventos.

  5. No separador Eventos, aceda ao separador YAML.

  6. Tome nota dos pedidos de recursos de cada contentor no agrupamento para saber qual é o total de pedidos de recursos. Por exemplo, na seguinte configuração do agrupamento, o agrupamento precisa de 2 vCPUs:

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

  7. Veja os detalhes do conjunto de nós do cluster com o pod não agendado:

    1. Na Trusted Cloud consola, aceda à página Clusters do Kubernetes.

      Aceda aos clusters do Kubernetes

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

    3. Na página Detalhes do cluster, aceda ao separador Nós.

  8. Na secção Conjuntos de nós, tome nota do valor na coluna Tipo de máquina. Por exemplo, n1-standard-1.

  9. Compare o pedido de recursos com as vCPUs fornecidas pelo tipo de máquina. Por exemplo, se um pod pedir 2 vCPUs, mas os nós disponíveis tiverem o tipo de máquina n1-standard-1, os nós só teriam 1 vCPU. Com uma configuração como esta, o redimensionador automático de clusters não acionaria o aumento da escala porque, mesmo que adicionasse um novo nó, este pod não caberia nele. Se quiser saber mais sobre os tipos de máquinas disponíveis, consulte o recurso de famílias de máquinas e o guia de comparação na documentação do Compute Engine.

Tenha também em atenção que os recursos atribuíveis de um nó são inferiores aos recursos totais, uma vez que é necessária uma parte para executar os componentes do sistema. Para saber mais sobre como este valor é calculado, consulte Recursos atribuíveis do nó.

Para resolver este problema, decida se os pedidos de recursos definidos para a carga de trabalho são adequados às suas necessidades. Se o tipo de máquina não deve ser alterado, crie um conjunto de nós com um tipo de máquina que possa suportar o pedido proveniente do pod. Se os pedidos de recursos do Pod não forem precisos, atualize a definição do Pod para que os Pods se possam ajustar aos nós.

Problema: clusters em mau estado de funcionamento que impedem o aumento de recursos

O redimensionador automático de clusters pode não aumentar a escala se considerar que um cluster não está em bom estado. O estado de mau funcionamento do cluster não se baseia no bom funcionamento do plano de controlo, mas sim na proporção de nós em bom funcionamento e prontos. Se 45% dos nós num cluster estiverem em mau estado ou não estiverem prontos, o redimensionador automático de clusters interrompe todas as operações.

Se for este o motivo pelo qual o redimensionador automático de clusters não está a aumentar os recursos, existe um evento no ConfigMap do redimensionador automático de clusters com o tipo Warning e ClusterUnhealthy indicado como o motivo.

Para ver o ConfigMap, execute o seguinte comando:

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

Para resolver este problema, diminua o número de nós não íntegros.

Também é possível que alguns dos nós estejam prontos, embora não sejam considerados prontos pelo escalador automático do cluster. Isto acontece quando uma mancha com o prefixo ignore-taint.cluster-autoscaler.kubernetes.io/ está presente num nó. O redimensionador automático de clusters considera um nó como NotReady enquanto essa mancha estiver presente.

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

O que se segue?