Resolva problemas do redimensionador automático de clusters que não está a reduzir recursos

Se os nós do Google Kubernetes Engine (GKE) não estiverem a ser reduzidos como esperado, é frequentemente porque o escalador automático do cluster não os está a remover, o que gera custos desnecessários e uma utilização ineficiente dos recursos.

Use esta página para diagnosticar e resolver problemas comuns que bloqueiam as ações de redução da escala do escalador automático do cluster. A resolução destes problemas ajuda a garantir que o cluster funciona de forma rentável e se adapta às alterações da carga de trabalho.

Estas informações são importantes para os administradores e os operadores da plataforma responsáveis pela eficiência do cluster, pela otimização de custos e pela gestão de recursos. Os programadores de aplicações também podem precisar destas informações se as respetivas configurações de carga de trabalho (como PodDisruptionBudgets ou seletores de nós) estiverem a impedir involuntariamente a remoção de nós. Para mais informações sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Compreenda quando o dimensionamento automático do cluster reduz 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 do cluster tenta reduzir a escala dos seus nós. Pode acontecer que o redimensionador automático de clusters não tenha sido reduzido porque não era necessário.

O redimensionador automático de clusters determina se um nó está subutilizado e é elegível para redução calculando um fator de utilização. O fator de utilização é calculado dividindo a vCPU e a memória pedidas pelos pods no nó pela vCPU e memória alocáveis no nó.

A cada 10 segundos, o redimensionador automático de clusters verifica o fator de utilização dos seus nós para ver se está abaixo do limite necessário. Se estiver a usar um balanced perfil de ajuste automático da escala, o limite do fator de utilização é 0,5. Se estiver a usar o perfil optimize-utilization, o fator de utilização varia. Quando o fator de utilização é inferior ao limite necessário para a vCPU e a memória, o escalador automático de clusters considera o nó subutilizado.

Quando um nó é subutilizado, o escalador automático de clusters marca o nó para remoção e monitoriza o nó durante os 10 minutos seguintes para garantir que o fator de utilização permanece abaixo do limite necessário. Se o nó ainda estiver subutilizado após 10 minutos, o escalador automático do cluster deve remover o nó.

Exemplo: cálculo do fator de utilização

Tem um cluster com o redimensionador automático de clusters ativado e está a usar o balanced perfil de escala automática. Um nó neste cluster é aprovisionado com o tipo de máquina e2-standard-4, que oferece 4 vCPUs e 16 GB de memória. Um pod neste nó pede 0,5 vCPU e 10 GB de memória, pelo que o redimensionador automático de clusters calcula os seguintes fatores de utilização:

  • Fator de utilização da vCPU: 0,5 vCPU / 4 vCPUs = 0,125
  • Fator de utilização da memória: 10 GB / 16 GB = 0,625

Neste cenário, o dimensionamento automático do cluster não considera que este nó está subutilizado porque o fator de utilização da memória (0,625) excede o limite de 0,5. Embora a utilização da vCPU seja baixa, a utilização de memória mais elevada impede a redução da escala para garantir que permanecem recursos suficientes disponíveis para a carga de trabalho do pod.

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

Se observar um cluster com uma utilização baixa durante mais de 10 minutos e este não estiver a ser reduzido, certifique-se de que o problema não é causado por uma das limitações do redimensionador automático de clusters.

Ver erros

Se o problema não tiver sido causado por uma limitação, pode diagnosticar a causa ao ver as 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 Google Cloud consola. Estas notificações fornecem estatísticas valiosas sobre o motivo pelo qual o redimensionador automático de clusters não foi reduzido e oferecem sugestões sobre como resolver o erro e ver os registos relevantes para uma investigação mais detalhada.

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

  1. Na Google 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 redução de escala:

    • Can't scale down nodes
    • Scale down blocked by pod

  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 leva-o ao Explorador de registos com uma consulta pré-preenchida para ajudar a investigar mais detalhadamente o evento de escalabilidade. Para saber como funcionam os eventos de redução de escala, consulte o artigo Veja os eventos do escalador 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 receber 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 Google Cloud consola, conclua os seguintes passos:

  1. Na Google 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 reduçã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 reduzido.

Cenário:

Há uma semana, estava a consultar o painel de controlo do GKE e reparou que o seu cluster só usou 10% da CPU e da memória. Apesar da baixa utilização, o redimensionador automático de clusters não eliminou o nó, como esperado. Quando olha para o painel de controlo, o problema parece ter sido resolvido, mas decide descobrir o que aconteceu para evitar que volte a acontecer.

