Sobre o provisionamento automático de nós


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 cria 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:

Como funciona o provisionamento automático de nós

O provisionamento automático de nós é um mecanismo do escalonador automático de cluster. O escalonador automático de cluster só escalona pools de nós. 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.

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

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.

Limitações do uso de rótulos para a separação de cargas de trabalho

O provisionamento automático de nós aciona a criação de um novo pool de nós quando você usa rótulos com suporte ao provisionamento automático de nós, como cloud.google.com/gke-spot ou famílias de máquinas. É possível usar outros rótulos nos manifestos de pods para restringir os nós em que o GKE coloca pods, mas ele não vai usar esses rótulos para provisionar novos pools de nós. Para conferir a lista de identificadores que não acionam explicitamente a criação de um pool de nós, consulte Limitações da separação de cargas de trabalho com taints e tolerâncias.

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:

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.

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.

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, você pode usar qualquer uma das seguintes opções:
    • TPU v4 com tpu-v4-podslice
    • TPU v5e com tpu-v5-lite-podslice.
    • TPU v6e com tpu-v6e-slice. A TPU v6e está em Pré-lançamento.
  • 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 v6e (disponível na pré-visualização), o provisionamento automático de nós vai 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 ct6e-standard-1t
2x2 4 Fatia de TPU de host único Flexível ct6e-standard-4t
2x4 8 Fatia de TPU de host único Flexível ct6e-standard-8t
2x4 4 Fatia de TPU de vários hosts 2 ct6e-standard-4t
4x4 4 Fatia de TPU de vários hosts 4 ct6e-standard-4t
4x8 4 Fatia de TPU de vários hosts 8 ct6e-standard-4t
8x8 4 Fatia de TPU de vários hosts 16 ct6e-standard-4t
8x16 4 Fatia de TPU de vários hosts 32 ct6e-standard-4t
16x16 4 Fatia de TPU de vários hosts 64 ct6e-standard-4t

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
2x41 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.

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