Sobre o escalonamento automático de clusters

Autopilot Standard

Neste documento explicamos como o Google Kubernetes Engine (GKE) redimensiona automaticamente os pools de nós do cluster padrão com base nas demandas das cargas de trabalho. Quando a demanda é alta, o escalonador automático de clusters acrescenta nós ao pool de nós. Para saber como configurar o escalonador automático do cluster, consulte Como escalonar automaticamente um cluster.

Com os clusters do Autopilot, você não precisa se preocupar com o provisionamento de nós ou o gerenciamento de pools de nós porque eles são provisionados automaticamente usando o provisionamento automático de nós, e são escalonadas automaticamente para atender aos requisitos das cargas de trabalho.

Por que usar o escalonador automático de clusters

O escalonador automático de cluster do GKE faz o escalonamento automático do número de nós em um determinado pool de nós, com base nas demandas das cargas de trabalho. Quando ela é baixa, o escalonador automático do cluster volta para um tamanho mínimo designado por você. Isso pode aumentar a disponibilidade das cargas de trabalho quando você precisar delas e, ao mesmo tempo, controlar os custos. Você não precisa adicionar ou remover manualmente os nós ou provisionar em excesso seus pools de nós. Em vez disso, especifique um tamanho mínimo e máximo para o pool de nós, e o restante é automático.

Se os recursos forem excluídos ou movidos durante o escalonamento automático do cluster, as cargas de trabalho poderão sofrer interrupções temporárias. Por exemplo, se a carga de trabalho consistir em um controlador com uma única réplica, o pod dessa réplica poderá ser remarcado em um nó diferente caso o nó atual seja excluído. Antes de ativar o escalonador automático de cluster, projete as cargas de trabalho para tolerar possíveis interrupções ou garantir que os pods críticos não sejam interrompidos.

É possível aumentar o desempenho do escalonador automático de cluster com streaming de imagens, que transmite remotamente os dados de imagem necessários de imagens de contêiner qualificadas, ao mesmo tempo em que armazena a imagem em cache localmente para permitir cargas de trabalho em novos nós começar mais rápido.

Como funciona o autoescalador de clusters

O escalonador automático de cluster funciona por pool de nós. Ao configurar um pool de nós com ele, você especifica os tamanhos mínimo e máximo para o pool de nós.

O escalonador automático de cluster aumenta ou diminui o tamanho do pool de nós automaticamente adicionando ou removendo instâncias de máquina virtual (VM) no Grupo de instâncias gerenciadas (MIG) do Compute Engine para o pool de nós. , O autoescalador de cluster toma essas decisões de escalonamento com base nas solicitações de recursos (em vez da utilização real de recursos) dos pods em execução nos nós do pool de nós. Ele verifica periodicamente o status de pods e nós e toma as seguintes medidas:

Se os pods não forem programados em qualquer um dos nós atuais, o escalonador automático de clusters adicionará nós até o tamanho máximo deles pool. Para mais informações sobre quando o escalonador automático de clusters altera o tamanho de um cluster, consulte Quando o escalonador automático de cluster altera o tamanho de um cluster?
Se o GKE decidir adicionar novos nós ao pool de nós, o escalonador automático adiciona quantos nós forem necessários, por limites de pool de nós ou de cluster.
O escalonador automático de cluster não espera a criação de um nó para criar o o próximo. Depois que o GKE decide quantos nós criar, a criação do nó acontece em paralelo. O objetivo é minimizar o tempo necessário para que os pods não programáveis se tornem Active.
Se a criação de alguns nós falhar devido à exaustão de cota, o escalonador automático de cluster espera até que os recursos possam ser agendados com sucesso.
Se os nós forem subutilizados e todos os pods puderem ser programados mesmo com menos nós no pool de nós, o escalonador automático de cluster removerá nós até o tamanho mínimo do pool de nós. Se houver pods em um nó que não podem ser movidos para outros nós no cluster, o escalonador automático de cluster não tentará reduzir esse nó. Se os pods puderem ser movidos para outros nós, mas o nó não puder ser drenado normalmente após um período de tempo limite (atualmente de 10 minutos), o nó será encerrado à força. O período de carência não é configurável para clusters do GKE. Para mais informações sobre como a redução de escala funciona, consulte a documentação do escalonador automático de cluster.

A frequência com que o escalonador automático de cluster inspeciona um cluster em busca de pods não programáveis depende em grande parte do tamanho do cluster. Em pequenos clusters, a inspeção pode acontecer em intervalos de alguns segundos. Não é possível definir um período exato necessário para a inspeção.

Se os pods tiverem solicitado poucos recursos (ou não alteraram os recursos padrão, o que pode ser insuficiente) e os nós estiverem passando por uma escassez, o autoescalador de clusters não corrigirá a situação. Para garantir que o autoescalador de cluster trabalhe com a maior precisão possível, faça solicitações de recursos explícitas para todas as cargas de trabalho.

