Sobre TPUs no GKE

Nesta página, você conhece o Cloud TPU e descobre onde encontrar informações sobre o uso dele com o Google Kubernetes Engine (GKE). As Unidades de Processamento de Tensor (TPUs) são circuitos integrados de aplicação específica (ASICs, na sigla em inglês) desenvolvidos especialmente pelo Google. Elas são usadas para acelerar as cargas de trabalho de machine learning que usam frameworks como oTensorFlow, PyTorch e JAX.

Antes de usar TPUs no GKE, recomendamos que você conclua o seguinte programa de aprendizado:

  1. Saiba como os aceleradores de machine learning funcionam com a Introdução à Cloud TPU.
  2. Saiba mais sobre a disponibilidade atual da versão da TPU com a arquitetura do sistema do Cloud TPU.

Para saber como configurar a Cloud TPU no GKE, consulte os recursos a seguir:

Benefícios do uso de TPUs no GKE

O GKE oferece suporte total ao gerenciamento do ciclo de vida das VMs de TPU, incluindo criação, configuração e exclusão de VMs de TPU. O GKE também oferece suporte a VMs do Spot e usa a Cloud TPU reservada. Os benefícios do uso de TPUs no GKE incluem:

  • Ambiente operacional consistente: uma única plataforma para todo o machine learning e outras cargas de trabalho.
  • Upgrades automáticos: o GKE automatiza as atualizações de versão, o que reduz a sobrecarga operacional.
  • Balanceamento de carga: o GKE distribui a latência reduzindo a carga e melhorando a confiabilidade.
  • Escalonamento responsivo: o GKE escalona automaticamente os recursos da TPU para atender às necessidades das cargas de trabalho.
  • Gerenciamento de recursos: comKueue, um sistema de enfileiramento de jobs nativo do Kubernetes, é possível gerenciar recursos em vários locatários na sua organização usando enfileiramento, preempção, priorização e compartilhamento justo.

Terminologia relacionada à TPU no GKE

Neste documento, usamos a seguinte terminologia relacionada às TPUs:

  • Tipo de TPU: o tipo de Cloud TPU, como v5e.
  • Fração de TPU: um conjunto de chips de TPU interconectados.
  • Topologia de TPU: o número e a disposição física dos chips de TPU em uma fração de TPU.
  • Nós de fração de TPU de host único: um ou mais nós de TPU independentes. As TPUs anexadas às VMs não são conectadas umas às outras por interconexões de alta velocidade.
  • Nós de fração de TPU de vários hosts: dois ou mais nós de TPU interconectados. As TPUs anexadas às VMs são conectadas por interconexões de alta velocidade. Os nós da TPU de vários hosts têm as características a seguir:
    • Atômico: o GKE trata todos os nós interconectados como uma única unidade. Durante as operações de escalonamento, o GKE escalona todo o conjunto de nós para 0 e cria novos nós. Se uma máquina no grupo falhar ou for encerrada, o GKE recria todo o conjunto de nós como uma nova unidade.
    • Imutável: não é possível adicionar manualmente novos nós ao conjunto de nós interconectados.

Como funcionam as TPUs no GKE

O gerenciamento de recursos e a prioridade do Kubernetes tratam as VMs de TPU da mesma forma que outros tipos de VM. Você solicita chips de TPU por meio do nome do recurso google.com/tpu:

    resources:
        requests:
          google.com/tpu: 4
        limits:
          google.com/tpu: 4

