Implemente cargas de trabalho de TPU no GKE Standard

Esta página fornece uma base para saber como acelerar as cargas de trabalho de aprendizagem automática (AA) através das UTPs no Google Kubernetes Engine (GKE). As TPUs foram concebidas para o processamento de multiplicação de matrizes, como a preparação de modelos de aprendizagem profunda em grande escala. As TPUs estão otimizadas para processar os enormes conjuntos de dados e os modelos complexos de ML e, por isso, são mais rentáveis e eficientes em termos de energia para cargas de trabalho de ML devido ao seu desempenho superior. Neste guia, vai aprender a implementar cargas de trabalho de ML usando aceleradores de Cloud TPU, configurar quotas para TPUs, configurar atualizações para pools de nós que executam TPUs e monitorizar métricas de cargas de trabalho de TPU.

Este tutorial destina-se a engenheiros de aprendizagem automática (ML) e administradores e operadores de plataformas interessados em usar a orquestração de contentores do Kubernetes para gerir cargas de trabalho de grande escala de preparação, otimização e inferência de modelos usando TPUs. Para saber mais sobre as funções comuns e as tarefas de exemplo referenciadas no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler esta página, certifique-se de que conhece o seguinte:

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Planeie a configuração da TPU

Planeie a configuração da TPU com base no seu modelo e na quantidade de memória que requer. Antes de usar este guia para implementar as suas cargas de trabalho na TPU, conclua os passos de planeamento em Planeie a configuração da TPU.

Certifique-se de que tem quota de TPU

As secções seguintes ajudam a garantir que tem quota suficiente quando usa as UTPs no GKE.

Quota para VMs a pedido ou do Spot

Se estiver a criar um conjunto de nós de fatias de TPU com VMs a pedido ou VMs Spot, tem de ter uma quota de TPU suficiente disponível na região que quer usar.

A criação de um node pool de fatias de TPU que consuma uma reserva de TPU não requer qualquer quota de TPU.1 Pode ignorar esta secção com segurança para TPUs reservadas.

A criação de um node pool de fatia de TPU a pedido ou Spot no GKE requer quota da API Compute Engine. A quota da API Compute Engine (compute.googleapis.com) não é igual à quota da API Cloud TPU (tpu.googleapis.com), que é necessária quando cria TPUs com a API Cloud TPU.

Para verificar o limite e a utilização atual da sua quota da API Compute Engine para TPUs, siga estes passos:

  1. Aceda à página Quotas na Google Cloud consola:

    Aceder a Quotas

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

    1. Use a tabela seguinte para selecionar e copiar a propriedade da quota com base na versão da TPU e no tipo de máquina. Por exemplo, se planear criar nós da TPU v5e a pedido cujo tipo de máquina comece por ct5lp-, introduza Name: TPU v5 Lite PodSlice chips.

      Versão da TPU, o tipo de máquina começa com Propriedade e nome da quota para instâncias a pedido Propriedade e nome da quota para instâncias do Spot2
      TPU v3,
      ct3- 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Não aplicável
      TPU v3,
      ct3p- 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Não aplicável
      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

    2. Selecione a propriedade Dimensões (por exemplo, localizações) e introduza region: seguido do nome da região na qual planeia criar as TPUs no GKE. Por exemplo, introduza region:us-west4 se planear criar nós de fatia de TPU na zona us-west4-a. A quota de TPUs é regional, pelo que todas as zonas na mesma região consomem a mesma quota de TPUs.

Se nenhuma quota corresponder ao filtro que introduziu, significa que não foi concedida nenhuma das quotas especificadas ao projeto para a região de que precisa e tem de pedir um ajuste da quota de TPUs.

Quando é criada uma reserva de TPU, os valores do limite e da utilização atual da quota correspondente aumentam pelo número de chips na reserva de TPU. Por exemplo, quando é criada uma reserva para 16 chips TPU v5e cujo tipo de máquina começa por ct5lp-, o limite e a utilização atual da quota TPU v5 Lite PodSlice chips na região relevante aumentam em 16.

  1. Quando criar um node pool de fatia de TPU, use as flags --reservation e --reservation-affinity=specific para criar uma instância reservada. As reservas de TPUs estão disponíveis quando compra um compromisso. ↩

  2. Quando criar um node pool de fatia de TPU, use a flag --spot para criar uma instância Spot. ↩

Quotas para recursos adicionais do GKE

Pode ter de aumentar as seguintes quotas relacionadas com o GKE nas regiões onde o GKE cria os seus recursos.

  • Quota de SSDs do Persistent Disk (GB): por predefinição, o disco de arranque de cada nó do Kubernetes requer 100 GB. Por conseguinte, esta quota deve ser definida, pelo menos, como tão elevada quanto o produto do número máximo de nós do GKE que prevê criar e 100 GB (nós * 100 GB).
  • Quota de endereços IP em utilização: cada nó do Kubernetes consome um endereço IP. Por conseguinte, esta quota deve ser definida, pelo menos, tão elevada quanto o número máximo de nós do GKE que prevê criar.
  • Certifique-se de que max-pods-per-node está alinhado com o intervalo de sub-redes: cada nó do Kubernetes usa intervalos de IP secundários para pods. Por exemplo, max-pods-per-node de 32 requer 64 endereços IP, o que se traduz numa sub-rede /26 por nó. Tenha em atenção que este intervalo não deve ser partilhado com nenhum outro cluster. Para evitar esgotar o intervalo de endereços IP, use a flag --max-pods-per-node para limitar o número de pods que podem ser agendados num nó. A quota para max-pods-per-node deve ser definida, pelo menos, tão elevada quanto o número máximo de nós do GKE que prevê criar.

