Acerca do aprovisionamento automático de nós

Esta página explica como funciona o aprovisionamento automático de nós em clusters do Google Kubernetes Engine (GKE) Standard. Com o aprovisionamento automático de nós, os nós são dimensionados automaticamente para satisfazer os requisitos das suas cargas de trabalho.

Com os clusters do Autopilot, não precisa de aprovisionar nós manualmente nem gerir conjuntos de nós, porque o GKE gere automaticamente o escalonamento e o aprovisionamento de nós.

Por que motivo deve usar o aprovisionamento automático dos nós

O aprovisionamento automático de nós gere e dimensiona automaticamente um conjunto de pools de nós em nome do utilizador. Sem o aprovisionamento automático de nós, o escalador automático de clusters do GKE cria nós apenas a partir de conjuntos de nós criados pelo utilizador. Com o aprovisionamento automático de nós, o GKE cria e elimina automaticamente node pools.

Funcionalidades não suportadas

O aprovisionamento automático de nós não cria node pools que usem qualquer uma das seguintes funcionalidades. No entanto, o redimensionador automático de clusters dimensiona os nós em conjuntos de nós existentes com estas funcionalidades:

Como funciona o aprovisionamento automático de nós

O aprovisionamento automático de nós é um mecanismo do redimensionador automático de cluster. O redimensionador automático de clusters apenas dimensiona os conjuntos de nós existentes. Com a administração de contas automática de nós ativada, o redimensionador automático de cluster pode criar pools de nós automaticamente com base nas especificações de pods não agendáveis.

O aprovisionamento automático de nós cria conjuntos de nós com base nas seguintes informações:

Limites de recursos

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

  • Nível do conjunto de nós: os conjuntos de nós aprovisionados automaticamente estão limitados a 1000 nós.
  • Nível do cluster:
    • Todos os limites de aprovisionamento automático que definir são aplicados com base no total de recursos de CPU e memória usados em todos os conjuntos de nós, e não apenas nos conjuntos aprovisionados automaticamente.
    • O escalador automático de clusters não cria novos nós se isso exceder um dos limites definidos. Se os limites já tiverem sido excedidos, o GKE não elimina os nós.

Separação de cargas de trabalho

Se os pods pendentes tiverem afinidades e tolerâncias de nós, o aprovisionamento automático de nós pode aprovisionar nós com etiquetas e taints correspondentes.

O aprovisionamento automático de nós pode criar conjuntos de nós com etiquetas e taints se todas as seguintes condições forem cumpridas:

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

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

Limitações da utilização de etiquetas para a separação de cargas de trabalho

O aprovisionamento automático dos nós aciona a criação de um novo conjunto de nós quando usa etiquetas suportadas pelo aprovisionamento automático dos nós, como cloud.google.com/gke-spot ou famílias de máquinas. Pode usar outras etiquetas nos seus manifestos de pods para restringir os nós nos quais o GKE coloca os pods, mas o GKE não usa estas etiquetas para aprovisionar novos conjuntos de nós. Para ver a lista de etiquetas que não acionam explicitamente a criação do conjunto de nós, consulte o artigo Limitações da separação de cargas de trabalho com restrições e tolerâncias.

Eliminação de node pools aprovisionados automaticamente

Quando não existem nós num conjunto de nós aprovisionado automaticamente, o GKE elimina o conjunto de nós. O GKE não elimina pools de nós que não sejam aprovisionados automaticamente.

Tipos de máquinas suportados

O aprovisionamento automático de nós tem em conta os requisitos dos pods no seu cluster para determinar que tipo de nós se adequa melhor a esses pods.

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

  • A carga de trabalho pede uma funcionalidade que não está disponível na série de máquinas E2. Por exemplo, se uma GPU for pedida pela carga de trabalho, a série de máquinas N1 é usada para o novo conjunto de nós.
  • A carga de trabalho pede recursos de TPU. Para saber mais sobre as TPUs, consulte a Introdução à Cloud TPU.
  • A carga de trabalho usa a etiqueta machine-family. Para mais informações, consulte o artigo Usar uma família de máquinas personalizada.

