Sobre o provisionamento automático de nós

Padrão

---

Nesta página, explicamos como o provisionamento automático de nós funciona em clusters padrão do Google Kubernetes Engine (GKE). Com o provisionamento automático de nós, os nós são escalonados automaticamente para atender aos requisitos das suas cargas de trabalho.

Com os clusters do Autopilot, você não precisa provisionar nós manualmente ou gerenciar pools de nós, porque o GKE gerencia automaticamente o escalonamento e o provisionamento dos nós.

Por que usar o provisionamento automático de nós

O provisionamento automático de nós gerencia e escalona automaticamente um conjunto de pools de nós em nome do usuário. Sem o provisionamento automático de nós, o escalonador automático de cluster do GKE cria nós somente com base nos pools de nós criados pelo usuário. Com o provisionamento automático de nós, o GKE cria e exclui automaticamente os pools de nós.

Recursos não suportados

O provisionamento automático de nós não create pools de nós que usam qualquer um dos recursos a seguir. No entanto, o escalonador automático de cluster escalona os nós nos pools de nós atuais com estes recursos:

• GKE Sandbox
• Sistemas operacionais Windows.
• Como controlar a afinidade de reserva.
• Escalonamento automático de PersistentVolumes locais.
• Nós de provisionamento automático com SSDs locais como armazenamento temporário.
• Aprovisionamento automático por meio de programação personalizada que usa Filtros alterados.
• Configurar várias linhas de execução simultâneas (SMT, na sigla em inglês).

Como funciona o provisionamento automático de nós

O provisionamento automático de nós é um mecanismo do escalonador automático de cluster que só escalona pools de nós atuais. Com o provisionamento automático de nós ativado, o escalonador automático de cluster pode criar os pools de nós automaticamente com base nas especificações dos pods não programáveis.

Observação: o escalonador automático de cluster é ativado automaticamente ao usar provisionamento automático de nós.

O provisionamento automático de nós cria pools de nós com base nestas informações:

• Solicitações de recursos de CPU, memória e armazenamento temporário.
• Solicitações de GPU
• Afinidades de nós e seletores de rótulos (em inglês) dos pods pendentes
• Taints e tolerâncias de nós dos pods pendentes

Observação: para que o provisionamento automático de nós funcione como o esperado, as solicitações de recurso do pod precisam ser grandes o bastante para que o pod funcione normalmente. Se as solicitações de recursos forem muito pequenas, talvez os nós com provisionamento automático não tenham recursos para iniciar os pods.

Limites de recursos

O provisionamento automático de nós e o escalonador automático de cluster têm limites nos seguintes níveis:

• Nível do pool de nós: os pools de nós provisionados automaticamente estão limitados a 1.000 nós.
• Nível do cluster:
  • Todos os limites do provisionamento automático definidos por você são aplicados com base nos recursos totais de CPU e memória usados em todos os pools de nós, e não apenas nos pools provisionados automaticamente.
  • O escalonador automático de cluster não criará novos nós se essa ação exceder um dos limites definidos. Se os limites já tiverem sido excedidos, o GKE não excluirá os nós.

Separação da carga de trabalho

Se os pods pendentes tiverem afinidades e tolerâncias de nó, o provisionamento automático poderá ser feito em nós com rótulos e taints correspondentes.

O provisionamento automático de nós pode criar pools de nós com rótulos e taints se todas as condições a seguir forem atendidas:

• Um pod pendente requer um nó com uma chave de rótulo e um valor específicos.
• O pod tem uma tolerância para um taint com a mesma chave.
• A tolerância é para o efeito NoSchedule, NoExecute ou todos os efeitos.

Para instruções, consulte Configurar a separação de cargas de trabalho no GKE.

Exclusão de pools de nós provisionados automaticamente

Quando não há nós em um pool de nós provisionado automaticamente, o GKE exclui o pool de nós. O GKE não exclui pools de nós que não foram provisionados automaticamente.

Tipos de máquina compatíveis

O provisionamento automático de nós analisa os requisitos de pods no seu cluster para determinar o tipo de nó mais adequado para esses pods.

Por padrão, o GKE usa a série de máquinas E2, a menos que uma das seguintes condições se aplique:

• A carga de trabalho solicite um recurso que não está disponível na série de máquinas E2. Por exemplo, se a carga de trabalho solicitar uma GPU, a série de máquinas N1 vai ser usada no novo pool de nós.
• A carga de trabalho solicita recursos de TPU. Para saber mais sobre TPUs, consulte a Introdução ao Cloud TPU.
• A carga de trabalho use o rótulo machine-family. Saiba mais em Como usar uma família de máquinas personalizada.

Se o pod solicitar GPUs, o provisionamento automático de nós atribuirá um tipo de máquina suficientemente grande para suportar o número de GPUs solicitadas pelo pod. O número de GPUs restringe a CPU e a memória que o nó pode ter. Para mais informações, consulte Plataformas de GPU.