Para pedir um aumento da quota, consulte o artigo Peça um ajuste da quota.

Garantir a disponibilidade de reservas

Para criar um node pool de fatia de TPU usando uma reserva, a reserva tem de ter chips de TPU disponíveis suficientes no momento da criação do node pool.

Para ver que reservas existem num projeto e quantos chips de TPU numa reserva de TPU estão disponíveis, veja uma lista das suas reservas.

Opções para aprovisionar TPUs no GKE

O GKE permite-lhe usar TPUs diretamente em cargas de trabalho individuais através de nodeSelectors do Kubernetes no manifesto da carga de trabalho ou criando pools de nós no modo padrão com TPUs.

Em alternativa, pode pedir TPUs através de classes de computação personalizadas. As classes de computação personalizadas permitem que os administradores da plataforma definam uma hierarquia de configurações de nós para que o GKE priorize durante as decisões de escalabilidade de nós, para que as cargas de trabalho sejam executadas no hardware selecionado.

Para obter instruções, consulte a secção Aprovisione TPUs com classes de computação personalizadas.

Crie um cluster

Crie um cluster do GKE no modo Standard numa região com TPUs disponíveis.

Prática recomendada:

Use clusters regionais, que oferecem alta disponibilidade do painel de controlo do Kubernetes.

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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do novo cluster.
  • LOCATION: a região com a sua capacidade de TPU disponível.
  • VERSION: a versão do GKE, que tem de suportar o tipo de máquina que quer usar. Tenha em atenção que a versão predefinida do GKE pode não ter disponibilidade para a 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 o artigo Disponibilidade de TPUs no GKE.

Crie um node pool

Pode criar um conjunto de nós de segmentação de TPU de host único ou múltiplo.

Crie um node pool de fatia de TPU de host único

Pode criar um conjunto de nós de fatia de TPU de anfitrião único através da CLI Google Cloud, do Terraform ou da Google Cloud consola.

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 o seguinte:

  • NODE_POOL_NAME: o nome do novo node pool.
  • LOCATION: o nome da zona com base na versão da TPU que quer usar. Para identificar uma localização disponível, consulte o artigo Disponibilidade de TPUs no GKE.
  • CLUSTER_NAME: o nome do cluster.
  • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas onde o GKE cria o conjunto de nós.
  • MACHINE_TYPE: o tipo de máquina a usar para os nós. Para mais informações sobre os tipos de máquinas compatíveis com a TPU, use a tabela em Escolha a versão da TPU.

Opcionalmente, também pode usar as seguintes flags:

  • --num-nodes=NUM_NODES: o número inicial de nós no node pool em cada zona. Se omitir esta flag,o GKE atribui a predefinição de 3,

    Prática recomendada:

    Se usar a flag enable-autoscaling para o conjunto de nós, defina num-nodes como 0 para que o escalador automático aprovicione nós adicionais assim que as suas cargas de trabalho os exigirem.

  • --reservation=RESERVATION_NAME: o nome da reserva que o GKE usa quando cria o conjunto de nós. Se omitir esta flag, o GKE usa as TPUs disponíveis. Para saber mais sobre as reservas de TPUs, consulte o artigo Acerca das reservas de Cloud TPUs.

  • --node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: indica ao GKE que o conjunto de nós da fatia de TPU de anfitrião único faz parte de uma coleção. Use esta flag se as seguintes condições se aplicarem:

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

    Para saber mais sobre a gestão do agendamento da recolha, consulte o artigo Faça a gestão do agendamento da recolha em fatias de TPU de anfitrião único.

  • --enable-autoscaling: crie um node pool com o dimensionamento automático ativado. Requer as seguintes flags adicionais:

    • --total-min-nodes=TOTAL_MIN_NODES: número mínimo de todos os nós no node pool.
    • --total-max-nodes=TOTAL_MAX_NODES: número máximo de todos os nós no node pool.
    • --location-policy=ANY: priorizar a utilização de reservas não utilizadas e reduzir o risco de preemptção de VMs do Spot.

  • --spot: define o node pool para usar VMs do Spot para os nós no node pool. Não é possível alterar esta opção após a criação do conjunto de nós.

  • --flex-start: define o conjunto de nós para usar VMs de início flexível. As VMs de início flexível são criadas através da opção de consumo flex-start, que é suportada na versão 1.33.0-gke.1712000 ou posterior do GKE.

  • --sandbox=type=gvisor: aprovisiona um nó com o GKE Sandbox ativado. Requer a TPU v4 e versões posteriores. Para mais informações, consulte o artigo GKE Sandbox.

Para ver uma lista completa de todas as flags que pode especificar, consulte a referência gcloud container clusters create.

Terraform

  1. Certifique-se de que usa a versão 4.84.0 ou posterior do fornecedor 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 o seguinte:

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

Opcionalmente, também pode usar as seguintes variáveis:

  • autoscaling: crie um node pool com o dimensionamento automático ativado. Para uma fatia de TPU de host único, o GKE é dimensionado entre os valores TOTAL_MIN_NODES e TOTAL_MAX_NODES.
    • TOTAL_MIN_NODES: número mínimo de todos os nós no node pool. Este campo é opcional, a menos que o ajuste automático também seja especificado.
    • TOTAL_MAX_NODES: Número máximo de todos os nós no node pool. Este campo é opcional, a menos que o ajuste automático também seja especificado.
  • RESERVATION_NAME: Se usar Acerca das reservas de Cloud TPU, esta é a lista de etiquetas dos recursos de reserva a usar quando criar o conjunto de nós. Para saber como preencher o campo RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte o fornecedor do Terraform.
  • spot: define o node pool para usar VMs do Spot para os nós da TPU. Não é possível alterar esta opção após a criação do conjunto de nós. Para mais informações, consulte VMs do Spot.
  • flex_start: Define o conjunto de nós para usar a opção de consumo flex-start. Não é possível definir como true se spot estiver ativado. O início flexível é suportado na versão 1.33.0-gke.1712000 ou posterior do GKE.