Investigaçã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. Pesquise scaleDown eventos que contenham os nós pertencentes ao cluster que está a investigar no campo nodesToBeRemoved. Pode filtrar as entradas do registo, incluindo a filtragem por um valor de campo JSON específico. Saiba mais em Consultas avançadas de registos.
  4. Não encontra eventos de scaleDown. No entanto, se encontrou um evento scaleDown, pode pesquisar um evento eventResult que contenha o eventId associado. Em seguida, pode pesquisar um erro no campo errorMsg.

  5. Decide continuar a investigação pesquisando eventos que tenham o nó que está a investigar no campo de nós.noScaleDown

    Encontra um evento noScaleDown que contém um motivo pelo qual o seu nó não está a ser reduzido. O ID da mensagem é "no.scale.down.node.pod.not.backed.by.controller" e existe um único parâmetro: "test-single-pod".

Resolução:

Consulta a tabela de mensagens de erro e descobre que esta mensagem significa que o pod está a bloquear a redução porque não é suportado por um controlador. Descobre que uma solução é adicionar uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ao Pod. Investiga test-single-pod e vê que um colega adicionou a anotação e, após a aplicação da anotação, o escalador automático do cluster reduziu corretamente o cluster. Decide adicionar a anotação a todos os outros Pods onde é seguro fazê-lo para evitar que o problema volte a acontecer.

Resolva erros de redução de escala

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

Erros ScaleDown

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

Mensagem de evento Detalhes Parâmetro Mitigação
"scale.down.error.failed.to.mark.to.be.deleted" Não foi possível marcar um nó para eliminação. Nome do nó com falhas. Esta mensagem deve ser transitória. Se persistir, contacte o apoio ao cliente da nuvem para uma investigação mais detalhada.
"scale.down.error.failed.to.evict.pods" O escalador automático do cluster não consegue reduzir a escala porque não foi possível expulsar alguns dos pods de um nó. Nome do nó com falhas. Reveja o PodDisruptionBudget para o pod e certifique-se de que as regras permitem a remoção de réplicas da aplicação quando for aceitável. Para saber mais, consulte Especificar um orçamento de interrupção para a sua aplicação na documentação do Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" O escalador automático do cluster não pode reduzir a escala porque não foi possível eliminar um nó devido ao cluster já ter o tamanho mínimo. Nome do nó com falhas. Reveja o valor mínimo definido para a escala automática do node pool e ajuste as definições conforme necessário. Para saber mais, consulte o artigo Erro: os nós no cluster atingiram o tamanho mínimo.

Motivos de um evento noScaleDown

Um evento noScaleDown é emitido periodicamente quando existem nós cuja eliminação está bloqueada pelo escalador automático do cluster. Os eventos noScaleDown são de melhor esforço e não abrangem todos os casos possíveis.

NoScaleDown top-level reasons

As mensagens de motivo de nível superior para eventos noScaleDown aparecem no campo noDecisionStatus.noScaleDown.reason. A mensagem contém um motivo de nível superior pelo qual o escalador automático de clusters não consegue reduzir a escala do cluster.

Mensagem de evento Detalhes Mitigação
"no.scale.down.in.backoff" O escalamento automático do cluster não pode ser reduzido porque a redução está num período de recuo (bloqueado temporariamente).

Esta mensagem deve ser transitória e pode ocorrer quando tiver havido um evento de aumento recente.

Se a mensagem persistir, contacte o apoio ao cliente do Google Cloud para uma investigação mais aprofundada.
"no.scale.down.in.progress"

O redimensionador automático de clusters não consegue reduzir a escala porque uma redução de escala anterior ainda estava em curso.

 Esta mensagem deve ser transitória, uma vez que o pod vai acabar por ser removido. Se esta mensagem ocorrer com frequência, reveja o período de tolerância de encerramento para a redução da escala de pods. Para acelerar a resolução, também pode eliminar o agrupamento se já não for necessário.

Motivos ao nível do nó para noScaleDown

As mensagens de motivo ao nível do nó para eventos noScaleDown aparecem em noDecisionStatus.noScaleDown.nodes[].reason field. A mensagem contém um motivo pelo qual o escalador automático do cluster não consegue remover um nó específico.