Se o Pod pedir GPUs, o aprovisionamento automático de nós atribui um tipo de máquina suficientemente grande para suportar o número de GPUs que o Pod pede. O número de GPUs restringe a CPU e a memória que o nó pode ter. Para mais informações, consulte o artigo Plataformas de GPU.

Os tipos de máquinas C4D são suportados com a versão 1.32.3-gke.1717000 e posteriores do GKE, e os tipos de máquinas C3D são suportados com a versão 1.28 e posteriores do GKE.

Imagens de nós suportadas

O aprovisionamento automático de nós cria conjuntos de nós com uma das seguintes imagens de nós:

  • SO otimizado para contentores (cos_containerd).
  • Ubuntu (ubuntu_containerd).

Aceleradores de aprendizagem automática suportados

O aprovisionamento automático de nós pode criar conjuntos de nós com aceleradores de hardware, como a GPU e a Cloud TPU. O aprovisionamento automático de nós suporta TPUs no GKE na versão 1.28 e posteriores.

GPUs

Se o Pod pedir GPUs, o aprovisionamento automático de nós atribui um tipo de máquina suficientemente grande para suportar o número de GPUs que o Pod pede. O número de GPUs restringe a CPU e a memória que o nó pode ter. Para mais informações, consulte o artigo Plataformas de GPU.

TPUs do Cloud

O GKE suporta unidades de processamento tensor (TPUs) para acelerar as cargas de trabalho de aprendizagem automática. O conjunto de nós de fatia de TPU de anfitrião único e o conjunto de nós de fatia de TPU de vários anfitriões suportam o dimensionamento automático e o aprovisionamento automático.

Com a flag --enable-autoprovisioning num cluster do GKE, o GKE cria ou elimina pools de nós de fatias de TPU de anfitrião único ou vários anfitriões com uma versão e uma topologia da TPU que cumprem os requisitos das cargas de trabalho pendentes.

Quando usa o --enable-autoscaling, o GKE dimensiona o conjunto de nós com base no respetivo tipo, da seguinte forma:

  • Pool de nós de fatia de TPU de host único: o GKE adiciona ou remove nós de TPU no pool de nós existente. O conjunto de nós pode conter qualquer número de nós de TPU entre zero e o tamanho máximo do conjunto de nós, conforme determinado pelas flags --max-nodes e --total-max-nodes. Quando o conjunto de nós é dimensionado, todos os nós da TPU no conjunto de nós têm o mesmo tipo de máquina e topologia. Para saber como criar um node pool de fatia de TPU de host único, consulte o artigo Crie um node pool.

  • Pool de nós de fatia de TPU com vários anfitriões: o GKE aumenta automaticamente a escala do pool de nós de zero para o número de nós necessários para satisfazer a topologia da TPU. Por exemplo, com um conjunto de nós da TPU com um tipo de máquina ct5lp-hightpu-4t e uma topologia de 16x16, o conjunto de nós contém 64 nós. O escalador automático do GKE garante que este conjunto de nós tem exatamente 0 ou 64 nós. Quando reduz a escala, o GKE despeja todos os pods agendados e esgota todo o conjunto de nós até zero. Para saber como criar um node pool de fatia de TPU com vários anfitriões, consulte o artigo Crie um node pool.

Se uma fatia de TPU específica não tiver Pods em execução ou pendentes de agendamento, o GKE reduz a escala do conjunto de nós. Os conjuntos de nós de fatias de TPUs com vários anfitriões são reduzidos de forma atómica. Os node pools de fatias de TPU de host único são reduzidos através da remoção de fatias de TPU de host único individuais.

Quando ativa o aprovisionamento automático de nós com TPUs, o GKE toma decisões de escalabilidade com base nos valores definidos no pedido de pod. O manifesto seguinte é um exemplo de uma especificação de implementação que resulta num conjunto de nós que contém uma fatia 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