Consola

Para criar um node pool com TPUs:

  1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

    Aceda ao Google Kubernetes Engine

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

  3. Clique em Adicionar conjunto de nós.

  4. Na secção Detalhes do conjunto de nós, selecione a caixa Especificar localizações dos nós.

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

  6. No painel de navegação, clique em Nodes.

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

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

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

  9. No menu pendente Tipo de máquina, selecione o nome da máquina a usar para os nós. Use a tabela Escolha a versão da TPU para saber como definir o tipo de máquina e a topologia da TPU que criam um conjunto de nós de fatia da TPU de host único.

  10. No menu pendente 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 arranque é um Disco persistente padrão ou um Disco persistente SSD.

  13. Opcionalmente, selecione a caixa de verificação Ativar nós em VMs spot para usar VMs spot para os nós no conjunto de nós.

  14. Clique em Criar.

Crie um node pool de fatia de TPU com vários anfitriões

Pode criar um nó de segmento de TPU com vários anfitriões usando a CLI Google Cloud, o Terraform ou a Google Cloud consola.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --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 o seguinte:

  • POOL_NAME: o nome do novo node pool.
  • LOCATION: o nome da zona com base na versão da TPU que quer usar. Para identificar uma localização disponível, consulte o artigo Disponibilidade de TPUs no GKE.
  • CLUSTER_NAME: o nome do cluster.
  • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas onde o GKE cria o conjunto de nós.
  • MACHINE_TYPE: o tipo de máquina a usar para os nós. Para saber mais sobre os tipos de máquinas disponíveis, consulte o artigo Escolha a versão da TPU.

  • TPU_TOPOLOGY: a topologia física da fatia da TPU. O formato da topologia depende da versão da TPU. Para saber mais sobre as topologias de TPUs, use a tabela em Escolha uma topologia.

    Para saber mais, consulte o artigo Topologia.

Opcionalmente, também pode usar as seguintes flags:

  • NUM_NODES: o número de nós no node pool. Tem de ser zero ou o produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada MV. Para a TPU v4 e a TPU v5e com vários anfitriões, o número de chips em cada VM é quatro. Por conseguinte, se o seu TPU_TOPOLOGY for 2x4x4 (TPU v4 com quatro chips em cada VM), o NUM_NODES é 32/4, o que equivale a 8. Se omitir esta flag, o número de nós é calculado e definido por predefinição com base na topologia e no tipo de máquina.
  • RESERVATION_NAME: o nome da reserva que o GKE usa quando cria o conjunto de nós. Se omitir este sinalizador, o GKE usa os conjuntos de nós de fatias de TPU disponíveis. Para saber mais acerca das reservas de TPUs, consulte o artigo Reserva de TPUs.
  • --spot: define o node pool para usar VMs do Spot para os nós da fatia de TPU. Não é possível alterar esta opção após a criação do conjunto de nós. Para mais informações, consulte VMs do Spot.
  • --flex-start: define o conjunto de nós para usar VMs de início flexível. As VMs de início flexível são criadas através da opção de consumo flex-start, que é suportada na versão 1.33.0-gke.1712000 ou posterior do GKE.

  • --enable-autoscaling: crie um node pool com o dimensionamento automático ativado. Quando o GKE dimensiona um conjunto de nós de fatia de TPU com vários anfitriões, dimensiona atomicamente o conjunto de nós de zero para o tamanho máximo.

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

  • --node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: indica ao GKE que o conjunto de nós da fatia de TPU com vários anfitriões é uma coleção. Use esta flag se as seguintes condições se aplicarem:

    • O node pool executa cargas de trabalho de inferência no novo node pool.
    • O conjunto de nós usa a TPU Trillium.
    • As VMs do Spot não suportam o agendamento de recolhas.

    Para saber mais sobre a gestão do agendamento da recolha, consulte o artigo Faça a gestão do agendamento da recolha em fatias de TPU com vários anfitriões.

  • --placement-type=COMPACT: crie um node pool com o posicionamento compacto ativado. Esta opção tem de ser usada com a flag --tpu-topology. Para mais informações, consulte os artigos Crie uma política de posicionamento compacta e Topologia da TPU.

