Implantar cargas de trabalho de TPU no GKE Standard

Esta página oferece uma base para aprender a acelerar cargas de trabalho de machine learning (ML) usando TPUs no Google Kubernetes Engine (GKE). As TPUs são projetadas para processamento de multiplicação de matrizes, como treinamento de modelos de aprendizado profundo em grande escala. As TPUs são otimizadas para processar os enormes conjuntos de dados e modelos complexos de ML e, portanto, são mais econômicas e eficientes em termos de energia para cargas de trabalho de ML devido ao desempenho superior. Neste guia, você vai aprender a implantar cargas de trabalho de ML usando aceleradores do Cloud TPU, configurar cotas para TPUs, configurar upgrades para pools de nós que executam TPUs e monitorar métricas de carga de trabalho de TPU.

Este tutorial é destinado a engenheiros de machine learning (ML) e administradores e operadores de plataforma interessados em usar a orquestração de contêineres do Kubernetes para gerenciar treinamento, ajuste e inferência de modelos em grande escala usando TPUs. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Antes de ler esta página, confira se você conhece:

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.

Planejar a configuração da TPU

Planeje a configuração de TPU com base no modelo e na quantidade de memória necessária. Antes de usar este guia para implantar suas cargas de trabalho na TPU, conclua as etapas de planejamento em Planejar a configuração da TPU.

Verifique se você tem uma cota de TPU

As seções a seguir ajudam a garantir que você tenha cota suficiente ao usar TPUs no GKE.

Cota para VMs spot ou sob demanda

Se você estiver criando um pool de nós de fração de TPU com VMs spot ou sob demanda, é preciso ter cota de TPU suficiente disponível na região que você quer usar.

A criação de um pool de nós de fração de TPU que consome uma reserva de TPU não exige nenhuma cota de TPU.1 É possível pular essa etapa com segurança para TPUs reservadas.

Criar um pool de nós de fração de TPU sob demanda ou Spot no GKE requer cota da API Compute Engine. A cota da API Compute Engine (compute.googleapis.com) não é igual à cota da API Cloud TPU (tpu.googleapis.com), que é necessária para criar TPUs com a API Cloud TPU.

Para verificar o limite e o uso atual da sua cota da API Compute Engine para TPUs, siga estas etapas:

  1. Acesse a página Cotas no console do Google Cloud :

    Acessar "Cotas"

  2. Na caixa Filtro , faça o seguinte:

    1. Use a tabela a seguir para selecionar e copiar a propriedade da cota com base na versão da TPU e no tipo de máquina. Por exemplo, se você planeja criar nós da TPU v5e sob demanda com o tipo de máquina que começa com ct5lp-, digite Name: TPU v5 Lite PodSlice chips.

      Versão da TPU, o tipo de máquina começa com Propriedade e nome da cota para instâncias sob demanda Propriedade e nome da cota para instâncias spot2
      TPU v3,
      ct3- 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Não relevante
      TPU v3,
      ct3p- 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Não relevante
      TPU v4,
      ct4p- 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      ct5lp- 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p,
      ct5p- 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium,
      ct6e- 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e
      Ironwood (TPU7x) (pré-lançamento),
      tpu7x-standard-4t 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

    2. Selecione a propriedade Dimensões (por exemplo, locais) e insira region: seguido do nome da região em que você planeja criar TPUs no GKE. Por exemplo, insira region:us-west4 se planeja criar nós de fração da TPU na zona us-west4-a. A cota de TPU é regional, portanto, todas as zonas na mesma região consomem a mesma cota de TPU.

Se nenhuma cota corresponder ao filtro inserido, isso significa que o projeto não recebeu nenhuma das cotas especificadas para a região desejada. Você precisará solicitar um ajuste de cota de TPU.

Quando uma reserva de TPU é criada, os valores de limite e de uso atual da cota correspondente aumentam pelo número de ícones na reserva da TPU. Por exemplo, quando uma reserva é criada para 16 chips de TPU v5e com tipo de máquina que começa com ct5lp-, o Limite e o Uso atual para a cota de TPU v5 Lite PodSlice chips na região relevante aumentam em 16.

  1. Ao criar um pool de nós de fração de TPU, use as flags --reservation e --reservation-affinity=specific para criar uma instância reservada. As reservas de TPU estão disponíveis ao comprar um compromisso. ↩

  2. Ao criar um pool de nós de fração de TPU, use a flag --spot para criar uma instância de Spot. ↩

Cotas para outros recursos do GKE

Talvez seja necessário aumentar as seguintes cotas relacionadas ao GKE nas regiões em que o GKE cria seus recursos.

  • Cota de SSD de disco permanente (GB): o disco de inicialização de cada nó do Kubernetes requer 100 GB por padrão. Portanto, essa cota precisa ser definida pelo menos até o produto do número máximo de nós do GKE que você espera criar e 100 GB (nós * 100 GB).
  • Cota de endereços IP em uso: cada nó do Kubernetes consome um endereço IP. Portanto, essa cota precisa ser definida pelo menos tão alta quanto o número máximo de nós do GKE que você prevê que serão criados.
  • Verifique se max-pods-per-node está alinhado com o intervalo da sub-rede: cada nó do Kubernetes usa intervalos de IP secundários para pods. Por exemplo, um max-pods-per-node de 32 requer 64 endereços IP, o que se traduz em uma sub-rede /26 por nó. Esse intervalo não pode ser compartilhado com nenhum outro cluster. Para evitar o esgotamento do intervalo de endereços IP, use a flag --max-pods-per-node para limitar o número de pods que podem ser programados em um nó. A cota para max-pods-per-node precisa ser definida pelo menos tão alta quanto o número máximo de nós do GKE que você prevê que serão criados.

Para solicitar um aumento de cota, consulte Solicitar um ajuste de cota.

Garantir a disponibilidade de reserva

Para criar um pool de nós de fração de TPU usando uma reserva, ela precisa ter chips de TPU disponíveis suficientes no momento da criação do pool de nós.

Para ver quais reservas existem em um projeto e quantos chips de TPU estão disponíveis em uma reserva de TPU, confira uma lista de reservas.

Criar um cluster

É possível criar um cluster que usa TPUs com a Google Cloud CLI ou um kit de processamento acelerado (XPK, na sigla em inglês).

  • Use a Google Cloud CLI para criar manualmente a instância do cluster do GKE para personalização ou expansão precisa dos ambientes de produção do GKE.
  • Use o XPK para criar rapidamente clusters do GKE e executar cargas de trabalho para prova de conceito e testes. Para mais informações e instruções, consulte o README do XPK.

O documento a seguir descreve como configurar TPUs usando a Google Cloud CLI.

Crie um cluster do GKE no modo padrão em uma região com TPUs disponíveis.

Prática recomendada:

Use clusters regionais, que fornecem alta disponibilidade do plano de controle do Kubernetes.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Substitua:

  • CLUSTER_NAME: o nome do novo cluster;
  • LOCATION: a região com sua capacidade de TPU disponível.
  • VERSION: a versão do GKE, que precisa ser compatível com o tipo de máquina que você quer usar. A versão padrão do GKE pode não ter disponibilidade para sua TPU de destino. Para saber quais são as versões mínimas do GKE disponíveis por tipo de máquina de TPU, consulte Disponibilidade de TPU no GKE.