Ao usar TPUs no GKE, considere as seguintes características da TPU:

  • Uma VM de TPU pode acessar até oito chips de TPU.
  • Uma fração de TPU contém um número fixo de ícones de TPU que depende do tipo de máquina de TPU escolhido.
  • O número solicitado de google.com/tpu precisa ser igual ao número total de chips disponíveis no nó da TPU. Qualquer contêiner em um pod do GKE que solicite TPUs precisa consumir todos os chips TPU no nó. Caso contrário, a implantação falhará, porque o GKE não pode consumir parcialmente os recursos de TPU. Por exemplo, veja os seguintes cenários:
    • O tipo de máquina ct5l-hightpu-8t tem um único nó de TPU com 8 chips de TPU. Um pod do GKE que requer oito chips de TPU pode ser implantado no nó, mas dois pods do GKE que exigem quatro chips de TPU não podem ser implantados em um nó.
    • O tipo de máquina ct5lp-hightpu-4t com uma topologia 2x4 contém dois nós de TPU com quatro chips cada, um total de oito chips de TPU. Um pod do GKE que requer oito chips de TPU não pode ser implantado em nenhum dos nós neste pool de nós, mas dois pods que exigem quatro chips de TPU podem ser implantados nos dois nós no pool de nós.
    • A TPU v5e com topologia 4x4 tem 16 chips em quatro nós. A carga de trabalho do GKE Autopilot que seleciona essa configuração precisa solicitar quatro chips em cada réplica, para até quatro réplicas.
  • Em clusters padrão, vários pods do Kubernetes podem ser programados em uma VM da TPU, mas apenas um contêiner em cada pod pode acessar os ícones da TPU.
  • Cada cluster padrão precisa de pelo menos um pool de nós não TPU para criar pods do kube-system, como o kube-dns.
  • Por padrão, os nós da TPU têm o taint google.com/tpu que impede que pods não TPU sejam programados neles. O taint não garante que os recursos da TPU sejam totalmente utilizados. Com ele, é possível executar cargas de trabalho que não usam TPUs em nós não TPU, liberando computação em nós de TPU para o código que usa TPUs.
  • O GKE coleta os registros emitidos por contêineres em execução nas VMs da TPU. Para saber mais, consulte Logging.
  • As métricas de inicialização da TPU, como o desempenho do ambiente de execução, estão disponíveis no Cloud Monitoring. Para saber mais, consulte Observabilidade e métricas.

Planejar a configuração da TPU

Para trabalhar com TPUs em clusters do GKE, é preciso decidir os seguintes parâmetros:

  • Tipo de TPU: diferentes tipos de TPU têm diferentes recursos, como proporções preço-desempenho, capacidade de treinamento e latência de exibição. As VMs a quais as TPUs estão anexadas têm diferentes capacidades de CPU e memória.
  • Topologia: o layout dos ícones no tipo de TPU. Cada tipo de TPU é compatível com um layout de chip 2D ou 3D e arranjos específicos. Selecione uma topologia que corresponda aos requisitos de paralelismo do modelo.

  • Interconectividade de TPU: o tipo e a topologia de TPU determinam se você recebe TPUs em vários nós com interconexões de alta velocidade. Isso determina se você quer nós de fração de TPU de host único ou de vários hosts.

    • Para modelos em grande escala, use nós de fração de TPU de vários hosts
    • Para modelos de pequena escala, use nós de fração de TPU de host único

Escolher uma configuração de TPU para o modo Autopilot do GKE

No Autopilot, você escolhe um tipo de TPU e uma topologia e os especifica no manifesto do Kubernetes. O GKE gerencia nós de provisionamento com TPUs e programa suas cargas de trabalho.

Disponibilidade da TPU no Autopilot do GKE

As TPUs estão disponíveis em regiões específicas do Google Cloud. Para usar um tipo de TPU na carga de trabalho do GKE, o cluster precisa estar em uma região compatível com esse tipo. Para detalhes, consulte Regiões e zonas de TPU na documentação do Cloud TPU.

Escolher um tipo de TPU no Autopilot

Tipo de TPU Número de vCPUs Memória (GiB) Número de nós NUMA Máximo de chips de TPU em uma fração
TPU v5p (pré-lançamento)
tpu-v5p-slice		 208 448 2 6.144
TPU v5e
tpu-v5-lite-podslice		 24 a 224 48 a 384 1 256
TPU v5e (somente host único)
tpu-v5-lite-device		 24 a 224 48 a 384 1 a 2 8
TPU v4
tpu-v4-podslice		 240 407 2 4.096