Terraform

  1. Certifique-se de que usa a versão 4.84.0 ou posterior do fornecedor 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]
    }
    spot = true
    flex_start = false
  }

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

    Substitua o seguinte:

    • NODE_POOL_RESOURCE_NAME: o nome do recurso do conjunto de nós no modelo do Terraform.
    • PROJECT_ID: o ID do seu projeto.
    • CLUSTER_NAME: O nome do cluster existente ao qual adicionar o conjunto de nós.
    • POOL_NAME: o nome do node pool a criar.
    • CLUSTER_LOCATION: calcular a localização do cluster. Recomendamos que tenha um cluster regional para uma maior fiabilidade do plano de controlo do Kubernetes. Também pode usar um cluster zonal. Para saber mais, consulte o artigo Selecione uma versão e uma topologia da TPU.
    • NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas onde o GKE cria o conjunto de nós.
    • NUM_NODES: o número de nós no node pool. Tem de ser zero ou o produto do número de chips da TPU dividido por quatro, porque nas fatias de TPU com vários anfitriões, cada nó de fatia de TPU tem 4 chips. Por exemplo, se TPU_TOPOLOGY for 4x8, existem 32 chips, o que significa que NUM_NODES tem de ser 8. Para saber mais sobre as topologias de TPU, use a tabela em Escolha a versão do TPU.
    • TPU_TOPOLOGY: isto indica a topologia física desejada para a fatia da TPU. O formato da topologia depende da versão da TPU que está a usar. Para saber mais sobre as topologias de TPUs, use a tabela em Escolha uma topologia.

    Opcionalmente, também pode usar as seguintes variáveis:

    • RESERVATION_NAME: se usar a reserva de TPU, esta é a lista de etiquetas dos recursos de reserva a usar quando criar o conjunto de nós. Para saber como preencher o campo RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte o fornecedor do Terraform.
    • autoscaling: crie um node pool com o dimensionamento automático ativado. Quando o GKE dimensiona um conjunto de nós de fatia de TPU com vários anfitriões, dimensiona atomicamente o conjunto de nós de zero para o tamanho máximo.
      • MAX_NODES: é o tamanho máximo do node pool. Tem de ser igual ao produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada MV.
    • spot: permite que o node pool use VMs do Spot para os nós de fatia da TPU. Não é possível alterar esta opção após a criação do conjunto de nós. Para mais informações, consulte VMs de spot.
    • flex_start: Define o conjunto de nós para usar a opção de consumo flex-start. Não é possível definir como true se spot estiver ativado.

Consola

Para criar um node pool com TPUs:

  1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

    Aceda ao Google Kubernetes Engine

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

  3. Clique em Adicionar conjunto de nós.

  4. Na secção Detalhes do conjunto de nós, selecione a caixa Especificar localizações dos nós.

  5. Selecione o nome da zona com base na versão da TPU que quer usar. Para identificar uma localização disponível, consulte o artigo Disponibilidade de TPUs no GKE.

  6. No painel de navegação, clique em Nodes.

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

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

    • CT3P: para a TPU v3.
    • CT4P: para a TPU v4.
    • CT5LP: para a TPU v5e.

  9. No menu pendente Tipo de máquina, selecione o nome da máquina a usar para os nós. Use a tabela Escolha a versão do TPU para saber como definir o tipo de máquina e a topologia do TPU que criam um conjunto de nós de fatia do TPU com vários anfitriões.

  10. No menu pendente 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 arranque é um Disco persistente padrão ou um Disco persistente SSD.

  13. Opcionalmente, selecione a caixa de verificação Ativar nós em VMs spot para usar VMs spot para os nós no conjunto de nós.

  14. Clique em Criar.

Como o GKE processa problemas de capacidade

Se o GKE não conseguir criar o seu conjunto de nós de fatia de TPU devido à capacidade de TPU disponível insuficiente, o GKE devolve uma mensagem de erro a indicar que não é possível criar os nós de fatia de TPU devido à falta de capacidade.

Se estiver a criar um node pool de fatia de TPU de anfitrião único, a mensagem de erro é semelhante à seguinte:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Se estiver a criar um node pool de fatia de TPU com vários anfitriões, a mensagem de erro é semelhante a esta:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

O seu pedido de aprovisionamento de TPU pode permanecer na fila durante muito tempo e permanece no estado "Aprovisionamento" enquanto estiver na fila.

Assim que a capacidade estiver disponível, o GKE cria os nós restantes que não foram criados.

Se precisar de capacidade mais cedo, considere experimentar as VMs do Spot, embora as VMs do Spot consumam uma quota diferente das instâncias a pedido.

Pode eliminar o pedido de TPU em fila eliminando o conjunto de nós da fatia de TPU.

Execute a sua carga de trabalho em nós de fatia de TPU

Esta secção explica como preparar as cargas de trabalho e apresenta exemplos de como pode executá-las.

Prepare as suas cargas de trabalho

As cargas de trabalho da TPU têm os seguintes requisitos de preparação.

  1. As frameworks como JAX, PyTorch e TensorFlow acedem às VMs da TPU através da libtpu biblioteca partilhada. libtpu inclui o compilador XLA, o software de tempo de execução da TPU e o controlador da TPU. Cada lançamento do PyTorch e do JAX requer uma determinada versão do libtpu.so. Para evitar conflitos de versões de pacotes, recomendamos que use uma imagem de IA JAX. Para usar TPUs no GKE, certifique-se de que usa as seguintes versões:
    Tipo de TPU libtpu.so versão
    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. Defina as seguintes variáveis de ambiente para o contentor que pede os recursos da TPU:
    • TPU_WORKER_ID: um número inteiro exclusivo para cada Pod. Este ID denota um worker-id exclusivo na fatia de TPU. Os valores suportados para este campo variam entre zero e o número de pods menos um.
    • TPU_WORKER_HOSTNAMES: uma lista separada por vírgulas de nomes de anfitriões de VMs de TPUs ou endereços IP que têm de comunicar entre si na fatia. Deve existir um nome de anfitrião ou um endereço IP para cada VM de TPU na fatia. A lista de endereços IP ou nomes de anfitriões está ordenada e indexada a zero pelo TPU_WORKER_ID.

      • O GKE injeta automaticamente estas variáveis de ambiente através de um webhook de mutação quando é criado um Job com as propriedades completionMode: Indexed, subdomain, parallelism > 1 e de pedido google.com/tpu. O GKE adiciona um serviço sem cabeça para que os registos DNS sejam adicionados para os pods que suportam o serviço.

      Quando implementa recursos multi-anfitrião de TPU com o Kuberay, o GKE fornece um webhook implementável como parte dos modelos do Terraform para executar o Ray no GKE. Pode encontrar instruções para executar o Ray no GKE com TPUs no guia do utilizador de TPUs experimental. O webhook de mutação vai injetar estas variáveis de ambiente em clusters do Ray que pedem propriedades google.com/tpu e um seletor de nós cloud.google.com/gke-tpu-topology multi-host.

    • No manifesto da carga de trabalho, adicione seletores de nós do Kubernetes para garantir que o GKE agenda a carga de trabalho da TPU no tipo de máquina da TPU e na topologia da TPU que definiu:

        nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY

      Substitua o seguinte:

      • TPU_ACCELERATOR: o nome do acelerador de TPU.
      • TPU_TOPOLOGY: a topologia física do segmento da TPU. O formato da topologia depende da versão da TPU. Para saber mais, consulte o artigo Planeie TPUs no GKE.