Provisionar TPUs

Para provisionar TPUs no GKE, você tem as seguintes opções de configuração:
  • Criar um pool de nós manualmente: é possível criar um pool de nós com uma versão e uma topologia específicas da TPU.
  • Usar o provisionamento automático de nós do GKE: é possível ativar o provisionamento automático de nós no nível do cluster e, no manifesto do pod, usar um nodeSelector para especificar a versão e a topologia da TPU. Quando um pod pendente corresponde a esses seletores, o GKE cria automaticamente um novo pool de nós que atende à solicitação. Esse método exige que você defina limites de recursos no nível do cluster para as TPUs.
  • Definir ComputeClasses personalizadas: é possível solicitar TPUs usando ComputeClasses personalizadas. Com as ComputeClasses personalizadas, os administradores da plataforma podem definir uma hierarquia de configurações de nós para o GKE priorizar durante as decisões de escalonamento de nós, de modo que as cargas de trabalho sejam executadas no hardware selecionado.

Criar um pool de nós manualmente

É possível criar um pool de nós de fração de TPU de host único ou de vários hosts.

Criar um pool de nós de fração de TPU de host único

É possível criar um pool de nós de fatia da TPU de host único usando a Google Cloud CLI, o Terraform ou o console Google Cloud .

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

Substitua:

  • NODE_POOL_NAME: o nome do novo pool de nós.
  • LOCATION: o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
  • CLUSTER_NAME: o nome do cluster.
  • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
  • MACHINE_TYPE: a versão e o tipo da TPU. Por exemplo, use tpu7x-standard-4t para Ironwood (TPU7x).

Opcionalmente, é possível usar as seguintes sinalizações:

  • --num-nodes=NUM_NODES: o número inicial de nós no pool de nós em cada zona.

    Prática recomendada:

    Se você usar a flag enable-autoscaling para o pool de nós, defina num-nodes como 0 para que o escalonador automático provisione nós adicionais assim que suas cargas de trabalho exigirem.

  • --reservation=RESERVATION_NAME: o nome da reserva que o GKE usa ao criar o pool de nós. Se você omitir essa sinalização, o GKE usará as TPUs disponíveis. Para saber mais sobre reservas de TPU, consulte Sobre as reservas do Cloud TPU.

  • --node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: informa ao GKE que o pool de nós de fração de TPU de host único faz parte de uma coleção. Use essa flag se as seguintes condições forem verdadeiras:

    • O pool de nós executa a carga de trabalho de inferência no novo pool.
    • O pool de nós usa a TPU Trillium.
    • O pool de nós não usa VMs spot.

    Para saber mais sobre o gerenciamento da programação de coleta, consulte Gerenciar a programação de coleta em frações de TPU de host único.

  • --enable-autoscaling: adicionar um pool de nós com escalonamento automático ativado. Requer as seguintes flags adicionais:

    • --total-min-nodes=TOTAL_MIN_NODES: o número mínimo de nós no pool de nós.
    • --total-max-nodes=TOTAL_MAX_NODES: o número máximo de todos os nós no pool de nós.
    • --location-policy=ANY: priorizar o uso de reservas não utilizadas e reduzir o risco de preempção das VMs spot.

  • --spot: define o pool de nós para usar VMs spot para os nós no pool de nós. Isso não pode ser alterado após a criação do pool de nós.

  • --flex-start: define o pool de nós para usar VMs de início flexível. As VMs de início flexível são criadas usando a opção de consumo flex-start. Para mais informações, consulte Executar uma pequena carga de trabalho em lote com TPUs e VMs de início flexível.

Para uma lista completa de todas as flags que podem ser especificadas, consulte a referência gcloud container clusters create.

Terraform

  1. Use a versão 4.84.0 ou mais recente do provedor google.
  2. Adicione o seguinte bloco à configuração do Terraform:
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Substitua:

  • NODE_POOL_RESOURCE_NAME: o nome do recurso do pool de nós no modelo do Terraform.
  • PROJECT_ID: o ID do projeto.
  • CLUSTER_NAME: o nome do cluster existente.
  • POOL_NAME: o nome do pool de nós a ser criado.
  • CLUSTER_LOCATION: as zonas de computação do cluster. Especifique a região em que a versão da TPU está disponível. Para saber mais, consulte Selecionar uma versão de TPU e topologia.
  • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
  • MACHINE_TYPE: o tipo de máquina da TPU a ser usada. Para ver os tipos de máquina compatíveis com a TPU, use a tabela em Escolher a versão da TPU.

Também é possível usar as seguintes variáveis:

  • autoscaling: Adicionar um pool de nós com escalonamento automático ativado. Para uma fração de TPU de host único, o GKE faz o escalonamento entre os valores TOTAL_MIN_NODES e TOTAL_MAX_NODES.
    • TOTAL_MIN_NODES: O número mínimo de nós no pool. Esse campo é opcional, a menos que o escalonamento automático também seja especificado.
    • TOTAL_MAX_NODES: o número máximo de todos os nós no pool. Esse campo é opcional, a menos que o escalonamento automático também seja especificado.
  • RESERVATION_NAME: se você usar Sobre as reservas do Cloud TPU, esta será a lista de rótulos dos recursos de reserva a serem usados ao criar o pool de nós. Para saber como preencher o RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte Provedor do Terraform.
  • spot: define o pool de nós para usar VMs do Spot nos nós da TPU. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.
  • flex_start: define o pool de nós para usar a opção de consumo flex-start. Não pode ser definido como true se spot estiver ativado. O início flexível é compatível com a versão 1.33.0-gke.1712000 ou mais recente do GKE.

Console

Para criar um pool de nós com TPUs:

  1. Acesse a página do Google Kubernetes Engine no console do Google Cloud .

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Clique em Adicionar pool de nós.

  4. Na seção Detalhes do pool de nós, marque a caixa Especificar locais do nó.

  5. Selecione a zona com base na versão de TPU que você quer usar. Para identificar uma zona disponível, consulte Disponibilidade da TPU no GKE.

  6. No painel de navegação, clique em Nós.

  7. Na seção Configuração da máquina, selecione TPUs.

  8. No menu suspenso Série, selecione uma das seguintes opções:

    • CT3: TPU v3, dispositivo de host único
    • CT3P: TPU v3, fração de pod de vários hosts
    • CT4P: TPU v4.
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. No menu suspenso Tipo de máquina, selecione o nome da máquina que será usada para os nós. Use a tabela Escolher a versão da TPU para saber como definir o tipo de máquina e a topologia de TPU que criam um pool de nós de fração de TPU de host único.

  10. No menu suspenso Topologia da TPU, selecione a topologia física para a fatia da TPU.

  11. Na caixa de diálogo Alterações necessárias, clique em Fazer alterações.

  12. Certifique-se de que o Tipo de disco de inicialização seja Disco permanente padrão ou Disco permanente SSD.

  13. Se quiser, marque a caixa de seleção Ativar nós em VMs do Spot para usar as VMs do Spot nos nós do pool.

  14. Clique em Criar.