Revise as especificações e os preços do chip na documentação do Cloud TPU para ajudar você a decidir qual versão usar.

Escolher uma topologia para o Autopilot

A topologia é o layout físico dos chips em uma fração de TPU. Dependendo do tipo de TPU, a topologia é bidimensional ou tridimensional. Depois de escolher um tipo de TPU, selecione uma topologia compatível com ele. Os requisitos de paralelismo do modelo ajudarão você a decidir sobre uma topologia. O produto da topologia é o número de chips na fração. Exemplo:

  • 2x2x2 é uma fração de TPU v4 com vários hosts com oito chips
  • 2x2 é uma fração da TPU v5e de host único com quatro chips

A topologia selecionada para um tipo de TPU determina se você recebe nós de fração de TPU de um ou vários hosts. Se uma topologia específica oferecer suporte a frações de host único e de vários hosts, o número de chips de TPU que suas solicitações de carga de trabalho determinarão o tipo de host que você receberá. Por exemplo, a TPU v5e (tpu-v5-lite-podslice) é compatível com a topologia 2x4 como host único e de vários hosts. Se você solicitar quatro chips na sua carga de trabalho, vai receber um nó de vários hosts com quatro chips. Se você solicitar oito chips na sua carga de trabalho, vai receber um nó de host único com oito chips.

Na tabela a seguir, descrevemos as topologias compatíveis com cada tipo de TPU e o número de chips, números de nós e tipo de host:

Tipo de TPU topologia Chips de TPU em uma fração Número de nós Tipo de host Observações
TPU v5p (pré-lançamento)
tpu-v5p-slice		 2x2x1 4 1 Host único

Topologias personalizadas para mais de 64 chips são aceitas. Aplicam-se as seguintes condições:

  • Para mais de 64 ícones, {A}, {B} e {C} precisam ser múltiplos de 4
  • A maior topologia é 16x16x24
  • Os valores precisam ser {A}≤{B}≤{C}, como 8x12x16.
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
4x4x4 64 16 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5e
tpu-v5-lite-podslice		 1x1 1 1 Host único Não há suporte para topologias personalizadas.
2x2 4 1
2x4 8 1
2x4 2 1 Vários hosts
4x4 16 4
4x8 32 8
8x8 64 16
8x16 128 32
16x16 256 64
TPU v5e (somente host único)
tpu-v5-lite-device		 1x1 1 1 Host único Topologias personalizadas não são compatíveis
2x2 4 1
2x4 8 1
TPU v4
tpu-v4-podslice		 2x2x1 4 1 Host único

Topologias personalizadas para mais de 64 chips são aceitas. Aplicam-se as seguintes condições:

  • Para mais de 64 ícones, {A}, {B} e {C} precisam ser múltiplos de 4
  • A maior topologia é 12x16x16
  • Os valores precisam ser {A}≤{B}≤{C}, como 8x12x16.
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
4x4x4 64 16 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts

  1. Calculado pelo produto de topologia dividido por quatro. ↩

Depois de escolher um tipo de TPU e uma topologia, especifique-os no manifesto da carga de trabalho. Para instruções, consulte Implantar cargas de trabalho de TPU no Autopilot do GKE.

Escolher uma configuração de TPU para o modo GKE Standard

Nas seções a seguir, descrevemos as características da TPU que você avalia ao planejar e configurar as cargas de trabalho da TPU no GKE. Para detalhes sobre versões disponíveis, tipos de máquina, topologias válidas e o número de chips, consulte Mapeamento de configurações de TPU neste documento.

Disponibilidade da TPU no modo GKE Standard