Onde:

  • cloud.google.com/gke-tpu-accelerator: a versão e o tipo da TPU. Por exemplo, pode usar qualquer uma das seguintes opções:
    • TPU v4 com tpu-v4-podslice
    • TPU v5e com tpu-v5-lite-podslice.
    • TPU v5p com tpu-v5p-slice.
    • TPU Trillium (v6e) com tpu-v6e-slice.
  • cloud.google.com/gke-tpu-topology: o número e a disposição física dos chips da TPU numa fatia da TPU. Quando cria um node pool e ativa o aprovisionamento automático de nós, seleciona a topologia da TPU. Para mais informações sobre as topologias do Cloud TPU, consulte as configurações do TPU.
  • limit.google.com/tpu: o número de chips da TPU na VM da TPU. A maioria das configurações tem apenas um valor correto. No entanto, o tpu-v5-lite-podslice com a configuração de topologia 2x4:
    • Se especificar google.com/tpu = 8, o aprovisionamento automático de nós é dimensionado para cima no conjunto de nós da fatia de TPU de anfitrião único, adicionando uma máquina ct5lp-hightpu-8t.
    • Se especificar google.com/tpu = 4, o aprovisionamento automático de nós cria um node pool de fatia de TPU com vários anfitriões com duas máquinas ct5lp-hightpu-4t.
  • cloud.google.com/reservation-name: o nome da reserva que a carga de trabalho usa. Se for omitido, a carga de trabalho não usa nenhuma reserva.

Se definir o tipo de acelerador como tpu-v6e-slice (para indicar TPU Trillium), o aprovisionamento automático de nós toma as seguintes decisões:

Valores definidos no manifesto do podcast Decidido pelo aprovisionamento automático de nós
gke-tpu-topology limit.google.com/tpu Tipo de node pool Tamanho do node pool Tipo de máquina
1x1 1 Segmento de TPU de anfitrião único Flexível ct6e-standard-1t
2x2 4 Segmento de TPU de anfitrião único Flexível ct6e-standard-4t
2x4 8 Segmento de TPU de anfitrião único Flexível ct6e-standard-8t
2x4 4 Segmento de TPU com vários anfitriões 2 ct6e-standard-4t
4x4 4 Segmento de TPU com vários anfitriões 4 ct6e-standard-4t
4x8 4 Segmento de TPU com vários anfitriões 8 ct6e-standard-4t
8x8 4 Segmento de TPU com vários anfitriões 16 ct6e-standard-4t
8x16 4 Segmento de TPU com vários anfitriões 32 ct6e-standard-4t
16x16 4 Segmento de TPU com vários anfitriões 64 ct6e-standard-4t

Se definir o tipo de acelerador como tpu-v4-podslice (para indicar TPU v4), o aprovisionamento automático de nós toma as seguintes decisões:

Valores definidos no manifesto do podcast Decidido pelo aprovisionamento automático de nós
gke-tpu-topology limit.google.com/tpu Tipo de node pool Tamanho do node pool Tipo de máquina
2x2x1 4 Segmento de TPU de anfitrião único Flexível ct4p-hightpu-4t
{A}x{B}x{C} 4 Segmento de TPU com vários anfitriões {A}x{B}x{C}/4 ct4p-hightpu-4t

O produto de {A}x{B}x{C} define o número de chips no conjunto de nós. Por exemplo, pode definir uma pequena topologia de 64 chips com combinações como 4x4x4. Se usar topologias com mais de 64 chips, os valores que atribui a {A}, {B} e {C} têm de cumprir as seguintes condições:

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

Se definir o tipo de acelerador como tpu-v5-lite-podslice (para indicar TPU v5e com tipos de máquinas que começam por ct5lp-), o aprovisionamento automático de nós toma as seguintes decisões:

Valores definidos no manifesto do podcast Decidido pelo aprovisionamento automático de nós
gke-tpu-topology limit.google.com/tpu Tipo de node pool Tamanho do node pool Tipo de máquina
1x1 1 Segmento de TPU de anfitrião único Flexível ct5lp-hightpu-1t
2x2 4 Segmento de TPU de anfitrião único Flexível ct5lp-hightpu-4t
2x4 8 Segmento de TPU de anfitrião único Flexível ct5lp-hightpu-8t
2x41 4 Segmento de TPU com vários anfitriões 2 (8/4) ct5lp-hightpu-4t
4x4 4 Segmento de TPU com vários anfitriões 4 (16/4) ct5lp-hightpu-4t
4x8 4 Segmento de TPU com vários anfitriões 8 (32/4) ct5lp-hightpu-4t
4x8 4 Segmento de TPU com vários anfitriões 16 (32/4) ct5lp-hightpu-4t
8x8 4 Segmento de TPU com vários anfitriões 16 (64/4) ct5lp-hightpu-4t
8x16 4 Segmento de TPU com vários anfitriões 32 (128/4) ct5lp-hightpu-4t
16x16 4 Segmento de TPU com vários anfitriões 64 (256/4) ct5lp-hightpu-4t

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

Para saber como configurar o aprovisionamento automático de nós, consulte o artigo Configurar as UTPs.

Suporte para VMs do Spot

O aprovisionamento automático de nós suporta a criação de node pools com base em VMs Spot.

A criação de node pools com base em VMs do Spot só é considerada se existirem pods não agendáveis com uma tolerância para a restrição cloud.google.com/gke-spot="true":NoSchedule. A restrição é aplicada automaticamente aos nós em conjuntos de nós aprovisionados automaticamente que se baseiam em VMs Spot.

Pode combinar a utilização da tolerância com uma regra de afinidade de nós nodeSelector para os rótulos de nós cloud.google.com/gke-spot="true" ou cloud.google.com/gke-provisioning=spot (para nós que executam a versão 1.25.5-gke.2500 ou posterior do GKE) para garantir que as suas cargas de trabalho só são executadas em conjuntos de nós baseados em VMs Spot.

Suporte para agrupamentos que pedem armazenamento efémero

O aprovisionamento automático de nós suporta a criação de conjuntos de nós quando os pods pedem armazenamento efémero. O tamanho do disco de arranque aprovisionado nos conjuntos de nós é constante para todos os novos conjuntos de nós aprovisionados automaticamente. Pode personalizar o tamanho do disco de arranque.

A predefinição é 100 GiB. O armazenamento efémero suportado por SSDs locais não é suportado.

O aprovisionamento automático de nós aprovisiona um conjunto de nós apenas se o armazenamento efémero atribuível de um nó com um disco de arranque especificado for superior ou igual ao pedido de armazenamento efémero de um pod pendente. Se o pedido de armazenamento efémero for superior ao que é alocável, o aprovisionamento automático de nós não aprovisiona um conjunto de nós. Os tamanhos dos discos para os nós não são configurados dinamicamente com base nos pedidos de armazenamento efémero dos pods pendentes.

Limitações de escalabilidade

O aprovisionamento automático de nós tem as mesmas limitações que o redimensionador automático de cluster.

Também deve considerar os limites do node pool para cargas de trabalho distintas. Uma carga de trabalho distinta refere-se à utilização da separação de cargas de trabalho para indicar ao GKE que separe os pods em nós diferentes, coloque os pods em nós que cumpram critérios específicos ou agende cargas de trabalho específicas em conjunto.

O aprovisionamento automático dos nós prefere sempre usar pools de nós existentes e compatíveis em vez de criar um novo. A força desta preferência aumenta à medida que o número de node pools no cluster aumenta. À medida que o número de conjuntos de nós distintos se aproxima do limite suportado, o aprovisionamento automático de nós desprioriza a criação de novos conjuntos de nós. Para mais informações sobre os limites de clusters, consulte a secção de limites e práticas recomendadas do artigo Planeamento de clusters grandes.

Para clusters com muitos requisitos de carga de trabalho diferentes, recomendamos a utilização de classes de computação personalizadas.

O que se segue?