Configurar a rede automatizada para VMs de acelerador

Neste documento, mostramos como usar o networking automatizado para VMs aceleradoras, como GPUs e TPUs, e simplificar a configuração de rede para cargas de trabalho aceleradoras do Google Kubernetes Engine (GKE). Isso é essencial para executar inteligência artificial (IA), machine learning (ML) e computação de alto desempenho (HPC) em máquinas otimizadas para aceleradores.

Neste documento, presumimos que você esteja familiarizado com os conceitos fundamentais do GKE, as cargas de trabalho de GPU e TPU e a rede VPC. Especificamente, você precisa conhecer:

Esta página é destinada a arquitetos de nuvem e especialistas em redes que projetam e arquitetam a rede da organização. Para uma visão geral de todos os conjuntos de documentação do GKE, consulte Conheça a documentação do GKE. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo doGoogle Cloud , consulte Funções e tarefas comuns do usuário do GKE.

O GKE simplifica a execução de IA e ML de alto desempenho em aceleradores especializados. Com a rede automatizada para VMs de acelerador, é possível ativar a conectividade de alta velocidade e várias redes, essencial para protocolos como RDMA, com uma única flag de configuração. Essa automação elimina o processo manual e complexo de configurar várias redes VPC, gerenciar intervalos de endereços IP e configurar interfaces de rede para cada pool de nós e pod. Ao usar um único parâmetro ao criar um pool de nós, o GKE fornece todos os recursos de rede necessários do Kubernetes e da nuvem.

Terminologia

Os termos a seguir são essenciais para entender a arquitetura de rede das VMs aceleradoras.

  • Nuvem privada virtual (VPC): uma VPC é uma versão virtual de uma rede física, implementada dentro da rede de produção do Google. Ela fornece conectividade para suas instâncias de máquina virtual (VM) do Compute Engine, clusters do GKE e outros recursos.
  • NIC Titanium: uma NIC inteligente que descarrega tarefas de processamento da rede da CPU, liberando a CPU para se concentrar nas suas cargas de trabalho. Em máquinas com GPU, eles processam todo o tráfego que não é comunicação direta entre GPUs. Em máquinas de TPU, todas as NICs são Titanium.
  • Sub-rede: uma sub-rede é uma parte segmentada de uma VPC maior. Cada sub-rede é associada a uma região e tem um intervalo de endereços IP definido.
  • Controlador de interface de rede (NIC): uma NIC é uma interface de rede virtual que conecta uma instância de VM a uma rede. Cada placa de rede é anexada a uma VPC e sub-rede específicas.
  • Rede do host: a rede principal usada pelas interfaces de rede (NICs) principais do nó para comunicação geral do cluster, como tráfego do plano de controle e rede regular de pods.
  • Rede de dados: uma rede dedicada para transferência de dados de alta performance entre VMs de acelerador. Para GPUs, geralmente é uma VPC do GPUDirect com RDMA. Para TPUs, pode ser uma segunda rede de host.
  • Acesso direto à memória remota(RDMA): RDMA é uma tecnologia que permite que dispositivos de rede troquem dados diretamente com a memória principal de um computador sem envolver o sistema operacional ou a CPU. Isso reduz significativamente a latência e melhora a capacidade de processamento, 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 conectar várias GPUs em um único nó, permitindo que elas compartilhem memória e trabalhem juntas em grandes conjuntos de dados.
  • Alocação dinâmica de recursos (DRA) do Kubernetes: a DRA é um recurso do Kubernetes que oferece uma maneira mais flexível para os pods solicitarem e consumirem recursos, como GPUs e outros hardwares especializados. Isso permite um controle refinado sobre a alocação de recursos.

Como funciona a rede automatizada