Depois de concluir a preparação da carga de trabalho, pode executar uma tarefa que use TPUs.

As secções seguintes mostram exemplos de como executar uma tarefa que realiza cálculos básicos com as TPUs.

Exemplo 1: execute uma carga de trabalho que apresente o número de chips de TPU disponíveis num conjunto de nós de uma fatia de TPU

A carga de trabalho seguinte devolve o número de chips de TPU em todos os nós numa fatia de TPU de vários anfitriões. Para criar uma fatia com vários anfitriões, a carga de trabalho tem os seguintes parâmetros:

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

Esta seleção de versão e topologia resulta numa fatia com vários anfitriões.

  1. Guarde 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. Implemente o manifesto: 
    kubectl create -f available-chips-multihost.yaml

    O GKE executa uma fatia de TPU v4 com quatro VMs (fatia de TPU multi-host). A fatia tem 16 chips de TPU interligados.

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

    O resultado é semelhante ao seguinte:

    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. Obtenha os registos 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 é semelhante ao seguinte: 

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

Exemplo 2: execute uma carga de trabalho que apresente o número de chips de TPU disponíveis na fatia de TPU

A seguinte carga de trabalho é um pod estático que apresenta o número de chips de TPU associados a um nó específico. Para criar um nó de anfitrião único, a carga de trabalho tem os seguintes parâmetros:

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

Esta seleção de versão e topologia resulta numa fatia de anfitrião único.

  1. Guarde 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. Implemente o manifesto: 
    kubectl create -f available-chips-singlehost.yaml

    O GKE aprovisiona nós com oito fatias de TPU de anfitrião único que usam a TPU v5e. Cada nó da TPU tem 8 chips de TPU (segmento de TPU de anfitrião único).

  3. Obtenha os registos do Pod: 
    kubectl logs tpu-job-jax-v5

    O resultado é semelhante ao seguinte: 

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

Atualize node pools com aceleradores (GPUs e TPUs)

O GKE atualiza automaticamente os clusters padrão, incluindo os conjuntos de nós. Também pode atualizar manualmente os conjuntos de nós se quiser que os seus nós tenham uma versão mais recente mais cedo. Para controlar o funcionamento das atualizações para o seu cluster, use canais de lançamento, janelas de manutenção e exclusões e sequenciação da implementação.

Também pode configurar uma estratégia de atualização de nós para o seu conjunto de nós, como atualizações rápidas, atualizações azul-verde ou atualizações de curta duração. Ao configurar estas estratégias, pode garantir que os conjuntos de nós são atualizados de forma a alcançar o equilíbrio ideal entre velocidade e interrupção para o seu ambiente. Para pools de nós de fatias de TPU com vários anfitriões, em vez de usar a estratégia de atualização de nós configurada, o GKE recria atomicamente todo o pool de nós num único passo. Para saber mais, consulte a definição de atomicidade na terminologia relacionada com a TPU no GKE.

A utilização de uma estratégia de atualização de nós requer temporariamente que o GKE faculte recursos adicionais, consoante a configuração. Se o Google Cloud tiver capacidade limitada para os recursos do seu conjunto de nós, por exemplo, se vir erros de disponibilidade de recursos ao tentar criar mais nós com GPUs ou TPUs, consulte o artigo Atualize num ambiente com restrições de recursos.

Limpar

Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste guia, pondere eliminar os conjuntos de nós de fatia de TPU que já não têm cargas de trabalho agendadas. Se as cargas de trabalho em execução tiverem de ser terminadas corretamente, use kubectl drain para limpar as cargas de trabalho antes de eliminar o nó.

  1. Elimine um node pool de fatia de TPU:

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

    Substitua o seguinte:

    • POOL_NAME: o nome do node pool.
    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a localização de computação do cluster.

Configure definições adicionais

As secções seguintes descrevem as configurações adicionais que pode aplicar às suas cargas de trabalho de TPUs.

Faça a gestão da programação da recolha

Na TPU Trillium, pode usar a programação da recolha para agrupar nós de fatias de TPU. O agrupamento destes nós de fatias de TPU facilita o ajuste do número de réplicas para satisfazer a procura da carga de trabalho.O Google Cloud controla as atualizações de software para garantir que existem sempre fatias suficientes na coleção para publicar tráfego.