A tabela a seguir lista a disponibilidade da TPU de acordo com o tipo e a versão da máquina:

Versão da TPU Tipo de máquina começando com Versão mínima do GKE Disponibilidade Zona
TPU v4 ct4p- 1.26.1-gke.1500 Disponibilidade geral us-central2-b
TPU v5e ct5l- 1.27.2-gke.2100 Disponibilidade geral europe-west4-b
us-central1-a
TPU v5e ct5lp- 1.27.2-gke.2100 Disponibilidade geral europe-west4-a1
us-central1-a1
us-east1-c
us-east5-b1
us-west1-c
us-west4-a
us-west4-b1
TPU v5p ct5p- 1.28.3-gke.1024000 Visualizar us-east1-d
us-east5-a
us-east5-c

  1. Ao criar uma TPU v5e com um tipo de máquina que começa com ct5lp- em qualquer uma das zonas europe-west4-a, us-central1-a, us-east5-b ou us-west4-b, os pools de nós da TPU v5e de host único não são compatíveis. Em outras palavras, ao criar um pool de nós da TPU v5e em qualquer uma dessas zonas, apenas o tipo de máquina ct5lp-hightpu-4t com uma topologia de pelo menos 2x4 ou maior é aceito. Para criar uma TPU v5e de host único em us-central1 ou europe-west4, escolha as zonas us-central1-a ou europe-west4-b, respectivamente, e use os tipos de máquina que começam com ct5l-, como ct5l-hightpu-1t, ct5l-hightpu-4t ou ct5l-hightpu-8t. Para criar uma TPU v5e de host único na região us-west4, escolha a zona us-west4-a e use tipos de máquina que começam com ct5lp-, como ct5lp-hightpu-1t. Os tipos de máquinas que começam com ct5l- exigem cotas diferentes dos tipos que começam com ct5lp-. ↩

Nas seções a seguir, descrevemos as características da TPU que você avalia ao planejar e configurar as cargas de trabalho da TPU no GKE. Para detalhes sobre versões disponíveis, tipos de máquina, topologias válidas e o número de chips, consulte Mapeamento de configurações de TPU neste documento.

Tipo de máquina

Os tipos de máquinas que oferecem suporte aos recursos de TPU seguem uma convenção de nomenclatura que inclui a versão da TPU e o número de ícones por nó, como ct<version>-hightpu-<node-chip-count>t. Por exemplo, o tipo de máquina ct5lp-hightpu-1t oferece suporte à TPU v5e e contém um chip de TPU no total.

topologia

A topologia define a disposição física das TPUs dentro de uma fração da TPU. O GKE provisiona uma fração da TPU em topologias bidimensionais ou tridimensionais, dependendo da versão da TPU. Especifique uma topologia como o número de chips de TPU em cada dimensão:

  • Para a TPU v4 e v5p programada em pools de nós de fração da TPU de vários hosts, defina a topologia em três tuplas ({A}x{B}x{C}), por exemplo, 4x4x4. O produto de {A}x{B}x{C} define o número de chips no pool de nós. Por exemplo, é possível definir topologias pequenas menores que 64 chips com formulários de topologia,como 2x2x2, 2x2x4 ou 2x4x4. Se você usar topologias maiores que 64 chips, os valores atribuídos a {A}, {B} e {C} precisarão atender às seguintes condições:

    • {A}, {B} e {C} são múltiplos de quatro.
    • A maior topologia compatível com v4 é 12x16x16 e v5p é 16x16x24.
    • Os valores atribuídos mantêm o padrão A ≤ B ≤ C. Por exemplo, 4x4x8 ou 8x8x8.

Mapeamento da configuração de TPU

Use a tabela a seguir para definir o tipo de máquina e a topologia da TPU a serem usados com base no seu caso de uso:

  • Para treinamento ou inferência de modelos em pequena escala, use a TPU v4 ou a TPU v5e com pools de nós de frações de TPU de host único.
  • Para treinamento ou inferência de modelos em grande escala, use a TPU v4 ou a TPU v5e com pools de nós de frações de TPU de vários hosts.