Criar um pool de nós de fração de TPU com vários hosts

As etapas para criar um pool de nós de fração de TPU de vários hosts variam dependendo se você usa o Ironwood (TPU7x) ou uma versão anterior da TPU.

Ironwood (TPU7x)

É possível criar um pool de nós de fração de TPU de vários hosts na versão Ironwood (TPU7x) usando a Google Cloud CLI ou o Terraform:

gcloud

Para criar um pool de nós de fração de TPU de vários hosts com Ironwood (TPU7x), primeiro crie uma política de carga de trabalho.

  1. Crie uma política de carga de trabalho:

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Substitua:

    • WORKLOAD_POLICY_NAME: um nome para a política de carga de trabalho.
    • TPU_TOPOLOGY: a topologia da TPU Ironwood (TPU7x). Por exemplo, 2x2x2. Para conferir todas as topologias do Ironwood (TPU7x) compatíveis, consulte a seção de topologia.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • REGION: a região da política de carga de trabalho. Uma política de carga de trabalho é um recurso regional e pode ser reutilizada em pools de nós que compartilham a mesma topologia.

  2. Crie o pool de nós com a política de carga de trabalho:

    gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=tpu7x-standard-4t \
  --placement-policy=WORKLOAD_POLICY_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --node-locations=NODE_ZONE \
  --project=PROJECT_ID \
  --reservation=RESERVATION_NAME \
  --reservation-affinity=specific

    Substitua:

    • NODE_POOL_NAME: o nome do novo pool de nós.
    • CLUSTER_NAME: o nome do cluster do GKE.
    • WORKLOAD_POLICY_NAME: o nome da política de carga de trabalho que você criou.
    • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
    • NODE_ZONE: o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • RESERVATION_NAME: o nome da reserva a ser usada.

    Neste comando, a flag --tpu-topology foi substituída pela flag --placement-policy.

Terraform

  1. Use a versão 4.84.0 ou mais recente do provedor google.

  2. Crie uma política de carga de trabalho:

    resource "google_compute_resource_policy" {
  name   = "WORKLOAD_POLICY_NAME"
  region = CLUSTER_LOCATION
  workload_policy {
    type = "HIGH_THROUGHPUT"
    accelerator_topology = "TPU_TOPOLOGY"
  }
}

    Substitua:

    • WORKLOAD_POLICY_NAME: um nome para a política de carga de trabalho.
    • CLUSTER_LOCATION: local do Compute do cluster. Recomendamos ter um cluster regional para aumentar a confiabilidade do plano de controle do Kubernetes. Também é possível usar um cluster zonal. Para mais informações, consulte Selecionar uma versão e uma topologia de TPU.
    • TPU_TOPOLOGY: a topologia da TPU Ironwood (TPU7x). Por exemplo, 2x2x2. Para conferir todas as topologias do Ironwood (TPU7x) compatíveis, consulte Planejar TPUs.

    Para mais informações sobre a referência google_compute_resource_policy, consulte Provedor do Terraform.

  3. Na configuração do Terraform, adicione o seguinte bloco:

    resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    policy_name = WORKLOAD_POLICY_NAME
  }
}

    Substitua:

    • NODE_POOL_RESOURCE_NAME: o nome do recurso do pool de nós no modelo do Terraform.
    • PROJECT_ID: o ID do projeto.
    • CLUSTER_NAME: o nome do cluster atual ao qual o pool de nós será adicionado.
    • POOL_NAME: o nome do pool de nós a ser criado;
    • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
    • NUM_NODES: o número de nós no pool de nós. Esse valor precisa ser zero ou o produto do número de chips de TPU dividido por quatro. Isso acontece porque, nas frações da TPU de vários hosts, cada nó de fração da TPU tem quatro chips. Por exemplo, se TPU_TOPOLOGY for 4x8, haverá 32 chips, o que significa que NUM_NODES precisa ser 8. Para saber mais sobre topologias de TPU, use a tabela em Escolher a versão de TPU.
    • TPU_TOPOLOGY: indica a topologia física selecionada para a fração de TPU. O formato da topologia depende da versão da TPU usada. Para saber mais sobre topologias de TPU, use a tabela em Escolher uma topologia.

    Também é possível usar as seguintes variáveis:

    • RESERVATION_NAME: se você usar uma reserva de TPU, forneça uma lista de rótulos de recursos de reserva a serem usados ao criar o pool de nós. Para saber como preencher o RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte Provedor do Terraform.
    • autoscaling: crie um pool de nós com o escalonamento automático ativado. Quando o GKE escalona um pool de nós de uma fração da TPU de vários hosts, ele escalona horizontalmente e de maneira atomizada esse pool de nós de zero até o tamanho máximo.
      • MAX_NODES: o tamanho máximo do pool de nós. O valor precisa ser igual ao produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada VM. Por exemplo, se TPU_TOPOLOGY for 2x2x2, o produto será 8. Como cada VM em tpu7x-standard-4t tem quatro chips, o número de nós é dois.
    • spot: o pool de nós que vai usar VMs spot para os nós de fração de TPU. Não é possível mudar essa configuração depois que o pool de nós é criado. Para mais informações, consulte VMs spot.
    • flex_start: o pool de nós que vai usar a opção de consumo flex-start. Essa configuração não pode ser definida como true se spot estiver ativado.

Outras versões de TPU

É possível criar um pool de nós de fração da TPU de vários hosts nas versões v3, v4, v5p, v5e e Trillium (v6e) usando a Google Cloud CLI, o Terraform ou o console Google Cloud .

