Configure a rede automatizada para VMs com acelerador

Este documento mostra como usar a rede automatizada para VMs com acelerador, como GPUs e TPUs, para simplificar a configuração de rede para cargas de trabalho com acelerador do Google Kubernetes Engine (GKE). Isto é essencial para executar inteligência artificial (IA), aprendizagem automática (AA) e computação de elevado desempenho (HPC) em máquinas otimizadas para aceleradores.

Este documento pressupõe familiaridade com os conceitos fundamentais do GKE, as cargas de trabalho de GPU e TPU, e a rede VPC. Em concreto, deve conhecer:

Esta página destina-se a arquitetos da nuvem e especialistas em redes que concebem e arquitetam a rede da respetiva organização. Para uma vista geral de todos os conjuntos de documentação do GKE, consulte o artigo Explore a documentação do GKE. Para saber mais sobre as funções comuns e as tarefas de exemplo referenciadas no Google Cloud conteúdo, consulte Funções e tarefas de utilizador comuns do GKE.

O GKE simplifica a execução de IA e ML de alto desempenho em aceleradores especializados. Com a rede automatizada para VMs com acelerador, pode ativar a conectividade de alta velocidade e com várias redes, essencial para protocolos como o RDMA, com um único indicador de configuração. Esta automatização elimina o processo manual complexo de configurar várias redes VPC, gerir intervalos de endereços IP e configurar interfaces de rede para cada conjunto de nós e Pod. Quando usa um único parâmetro para criar um conjunto de nós, o GKE fornece todos os recursos de rede do Kubernetes e da nuvem necessários.

Terminologia

Os seguintes termos são essenciais para compreender a arquitetura de rede das VMs com acelerador.

  • Nuvem virtual privada (VPC): uma VPC é uma versão virtual de uma rede física, implementada na rede de produção da Google. Fornece conetividade para as instâncias de máquinas virtuais (VMs) do Compute Engine, os clusters do GKE e outros recursos.
  • NIC Titanium: uma NIC inteligente que transfere tarefas de processamento de rede da CPU, libertando a CPU para se concentrar nas suas cargas de trabalho. Em máquinas com GPU, processam todo o tráfego que não seja comunicação direta entre GPUs. Nas máquinas de TPU, todas as NICs são NICs Titanium.
  • Sub-rede: uma sub-rede é uma parte segmentada de uma VPC maior. Cada sub-rede está associada a uma região e tem um intervalo de endereços IP definido.
  • Controlador de interface de rede (NIC): um NIC é uma interface de rede virtual que liga uma instância de VM a uma rede. Cada NIC está anexada a uma VPC e uma sub-rede específicas.
  • Rede anfitriã: a rede principal usada pelas interfaces de rede (NICs) principais do nó para comunicação geral do cluster, como tráfego do plano de controlo e rede de pods normal.
  • Rede de dados: uma rede dedicada para transferência de dados de elevado desempenho entre VMs de aceleradores. Para GPUs, trata-se frequentemente de um GPUDirect VPC com RDMA. Para as TPUs, esta pode ser uma segunda rede de anfitriões.
  • Acesso direto à memória remoto(RDMA): O RDMA é uma tecnologia que permite que os dispositivos de rede troquem dados diretamente com a memória principal de um computador sem envolver o sistema operativo nem a CPU. Isto reduz significativamente a latência e melhora o débito, o que é fundamental para cargas de trabalho de HPC e ML.
  • NVLink: NVLink é uma tecnologia de interconexão de alta velocidade desenvolvida pela NVIDIA para ligar várias GPUs num único nó, o que lhes permite partilhar memória e trabalhar em conjunto em grandes conjuntos de dados.
  • Atribuição dinâmica de recursos (DRA) do Kubernetes: a DRA é uma funcionalidade do Kubernetes que oferece uma forma mais flexível para os pods pedirem e consumirem recursos, como GPUs e outro hardware especializado. Permite um controlo detalhado da atribuição de recursos.

Como funciona a rede automatizada

As máquinas otimizadas para aceleradores têm uma arquitetura de rede especializada para suportar a comunicação de alto débito e baixa latência entre GPUs e TPUs. Cada máquina física contém várias GPUs ou TPUs, frequentemente ligadas por interconexões de alta velocidade, como o NVLink. As máquinas também têm uma ou mais NICs para rede geral e várias NICs de GPU para interconexões de alta velocidade.

Quando cria um nó do GKE que usa um tipo de máquina otimizado para aceleradores, o GKE configura várias NICs na VM subjacente. As NICs do anfitrião ligam-se às redes VPC do anfitrião para a comunicação e a gestão gerais do cluster, de modo a comunicar com o plano de controlo. As NICs de GPU ligam-se a uma rede VPC dedicada de alto desempenho, muitas vezes com RDMA ativado e uma definição de MTU elevada (8896), para facilitar a comunicação GPUDirect.