Mensagem de evento Detalhes Parâmetros Mitigação
"no.scale.down.node.scale.down.disabled.annotation" O escalador automático de clusters não pode remover um nó do conjunto de nós porque o nó está anotado com cluster-autoscaler.kubernetes.io/scale-down-disabled: true. N/A O escalador automático de clusters ignora os nós com esta anotação sem considerar a respetiva utilização, e esta mensagem é registada independentemente do fator de utilização do nó. Se quiser que o escalador automático de clusters reduza a escala destes nós, remova a anotação.
"no.scale.down.node.node.group.min.size.reached"

O redimensionador automático de clusters não consegue reduzir a escala quando o tamanho do grupo de nós excedeu o limite de tamanho mínimo.

Isto acontece porque a remoção de nós violaria os limites mínimos de recursos ao nível do cluster definidos nas definições de aprovisionamento automático de nós.

 N/A Reveja o valor mínimo definido para o ajuste de escala automático do conjunto de nós. Se quiser que o dimensionamento automático do cluster reduza a escala deste nó, ajuste o valor mínimo.
"no.scale.down.node.minimal.resource.limits.exceeded"

O redimensionador automático de clusters não consegue reduzir a escala dos nós porque violaria os limites mínimos de recursos ao nível do cluster.

Estes são os limites de recursos definidos para a administração de contas automática de nós.

 N/A Reveja os limites de memória e vCPU e, se quiser que o redimensionador automático de clusters reduza a escala deste nó, diminua os limites.
"no.scale.down.node.no.place.to.move.pods" O redimensionador automático de clusters não consegue reduzir a escala porque não existe nenhum local para mover os pods. N/A Se espera que o pod seja reagendado, reveja os requisitos de agendamento dos pods no nó subutilizado para determinar se podem ser movidos para outro nó no cluster. Para saber mais, consulte o Erro: Não existe nenhum local para mover os pods.
"no.scale.down.node.pod.not.backed.by.controller"

O pod está a bloquear a redução porque não tem um controlador.

Especificamente, o redimensionador automático de cluster não consegue reduzir a escala de um nó subutilizado devido a um pod que não tem um controlador reconhecido. Os controladores permitidos incluem ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet.

 Nome do pod de bloqueio. Defina a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o Pod ou defina um controlador aceitável.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Um pod no nó tem a anotação safe-to-evict=false. Nome do pod de bloqueio. Se o Pod puder ser removido com segurança, edite o manifesto do Pod e atualize a anotação para "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" O pod está a bloquear a redução porque é um pod não DaemonSet, não espelhado e sem um PodDisruptionBudget no espaço de nomes kube-system. Nome do pod de bloqueio.

Nas versões do GKE anteriores a 1.32.4-gke.1236000, o escalador automático de clusters não remove os pods no espaço de nomes kube-system. A partir da versão 1.32.4-gke.1236000, o escalador automático do cluster considera estes pods para remoção após terem sido criados durante uma hora.

Para resolver este problema, adicione um PodDisruptionBudget para os pods kube-system ou use uma combinação de taints e tolerâncias de node pools para separar os pods kube-system dos pods da aplicação. Para saber mais, consulte o artigo Erro: o pod kube-system não pode ser movido.
"no.scale.down.node.pod.not.enough.pdb" O pod está a bloquear a redução porque não tem um PodDisruptionBudget suficiente. Nome do pod de bloqueio. Reveja o PodDisruptionBudget do pod e considere torná-lo menos restritivo. Para saber mais, consulte o artigo Erro: Not enough PodDisruptionBudget.
"no.scale.down.node.pod.controller.not.found" O pod está a bloquear a redução porque não é possível encontrar o respetivo controlador (por exemplo, uma implementação ou um ReplicaSet). N/A Para determinar que ações foram tomadas que deixaram o pod em execução depois de o respetivo controlador ter sido removido, reveja os registos. Para resolver este problema, elimine manualmente o pod.
"no.scale.down.node.pod.unexpected.error" O pod está a bloquear a redução devido a um erro inesperado. N/A A causa principal deste erro é desconhecida. Contacte o apoio ao cliente do Google Cloud para uma investigação mais aprofundada.

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, pode ver registos específicos do erro:

  1. Na Google 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.down.error.failed.to.delete.node.min.size.reached.

  3. Clique em Executar consulta.

Depure alguns erros com o gcpdiag

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

Se recebeu uma das seguintes mensagens de erro, pode usar a gcpdiag para ajudar a resolver o problema:

  • scale.down.error.failed.to.evict.pods
  • no.scale.down.node.node.group.min.size.reached

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 complexos de redução de escala

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 escalador automático de clusters associada.