gcloud

  gcloud container node-pools create POOL_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --cluster=CLUSTER_NAME \
      --node-locations=NODE_ZONE \
      --machine-type=MACHINE_TYPE \
      --tpu-topology=TPU_TOPOLOGY \
      [--num-nodes=NUM_NODES] \
      [--spot \]
      [--flex-start \]
      [--enable-autoscaling \
        --max-nodes MAX_NODES]
      [--reservation-affinity=specific \
      --reservation=RESERVATION_NAME] \
      [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
      [--placement-type=COMPACT]

Substitua:

  • POOL_NAME: o nome do novo pool de nós.
  • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
  • CLUSTER_NAME: o nome do cluster.
  • NODE_ZONES: o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
  • MACHINE_TYPE: o tipo de máquina a ser usado para nós. Para saber mais sobre os tipos de máquina disponíveis, consulte Escolher a versão da TPU.

  • TPU_TOPOLOGY: a topologia física da fração de TPU. O formato da topologia depende da versão da TPU. Para mais informações sobre topologias de TPU, use a tabela em Escolher uma topologia.

    Para mais informações, consulte Topologia.

    Opcionalmente, é possível usar as seguintes sinalizações:

  • NUM_NODES: o número de nós no pool de nós. Precisa ser zero ou o produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada VM. Para a TPU v4e de vários hosts e a TPU v5e, o número de chips em cada VM é quatro. Portanto, se a TPU_TOPOLOGY for 2x4x4 (TPU v4 com quatro chips em cada VM), a NUM_NODES será 32/4, que é igual a 8. Se você omitir essa flag, o número de nós será calculado e definido como padrão com base na topologia e no tipo de máquina.

  • RESERVATION_NAME: o nome da reserva que o GKE usa ao criar o pool de nós. Se você omitir essa flag, o GKE usará pools de nós da fração de TPU disponíveis. Para mais informações sobre reservas de TPU, consulte Reserva de TPU.

  • --spot: define o pool de nós para usar VMs spot nos nós de fração de TPU. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.

  • --flex-start: define o pool de nós para usar VMs de início flexível. As VMs de início flexível são criadas usando a opção de consumo flex-start, que é compatível com a versão 1.33.0-gke.1712000 ou mais recente do GKE.

  • --enable-autoscaling: adicionar um pool de nós com escalonamento automático ativado. Quando o GKE escalona um pool de nós de uma fração da TPU de vários hosts, ele escalona horizontalmente e de maneira atomizada esse pool de nós de zero até o tamanho máximo.

    • MAX_NODES: o tamanho máximo do pool de nós. A flag --max-nodes será obrigatória se --enable-autoscaling for fornecido e precisar ser igual ao produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de ícones para cada VM.

  • --node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: informa ao GKE que o pool de nós de fração de TPU de vários hosts é uma coleção. Use essa flag se as seguintes condições forem verdadeiras:

    • O pool de nós executa cargas de trabalho de inferência.
    • O pool de nós usa a TPU Trillium.
    • As VMs spot não são compatíveis com o agendamento de coleta.

    Para mais informações sobre o gerenciamento da programação de coleta, consulte Gerenciar a programação de coleta em frações de TPU de vários hosts.

  • --placement-type=COMPACT: crie um pool de nós com o posicionamento compacto ativado. Essa opção precisa ser usada com a flag --tpu-topology. Para mais informações, consulte Criar uma política de posicionamento compacto e Topologia de TPU.

Terraform

  1. Use a versão 4.84.0 ou mais recente do provedor google.

  2. Adicione o seguinte bloco à configuração do Terraform:

    resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}

    Substitua:

    • NODE_POOL_RESOURCE_NAME: o nome do recurso do pool de nós no modelo do Terraform.
    • PROJECT_ID: o ID do projeto.
    • CLUSTER_NAME: o nome do cluster atual ao qual o pool de nós será adicionado.
    • POOL_NAME: o nome do pool de nós a ser criado;
    • CLUSTER_LOCATION: local de computação do cluster. Recomendamos ter um cluster regional para aumentar a confiabilidade do plano de controle do Kubernetes. Também é possível usar um cluster zonal. Para saber mais, consulte Selecionar uma versão de TPU e topologia.
    • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
    • NUM_NODES: o número de nós no pool de nós. Esse valor precisa ser zero ou o produto do número de chips de TPU dividido por quatro. Isso acontece porque, nas frações da TPU de vários hosts, cada nó de TPU de fração tem quatro chips. Por exemplo, se TPU_TOPOLOGY for 4x8, haverá 32 chips, o que significa que NUM_NODES precisa ser 8. Para saber mais sobre topologias de TPU, use a tabela em Escolher a versão de TPU.
    • TPU_TOPOLOGY: indica a topologia física da fração de TPU. O formato da topologia depende da versão da TPU usada. Para saber mais sobre topologias de TPU, use a tabela em Escolher uma topologia.

    Também é possível usar as seguintes variáveis:

    • RESERVATION_NAME: se você usar a reserva de TPU, esta será a lista de rótulos dos recursos de reserva a serem usados ao criar o pool de nós. Para saber como preencher o RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte Provedor do Terraform.
    • autoscaling: adicionar um pool de nós com escalonamento automático ativado. Quando o GKE escalona um pool de nós de uma fração da TPU de vários hosts, ele escalona horizontalmente e de maneira atomizada esse pool de nós de zero até o tamanho máximo.
      • MAX_NODES: o tamanho máximo do pool de nós. Ele precisa ser igual ao produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada VM.
    • spot: permite que o pool de nós use VMs spot para os nós de fração de TPU. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.
    • flex_start: define o pool de nós para usar a opção de consumo flex-start. Não pode ser definido como true se spot estiver ativado.

Console

Para criar um pool de nós com TPUs:

  1. Acesse a página do Google Kubernetes Engine no console do Google Cloud .

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Clique em Adicionar pool de nós.

  4. Na seção Detalhes do pool de nós, marque a caixa Especificar locais do nó.

  5. Selecione o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.

  6. No painel de navegação, clique em Nós.

  7. Na seção Configuração da máquina, selecione TPUs.

  8. No menu suspenso Série, selecione uma das seguintes opções:

    • CT3: TPU v3, dispositivo de host único
    • CT3P: TPU v3, fração de pod de vários hosts
    • CT4P: TPU v4.
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)

  9. No menu suspenso Tipo de máquina, selecione o nome da máquina que será usada para os nós. Use a tabela Escolher a versão da TPU para saber como definir o tipo de máquina e a topologia de TPU que criam um pool de nós de fração de TPU de vários hosts.

  10. No menu suspenso Topologia da TPU, selecione a topologia física para a fatia da TPU.

  11. Na caixa de diálogo Alterações necessárias, clique em Fazer alterações.

  12. Certifique-se de que o Tipo de disco de inicialização seja Disco permanente padrão ou Disco permanente SSD.

  13. Como opção, marque a caixa de seleção Ativar nós em VMs do Spot para usar VMs do Spot nos nós do pool de nós.

  14. Clique em Criar.

Usar o provisionamento automático de nós do GKE

É possível configurar o GKE para criar e excluir automaticamente pools de nós e atender às demandas de recursos das cargas de trabalho de TPU.

  1. Para ativar o provisionamento automático de pool de nós, edite os limites de recursos de TPU do cluster:

      gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=TPU_TYPE,count=MINIMUM_TPU_COUNT \
      --max-accelerator=type=TPU_TYPE,count=MAXIMUM_TPU_COUNT

    Substitua:

    • TPU_TYPE: o tipo de TPU. Por exemplo, use tpu7x-standard-4t para Ironwood (TPU7x).
    • MINIMUM_TPU_COUNT: o número mínimo de chips de TPU do tipo especificado que o cluster pode ter. Se o valor especificado for maior que o número de chips de TPU em uma fração de TPU de vários hosts, o GKE vai remover todos os nós da fração. Os pools de nós de vários hosts são escalonados entre 0 e o número de nós na fração, sem valores intermediários.
    • MAXIMUM_TPU_COUNT: o número máximo de chips de TPU do tipo especificado que o cluster pode ter. Para frações de TPU de vários hosts, especifique um valor maior que o número de chips em cada fração para que o GKE possa escalonar a fração de maneira atômica. O número de chips em uma fração é o produto da topologia da TPU. Por exemplo, se a topologia for 2x2x2, o número de chips na fração será 8, o que significa que o valor de MAXIMUM_TPU_COUNT precisa ser maior que 8.