Versão da TPU Tipo de máquina Topologia Número de chips do TPU Número de VMs Tipo de pool de nós
TPU v4 ct4p-hightpu-4t 2x2x1 4 1 Host único
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5p ct5p-hightpu-4t 2x2x1 4 1 Host único
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5e ct5l-hightpu-1t 1x1 1 1 Host único
ct5l-hightpu-4t 2x2 4 1 Host único
ct5l-hightpu-8t 2x4 8 1 Host único
ct5lp-hightpu-1t 1x1 1 1 Host único
ct5lp-hightpu-4t 2x2 4 1 Host único
ct5lp-hightpu-8t 2x4 8 1 Host único
ct5lp-hightpu-4t 2x4 8 2 Vários hosts
4x4 16 4 Vários hosts
4x8 32 8 Vários hosts
8x8 64 16 Vários hosts
8x16 128 32 Vários hosts
16x16 256 64 Vários hosts

  1. Calculado pelo produto de topologia dividido por quatro. ↩

Características da TPU v5e

As máquinas TPU v5e têm as seguintes características técnicas:

Tipo de máquina Número de vCPUs Memória (GB) Número de nós NUMA Probabilidade de ser interrompido
ct5l-hightpu-1t 24 48 1 Mais alta
ct5l-hightpu-4t 112 192 1 Média
ct5l-hightpu-8t 224 384 2 Mais baixa
ct5lp-hightpu-1t 24 48 1 Mais alta
ct5lp-hightpu-4t 112 192 1 Média
ct5lp-hightpu-8t 224 384 1 Baixa

Características da TPU v4 e v5p

As máquinas TPU v4p e v5p têm as seguintes características técnicas:

Tipo de máquina Número de vCPUs Memória (GB) Número de nós NUMA
ct4p-hightpu-4t 240 407 2
ct5p-hightpu-4t 208 448 2

Reserva da TPU

As reservas de TPU estão disponíveis ao comprar um compromisso. Qualquer reserva de TPU pode ser usada com o GKE.

Ao criar um pool de nós de TPU, use as sinalizações --reservation e --reservation-affinity=specific para consumir uma instância de TPU reservada.

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.

Limitações

  • Para reservas de capacidade, é preciso usar uma reserva específica.
  • A alocação de custos e a medição de uso do GKE não incluem dados sobre o uso ou os custos da TPU v4 reservada.
  • As TPUs v5p e v5e não são compatíveis com riptide/image streaming em us-east5.
  • O escalonamento automático da TPU v5p é compatível com clusters do GKE com planos de controle que executam pelo menos 1.29.2-gke.1035000 ou 1.28.7-gke.1020000.

Considerações sobre a programação da carga de trabalho

As TPUs têm características únicas que exigem programação e gerenciamento especiais de cargas de trabalho no Kubernetes. Nas seções a seguir, descrevemos as práticas recomendadas de programação.

CPU

Esta seção não se aplica aos clusters do Autopilot porque o GKE coloca cada pod de TPU no próprio nó.

Para programar uma carga de trabalho na CPU integrada em uma VM da TPU, verifique se o pod do GKE pode tolerar o taint google.com/tpu. Se você quiser que a carga de trabalho seja implantada em nós específicos, use seletores de nó.

O gerenciamento de recursos e a prioridade do Kubernetes tratam as VMs de TPU da mesma forma que outros tipos de VM. Para dar a pods que exigem programação de TPUs prioridade sobre outros pods nos mesmos nós, solicite o máximo de CPU ou memória para esses pods de TPU. O seguinte precisa ser feito para os pods de baixa prioridade:

  1. Defina solicitações baixas de CPU e memória para garantir que o nó tenha recursos alocáveis suficientes para as cargas de trabalho da TPU. Para saber mais, consulte Como o Kubernetes aplica solicitações e limites de recursos.
  2. Não há limite de CPU (ilimitado) para garantir que os pods possam ter um burst para usar todos os ciclos não utilizados.
  3. Defina um limite alto de memória para garantir que os pods possam usar a maior parte da memória não utilizada, mantendo a estabilidade do nó.