Critérios de operação

O autoescalador de clusters parte dos seguintes pressupostos ao redimensionar um pool de nós:

Todos os pods replicados podem ser reiniciados em outro nó, o que pode causar uma breve interrupção. Se os serviços não puderem ser interrompidos, o uso do escalonador automático de cluster não é recomendado.
Usuários ou administradores não estão gerenciando manualmente os nós. Qualquer operação de gerenciamento manual de nós realizada pode ser substituída.
Todos os nós em um único pool têm o mesmo conjunto de rótulos.
O escalonador automático de clusters considera o custo relativo dos tipos de instâncias nos vários pools e tenta expandir o mais barato possível. O custo reduzido de pools de nós contendo VMs Spot é considerado.
O escalonador automático de cluster considera as solicitações do contêiner init antes de programar pods. As solicitações do contêiner init podem usar quaisquer recursos não alocados disponíveis nos nós, o que pode impedir que os pods sejam programados. O escalonador automático de cluster segue as mesmas regras de cálculo de solicitação que o Kubernetes. Para saber mais, consulte Como usar contêineres init.
Os rótulos adicionados manualmente após a criação inicial do cluster ou do pool de nós não são rastreados. Os nós criados pelo escalonador automático de cluster recebem rótulos especificados com --node-labels no momento da criação do pool de nós.
No GKE versão 1.21 ou anterior, o escalonador automático de clusters considera as informações de taint dos nós atuais de um pool de nós para representar todo o pool de nós. A partir da versão 1.22 do GKE, o escalonador automático de clusters combina informações de nós atuais do cluster e do pool de nós. O escalonador automático de cluster detecta mudanças manuais de nós e do pool de nós para escalonar verticalmente.

Balanceamento entre zonas

Se o pool de nós tiver vários grupos com instâncias gerenciadas do mesmo tipo, o autoescalador de cluster tentará manter o tamanho desses grupos balanceado durante o aumento da escala. Isso ajuda a evitar uma distribuição desigual de nós entre os grupos de instâncias gerenciadas em várias zonas de um pool de nós. O GKE não considera a política de escalonamento automático ao reduzir.

Política de localização

A partir da versão 1.24.1-gke.800 do GKE, é possível alterar a política de localização do escalonador automático do cluster do GKE. É possível controlar a política de distribuição do escalonador automático do cluster especificando a sinalização location_policy com qualquer um dos seguintes valores:

BALANCED: o escalonador automático considera os requisitos de pod e a disponibilidade dos recursos em cada zona. Isso não garante que grupos de nós semelhantes tenham exatamente os mesmos tamanhos, já que o escalonador automático considera muitos fatores, incluindo a capacidade disponível em uma determinada zona e as afinidades de zona dos pods que acionaram o escalonamento vertical.
ANY: o escalonador automático prioriza a utilização de reservas e contas não utilizadas para as restrições atuais dos recursos disponíveis. Esta política é recomendada ao usar VMs spot ou reservas de VM que não são iguais entre as zonas.

Reservas

A partir do GKE 1.27, o escalonador automático de cluster sempre considera as reservas ao tomar as decisões de escalonamento vertical. Os pools de nós com reservas não usadas correspondentes são priorizados ao escolher o pool de nós para escalonar verticalmente, mesmo quando ele não é o mais eficiente. Além disso, as reservas não usadas são sempre priorizadas ao balancear os escalonamentos verticais de várias zonas.

Valores padrão

Para pools de nós de VMs do Spot, a política de distribuição padrão do escalonador automático de cluster é ANY. Nessa política, as VMs do Spot têm um risco menor de serem antecipadas.

Para pools de nós não preemptivos, a política de distribuição padrão do escalonador automático de clusters é BALANCED.

Tamanho mínimo e máximo do pool de nós

Ao criar um novo pool de nós, é possível especificar os tamanhos mínimo e máximo para cada pool de nós no cluster, e o escalonador automático de clusters toma decisões de redimensionamento de acordo com essas restrições. Para atualizar o tamanho mínimo, redimensione manualmente o cluster para um tamanho dentro das novas restrições após especificar o novo valor mínimo. O escalonador automático de clusters toma decisões de reescalonamento com base nas novas restrições.