Definir ComputeClasses personalizadas

Também é possível configurar o GKE para solicitar TPUs durante operações de escalonamento que criam novos nós usando ComputeClasses personalizadas.

É possível especificar opções de configuração de TPU na especificação personalizada de ComputeClass. Quando uma carga de trabalho do GKE usa essa ComputeClass personalizada, o GKE tenta provisionar TPUs que usam a configuração especificada ao fazer escalonamento vertical.

As seções a seguir mostram como criar uma ComputeClass personalizada e, em seguida, criar um job que consome as TPUs definidas na ComputeClass.

Criar uma ComputeClass personalizada

As etapas para criar uma ComputeClass personalizada que segue as regras de TPU variam dependendo se você usa o Ironwood (TPU7x) ou uma versão anterior da TPU.

Ironwood (TPU7x)

  1. Crie uma política de carga de trabalho. Esta etapa é necessária apenas se você estiver criando um pool de nós de vários hosts, que depende da topologia escolhida. Se você usa um pool de nós de host único, pule esta etapa.

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Substitua:

    • WORKLOAD_POLICY_NAME: um nome para a política de carga de trabalho.
    • TPU_TOPOLOGY: a topologia da TPU Ironwood (TPU7x). Por exemplo, use 2x2x2. Para mais informações sobre todas as topologias do Ironwood (TPU7x) compatíveis, consulte a seção de topologia.
    • PROJECT_ID: o ID do projeto do Google Cloud .
    • REGION: a região da política de carga de trabalho. Uma política de carga de trabalho é um recurso regional que pode ser usado em todos os pools de nós.

  2. Salve o seguinte manifesto como tpu-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
    - tpu:
        type: tpu7x
        topology: TPU_TOPOLOGY
        count: 4
      placement:
        policyName: WORKLOAD_POLICY_NAME
  nodePoolAutoCreation:
    enabled: true

  3. (Opcional) Você pode consumir uma reserva ou um sub-bloco específico. Por exemplo, adicione o seguinte specs ao manifesto ComputeClass:

      reservations:
    affinity: Specific
    specific:
      - name: RESERVATION_NAME
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
          reservationSubBlock:
            name: RESERVATION_SUB_BLOCK_NAME

    Substitua:

    • RESERVATION_NAME: o nome da reserva de capacidade do Compute Engine.
    • RESERVATION_BLOCK_NAME: o nome do bloco de reserva de capacidade do Compute Engine.
    • RESERVATION_SUB_BLOCK_NAME: o nome do sub-bloco da reserva de capacidade do Compute Engine.

    Para mais informações, consulte Consumo de recursos zonais reservados.

Outras versões de TPU

Para provisionar TPUs v3, v4, v5p, v5e ou v6e (Trillium) usando uma ComputeClass personalizada configurada para TPUs, siga estas etapas:

  1. Salve o seguinte manifesto como tpu-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - spot: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - flexStart:
      enabled: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  nodePoolAutoCreation:
    enabled: true

    Substitua:

    • TPU_TYPE: o tipo de TPU a ser usado, como tpu-v4-podslice. Precisa ser um valor compatível com o GKE.
    • TOPOLOGY: a disposição dos chips de TPU na fração, como 2x2x4. Precisa ser uma topologia compatível com o tipo de TPU selecionado.
    • NUMBER_OF_CHIPS: o número de chips de TPU para o contêiner usar. Precisa ser o mesmo valor para limits e requests.

  2. Implante a ComputeClass:

    kubectl apply -f tpu-compute-class.yaml

    Para mais informações sobre ComputeClasses e TPUs personalizadas, consulte Configuração de TPU.

Criar um job que consuma TPUs

  1. Salve o seguinte manifesto como tpu-job.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

    Substitua:

    • NUMBER_OF_CHIPS: o número de chips de TPU para o contêiner usar. Precisa ser o mesmo valor para limits e requests, igual ao valor de CHIP_COUNT na ComputeClass personalizada selecionada.
    • MEMORY_SIZE: a quantidade máxima de memória que a TPU usa. Os limites de memória dependem da versão e da topologia da TPU que você usa. Para saber mais, consulte Mínimos e máximos para aceleradores.
    • NUMBER_OF_CHIPS: o número de chips de TPU para o contêiner usar. Precisa ser o mesmo valor para limits e requests.

  2. Implante o job:

    kubectl create -f tpu-job.yaml

    Quando você cria esse job, o GKE faz automaticamente o seguinte:

    • Provisiona nós para executar os pods. Dependendo do tipo de TPU, topologia e solicitações de recursos especificados, esses nós são frações de host único ou de vários hosts. Dependendo da disponibilidade de recursos de TPU na prioridade mais alta, o GKE pode voltar a prioridades mais baixas para maximizar a capacidade de obtenção.
    • Adiciona taints aos pods e tolerâncias aos nós para evitar que outras cargas de trabalho sejam executadas nos mesmos nós que as cargas de trabalho da TPU.

    Para saber mais, consulte Sobre as ComputeClasses personalizadas.

  3. Ao concluir esta seção, exclua os recursos criados para evitar o faturamento contínuo:

    kubectl delete -f tpu-job.yaml

Preparar suas cargas de trabalho

As cargas de trabalho de TPU têm os requisitos de preparação a seguir.

  1. Frameworks como JAX, PyTorch e TensorFlow acessam VMs de TPU usando a biblioteca compartilhada libtpu. libtpu inclui o compilador XLA, o software do ambiente de execução da TPU e o driver da TPU. Cada versão do PyTorch e do JAX requer uma determinada versão de libtpu.so. Para evitar conflitos de versão de pacote, recomendamos usar uma imagem de IA do JAX. Para usar TPUs no GKE, use as seguintes versões: tpu7x
    Tipo de TPU Versão do libtpu.so
    Ironwood (TPU7x) (pré-lançamento)
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. No manifesto da carga de trabalho, adicione seletores de nós do Kubernetes para garantir que o GKE programe a carga de trabalho da TPU no tipo de máquina e na topologia de TPU definidos:

      nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
    cloud.google.com/placement-policy-name: WORKLOAD_POLICY # Required only for Ironwood (TPU7x)

    Substitua:

    • TPU_ACCELERATOR: o nome do acelerador de TPU. Por exemplo, use tpu7x-standard-4t.
    • TPU_TOPOLOGY: a topologia física da fração da TPU. O formato da topologia depende da versão da TPU. Por exemplo, use 2x2x2. Para saber mais, consulte Planejar TPUs no GKE.
    • WORKLOAD_POLICY: o nome da política de carga de trabalho que você quer usar para colocar os pods de TPU. Esse seletor de nós é necessário apenas para o Ironwood (TPU7x).

Depois de concluir a preparação da carga de trabalho, é possível executar um job que usa TPUs.

As seções a seguir mostram exemplos de como executar um job que realiza computação básica com TPUs.

Executar a carga de trabalho em nós de fração da TPU

Esta seção explica como preparar suas cargas de trabalho e exemplos de como executá-las.

Exemplo 1: executar uma implantação que solicita TPUs na especificação do pod