Erro: os nós no cluster atingiram o tamanho mínimo

Se vir os seguintes erros, o redimensionador automático de clusters não conseguiu eliminar um nó porque o número de nós no cluster já estava no tamanho mínimo:

Notificação

A redução da escala do nó subutilizado está bloqueada porque foram atingidos os limites mínimos de recursos do escalador automático do cluster.

Evento

"scale.down.error.failed.to.delete.node.min.size.reached"

Para resolver este problema, reveja e atualize os limites mínimos do dimensionamento automático:

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

    Aceda aos clusters do Kubernetes

  2. Clique no nome do cluster identificado na notificação ou no Cloud Logging.

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

  4. Reveja o valor na coluna Número de nós e compare-o com o número mínimo de nós indicado na coluna Ajuste automático de escala. Por exemplo, se vir 4 a 6 nós listados na coluna Dimensionamento automático e o número de nós no conjunto de nós for 4, o número de conjuntos de nós já é igual ao tamanho mínimo, pelo que o dimensionamento automático do cluster não pode reduzir ainda mais os nós.

  5. Se a configuração estiver correta e o valor do número de nós for igual ao mínimo definido para o dimensionamento automático, o dimensionador automático do cluster está a funcionar conforme previsto. Se o número mínimo de nós for demasiado elevado para as suas necessidades, reduza o tamanho mínimo para que os nós possam ser reduzidos.

Erro: não existe um local para mover os pods

Ocorrem os seguintes erros quando o redimensionador automático de clusters tenta reduzir um nó, mas não consegue, porque não é possível mover um pod nesse nó para outro nó:

Notificação

A redução do número de nós subutilizados está bloqueada porque tem um pod que não pode ser movido para outro nó no cluster.

Evento

"no.scale.down.node.no.place.to.move.pods"

Se não quiser reagendar este Pod, esta mensagem é esperada e não são necessárias alterações. Se quiser reagendar o pod, investigue as seguintes definições no elemento pod.spec block no manifesto do pod:

  • NodeAffinity: reveja os requisitos de agendamento dos pods no nó com utilização inferior à esperada. Pode rever estes requisitos examinando o manifesto do pod e procurando regras NodeAffinity ou NodeSelector. Se o pod tiver um nodeSelector definido e não existirem outros nós (de outros nodePools) no cluster que correspondam a este seletor, o cluster autoscaler não consegue mover o pod para outro nó, o que, por sua vez, impede a remoção de nós subutilizados.
  • maxPodConstraint: se maxPodConstraint estiver configurado para qualquer outro número que não seja o número predefinido de 110, confirme se esta foi uma alteração pretendida. Diminuir este valor aumenta a probabilidade de problemas. O redimensionador automático de clusters não pode reagendar pods para outros nós, se todos os outros nós no cluster já tiverem atingido o valor definido em maxPodConstraint, não deixando espaço para agendar novos pods. Aumentar o valor de maxPodConstraint permite agendar mais pods em nós e o escalador automático do cluster tem espaço para reagendar pods e reduzir a escala de nós subutilizados. Quando definir maxPodConstraint, tenha em atenção que existem aproximadamente 10 pods do sistema em cada nó.
  • hostPort: especificar um hostPort para o agrupamento significa que apenas um agrupamento pode ser executado nesse nó. Isto pode dificultar a redução do número de nós por parte do dimensionamento automático do cluster, uma vez que o pod pode não conseguir mover-se para outro nó se a porta desse nó já estiver em utilização. Este comportamento é o esperado.
  • Armazenamento temporário: os pods dependem do armazenamento temporário para dados temporários. O armazenamento efémero insuficiente nos nós pode impedir o agendamento de pods e impedir a redução de escala de nós subutilizados. Exemplo: não é possível agendar um pod que requer 6 GB de armazenamento efémero em nós com menos de 6 GB de armazenamento efémero livre, mesmo que tenham recursos de CPU e memória suficientes. Para mitigar as limitações de armazenamento efémero, aumente a capacidade de armazenamento efémero aprovisionada para os seus nós. Isto garante capacidade suficiente para a mudança de localização e as operações de escalabilidade dos pods.

Erro: o pod kube-system não pode ser movido

Ocorrem os seguintes erros quando um pod do sistema está a impedir a redução:

Notificação

O pod está a bloquear a redução porque é um pod não DaemonSet, não espelhado, sem um PodDisruptionBudget no espaço de nomes kube-system.