As máquinas otimizadas para aceleradores têm uma arquitetura de rede especializada para oferecer suporte à comunicação de alta taxa de transferência e baixa latência entre GPUs e TPUs. Cada máquina física contém várias GPUs ou TPUs, geralmente conectadas 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 você 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 host se conectam às redes VPC do host para comunicação e gerenciamento gerais do cluster com o plano de controle. As NICs de GPU se conectam a uma rede VPC dedicada de alto desempenho, geralmente com RDMA ativado e uma configuração de MTU alta (8896), para facilitar a comunicação do GPUDirect.

Quando um pod solicita GPUs ou TPUs, é possível configurá-lo para acessar as interfaces de rede de alta performance no nó. Você pode solicitar todas as NICs disponíveis ou um subconjunto específico. Cada interface de rede reivindicada é dedicada a um único pod e não é compartilhada. Essa configuração de rede ajuda a garantir que o pod tenha acesso exclusivo à largura de banda e aos recursos completos dessa interface, um benefício fundamental para cargas de trabalho sensíveis ao desempenho.

Limitações

  • A rede automatizada exige que o cluster use o GKE Dataplane V2.
  • Tipos de máquinas compatíveis: a rede automatizada é compatível com as famílias de máquinas A3, A4 e TPU Trillium (v6e) otimizadas para aceleradores.
  • Pools de nós de zona única obrigatórios: use um pool de nós com uma única zona.
  • Ao usar o DRANET gerenciado pelo GKE para configurar cargas de trabalho, consulte as principais considerações e limitações do DRANET gerenciado pelo GKE.
  • Não é possível usar a API de várias redes e o DRANET no mesmo pool de nós. É preciso escolher um método de vinculação de rede para seus pods.
  • Para clusters regionais, especifique a zona de destino ao ativar perfis de rede de aceleradores. Se a carga de trabalho abranger várias zonas, você precisará ativar o perfil de rede para cada uma delas de forma independente.

Configurações de rede de máquinas otimizadas para aceleradores

As máquinas otimizadas para aceleradores têm configurações de rede variadas, dependendo do tipo. A tabela a seguir resume as especificações de rede para vários tipos de máquinas.

VMs aceleradas por GPU

Tipo de máquina Número de GPUs Número de NICs Titanium Número de NICs de GPU Tecnologia GPUDirect VPCs extras
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 e 1 para as NICs de GPU)
A4 8 (B200) 2 8 RDMA 2 (1 para a segunda NIC e 1 para as NICs de GPU)
A4X 4 (GB200) 2 4 RDMA 2 (1 para a segunda NIC e 1 para as NICs de GPU)
A4X BM 8 2 8 BM-RDMA 2 (1 para a segunda NIC e 1 para as NICs de GPU)

VMs de aceleração com TPU

Tipo de máquina Número de chips de TPU Número de NICs VPCs extras
TPU Trillium (v6e) (ct6e-standard-1t) 1 0,25 1
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 para a segunda NIC, 1 para a VNIC extra na primeira NIC)
TPU Trillium (v6e) (ct6e-standard-8t) 8 4 4
tpu7x-standard-4t 4 2 2

Antes de começar

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

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
  • Verifique se o cluster usa o GKE versão 1.34.1-gke.2037000 ou posterior.

  • Para ativar o provisionamento automático de nós e as ComputeClasses personalizadas, verifique se o cluster usa a versão 1.35.2-gke.1302000 ou mais recente do GKE.

  • Verifique se a conta de serviço do GKE no seu projeto tem o papel compute.networkAdmin.

  • Verifique se o cluster tem o GKE Dataplane V2. É possível ativar esse recurso ao criar ou atualizar um cluster.

    • Crie um novo cluster:

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

      Substitua:

      • CLUSTER_NAME: o nome do novo cluster;
      • CLUSTER_VERSION: a versão do cluster, que precisa ser 1.34.1-gke.2037000 ou mais recente.

    • Atualize um cluster atual:

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

      Substitua CLUSTER_NAME pelo nome do cluster.

  • Se você planeja implantar cargas de trabalho de GPU que usam RDMA, verifique a existência dos recursos DeviceClass:

    kubectl get deviceclass mrdma.google.com