Observação: nas versões do GKE anteriores à 1.25, o provisionamento automático de nós atribui um tipo de máquina com a contagem exata de GPU. Um problema conhecido faz com que pods com proporções muito altas de CPU:GPU ou memory:GPU fiquem travados no status Pending. Recomendamos que você faça upgrade para o GKE versão 1.25 ou posterior.

Imagens de nó compatíveis

O provisionamento automático de nós cria pools de nós usando uma das seguintes imagens de nó:

• Container-Optimized OS (cos_containerd).
• Ubuntu (ubuntu_containerd).

Aceleradores de machine learning compatíveis

O provisionamento automático de nós pode criar pools de nós com aceleradores de hardware, como GPU e Cloud TPU. O provisionamento automático de nós oferece suporte a TPUs no GKE 1.28 e em versões posteriores.

GPUs

Se o pod solicitar GPUs, o provisionamento automático de nós atribuirá um tipo de máquina suficientemente grande para suportar o número de GPUs solicitadas pelo pod. O número de GPUs restringe a CPU e a memória que o nó pode ter. Para mais informações, consulte Plataformas de GPU.

Observação: nas versões do GKE anteriores à 1.25, o provisionamento automático de nós atribui um tipo de máquina com a contagem exata de GPU. Um problema conhecido faz com que os pods com proporções muito altas de CPU:GPU ou memória:GPU fiquem travados no status pendente. Recomendamos que você faça upgrade para o GKE 1.25 ou para versões posteriores.

Cloud TPUs

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.

Se uma fração específica da TPU não tiver pods em execução ou com programação pendente, o GKE reduzirá a escala vertical do pool de nós. Os pools de nós de frações de TPU de vários hosts são reduzidos atomicamente. Os pools de nós de frações de TPU de host único são reduzidos por meio da remoção de frações de TPU de host único individuais.

Quando você ativa o provisionamento automático de nós com TPUs, o GKE toma decisões de escalonamento com base nos valores definidos na solicitação do pod. O seguinte manifesto é um exemplo de especificação de implantação que resulta em um pool de nós que contém uma fração de TPU v4 com uma topologia 2x2x2 e duas máquinas ct4p-hightpu-4t:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: tpu-workload
      labels:
        app: tpu-workload
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx-tpu
      template:
        metadata:
          labels:
            app: nginx-tpu
        spec:
          nodeSelector:
            cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
            cloud.google.com/gke-tpu-topology: 2x2x2
            cloud.google.com/reservation-name: my-reservation
          containers:
          - name: nginx
            image: nginx:1.14.2
            resources:
              requests:
                google.com/tpu: 4
              limits:
               google.com/tpu: 4
            ports:
            - containerPort: 80

Em que:

• cloud.google.com/gke-tpu-accelerator: a versão e o tipo da TPU. Por exemplo, TPU v4 com tpu-v4-podslice ou TPU v5e com tpu-v5-lite-podslice.
• cloud.google.com/gke-tpu-topology: o número e a organização física dos ícones de TPU em uma fração de TPU. Ao criar um pool de nós e ativar o provisionamento automático de nós, você seleciona a topologia de TPU. Para mais informações sobre as topologias do Cloud TPU, consulte Configurações da TPU.
• limit.google.com/tpu: o número de ícones de TPU na VM da TPU. A maioria das configurações tem apenas um valor correto. No entanto, a configuração de topologia tpu-v5-lite-podslice com 2x4:
  • Se você especificar google.com/tpu = 8, o provisionamento automático de nós escalonará verticalmente o pool de nós da fração de TPU de host único adicionando uma máquina ct5lp-hightpu-8t.
  • Se você especificar google.com/tpu = 4, o provisionamento automático de nós criará um pool de nós da fração de TPU de vários hosts com duas máquinas ct5lp-hightpu-4t.
• cloud.google.com/reservation-name: o nome da reserva que a carga de trabalho usa. Se omitido, a carga de trabalho não usará uma reserva.

Se você definir tpu-v4-podslice, o provisionamento automático de nós tomará as seguintes decisões:

Valores definidos no manifesto do pod		Decidido pelo provisionamento automático de nós
gke-tpu-topology	limit.google.com/tpu	Tipo de pool de nós	Tamanho do pool de nós	Tipo de máquina
2x2x1	4	Fatia de TPU de host único	Flexível	ct4p-hightpu-4t
{A}x{B}x{C}	4	Fatia de TPU de vários hosts	{A}x{B}x{C}/4	ct4p-hightpu-4t

O produto de {A}x{B}x{C} define o número de ícones no pool de nós. Por exemplo, é possível definir uma pequena topologia de 64 ícones com combinações como 4x4x4. Se você usar topologias maiores que 64 ícones, os valores atribuídos a {A}, {B} e {C} precisarão atender às seguintes condições:

• {A}, {B} e {C} são todos menores ou iguais a quatro ou múltiplos de quatro.
• A maior topologia compatível é 12x16x16.
• Os valores atribuídos mantêm o padrão A ≤ B ≤ C. Por exemplo, 2x2x4 ou 2x4x4 para topologias pequenas.

Se você definir tpu-v5-lite-podslice, o provisionamento automático de nós tomará as seguintes decisões:

Valores definidos no manifesto do pod		Decidido pelo provisionamento automático de nós
gke-tpu-topology	limit.google.com/tpu	Tipo de pool de nós	Tamanho do pool de nós	Tipo de máquina
1x1	1	Fatia de TPU de host único	Flexível	ct5lp-hightpu-1t
2x2	4	Fatia de TPU de host único	Flexível	ct5lp-hightpu-4t
2x4	8	Fatia de TPU de host único	Flexível	ct5lp-hightpu-8t
2x4^1	4	Fatia de TPU de vários hosts	2 (8/4)	ct5lp-hightpu-4t
4x4	4	Fatia de TPU de vários hosts	4 (16/4)	ct5lp-hightpu-4t
4x8	4	Fatia de TPU de vários hosts	8 (32/4)	ct5lp-hightpu-4t
4x8	4	Fatia de TPU de vários hosts	16 (32/4)	ct5lp-hightpu-4t
8x8	4	Fatia de TPU de vários hosts	16 (64/4)	ct5lp-hightpu-4t
8x16	4	Fatia de TPU de vários hosts	32 (128/4)	ct5lp-hightpu-4t
16x16	4	Fatia de TPU de vários hosts	64 (256/4)	ct5lp-hightpu-4t

1. Caso especial em que o tipo de máquina depende do valor definido no campo de limites de google.com/tpu. ↩

Se você definir o tipo de acelerador como tpu-v5-lite-device, o provisionamento automático de nós tomará as seguintes decisões:

Valores definidos no manifesto do pod		Decidido pelo provisionamento automático de nós
gke-tpu-topology	limit.google.com/tpu	Tipo de pool de nós	Tamanho do pool de nós	Tipo de máquina
1x1	1	Fatia de TPU de host único	Flexível	ct5l-hightpu-1t
2x2	4	Fatia de TPU de host único	Flexível	ct5l-hightpu-4t
2x4	8	Fatia de TPU de host único	Flexível	ct5l-hightpu-8t

Para saber como configurar o provisionamento automático de nós, consulte Como configurar TPUs.

Suporte para VMs do Spot

O provisionamento automático de nós aceita a criação de pools de nós com base em VMs do Spot.

A criação de pools de nós com base em VMs spot só será considerada se existirem pods não programáveis com tolerância para o taint cloud.google.com/gke-spot="true":NoSchedule. O taint é aplicado automaticamente aos nós em pools de nós provisionados automaticamente com base em VMs spot.

É possível combinar o uso da tolerância com um nodeSelector ou a regra de afinidade de nó para os rótulos de nó cloud.google.com/gke-spot="true" ou cloud.google.com/gke-provisioning=spot (para nós que executam o GKE 1.25.5-gke.2500 ou versões posteriores) a fim de garantir que as cargas de trabalho sejam executadas apenas em pools de nós baseados em VMs spot.

Observação: o provisionamento automático de nós também oferece suporte para a criação de pools de nós com base em VMs preemptivas usando o taint cloud.google.com/gke-preemptible="true":NoSchedule e a tolerância correspondente. No entanto, as VMs do Spot são altamente recomendadas.

Observação: a criação de pools de nós com base nas VMs do Spot só é compatível com as versões 1.21 e do GKE. mais tarde. VMs preemptivas podem ser usadas em versões anteriores do GKE. Se um pod tiver uma tolerância para o rótulo cloud.google.com/gke-spot="true" na versão 1.20 do GKE e anteriores, o provisionamento automático de nós criará um pool de nós com esse rótulo, mas o pool de nós não usará VMs do Spot.

Suporte para pods que solicitam armazenamento temporário

O provisionamento automático de nós é compatível com a criação de pools de nós quando os pods solicitam armazenamento temporário. O tamanho do disco de inicialização provisionado nos pools de nós é constante para todos os novos pools de nós provisionados automaticamente. Esse tamanho do disco de inicialização pode ser personalizado.

O padrão é 100 GiB. O armazenamento temporário com suporte de SSDs locais não é compatível.

O provisionamento automático de nós provisionará um pool de nós somente se o armazenamento temporário alocável de um nó com um disco de inicialização especificado for maior ou igual à solicitação de armazenamento temporário de um pod pendente. Se a solicitação de armazenamento temporário for maior do que a alocação, o provisionamento automático de nós não provisionará um pool de nós. Os tamanhos de disco para nós não são configurados dinamicamente com base nas solicitações de armazenamento temporário de pods pendentes.

Limitações de escalonabilidade

O provisionamento automático de nós tem as mesmas limitações que o escalonador automático de cluster, bem como as seguintes limitações adicionais:

Limite no número de cargas de trabalho separadas

O provisionamento automático de nós é compatível com no máximo 100 cargas de trabalho separadas e diferentes.

Limite no número de pools de nós

O provisionamento automático de nós deixa de priorizar a criação de novos pools quando a quantidade deles no cluster chega perto de 100. Criar mais de 100 pools de nós é possível, mas só quando isso é a única opção para programar um pod pendente.

A seguir

• Saiba mais sobre como ativar o provisionamento automático de nós
• Saiba mais sobre o escalonador automático de cluster