Evento

"no.scale.down.node.pod.kube.system.unmovable"

Os pods no espaço de nomes kube-system são considerados pods do sistema. Na versão 1.32.4-gke.1236000 e posteriores do GKE, o escalamento automático do cluster pode reduzir o número de nós expulsando pods do sistema que estão em execução há, pelo menos, uma hora. Nas versões anteriores do GKE, o redimensionador automático de clusters não remove os pods no espaço de nomes kube-system, o que pode impedir a redução de recursos indefinidamente.

Para resolver este erro, escolha uma das seguintes resoluções:

  • Adicione um PodDisruptionBudget para os kube-system Pods. Para mais informações sobre como adicionar manualmente um PodDisruptionBudget para os pods kube-system, consulte as Perguntas frequentes do redimensionador automático de clusters de Kubernetes.

    A criação de um PodDisruptionBudget pode afetar a disponibilidade das cargas de trabalho do sistema, o que pode causar tempo de inatividade no cluster. O redimensionador automático de clusters reagenda estas cargas de trabalho do sistema em diferentes nós de trabalho durante o processo de redução da escala.

  • Use uma combinação de taints e tolerations de node pools para separar os pods do sistema dos pods da aplicação.kube-system Para mais informações, consulte o aprovisionamento automático de nós no GKE.

Verifique se os nós têm kube-system pods

Se não tiver a certeza de que os seus nós estão a executar kube-systempods e quiser validar, conclua os seguintes passos:

  1. Aceda à página Explorador de registos na Google Cloud consola.

    Aceda ao Explorador de registos

  2. Clique em Criador de consultas.

  3. Use a seguinte consulta para encontrar todos os registos de registo da política de rede:

    - resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"

    Substitua o seguinte:

    • CLUSTER_LOCATION: a região em que o cluster se encontra.
    • CLUSTER_NAME: o nome do seu cluster.
    • PROJECT_ID: o ID do projeto ao qual o seu cluster pertence.
    • NODE_POOL_NAME: o nome do node pool.

    Se existirem kube-systempods a serem executados no seu conjunto de nós, o resultado inclui o seguinte:

    "no.scale.down.node.pod.kube.system.unmovable"

Erro: não existem PodDisruptionBudget suficientes

Ocorrem os seguintes erros quando o seu PodDisruptionBudget está a impedir a redução:

Notificação

A redução do nó subutilizado está bloqueada porque tem um pod em execução que não tem um orçamento de interrupção de pods suficiente para permitir a remoção do pod.

Evento

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Para ver se uma PodDisruptionBudget é demasiado restritiva, reveja as respetivas definições:

kubectl get pdb --all-namespaces

O resultado é semelhante ao seguinte:

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

Neste exemplo, todos os pods que correspondam ao seletor de etiquetas two_pdb não são desalojados pelo escalador automático do cluster. A definição maxUnavailable: 0 neste PodDisruptionBudget determina que todas as réplicas têm de permanecer disponíveis em todos os momentos. Além disso, a disruptionsAllowed: 0 proíbe quaisquer interrupções nestes Pods. Consequentemente, não é possível reduzir a escala dos nós que executam estes pods, uma vez que isso causaria uma interrupção e violaria a PodDisruptionBudget.

Se o PodDisruptionBudget estiver a funcionar da forma pretendida, não é necessária nenhuma ação adicional. Se quiser ajustar o PodDisruptionBudget para que os pods num nó subutilizado possam ser movidos, edite o manifesto do PodDisruptionBudget. Por exemplo, se tiver definido maxUnavailable como 0, pode alterá-lo para 1 para que o redimensionador automático de clusters possa reduzir a escala.

Problema: o nó permanece no estado isolado e não é removido

Ocorrem erros semelhantes aos seguintes quando o escalador automático de clusters não consegue reduzir o tamanho do conjunto de nós porque a conta de serviço Google não tem a função de editor:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Um sintoma comum deste problema é quando o escalador automático de clusters tenta reduzir o tamanho do node pool, mas o nó não altera o estado.

Para resolver este problema, verifique se a conta de serviço predefinida (PROJECT_NUMBER@cloudservices.gserviceaccount.com) tem a função de editor (roles/editor) no projeto. Se a conta de serviço não tiver esta função, adicione-a. O GKE usa esta conta de serviço para gerir os recursos do seu projeto. Para saber como o fazer, consulte o artigo Conceda ou revogue uma única função na documentação da IAM.

O que se segue?