Tamanho atual do pool de nós	Ação do escalonador automático de clusters	Restrições de escalonamento
Inferior ao mínimo especificado	O escalonador automático de clusters escalona verticalmente para provisionar pods pendentes. A redução da escala vertical está desativada.	O pool de nós não reduz a escala vertical abaixo do valor especificado.
Dentro dos tamanhos mínimo e máximo especificados	O escalonador automático de clusters escalona verticalmente ou reduz em escala vertical de acordo com a demanda.	O pool de nós permanece dentro dos limites de tamanho que você especificou.
Maior que o máximo especificado	O escalonador automático de clusters reduz a escala vertical apenas dos nós que podem ser removidos com segurança. O escalonamento vertical está desativado.	O pool de nós não escalona acima do valor especificado.

Em clusters padrão, o escalonador automático de clusters nunca faz o escalonamento automaticamente de um cluster para zero nós. Um ou mais nós precisam estar sempre disponíveis no cluster para executar pods do sistema. Além disso, se o número atual de nós for zero devido à remoção manual de nós, o escalonador automático de cluster e o provisionamento automático de nós poderão ser escalonados verticalmente a partir de zero clusters de nós.

Para saber mais sobre as decisões do escalonador automático, consulte as limitações do escalonador automático de clusters.

Limites do escalonamento automático

Defina o número mínimo e máximo de nós para o escalonador automático de cluster usar ao escalonar um pool de nós. Use as sinalizações --min-nodes e --max-nodes para definir o número mínimo e máximo de nós por zona.

A partir do GKE versão 1.24, é possível usar as sinalizações --total-min-nodes e --total-max-nodes para novos clusters. Essas sinalizações definem os números mínimo e máximo do número total de nós no pool em todas as zonas.

Exemplo de nós mínimo e máximo

O comando a seguir cria um cluster com várias zonas de escalonamento automático com seis nós em três zonas, com um mínimo de um nó por zona e um máximo de quatro nós por zona:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

Neste exemplo, o tamanho total do cluster pode estar entre 3 e 12 nós, distribuídos nas três zonas. Se uma delas falhar, o tamanho total do cluster pode estar entre dois e oito nós.

Exemplo de total de nós

O comando a seguir, disponível no GKE 1.24 ou posterior, cria um cluster multizonal de escalonamento automático com seis nós em três zonas inicialmente, com um mínimo de três nós e no máximo 12 nós no pool em todas as zonas:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

Neste exemplo, o tamanho total do cluster pode estar entre três e doze nós, independentemente da propagação entre as zonas.

Perfis de escalonamento automático

A decisão de quando remover um nó está relacionada à otimização da utilização ou à disponibilidade de recursos. Remover nós subutilizados melhora o uso do cluster, mas talvez novas cargas de trabalho precisem esperar que os recursos sejam provisionados novamente antes de serem executadas.

Ao tomar essas decisões, especifique qual perfil de escalonamento automático deve ser usado. Os perfis disponíveis são:

balanced: o perfil padrão que prioriza a manutenção de mais recursos prontamente disponíveis para os pods de entrada, reduzindo o tempo necessário para ativá-los nos clusters padrão. O perfil balanced não está disponível para clusters do Autopilot.
optimize-utilization: prioriza a otimização do uso em vez de manter recursos sobressalentes no cluster. Quando você ativa esse perfil, o escalonador automático do cluster reduz a escala vertical do cluster de forma mais agressiva. O GKE pode remover mais nós e com mais rapidez. O GKE prefere programar pods em nós que já têm alta alocação de CPU, memória ou GPUs. No entanto, outros fatores influenciam a programação, como a distribuição de pods pertencentes à mesma implantação, StatefulSet ou Serviço, entre os nós.

O perfil de escalonamento automático optimize-utilization ajuda o escalonador automático de cluster a identificar e remover nós subutilizados. Para alcançar essa otimização, o GKE define o nome do programador na especificação do pod como gke.io/optimize-utilization-scheduler. Os pods que especificam um programador personalizado não são afetados.

O comando a seguir ativa o perfil de escalonamento automático optimize-utilization em um cluster atual:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Como considerar a programação e a interrupção do pod

Ao reduzir a escala, o autoescalador de clusters respeita as regras de programação e remoção definidas nos pods. Essas restrições podem impedir que um nó seja excluído pelo autoescalador. A exclusão de um nó pode ser evitada se ele contiver um pod com qualquer uma das seguintes condições:

As regras de afinidade ou antiafinidade impedem a reprogramação.
O Pod não é gerenciado por um Controlador, como Deployment, StatefulSet, Job ou ReplicaSet.
O pod tem armazenamento local, e a versão do plano de controle do GKE é anterior à 1.22. Nos clusters do GKE com a versão de plano de controle 1.22 ou posterior, os pods com armazenamento local não bloqueiam mais a redução da escala vertical.
O pod tem a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
A exclusão do nó excederia o PodDisruptionBudget configurado.

Para mais informações sobre o autoescalador de clusters e prevenção de interrupções, consulte os seguintes itens nas Perguntas frequentes sobre o autoescalador de clusters:

Como fazer o escalonamento automático de TPUs no GKE

O GKE é compatível com Unidades de Processamento de Tensor (TPUs) para acelerar as cargas de trabalho de machine learning. O pool de nós de fração de TPU de host único e o pool de nós de frações de TPU de vários hosts são compatíveis com escalonamento automático e provisionamento automático.

Com a sinalização --enable-autoprovisioning em um cluster do GKE, o GKE cria ou exclui pools de nós de frações de TPU de host único ou de vários hosts com uma versão e topologia de TPU que atende aos requisitos das cargas de trabalho pendentes.

Quando você usa --enable-autoscaling, o GKE escalona o pool de nós com base no tipo, da seguinte maneira:

Pool de nós da fração de TPU de host único: o GKE adiciona ou remove nós da TPU no pool de nós atual. O pool de nós pode conter qualquer número de nós da TPU entre zero e o tamanho máximo dele, conforme determinado por --max-nodes e os --total-max-nodes. Quando o pool de nós é escalonado, todos os nós da TPU nele têm o mesmo tipo de máquina e topologia. Para saber mais sobre como criar um pool de nós de fatia de TPU de host único, consulte Criar um pool de nós.
Pool de nós de fração de TPU de vários hosts: o GKE escalona atomicamente o pool de nós de zero para o número de nós necessários para satisfazer a topologia de TPU. Por exemplo, com um pool de nós de TPU com um tipo de máquina ct5lp-hightpu-4t e uma topologia de 16x16, o pool de nós contém 64 nós. O escalonador automático do GKE garante que esse pool de nós tenha exatamente 0 ou 64 nós. Ao reduzir o escalonamento, o GKE remove todos os pods programados e drena todo o pool de nós para zero. Para saber mais como criar um pool de nós de fração de TPU de vários hosts, consulte Criar um pool de nós.

Informações adicionais

Você pode encontrar mais informações sobre o autoescalador de clusters nas Perguntas frequentes de escalonamento automático no projeto de código aberto do Kubernetes.

Limitações

O escalonador automático de cluster tem as seguintes limitações:

Os PersistentVolumes locais não são compatíveis com o escalonador automático de cluster.
Na versão do plano de controle do GKE anterior à 1.24.5-gke.600, quando os pods solicitam armazenamento temporário, o escalonador automático de cluster não oferece suporte ao escalonamento vertical de um pool de nós com zero nós que usamSSDs locais como armazenamento temporário.
Limitações de tamanho do cluster: até 15.000 nós. Considere outros limites de cluster e nossas práticas recomendadas ao executar clusters desse tamanho.
Ao reduzir o dimensionamento, o escalonador automático de clusters respeita um período de encerramento de 10 minutos para reprogramar os pods do nó em um nó diferente antes de forçar seu encerramento.
Em alguns casos, não será possível reduzir a escala com o escalonador automático de cluster, e haverá um nó extra após esse processo. Isso ocorre quando os pods necessários do sistema são programados em nós diferentes. O motivo é porque não há nenhum acionador nesses pods para transferir para um nó diferente. Consulte a pergunta Tenho um par de nós com baixa utilização, mas ele não está com a escala reduzida. Por quê? (em inglês). Para contornar essa limitação, configure um orçamento de interrupção de pod (em inglês).
A programação personalizada com filtros alterados não é compatível.
Os nós não serão escalonados verticalmente se os pods tiverem um valor de PriorityClass abaixo de -10. Saiba mais em Como o escalonador automático de cluster funciona com a prioridade e a preempção do pod?
O autoescalador de cluster pode não ter espaço de endereço IP não alocado suficiente para usar para adicionar novos nós ou pods, resultando em falhas de aumento de escala, que são indicadas por eventos eventResult com o motivo scale.up.error.ip.space.exhausted. Adicione mais endereços IP para nós expandindo a sub-rede principal ou adicione novos endereços IP para pods usando CIDR de vários pods descontínuos. Para mais informações, consulte Não há espaço IP livre suficiente para pods.
O escalonador automático de clusters do GKE é diferente do escalonador automático de clusters do projeto de código aberto do Kubernetes. Os parâmetros do escalonador automático de cluster dependem da configuração do cluster e estão sujeitos a mudanças. Se você precisar de mais controle sobre o comportamento do escalonamento automático, desative o escalonador automático de clusters do GKE e execute o escalonador automático de clusters do Kubernetes de código aberto. No entanto, o Kubernetes de código aberto não é compatível com o Google Cloud.

Problemas conhecidos

Na versão do plano de controle do GKE anterior à 1.22, o escalonador automático de cluster do GKE interrompe o escalonamento de todos os pools de nós em clusters vazios (zero nós). Esse comportamento não ocorre no GKE versão 1.22 e posterior.