Configurar rede automatizada

É possível ativar a rede automatizada especificando um perfil de rede de acelerador ao criar um pool de nós. Também é possível criar um recurso ComputeClass para clusters que usam o provisionamento automático de nós.

Criar um pool de nós com um perfil de rede padrão

Para criar automaticamente uma rede que conecte todas as máquinas de GPUs ou TPUs em uma única zona, crie um pool de nós com o perfil de rede de aceleradores auto.

gcloud

Para criar um pool 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

Quando você cria um pool de nós com a flag --accelerator-network-profile=auto, o GKE adiciona automaticamente o rótulo gke.networks.io/accelerator-network-profile: auto aos nós. Para programar cargas de trabalho nesses nós, inclua esse rótulo no nodeSelector da carga de trabalho.

Para mais informações sobre como criar pools de nós com aceleradores, consulte Executar GPUs em pools de nós do Autopilot e Implantar cargas de trabalho de TPU no Autopilot. Ao seguir as instruções nesses documentos, adicione a flag --accelerator-network-profile=auto ao comando gcloud container node-pools create.

Para pools de nós de fração de TPU de vários hosts, também é necessário adicionar a flag --tpu-topology.

Substitua:

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

REST

Em uma solicitação ao método nodePools.create, especifique o campo accelerator_network_profile:

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

Substitua:

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

Ativar a rede automatizada com o provisionamento automático de nós

Para configurar a rede automatizada em clusters do Autopilot ou padrão que usam o provisionamento automático de nós, adicione o campo acceleratorNetworkProfile a um recurso ComputeClass.

  1. O exemplo a seguir de manifesto ComputeClass ativa a rede automatizada para máquinas A3 Mega. Salve o seguinte manifesto como anp-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: anp-a3-mega-class
spec:
  autopilot:
    enabled: true
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Priority 1: A3 Mega in us-central1-a
  - machineType: a3-megagpu-8g
    gpu:
      count: 8
      driverVersion: default
      type: nvidia-h100-mega-80gb
    flexStart:
      enabled: true
    location:
      zones: [us-central1-a]
    acceleratorNetworkProfile: auto
  whenUnsatisfiable: DoNotScaleUp

  2. Aplique o manifesto ao cluster:

    kubectl apply -f anp-compute-class.yaml

Quando você implanta uma carga de trabalho que seleciona esse recurso ComputeClass, o GKE configura automaticamente as interfaces de rede necessárias para os nós provisionados.

Programar uma carga de trabalho que usa GPUs

As seções a seguir mostram como configurar um pool de nós de GPU e uma carga de trabalho para usar interfaces de rede RDMA com o DRANET gerenciado pelo GKE. Para mais detalhes, consulte Alocar recursos de rede usando o DRANET gerenciado pelo GKE.

Ativar o driver DRANET gerenciado pelo GKE em um pool de nós de GPU

Para ativar o driver DRANET do GKE em um pool de nós de GPU que oferece suporte a RDMA, adicione o rótulo cloud.google.com/gke-networking-dra-driver=true ao criar o pool 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:

  • NODE_POOL_NAME: o nome do novo pool de nós.
  • REGION: a região Google Cloud do cluster.
  • CLUSTER_NAME: o nome do cluster.

  • ACCELERATOR_TYPE: o tipo de acelerador de GPU:

    Exemplo:

    • VMs A4: insira nvidia-b200.
    • VMs A3 ultra: insira nvidia-h200-141gb.

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

  • DRIVER_VERSION: a versão do driver da GPU a ser usada. Por exemplo, default ou latest.

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

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

  • RESERVATION_PROJECT: o ID do projeto da reserva.

  • RESERVATION_NAME: o nome da sua reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantadas.

  • RESERVATION_BLOCK: o nome de um bloco específico dentro da reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantadas.