Quando um Pod pede GPUs ou TPUs, pode configurá-lo para aceder às interfaces de rede de alto desempenho no nó. Pode pedir todas as NICs disponíveis ou um subconjunto específico. Cada interface de rede reivindicada é dedicada a um único Pod e não é partilhada. Esta configuração de rede garante que o agrupamento tem acesso exclusivo à largura de banda total e aos recursos dessa interface, uma vantagem fundamental para cargas de trabalho sensíveis ao desempenho.

Limitações

  • A rede automatizada para VMs de acelerador não é suportada em clusters do Autopilot.
  • A rede automatizada requer que o cluster use o GKE Dataplane V2.
  • Tipos de máquinas suportados: as redes automatizadas são suportadas nas famílias de máquinas A3, A4 e TPU Trillium (v6e) otimizadas para aceleradores.
  • Node pools de zona única obrigatórios: tem de usar um node pool com uma única zona.
  • Quando usar o DRANET gerido do GKE para configurar cargas de trabalho, consulte as principais considerações e as limitações do DRANET gerido do GKE.
  • Não pode usar a API de várias redes e a DRANET no mesmo conjunto de nós. Tem de escolher um método de anexo de rede para os seus agrupamentos.

Configurações de rede de máquinas otimizadas pelo acelerador

As máquinas otimizadas para aceleradores têm configurações de rede variáveis consoante o respetivo tipo. A tabela seguinte resume as especificações de rede para vários tipos de máquinas.

VMs com acelerador de GPU

Tipo de máquina Número de GPUs Número de NICs Titanium Número de NICs de GPU Tecnologia GPUDirect VPCs adicionais
A3 8 (H100) 1 4 TCPX 4 para NICs de GPU
A3 Mega 8 (H100) 1 8 TCPXO 8 para NICs de GPU
A3 Ultra 8 (H200) 2 8 RDMA 2 (1 para a segunda NIC, 1 para as NICs da GPU)
A4 8 (B200) 2 8 RDMA 2 (1 para a segunda NIC, 1 para as NICs da GPU)
A4X 4 (GB200) 1 4 RDMA 2 (1 para a segunda NIC, 1 para as NICs da GPU)

VMs com acelerador de TPU

Tipo de máquina Número de chips de TPU Número de NICs VPCs adicionais
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 para a 2.ª NIC e 1 para a VNIC adicional na 1.ª NIC)

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 CLI gcloud. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

  • Certifique-se de que o cluster usa a versão 1.34.1-gke.1829001 ou posterior do GKE.

  • Certifique-se de que o cluster tem o GKE Dataplane V2. Pode ativar esta funcionalidade quando cria um novo cluster ou atualiza um existente.

    • Crie um novo cluster:

      gcloud container clusters create CLUSTER_NAME \
  --cluster-version=CLUSTER_VERSION \
  --enable-dataplane-v2

      Substitua o seguinte:

      • CLUSTER_NAME: o nome do novo cluster.
      • CLUSTER_VERSION: a versão do cluster tem de ser 1.34.1-gke.1829001 ou posterior.

    • Atualize um cluster existente:

      gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2

      Substitua CLUSTER_NAME pelo nome do seu cluster.

  • Se planeia implementar cargas de trabalho de GPU que usam RDMA, verifique a existência dos recursos DeviceClass:

    kubectl get deviceclass mrdma.google.com

Crie um node pool com um perfil de rede predefinido

Para criar automaticamente uma rede que ligue todas as máquinas com GPUs ou TPUs numa única zona, crie um conjunto de nós com o perfil de autorede de aceleradores.

gcloud

Para criar um conjunto de nós com um perfil de rede configurado automaticamente, execute o seguinte comando:

gcloud beta container node-pools create NODE_POOL_NAME \
    --accelerator-network-profile=auto \
    --node-locations=ZONE \
    --machine-type=MACHINE_TYPE

Para mais informações sobre a criação de pools de nós com aceleradores, consulte os artigos Execute GPUs em pools de nós do Autopilot e Implemente cargas de trabalho de TPU no Autopilot. Quando seguir as instruções nestes documentos, acrescente a flag --accelerator-network-profile=auto ao comando gcloud container node-pools create.

Para pools de nós de fatias de TPUs com vários anfitriões, também tem de adicionar a flag --tpu-topology.

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do novo node pool.
  • ZONE: a zona do node pool.
  • MACHINE_TYPE: o tipo de máquina dos nós, por exemplo, a3-ultragpu-8g.