O GKE usa a configuração no seu pod ou ComputeClass para determinar a configuração dos nós de TPU. O manifesto a seguir é um exemplo de especificação de implantação que solicita TPUs na especificação do pod. Se a configuração de provisionamento automático de nós no nível do cluster estiver ativada, esse Deployment vai acionar a criação automática do pool de nós. Ao criar esse exemplo de implantação, o GKE cria 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
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

Neste manifesto, os seguintes campos definem a configuração da TPU:

  • cloud.google.com/gke-tpu-accelerator: a versão e o tipo da TPU. Por exemplo, use tpu7x-standard-4t para Ironwood (TPU7x).
  • cloud.google.com/gke-tpu-topology: a topologia com o número e a disposição física dos chips de TPU em uma fração de TPU. Por exemplo, use 2x2x2.
  • limits.google.com/tpu: o número de chips de TPU por VM. Por exemplo, se você usar tpu7x-standard-4t, o número de chips de TPU por VM será 4.

Exemplo 2: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis em um pool de nós de fração da TPU

A carga de trabalho a seguir retorna o número de chips de TPU em todos os nós em uma fração de TPU de vários hosts. Para criar uma fração de vários hosts, a carga de trabalho tem os seguintes parâmetros:

  • Versão do TPU: TPU v4
  • Topologia: 2x2x4

Essa seleção de versão e topologia resultam em uma fração de vários hosts.

  1. Salve o seguinte manifesto como available-chips-multihost.yaml: 
    apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.
  2. Implante o manifesto: 
    kubectl create -f available-chips-multihost.yaml

    O GKE executa uma fatia da TPU v4 com quatro VMs (fatia da TPU de vários hosts). A fração tem 16 chips de TPU interconectados.

  3. Verifique se o job criou quatro pods: 
    kubectl get pods

    O resultado será assim:

    NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
  4. Consiga os registros de um dos pods: 
    kubectl logs POD_NAME

    Substitua POD_NAME pelo nome de um dos pods criados. Por exemplo, tpu-job-podslice-0-5cd8r.

    O resultado será o seguinte: 

    TPU cores: 16
  5. Opcional: remova a carga de trabalho: 
    kubectl delete -f available-chips-multihost.yaml

Exemplo 3: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis na fração de TPU

A carga de trabalho a seguir é um pod estático que exibe o número de chips de TPU anexados a um nó específico. Para criar um nó de host único, a carga de trabalho tem os seguintes parâmetros:

  • Versão do TPU: TPU v5e
  • Topologia: 2x4

Essa seleção de versão e topologia resultam em uma fração de host único.

  1. Salve o seguinte manifesto como available-chips-singlehost.yaml: 
    apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.
  2. Implante o manifesto: 
    kubectl create -f available-chips-singlehost.yaml

    O GKE provisiona nós com oito frações de TPU de host único que usam a TPU v5e. Cada nó de TPU tem oito chips de TPU (fração de TPU de host único).

  3. Consiga os registros do pod: 
    kubectl logs tpu-job-jax-v5

    O resultado será o seguinte: 

    Total TPU chips: 8
  4. Opcional: remova a carga de trabalho: 
      kubectl delete -f available-chips-singlehost.yaml

Fazer upgrade de pools de nós usando aceleradores (GPUs e TPUs)

O GKE faz upgrade automático de clusters Padrão, incluindo pools de nós. Também é possível fazer upgrade manual dos pools de nós se quiser que seus nós usem uma versão mais recente antecipadamente. Para controlar como os upgrades funcionam no cluster, use os canais de lançamento, janelas de manutenção e exclusões e sequenciamento de lançamento.

Também é possível configurar uma estratégia de upgrade de nós para o pool de nós, como upgrades súbitos, upgrades azuis-verdes ou upgrades de curta duração. Ao configurar essas estratégias, é possível garantir que o upgrade dos pools de nós ocorra de uma maneira que atinja o equilíbrio ideal entre velocidade e interrupção do seu ambiente. Para pools de nós de fração de TPU de vários hosts, em vez de usar a estratégia de upgrade de nós configurada, o GKE recria atomicamente todo o pool de nós em uma única etapa. Para saber mais, consulte a definição de atomicidade em Terminologia relacionada à TPU no GKE.

O uso de uma estratégia de upgrade de nó exige temporariamente que o GKE provisione recursos adicionais, dependendo da configuração. Se Google Cloud tiver capacidade limitada para os recursos do pool de nós, por exemplo, se você estiver enfrentando erros de disponibilidade de recursos ao tentar criar mais nós com GPUs ou TPUs, consulte Fazer upgrade em um ambiente limitado de recursos.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste guia, considere excluir os pools de nós de fração de TPU que não têm mais cargas de trabalho programadas. Se as cargas de trabalho em execução precisarem ser encerradas normalmente, use kubectl drain para limpá-las antes de excluir o nó.

  1. Exclua um pool de nós de fração da TPU:

    gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME

    Substitua:

    • POOL_NAME: o nome do pool de nós.
    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: o local de computação do cluster.

Definir outras configurações

Nas seções a seguir, descrevemos as configurações adicionais que você pode aplicar às cargas de trabalho da TPU.

Usar Multislice

É possível agregar frações menores em um Multislice para lidar com cargas de trabalho de treinamento maiores. Para mais informações, consulte TPUs com vários setores no GKE.

Migrar sua reserva da TPU

Se você tiver reservas de TPU atuais, primeiro será necessário migrá-las para um novo sistema de reservas do Compute Engine. Também é possível criar um sistema de reservas com base no Compute Engine, em que nenhuma migração é necessária. Para saber como migrar suas reservas de TPU, consulte Reserva de TPU.

Ativar a geração de registros

Os registros emitidos por contêineres em execução em nós do GKE, incluindo VMs de TPU, sãocoletou pelo agente do Logging do GKE, enviado para o Logging e sãovisível no Logging do Google Analytics.

Configurar o reparo automático para nós de fração da TPU

Se um nó de fração da TPU em um pool de nós de fração da TPU com vários hosts não estiver íntegro, todo o pool de nós será recriado. Já em um pool de nós de fração de TPU de host único, apenas o nó de TPU não íntegro é reparado automaticamente.

As condições que resultam em nós de fração da TPU não íntegros incluem:

  • Qualquer nó de fração de TPU com condições de nó comuns.
  • Qualquer nó de fração de TPU com uma TPU não alocável é maior que zero.
  • Qualquer instância de VM em uma fração de TPU que seja interrompida (devido à preempção) ou encerrada.
  • Manutenção do nó: se algum nó da fatia da TPU em um pool de nós da fatia da TPU de vários hosts ficar inativo para manutenção do host, o GKE recriará todo o pool de nós da fatia da TPU.

Veja o status do reparo (incluindo o motivo da falha) no histórico de operações. Se a falha for causada por cota insuficiente, entre em contato com o representante da conta doGoogle Cloud para aumentar a cota correspondente.

Configurar o encerramento automático para nós de fração da TPU