Esse comando usa perfis de rede de acelerador para configurar automaticamente redes e sub-redes VPC para suas VMs de acelerador. Como alternativa, é possível especificar explicitamente sua rede VPC e sub-redes.

Implantar recursos de RDMA de carga de trabalho

Para alocar recursos de RDMA para um pod, especifique um ResourceClaimTemplate.

  1. Crie um ResourceClaimTemplate para definir como alocar os dispositivos RDMA. O manifesto a seguir solicita todos os dispositivos mrdma disponíveis no nó. Salve 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. Implante a carga de trabalho e consulte o ResourceClaimTemplate. O manifesto a seguir implanta um pod que faz referência ao modelo all-mrdma, que concede ao pod acesso às interfaces RDMA no nó. Salve 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 alocadas extras estão visíveis dentro do pod.

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

    O exemplo de saída a seguir mostra as interfaces eth0 e lo padrão, bem como as interfaces RDMA alocadas, como gpu0rdma0. O número e os nomes das interfaces de rede (NICs) variam de acordo com o tipo de máquina do nó do GKE.

    eth0
gpu0rdma0
gpu1rdma0
gpu2rdma0
gpu3rdma0
lo

Programar uma carga de trabalho que usa TPUs

As seções a seguir mostram como configurar um pool de nós e uma carga de trabalho de TPU para usar interfaces de rede não RDMA com o DRANET gerenciado pelo GKE. Para mais detalhes, consulte Alocar recursos de rede usando o DRANET gerenciado pelo GKE.

Verificar DeviceClasses de rede

Verifique se os recursos DeviceClass para rede existem no cluster.

kubectl get deviceclass netdev.google.com

O resultado será o seguinte:

NAME                AGE
netdev.google.com   2d22h

Ativar o driver DRANET gerenciado pelo GKE em um pool de nós de fração de TPU

Para ativar o driver DRANET do GKE ao criar um pool de nós de fração de TPU, adicione o rótulo 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:

  • NODE_POOL_NAME: o nome do novo pool de nós.
  • LOCATION: a Google Cloud região ou zona do cluster.
  • CLUSTER_NAME: o nome do cluster.
  • NODE_LOCATIONS: as Google Cloud zonas dos nós no pool de nós.
  • MACHINE_TYPE: o tipo de máquina a ser usado para nós. Para mais informações sobre os tipos de máquinas compatíveis com TPU, consulte Escolher a versão de TPU.
  • TPU_TOPOLOGY: a topologia da TPU, por exemplo, 2x4x4. O formato da topologia depende da versão da TPU. Para saber mais sobre topologias de TPU, consulte Escolher uma topologia.
  • NUM_NODES: o número de nós no pool de nós.

Para mais informações, consulte Criar um pool de nós de fração de TPU de host único.

Implantar uma carga de trabalho reivindicando todos os dispositivos de rede

Para alocar dispositivos de rede não RDMA para um pod, especifique um ResourceClaimTemplate.

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

    Salve 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. Implante a carga de trabalho e consulte o ResourceClaimTemplate. O manifesto a seguir implanta um pod que usa o modelo all-netdev para conceder ao pod acesso a todos os dispositivos de rede não RDMA no nó. Salve 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:

    • 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 alocadas extras estão visíveis dentro do pod.

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

    O exemplo de saída a seguir mostra as interfaces padrão eth0 e lo, além dos dispositivos de rede alocados, que têm nomes como eth1 e eth2. O número de NICs e os nomes deles variam de acordo com o tipo de máquina do nó do GKE.

    eth0
eth1
eth2
lo

Resolver problemas

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

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

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós.
  • ZONE: a zona do pool de nós.
  • CLUSTER_NAME: o nome do cluster.

A saída mostra as redes e sub-redes adicionais anexadas ao pool de nós.

A seguir