O TPU Trillium suporta o agendamento da recolha para pools de nós de anfitrião único e vários anfitriões que executam cargas de trabalho de inferência. A seguir, descreve-se como o comportamento do agendamento da recolha depende do tipo de fatia de TPU que usa:

  • Segmento de TPU com vários anfitriões: o GKE agrupa segmentos de TPU com vários anfitriões para formar uma coleção. Cada GKE node pool é uma réplica nesta coleção. Para definir uma coleção, crie uma fatia de TPU com vários anfitriões e atribua um nome exclusivo à coleção. Para adicionar mais fatias de TPU à coleção, crie outro conjunto de nós de fatias de TPU multi-anfitrião com o mesmo nome da coleção e tipo de carga de trabalho.
  • Segmento de TPU de anfitrião único: o GKE considera o conjunto de nós do segmento de TPU de anfitrião único como uma coleção. Para adicionar mais fatias de TPU à coleção, pode redimensionar o conjunto de nós de fatias de TPU de anfitrião único.

Para gerir uma coleção, execute qualquer uma destas ações com base no tipo de conjunto de nós que usa.

Faça a gestão do agendamento da recolha em pools de nós de segmentação de TPUs multi-anfitrião

Use as seguintes tarefas para gerir pools de nós de fatia de TPU com vários anfitriões.

  • Para verificar se um conjunto de fatias de TPU com vários anfitriões 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 é semelhante ao seguinte:

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

    Se o conjunto de fatias de TPU multi-host fizer parte de uma coleção, o resultado tem as seguintes etiquetas:

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

  • Para ver 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 é semelhante ao seguinte:

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

  • Para obter uma lista de conjuntos 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 é semelhante ao seguinte:

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

  • Para aumentar a escala da coleção, crie outro node pool de fatia de TPU com vários anfitriões e adicione os parâmetros cloud.google.com/gke-workload-type e cloud.google.com/gke-nodepool-group-name. Use o mesmo nome da coleção em cloud.google.com/gke-nodepool-group-name e execute o mesmo tipo de carga de trabalho. Se o aprovisionamento automático de nós estiver ativado no cluster, o GKE cria automaticamente pools com base nas exigências da carga de trabalho.

  • Para reduzir a escala da coleção, elimine o node pool.

  • Para eliminar a coleção, remova todos os conjuntos de nós anexados. Pode eliminar o conjunto de nós ou eliminar o cluster. A eliminação do cluster remove todas as coleções que este contém.

Faça a gestão do agendamento da recolha em pools de nós de fatias de TPUs de anfitrião único

Use as seguintes tarefas para gerir node pools de fatias de TPUs de host único.

  • Para verificar se um conjunto de fatias de TPU de host único tem o agendamento de recolha 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 é semelhante ao seguinte:

    gke-workload-type: HIGH_AVAILABILITY

    Se o conjunto de fatias de TPU de host único fizer parte de uma coleção, o resultado tem a etiqueta cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

  • Para aumentar a escala da recolha, redimensione o conjunto de nós manualmente ou automaticamente com o aprovisionamento automático de nós.

  • Para reduzir a escala da coleção, elimine o node pool.

  • Para eliminar a coleção, remova todos os conjuntos de nós anexados. Pode eliminar o conjunto de nós ou eliminar o cluster. A eliminação do cluster remove todas as coleções no mesmo.

Use a funcionalidade de vários cortes

Pode agregar fatias mais pequenas num conjunto de várias fatias para processar cargas de trabalho de treino maiores. Para mais informações, consulte o artigo TPUs de várias fatias no GKE.

Migre a sua reserva de TPU

Se tiver reservas de TPUs existentes, tem de migrar a sua reserva de TPUs para um novo sistema de reservas baseado no Compute Engine. Também pode criar um sistema de reservas baseado no Compute Engine onde não é necessária migração. Para saber como migrar as suas reservas de TPUs, consulte o artigo Reserva de TPUs.

Ative o registo

Os registos emitidos por contentores em execução em nós do GKE, incluindo VMs de TPU, são recolhidos pelo agente de registo do GKE, enviados para o Logging e são visíveis no Logging.

Use o aprovisionamento automático de nós do GKE

Pode configurar o GKE para criar e eliminar automaticamente pools de nós de modo a satisfazer as exigências de recursos das suas cargas de trabalho de TPU. Para mais informações, consulte o artigo Configurar as TPUs na nuvem.

Aprovisione TPUs com classes de computação personalizadas

Também pode configurar o GKE para pedir TPUs durante as operações de escalabilidade que criam novos nós através de classes de computação personalizadas.

Pode especificar opções de configuração da TPU na especificação da classe de computação personalizada. Quando uma carga de trabalho do GKE usa essa classe de computação personalizada, o GKE tenta aprovisionar TPUs que usam a configuração especificada durante o aumento da escala.

Para aprovisionar TPUs com uma classe de computação personalizada que siga as regras de TPU e implementar a carga de trabalho, conclua os seguintes passos:

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

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - spot: true
    tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - flexStart:
      enabled: true
    tpu:
      type: tpu-v6e-slice
      count: 4
      topology: 2x4
  nodePoolAutoCreation:
    enabled: true

  2. Implemente a classe de computação:

    kubectl apply -f tpu-compute-class.yaml

    Para mais informações sobre as classes de computação personalizadas e as TPUs, consulte a secção Configuração da TPU.

  3. Guarde 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 o seguinte:

    • NUMBER_OF_CHIPS: o número de chips de TPU que o contentor vai usar. Tem de ser o mesmo valor para limits e requests, igual ao valor no campo tpu.count na classe de computação 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 usa. Para saber mais, consulte o artigo Valores mínimos e máximos para aceleradores.
    • NUMBER_OF_CHIPS: o número de chips de TPU que o contentor vai usar. Tem de ser o mesmo valor para limits e requests.

  4. Implemente a tarefa:

    kubectl create -f tpu-job.yaml

    Quando cria esta tarefa, o GKE faz automaticamente o seguinte:

    • Aprovisiona nós para executar os pods. Consoante o tipo de TPU, a topologia e os pedidos de recursos que especificou, estes nós são fatias de host único ou fatias de vários hosts. Consoante a disponibilidade de recursos de TPU na prioridade máxima, o GKE pode recorrer a prioridades mais baixas para maximizar a obtenção.
    • Adiciona restrições aos pods e tolerâncias aos nós para impedir que quaisquer outras cargas de trabalho sejam executadas nos mesmos nós que as cargas de trabalho da TPU.

    Para saber mais, consulte o artigo Acerca das classes de computação personalizadas.

  5. Quando terminar esta secção, pode evitar a faturação contínua eliminando os recursos que criou:

    kubectl delete -f tpu-job.yaml