Nos clusters do GKE com o plano de controle em execução na versão 1.29.1-gke.1425000 ou posterior, os nós de fração da TPU são compatíveis com sinais SIGTERM que alertam o nó sobre um encerramento iminente. A notificação de encerramento iminente pode ser configurada em até cinco minutos em nós da TPU.

Para configurar o GKE para encerrar as cargas de trabalho normalmente dentro desse período de notificação, siga as etapas em Gerenciar a interrupção de nós do GKE para GPUs e TPUs.

Executar contêineres sem o modo privilegiado

Os contêineres em execução nos nós do GKE 1.28 ou mais recente não precisam ter o modo privilegiado ativado para acessar TPUs. Os nós no GKE 1.28 e anteriores exigem o modo privilegiado.

Se o nó da fração de TPU estiver executando versões anteriores à 1.28, leia a seguinte seção:

Um contêiner em execução em uma VM em uma fração de TPU precisa de acesso a limites mais altos de memória bloqueada para que o driver possa se comunicar com os chips de TPU por acesso direto à memória (DMA). Para ativar esse recurso, é preciso configurar uma ulimit mais alta. Se você quiser reduzir o escopo de permissão no contêiner, siga estas etapas:

  1. Edite o securityContext para incluir os seguintes campos:

    securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

  2. Aumente o ulimit executando o seguinte comando dentro do contêiner antes de configurar as cargas de trabalho para usar os recursos da TPU:

    ulimit -l 68719476736

Na TPU v5e, a execução de contêineres sem o modo privilegiado está disponível em clusters nas versões 1.27.4-gke.900 e posteriores.

Observabilidade e métricas

Painel

A capacidade de observação do pool de nós no consoleGoogle Cloud está disponível para todos os usuários. Para conferir o status dos seus pools de nós de vários hosts da TPU no GKE, acesse o painel Status do pool de nós da TPU do GKE fornecido pelo Cloud Monitoring:

Acessar o status do pool de nós de TPU do GKE

Esse painel oferece insights abrangentes sobre a integridade dos seus pools de nós de TPU de vários hosts. Para mais informações, consulte Monitorar métricas de integridade para nós e pools de nós de TPU.

Na página Clusters do Kubernetes no console doGoogle Cloud , a guia Observabilidade também mostra métricas de observabilidade da TPU, como o uso da TPU, no cabeçalho Aceleradores > TPU. Para mais informações, consulte Conferir métricas de observabilidade.

O painel da TPU será preenchido apenas se você tiver métricas do sistema ativadas no cluster do GKE.

Métricas do ambiente de execução

No GKE 1.27.4-gke.900 ou mais recente, as cargas de trabalho da TPU que usam o JAX 0.4.14 ou mais recente e especificam containerPort: 8431 exportam as métricas de utilização da TPU como métricas do sistema do GKE. As métricas a seguir estão disponíveis no Cloud Monitoring para monitorar o desempenho do ambiente de execução da carga de trabalho da TPU

  • Ciclo de trabalho: porcentagem de tempo durante o período de amostragem anterior (60 segundos) em que os TensorCores estavam ativamente em processamento em um chip de TPU. Uma porcentagem maior significa melhor uso da TPU.
  • Memória usada: quantidade de memória do acelerador alocada em bytes. Amostras coletadas a cada 60 segundos.
  • Memória total: memória total do acelerador em bytes. Amostras coletadas a cada 60 segundos.

Essas métricas estão localizadas no esquema de nó (k8s_node) e contêiner de contêiner (k8s_container) do Kubernetes.

Contêiner do Kubernetes:

  • kubernetes.io/container/accelerator/duty_cycle
  • kubernetes.io/container/accelerator/memory_used
  • kubernetes.io/container/accelerator/memory_total

Nó do Kubernetes:

  • kubernetes.io/node/accelerator/duty_cycle
  • kubernetes.io/node/accelerator/memory_used
  • kubernetes.io/node/accelerator/memory_total

Monitorar métricas de integridade para nós e pools de nós da TPU

Quando um job de treinamento tem um erro ou termina com falha, é possível verificar as métricas relacionadas à infraestrutura subjacente para descobrir se a interrupção foi causada por um problema com o nó ou pool de nós subjacente.

Status do nó

No GKE 1.32.1-gke.1357001 ou mais recente, a seguinte métrica do sistema do GKE expõe a condição de um nó do GKE:

  • kubernetes.io/node/status_condition

O campo condition informa condições no nó, como Ready, DiskPressure e MemoryPressure. O campo status mostra o status informado da condição, que pode ser True, False ou Unknown. Essa é uma métrica com o tipo de recurso monitorado k8s_node.

Essa consulta PromQL mostra se um nó específico está Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Para ajudar a resolver problemas em um cluster, consulte os nós que apresentaram outras condições:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Talvez você queira analisar especificamente os nós que não são Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Se não houver dados, os nós estarão prontos. A condição de status é amostrada a cada 60 segundos.

Use a consulta a seguir para entender o status do nó em toda a frota:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

Status do pool de nós

A seguinte métrica de sistema do GKE para o recurso monitorado k8s_node_pool expõe o status de um pool de nós do GKE:

  • kubernetes.io/node_pool/status

Essa métrica é informada apenas para pools de nós de TPU de vários hosts.

O campo status informa o status do pool de nós, como Provisioning, Running, Error, Reconciling ou Stopping. As atualizações de status acontecem depois que as operações da API do GKE são concluídas.

Para verificar se um pool de nós específico tem o status Running, use esta consulta em PromQL:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Para monitorar o número de pools de nós no seu projeto agrupados por status, use a seguinte consulta do PromQL:

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Disponibilidade do pool de nós

A seguinte métrica do sistema do GKE mostra se um pool de nós da TPU de vários hosts está disponível:

  • kubernetes.io/node_pool/multi_host/available

A métrica tem um valor de True se todos os nós do pool de nós estiverem disponíveis e False caso contrário. A métrica é amostrada a cada 60 segundos.

Para verificar a disponibilidade de pools de nós de TPU de vários hosts no seu projeto, use a seguinte consulta PromQL:

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Contagem de interrupções de nós

A métrica do sistema do GKE a seguir informa a contagem de interrupções de um nó do GKE desde a última amostra. A métrica é amostrada a cada 60 segundos:

  • kubernetes.io/node/interruption_count

Os campos interruption_type (como TerminationEvent, MaintenanceEvent ou PreemptionEvent) e interruption_reason (como HostError, Eviction ou AutoRepair) podem ajudar a explicar por que um nó foi interrompido.

Para conferir um detalhamento das interrupções e das causas nos nós de TPU dos clusters no seu projeto, use a seguinte consulta do PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Para ver apenas os eventos de manutenção do host, atualize a consulta para filtrar o valor HW/SW Maintenance de interruption_reason. Use a seguinte consulta PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Para ver a contagem de interrupções agregada por pool de nós, use a seguinte consulta do PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Tempos de recuperação (TTR) do pool de nós

A seguinte métrica do sistema do GKE informa a distribuição das durações do período de recuperação para pools de nós da TPU de vários hosts do GKE:

  • kubernetes.io/node_pool/accelerator/times_to_recover