REST

Num pedido ao método nodePools.create, especifique o campo accelerator_network_profile:

{
  "nodePool": {
    "name": "NODE_POOL_NAME",
    "machineType": "MACHINE_TYPE",
    ...
    "accelerator_network_profile": "auto"
  }
}

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do novo node pool.
  • MACHINE_TYPE: o tipo de máquina dos nós, por exemplo, a3-ultragpu-8g.

Agende uma carga de trabalho que use GPUs

As secções seguintes mostram como configurar um conjunto de nós de GPU e uma carga de trabalho para usar interfaces de rede RDMA com o DRANET gerido pelo GKE. Para mais detalhes, consulte o artigo Atribua recursos de rede através do DRANET gerido do GKE.

Ative o controlador DRANET gerido do GKE num pool de nós de GPU

Para ativar o controlador GKE DRANET num conjunto de nós de GPU que suporte RDMA, adicione a etiqueta cloud.google.com/gke-networking-dra-driver=true quando criar o conjunto de nós.

gcloud beta container node-pools create NODE_POOL_NAME \
  --region=REGION \
  --cluster=CLUSTER_NAME \
  --node-locations=NODE_LOCATIONS \
  --accelerator type=ACCELERATOR_TYPE,count=ACCELERATOR_COUNT,gpu-driver-version=DRIVER_VERSION \
  --machine-type=MACHINE_TYPE \
  --num-nodes=NUM_NODES \
  --reservation-affinity=specific \
  --reservation=projects/RESERVATION_PROJECT/reservations/RESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK \
  --accelerator-network-profile=auto \
  --node-labels=cloud.google.com/gke-networking-dra-driver=true

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do novo node pool.
  • REGION: a Google Cloud região do seu cluster.
  • CLUSTER_NAME: o nome do seu cluster.

  • ACCELERATOR_TYPE: o tipo de acelerador de GPU:

    Por exemplo:

    • VMs A4: introduza nvidia-b200.
    • VMs A3 Ultra: introduza nvidia-h200-141gb.

  • ACCELERATOR_COUNT: o número de GPUs a associar aos nós no node pool. Por exemplo, para as VMs a4-highgpu-8g e a3-ultragpu-8g, a quantidade de GPUs é 8.

  • DRIVER_VERSION: a versão do controlador da GPU a usar. Por exemplo, default ou latest.

  • MACHINE_TYPE: o tipo de máquina do node pool, por exemplo, a3-ultragpu-8g.

  • NUM_NODES: o número de nós para o node pool. Para o início flexível, este valor tem de ser definido como 0.

  • RESERVATION_PROJECT: o ID do projeto da reserva.

  • RESERVATION_NAME: o nome da sua reserva. Para encontrar este valor, consulte o artigo Veja pedidos de reserva futuros.

  • RESERVATION_BLOCK: o nome de um bloco específico na reserva. Para encontrar este valor, consulte o artigo Veja pedidos de reserva futuros.

Este comando usa perfis de rede de aceleradores para configurar automaticamente redes VPC e sub-redes para as suas VMs de acelerador. Em alternativa, pode especificar explicitamente a sua rede de VPC e sub-redes.

Implemente recursos RDMA de uma carga de trabalho

Para atribuir recursos RDMA a um pod, especifique um ResourceClaimTemplate.

  1. Crie um ResourceClaimTemplate para definir como atribuir os dispositivos RDMA. O seguinte manifesto pede todos os dispositivos mrdma disponíveis no nó. Guarde o manifesto como all-mrdma-template.yaml:

    apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: all-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: All

  2. Aplique o manifesto:

    kubectl apply -f all-mrdma-template.yaml

  3. Implemente a sua carga de trabalho e consulte o ResourceClaimTemplate. O manifesto seguinte implementa um Pod que faz referência ao modelo all-mrdma, o que concede ao Pod acesso às interfaces RDMA no nó. Guarde o manifesto como agnhost-rdma-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: agnhost-rdma
  namespace: default
  labels:
    app: agnhost
spec:
  containers:
  - name: agnhost
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    args: ["netexec", "--http-port", "80"]
    ports:
    - name: agnhost-port
      containerPort: 80
    resources:
      claims:
      - name: rdma
      limits:
        nvidia.com/gpu: 1
  resourceClaims:
  - name: rdma
    resourceClaimTemplateName: all-mrdma

  4. Aplique o manifesto:

    kubectl apply -f agnhost-rdma-pod.yaml

  5. Verifique se as interfaces de rede adicionais atribuídas estão visíveis no Pod.

    kubectl exec agnhost-rdma -- ls /sys/class/net

    O exemplo de saída seguinte mostra as interfaces eth0 e lo predefinidas, bem como as interfaces RDMA atribuídas, como gpu0rdma0. O número e os nomes das interfaces de rede (NICs) variam consoante o tipo de máquina do nó do GKE.

    eth0