Configure a reparação automática para nós de fatia de TPU

Se um nó de fatia de TPU num conjunto de nós de fatia de TPU com vários anfitriões não estiver em bom estado, todo o conjunto de nós é recriado. Por outro lado, num conjunto de nós de parte da TPU de anfitrião único, apenas o nó da TPU não saudável é reparado automaticamente.

As condições que resultam em nós de fatia de TPU não saudáveis incluem o seguinte:

  • Qualquer nó de fatia da TPU com condições de nó comuns.
  • Qualquer nó de fatia da TPU com uma quantidade de TPUs não atribuíveis superior a zero.
  • Qualquer instância de VM numa fatia de TPU que esteja parada (devido à preempção) ou terminada.
  • Manutenção de nós: se qualquer nó de fatia de TPU num conjunto de nós de fatia de TPU com vários anfitriões ficar inativo para manutenção do anfitrião, o GKE recria todo o conjunto de nós de fatia de TPU.

Pode ver o estado da reparação (incluindo o motivo da falha) no histórico de operações. Se a falha for causada por uma quota insuficiente, contacte o seu Google Cloud representante da conta para aumentar a quota correspondente.

Configure o encerramento elegante para nós de fatia de TPU

Nos clusters do GKE com o plano de controlo a executar a versão 1.29.1-gke.1425000 ou posterior, os nós de fatia da TPU suportam sinais SIGTERM que alertam o nó para um encerramento iminente. A notificação de encerramento iminente é configurável até cinco minutos nos nós da TPU.

Para configurar o GKE de modo a terminar as suas cargas de trabalho normalmente dentro deste período de notificação, siga os passos em Gerir a interrupção de nós do GKE para GPUs e TPUs.

Execute contentores sem o modo privilegiado

Os contentores executados em nós na versão 1.28 ou posterior do GKE não precisam de ter o modo privilegiado ativado para aceder às TPUs. Os nós na versão 1.28 e anteriores do GKE requerem o modo privilegiado.

Se o nó da fatia da TPU estiver a executar versões inferiores a 1.28, leia a secção seguinte:

Um contentor executado numa VM numa fatia de TPU precisa de acesso a limites mais elevados na memória bloqueada para que o controlador possa comunicar com os chips da TPU através do acesso direto à memória (DMA). Para ativar esta opção, tem de configurar um valor ulimit mais elevado. Se quiser reduzir o âmbito das autorizações no seu contentor, conclua os seguintes passos:

  1. Edite o securityContext para incluir os seguintes campos:

    securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

  2. Aumente o valor de ulimit executando o seguinte comando no contentor antes de configurar as cargas de trabalho para usar recursos de TPU:

    ulimit -l 68719476736

Para a TPU v5e, a execução de contentores sem modo privilegiado está disponível em clusters na versão 1.27.4-gke.900 e posterior.

Observabilidade e métricas

Painel de controlo

A observabilidade do conjunto de nós na Google Cloud consola está disponível de forma geral. Para ver o estado dos seus pools de nós multi-host do TPU no GKE, aceda ao painel de controlo Estado do pool de nós do GKE TPU fornecido pelo Cloud Monitoring:

Aceda ao estado do conjunto de nós da TPU do GKE

Este painel de controlo oferece estatísticas abrangentes sobre o estado dos seus conjuntos de nós de TPU com vários anfitriões. Para mais informações, consulte o artigo Monitorize as métricas de saúde dos nós e dos conjuntos de nós da TPU.

Na página Clusters do Kubernetes na Google Cloud consola, o separador Observabilidade também apresenta métricas de observabilidade da TPU, como a utilização da TPU, no cabeçalho Aceleradores > TPU. Para mais informações, consulte o artigo Veja métricas de observabilidade.

O painel de controlo da TPU só é preenchido se tiver as métricas do sistema ativadas no cluster do GKE.

Métricas de tempo de execução

Na versão 1.27.4-gke.900 ou posterior do GKE, as cargas de trabalho de TPU que usam a versão 0.4.14 ou posterior do JAX e especificam containerPort: 8431 exportam 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 monitorizar o desempenho de tempo de execução da sua carga de trabalho de TPU:

  • Ciclo de trabalho: percentagem de tempo durante o período de amostragem anterior (60 segundos) em que os TensorCores estavam a processar ativamente num chip da TPU. Uma percentagem maior significa uma melhor utilização da TPU.
  • Memória usada: quantidade de memória do acelerador atribuída em bytes. Amostrada a cada 60 segundos.
  • Memory total: memória total do acelerador em bytes. Amostrada a cada 60 segundos.

Estas métricas encontram-se no esquema do nó do Kubernetes (k8s_node) e do contentor do Kubernetes (k8s_container).

