Sobre o escalonamento automático de clusters

Nesta página, 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.

Esta página é destinada a administradores, arquitetos e operadores que planejam as necessidades de capacidade e infraestrutura e otimizam a arquitetura e os recursos de sistemas para garantir o menor custo total de propriedade para uma empresa ou unidade de negócios. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

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.

Prática recomendada:

A configuração do cluster deve ser planejada e projetada com administradores, arquitetos, desenvolvedores ou outra equipe da organização responsável pela implementação e manutenção do aplicativo.

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.

Prática recomendada:

Para aumentar a tolerância da carga de trabalho à interrupção, ela deve ser implantada usando um controlador com várias réplicas, como uma implantação.

É 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 escalonador automático de clusters

O escalonador automático de clusters 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 vai 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 nós estiverem escassos porque os pods solicitaram ou definiram recursos insuficientes como padrão, o escalonador automático de clusters não vai 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.

Não ative o escalonamento automático do Compute Engine para grupos gerenciados de instâncias para os nós do cluster. O autoescalador de cluster do GKE é separado do escalonamento automático do Compute Engine. Isso pode fazer com que os pools de nós não aumentem ou diminuam, porque o escalonador automático do Compute Engine vai entrar em conflito com o escalonador automático de clusters do GKE.

Critérios de operação

Ao redimensionar um pool de nós, o escalonador automático de clusters parte dos seguintes pressupostos:

  • Todos os pods replicados podem ser reiniciados em outro nó, o que pode causar uma breve interrupção.
  • 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 usando o escalonador automático de clusters.
  • 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 escalonador automático de clusters considera o custo reduzido de pools de nós com VMs spot, que são preemptivas.
  • 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 qualquer recursos não alocados disponível 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 a documentação do Kubernetes sobre o uso de 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 clusters 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 clusters também detecta as mudanças manuais feitas no nó e no pool de nós.
Prática recomendada:

Não ative o escalonador automático de cluster se os aplicativos não forem tolerantes a interrupções.

Balanceamento entre zonas

Se o pool de nós tiver vários grupos gerenciados de instâncias do mesmo tipo, o escalonador automático de clusters 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.

O escalonador automático de clusters apenas equilibra as zonas durante um evento de escalonamento vertical. O escalonador automático de clusters reduz a escala dos nós subutilizados, seja qual for o tamanho relativo dos grupos de instâncias gerenciadas em um pool. Isso faz com que os nós sejam distribuídos de maneira desigual pelas zonas.

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. É 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 de clusters 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 de clusters prioriza a utilização de reservas e contas não utilizadas para as restrições atuais dos recursos disponíveis.
Prática recomendada:

A política ANY é 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.

VMs do Spot e escalonador automático de clusters

Como o escalonador automático de cluster prefere expandir os pools de nós menos caros, quando os workloads permitem, ele adiciona VMs Spot ao dimensionamento.

No entanto, embora o escalonador automático de cluster prefira adicionar VMs Spot, essa preferência não garante que a maioria dos pods será executada nesses tipos de VM. As VMs spot podem ser interrompidas. Devido a essa preempção, é mais provável que os pods em VMs do Spot sejam removidos. Quando são removidos, eles têm apenas 15 segundos para encerrar.

Por exemplo, imagine um cenário em que você tem 10 pods e uma mistura de VMs sob demanda e Spot:

  • Você começa com 10 pods em execução em VMs sob demanda porque as VMs Spot não estavam disponíveis.
  • Você não precisa de todos os 10 pods, então o escalonador automático de cluster remove dois pods e desativa as VMs extras sob demanda.
  • Quando você precisar de 10 pods novamente, o escalonador automático de clusters vai adicionar VMs do Spot (porque são mais baratas) e programar dois pods nelas. Os outros oito pods permanecem nas VMs sob demanda.
  • Se o escalonador automático de cluster precisar reduzir escala vertical novamente, as VMs do Spot provavelmente serão interrompidas primeiro, deixando a maioria dos pods em execução em VMs sob demanda.

Para priorizar as VMs do Spot e evitar o cenário anterior, recomendamos o uso de classes de computação personalizadas. Classes de computação personalizadas permitem criar regras de prioridade que favorecem as VMs Spot durante a expansão, proporcionando-lhes maior prioridade do que nós sob demanda. Para maximizar ainda mais a probabilidade de seus pods funcionarem em nós com suporte de VMs do Spot, configure a migração ativa.

O exemplo a seguir mostra uma maneira de usar classes de computação personalizadas para priorizar VMs spot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

No exemplo anterior, a regra de prioridade declara uma preferência para a criação de nós com o tipo de máquina g2-standard-24 e VMs do Spot. Se as VMs do Spot não estiverem disponíveis, o GKE vai usar VMs sob demanda como uma opção alternativa. Essa classe de computação também ativa activeMigration, permitindo que o escalonador automático de cluster migre cargas de trabalho para VMs do Spot quando a capacidade estiver disponível.

Se não for possível usar classes de computação personalizadas, adicione uma afinidade, contaminação ou tolerância de nó. Por exemplo, a regra de afinidade de nó a seguir declara uma preferência para a programação de pods em nós que são executados por VMs do Spot. O GKE adiciona automaticamente o rótulo cloud.google.com/gke-spot=true a esses tipos de nós:

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

Para saber mais sobre como usar afinidades, taints e tolerâncias de nó para programar VMs do Spot, consulte o blog Como executar um aplicativo do GKE em nós do Spot com nós sob demanda como substituto.

Mais informações

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.

Solução de problemas

Para receber conselhos sobre solução de problemas, consulte as seguintes páginas:

A seguir