Se um pod do Kubernetes não solicitar CPU e memória (mesmo que esteja solicitando TPUs), o Kubernetes o considerará um pod de melhor esforço e não haverá garantia de que ele precisará de CPU e memória. Somente os pods que solicitam explicitamente a CPU e a memória têm essas garantias. Para mais informações, consulte Gerenciamento de recursos para pods e contêineres.

Para saber mais, consulte as Práticas recomendadas do Kubernetes: limites e solicitações de recursos.

Reduzir a interrupção da carga de trabalho

Se você estiver usando TPUs para treinar um modelo de machine learning e a carga de trabalho for interrompida, todo o trabalho realizado desde o último checkpoint será perdido. Para diminuir a probabilidade de interrupção da carga de trabalho, faça o seguinte:

  • Defina uma prioridade mais alta para este job do que todos os outros jobs: se os recursos forem escassos, o programador do GKE antecipa os jobs de menor prioridade para programar um job de prioridade mais alta. Isso também garante que a carga de trabalho com prioridade mais alta receba todos os recursos necessários (até o total de recursos disponíveis no cluster). Para saber mais, consulte Prioridade e preempção do pod.
  • Configurar a exclusão de manutenção: uma exclusão de manutenção é uma janela de tempo não recorrente durante a qual a manutenção automática é proibida. Para saber mais, consulte Exclusões de manutenção.
  • Use pods de tempo de execução prolongado no Autopilot: use pods de tempo de execução estendido por um período de carência de até sete dias antes que o GKE encerre seus pods para redução de escala ou upgrade de nós.

Lidar com interrupções devido à manutenção do nó

Todos os nós do GKE, incluindo aqueles que hospedam VMs de TPU, estão sujeitos a eventos de manutenção ou outras interrupções que podem causar o encerramento do nó. É possível reduzir as interrupções nas cargas de trabalho em execução nos clusters do GKE com o plano de controle executando a versão 1.29.1-gke.1425000 e posterior. O GKE alerta os nós de um encerramento iminente enviando um sinal SIGTERM ao nó até 5 minutos antes das remoções. Se a carga de trabalho usar um framework de ML, como MaxText, Pax ou JAX com o Orbax, as cargas de trabalho vão poder capturar o sinal SIGTERM e iniciar um processo de checkpoint.

É possível configurar o GKE para encerrar as cargas de trabalho de ML de maneira otimizada com o tempo máximo de notificação. No manifesto do pod, defina o campo spec.terminationGracePeriodSeconds como 300 segundos (cinco minutos). O GKE se esforça para encerrar esses pods da melhor maneira possível e executar a ação de encerramento definida por você, por exemplo, salvando um estado de treinamento. O GKE respeita qualquer configuração de até 5 minutos para as configurações PodDisruptionBudget ou terminationGracePeriodSeconds. ,

O campo spec.terminationGracePeriodSeconds gerencia apenas interrupções devido a eventos de manutenção e desfragmentação que ocorrem em VMs não preemptivas. O GKE não processa interrupções involuntárias, como falhas de hardware.

Para saber mais, consulte Configurar o encerramento automático do nó da GPU.

Maximize a utilização da TPU

Para maximizar seu investimento em TPUs, programe uma combinação de prioridades de job e coloque-as em fila para maximizar o tempo de operação das TPUs. Se você quiser a programação e a preempção no nível do job, será necessário usar um complemento para o Kubernetes que organize os jobs em filas. Recomendamos usar o Kueue para esse caso de uso.

A seguir