Contentor 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

Monitorize as Métricas de Saúde para nós e conjuntos de nós da TPU

Quando uma tarefa de preparação tem um erro ou termina com falhas, pode verificar as métricas relacionadas com a infraestrutura subjacente para determinar se a interrupção foi causada por um problema com o nó ou o conjunto de nós subjacente.

Estado do nó

Na versão 1.32.1-gke.1357001 ou posterior do GKE, 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 comunica as condições no nó, como Ready, DiskPressure e MemoryPressure. O campo status mostra o estado comunicado da condição, que pode ser True, False ou Unknown. Esta é uma métrica com o k8s_node tipo de recurso monitorizado.

Esta 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 num cluster, pode querer analisar 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"}

É recomendável 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 existirem dados, os nós estão prontos. A condição de estado é amostrada a cada 60 segundos.

Pode usar a seguinte consulta para compreender o estado do nó na frota:

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

Estado do node pool

A seguinte métrica do sistema do GKE para o recurso monitorizado k8s_node_pool expõe o estado de um conjunto de nós do GKE:

  • kubernetes.io/node_pool/status

Esta métrica só é comunicada para pools de nós de TPU com vários anfitriões.

O campo status comunica o estado do conjunto de nós, como Provisioning, Running, Error, Reconciling ou Stopping. As atualizações de estado ocorrem após a conclusão das operações da API GKE.

Para verificar se um pool de nós específico tem o estado Running, use a seguinte consulta PromQL:

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

Para monitorizar o número de pools de nós no seu projeto agrupados pelo respetivo estado, use a seguinte consulta PromQL:

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

Disponibilidade do node pool

A seguinte métrica do sistema do GKE mostra se um conjunto de nós de TPU com vários anfitriões está disponível:

  • kubernetes.io/node_pool/multi_host/available

A métrica tem um valor de True se todos os nós no conjunto 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 TPUs multi-host 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}]))

Número de interrupções de nós

A seguinte métrica do sistema do GKE comunica 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 indicar o motivo pelo qual um nó foi interrompido.

Para obter uma discriminação das interrupções e das respetivas causas nos nós de TPU nos clusters no seu projeto, use a seguinte consulta 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 anfitrião, atualize a consulta para filtrar o valor HW/SW Maintenance para o 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 conjunto de nós, use a seguinte consulta 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 node pool

Os seguintes relatórios de métricas do sistema do GKE mostram a distribuição das durações do período de recuperação para pools de nós de TPU multi-host do GKE:

  • kubernetes.io/node_pool/accelerator/times_to_recover

Cada amostra registada nesta métrica indica um único evento de recuperação para o conjunto de nós a partir de um período de inatividade.

Esta métrica é útil para monitorizar o tempo de recuperação do conjunto de nós de TPU com vários anfitriões e o tempo entre interrupções.

Pode usar a seguinte consulta PromQL para calcular o tempo médio de recuperação (MTTR) dos últimos 7 dias no seu 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 node pool

O tempo de pool de nós entre interrupções mede o tempo de execução da sua infraestrutura antes de sofrer uma interrupção. É calculado como a média num período, em que o numerador mede o tempo total em que a sua infraestrutura esteve disponível e o denominador mede as interrupções totais da sua infraestrutura.

O exemplo de PromQL seguinte mostra o tempo médio de 7 dias entre interrupções (MTBI) 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 do anfitrião

Na versão 1.28.1-gke.1066000 ou posterior do GKE, as VMs numa fatia de TPU exportam 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 monitorizar o desempenho do seu anfitrião de TPU:

  • Utilização do TensorCore: percentagem atual do TensorCore que está a ser usado. O valor do TensorCore é igual à soma das unidades de multiplicação de matrizes (MXUs) mais a unidade vetorial. O valor de utilização do TensorCore é a divisão das operações do TensorCore que foram realizadas durante o período de amostragem anterior (60 segundos) pelo número suportado de operações do TensorCore durante o mesmo período. Um valor mais elevado significa uma melhor utilização.
  • Utilização da largura de banda da memória: percentagem atual da largura de banda da memória do acelerador que está a ser usada. Calculado dividindo a largura de banda da memória usada durante um período de amostragem (60 s) pela largura de banda máxima suportada durante o mesmo período de amostragem.

Estas métricas encontram-se no esquema do nó do Kubernetes (k8s_node) e do contentor do Kubernetes (k8s_container).

Contentor 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 os artigos Métricas do Kubernetes e Métricas do sistema do GKE.

Problemas conhecidos

  • O escalador automático de clusters pode calcular incorretamente a capacidade dos novos nós de fatias de TPU antes de esses nós comunicarem as TPUs disponíveis. O redimensionador automático de clusters pode, então, realizar um aumento da escala adicional e, como resultado, criar mais nós do que o necessário. O redimensionador automático de clusters reduz o número de nós adicionais, se não forem necessários, após a operação de redução regular.
  • O escalador automático do cluster cancela o aumento da escala dos node pools de fatias de TPU que permanecem no estado de espera durante mais de 10 horas. O redimensionador automático de clusters tenta novamente essas operações de aumento da escala mais tarde. Este comportamento pode reduzir a obtenção de UTPs para clientes que não usam reservas.
  • As cargas de trabalho não TPU que tenham uma tolerância para a contaminação da TPU podem impedir a redução do número de nós do conjunto de nós se estiverem a ser recriadas durante a drenagem do conjunto de nós da fatia de TPU.
  • A métrica de utilização da largura de banda da memória não está disponível para as TPUs v5e.

O que se segue?