Cada amostra registrada nessa métrica indica um único evento de recuperação do pool de nós de um período de inatividade.

Essa métrica é útil para rastrear o tempo de recuperação e o tempo entre interrupções do pool de nós de TPU de vários hosts.

Use a seguinte consulta do PromQL para calcular o tempo médio de recuperação (MTTR) nos últimos sete dias no cluster:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Tempos entre interrupções (TBI) do pool de nós

O tempo entre interrupções do pool de nós mede quanto tempo sua infraestrutura é executada antes de sofrer uma interrupção. Ele é calculado como a média em uma janela de tempo, em que o numerador mede o tempo total em que sua infraestrutura ficou ativa e o denominador mede o total de interrupções na sua infraestrutura.

O exemplo de PromQL a seguir mostra o tempo médio entre interrupções (MTBI, na sigla em inglês) de sete dias para o cluster especificado:

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Métricas de hospedagem

No GKE 1.28.1-gke.1066000 ou mais recente, as VMs em uma fração da TPU exportam as métricas de utilização da TPU como métricas do sistema do GKE. As seguintes métricas estão disponíveis no Cloud Monitoring para monitorar o desempenho do host da TPU:

  • Uso do TensorCore: porcentagem atual do TensorCore que está sendo utilizada. O valor do TensorCore é igual à soma das unidades de multiplicação de matriz (MXUs) mais a unidade vetorial. O valor de utilização do TensorCore é a divisão das operações do TensorCore que foram realizadas no período de amostragem anterior (60 segundos) pelo número de operações do TensorCore com suporte no mesmo período. Um valor maior significa melhor utilização.
  • Uso de largura de banda da memória: porcentagem atual da largura de banda da memória do acelerador que está sendo usada. Calculada pela divisão da largura de banda da memória usada durante um período de amostragem (60 segundos) pela largura de banda máxima aceita no mesmo período.

Essas métricas estão localizadas no esquema de nó (k8s_node) e contêiner de contêiner (k8s_container) do Kubernetes.

Contêiner do Kubernetes:

  • kubernetes.io/container/accelerator/tensorcore_utilization
  • kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nó do Kubernetes:

  • kubernetes.io/node/accelerator/tensorcore_utilization
  • kubernetes.io/node/accelerator/memory_bandwidth_utilization

Para mais informações, consulte Métricas do Kubernetes e Métricas do sistema do GKE.

Gerenciar a programação de coleta

No TPU Trillium, é possível usar a programação de coleta para agrupar nós de fração de TPU. Agrupar esses nós de fração de TPU facilita o ajuste do número de réplicas para atender à demanda da carga de trabalho.O Google Cloud controla as atualizações de software para garantir que sempre haja frações suficientes na coleção disponíveis para atender ao tráfego.

A TPU Trillium oferece suporte à programação de coleta para pools de nós de host único e vários hosts que executam cargas de trabalho de inferência. A seguir, descrevemos como o comportamento do agendamento de coleta depende do tipo de fração de TPU usada:

  • Fração de TPU de vários hosts:o GKE agrupa frações de TPU de vários hosts para formar uma coleção. Cada pool de nós do GKE é uma réplica nessa coleção. Para definir uma coleção, crie uma fração de TPU de vários hosts e atribua um nome exclusivo a ela. Para adicionar mais frações de TPU à coleta, crie outro pool de nós de fração de TPU de vários hosts com o mesmo nome de coleta e tipo de carga de trabalho.
  • Fração de TPU de host único:o GKE considera todo o pool de nós de fração de TPU de host único como uma coleção. Para adicionar mais frações de TPU à coleção, redimensione o pool de nós de fração de TPU de host único.

Para gerenciar uma coleção, realize uma destas ações com base no tipo de pool de nós que você usa.

Gerenciar a programação de coleta em pools de nós de frações de TPU de vários hosts

Use as tarefas a seguir para gerenciar pools de nós de frações de TPU com vários hosts.

  • Para verificar se um pool de fração de TPU de vários hosts faz parte de uma coleção, execute o seguinte comando:

    gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

    O resultado será o seguinte:

    nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

    Se o pool de fatias de TPU de vários hosts fizer parte de uma coleção, a saída terá os seguintes rótulos:

    • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
    • cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

  • Para receber a lista de coleções no cluster, execute o seguinte comando:

    #!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

    O resultado será o seguinte:

    Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

  • Para ver uma lista de pools de nós que pertencem a uma coleção, execute o seguinte comando:

    #!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

    O resultado será o seguinte:

    Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

  • Para escalonar verticalmente da coleção, crie outro pool de nós de fração de TPU de vários hosts e adicione cloud.google.com/gke-workload-type e cloud.google.com/gke-nodepool-group-name. Use o mesmo nome de coleção em cloud.google.com/gke-nodepool-group-name e execute o mesmo tipo de carga de trabalho. Se o provisionamento automático de nós estiver ativado no cluster, o GKE vai criar pools automaticamente com base nas demandas de carga de trabalho.

  • Para reduzir escala vertical da coleta, exclua o pool de nós.

  • Para excluir a coleção, remova todos os pools de nós anexados. É possível excluir o pool de nós ou excluir o cluster. A exclusão do cluster remove todas as coleções nele.

Gerenciar a programação de coleta em pools de nós de fração de TPU de host único

Use as tarefas a seguir para gerenciar pools de nós de fração de TPU de host único.

  • Para verificar se um pool de fração de TPU de host único tem o agendamento de coleta ativado, execute o seguinte comando:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'

    O resultado será o seguinte:

    gke-workload-type: HIGH_AVAILABILITY

    Se o pool de frações de TPU de host único fizer parte de uma coleção, a saída terá o rótulo cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

  • Para escalonar verticalmente da coleta, redimensione o pool de nós manualmente ou automaticamente com o provisionamento automático de nós.

  • Para reduzir escala vertical da coleta, exclua o pool de nós.

  • Para excluir a coleção, remova todos os pools de nós anexados. É possível excluir o pool de nós ou excluir o cluster. A exclusão do cluster remove todas as coleções dele.

Problemas conhecidos

  • O escalonador automático de cluster pode calcular incorretamente a capacidade de novos nós de fração de TPU antes que esses nós informem as TPUs disponíveis. Em seguida, o escalonador automático de cluster pode realizar um escalonamento adicional e, como resultado, criar mais nós do que o necessário. O escalonador automático de cluster reduz os nós adicionais, se eles não forem necessários, após a operação de reduzir escala vertical regular.
  • O escalonador automático de cluster cancela o escalonamento vertical de pools de nós de fração de TPU que permanecem em espera por mais de 10 horas. O autoescalador de cluster tentará realizar essas operações de escalonar verticalmente posteriormente. Esse comportamento pode reduzir a capacidade de obtenção de TPU para clientes que não usam reservas.
  • As cargas de trabalho que não são da TPU e têm tolerância para o taint da TPU podem impedir reduzir escala vertical do pool de nós se estiverem sendo recriadas durante a diminuição do pool de nós de fração da TPU.
  • A métrica de utilização da largura de banda da memória não está disponível para TPUs v5e.

A seguir