gpu0rdma0
gpu1rdma0
gpu2rdma0
gpu3rdma0
lo

Agende uma carga de trabalho que use TPUs

As secções seguintes mostram como configurar um conjunto de nós de TPU e uma carga de trabalho para usar interfaces de rede não RDMA com o DRANET gerido pelo GKE. Para mais detalhes, consulte o artigo Atribua recursos de rede através do DRANET gerido do GKE.

Valide as DeviceClasses de rede

Verifique se os recursos de DeviceClass rede existem no seu cluster.

kubectl get deviceclass netdev.google.com

O resultado é semelhante ao seguinte:

NAME                AGE
netdev.google.com   2d22h

Ative o controlador DRANET gerido pelo GKE num conjunto de nós de fatia de TPU

Para ativar o controlador DRANET do GKE ao criar um conjunto de nós de fatia de TPU, adicione a etiqueta cloud.google.com/gke-networking-dra-driver=true.

gcloud beta container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_LOCATIONS \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do novo node pool.
  • LOCATION: a Google Cloud região ou a zona do seu cluster.
  • CLUSTER_NAME: o nome do seu cluster.
  • NODE_LOCATIONS: as Google Cloud zonas dos nós no node pool.
  • 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, consulte o artigo Escolha a versão da TPU.
  • TPU_TOPOLOGY: a topologia da TPU, por exemplo, 2x4x4. O formato da topologia depende da versão da TPU. Para saber mais sobre as topologias de TPUs, consulte o artigo Escolha uma topologia.
  • NUM_NODES: o número de nós no node pool.

Para mais informações, consulte o artigo Crie um conjunto de nós de fatia de TPU de host único.

Implemente uma carga de trabalho que reivindique todos os dispositivos de rede

Para atribuir dispositivos de rede não RDMA a um pod, especifique um ResourceClaimTemplate.

  1. Crie um ResourceClaimTemplate que faça referência ao netdev.google.com DeviceClass. O manifesto seguinte pede todos os dispositivos de rede não RDMA disponíveis no nó.

    Guarde o manifesto como all-netdev-template.yaml:

    apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: all-netdev
spec:
  spec:
    devices:
      requests:
      - name: req-netdev
        exactly:
          deviceClassName: netdev.google.com
          allocationMode: All

  2. Aplique o manifesto:

    kubectl apply -f all-netdev-template.yaml

  3. Implemente a sua carga de trabalho e consulte o ResourceClaimTemplate. O manifesto seguinte implementa um pod que usa o modelo all-netdev para conceder ao pod acesso a todos os dispositivos de rede não RDMA no nó. Guarde o manifesto como netdev-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: agnhost-netdev
  namespace: default
  labels:
    app: agnhost
spec:
  containers:
  - name: agnhost
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    args: ["netexec", "--http-port", "80"]
    ports:
    - name: agnhost-port
      containerPort: 80
    resources:
      claims:
      - name: netdev
      limits:
        google.com/tpu: 4
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  resourceClaims:
  - name: netdev
    resourceClaimTemplateName: all-netdev

    Substitua o seguinte:

    • TPU_ACCELERATOR: o tipo de acelerador de TPU, por exemplo, tpu-v5p-slice.
    • TPU_TOPOLOGY: a topologia da TPU, por exemplo, 2x4x4.

  4. Aplique o manifesto:

    kubectl apply -f netdev-pod.yaml

  5. Verifique se as interfaces de rede adicionais atribuídas estão visíveis no Pod.

    kubectl exec agnhost-netdev -- ls /sys/class/net

    O exemplo de saída seguinte mostra as interfaces eth0 e lo predefinidas, juntamente com os dispositivos de rede atribuídos, que têm nomes como eth1 e eth2. O número de NICs e os respetivos nomes variam consoante o tipo de máquina do nó do GKE.

    eth0
eth1
eth2
lo

Resolver problemas

Para verificar a configuração de rede de um conjunto de nós, execute o seguinte comando:

gcloud beta container node-pools describe NODE_POOL_NAME \
    --zone=ZONE \
    --cluster=CLUSTER_NAME

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do seu node pool.
  • ZONE: a zona do node pool.
  • CLUSTER_NAME: o nome do seu cluster.

O resultado mostra as redes e sub-redes adicionais anexadas ao grupo de nós.

O que se segue?