Criar um cluster do GKE personalizado otimizado para IA que usa o A4X

Nesta página, mostramos como criar um cluster do Google Kubernetes Engine (GKE) otimizado para IA que usa máquinas virtuais (VMs) A4X para oferecer suporte às suas cargas de trabalho de IA e ML. Para mais informações sobre o A4X, consulte a série A4X.

A série de máquinas A4X foi projetada para permitir executar clusters de IA/ML em grande escala com recursos como posicionamento de carga de trabalho direcionado, controles avançados de manutenção de cluster e programação com reconhecimento de topologia. Para mais informações, consulte Visão geral do gerenciamento de clusters.

O GKE oferece uma única plataforma para executar um conjunto diversificado de cargas de trabalho para suas organizações, reduzindo o ônus operacional de gerenciar várias plataformas. É possível executar cargas de trabalho como pré-treinamento distribuído de alta performance, ajuste fino e inferência de modelos, disponibilização de aplicativos e serviços de suporte.

Nesta página, você vai aprender a criar um cluster do GKE com a Google Cloud CLI para ter a máxima flexibilidade na configuração do cluster com base nas necessidades da sua carga de trabalho. Como alternativa, use o Cluster Toolkit para implantar rapidamente seu cluster com configurações padrão que refletem as práticas recomendadas para muitos casos de uso.

Para mais informações, consulte Criar um cluster do GKE otimizado para IA com configuração padrão.
Para criar um cluster que usa A4 ou A3 Ultra, consulte Criar um cluster do GKE personalizado otimizado para IA que usa A4 ou A3 Ultra.

Opções de configuração de cluster com GPUDirect RDMA

Para criar seu cluster com a Google Cloud CLI, escolha uma das seguintes opções de configuração:

Se você planeja executar cargas de trabalho de IA distribuídas: crie um cluster do GKE com GPUDirect RDMA usando as instruções nesta página.
Se você não planeja executar cargas de trabalho de IA distribuídas: crie um cluster do GKE sem usar o GPUDirect RDMA. Para mais informações, consulte Criar um cluster sem GPUDirect RDMA.

Antes de começar

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

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.
Observação: em instalações prévias da gcloud CLI, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na gcloud CLI como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Funções exigidas

Para receber as permissões necessárias para criar e gerenciar um cluster do GKE, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

Administrador do Kubernetes Engine (roles/container.admin)
Editor do Cloud Build (roles/cloudbuild.builds.editor)
Administrador do Compute (roles/compute.admin)
Administrador de projetos do IAM (roles/resourcemanager.projectIamAdmin)
Administrador da conta de serviço (roles/iam.serviceAccountAdmin)
Usuário da conta de serviço (roles/iam.serviceAccountUser)
Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer)
Administrador de armazenamento (roles/storage.admin)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Obter capacidade

É possível obter capacidade para VMs A4X criando uma reserva futura. Para mais informações sobre reservas adiantadas, consulte a coluna Reservas adiantadas no AI Hypercomputer na tabela Escolher uma opção de consumo.

Para obter capacidade com uma reserva adiantada, consulte a linha Reservas adiantadas no Hipercomputador de IA na tabela Como obter capacidade.

Requisitos

Os requisitos a seguir se aplicam a um cluster do GKE otimizado para IA com VMs A4X:

Para o A4X, use a versão 1.33.4-gke.1036000 ou mais recente do GKE para a versão 1.33 ou mais recente. Ou, para a versão 1.32, use o GKE versão 1.32.8-gke.1108000 ou mais recente. Essas versões garantem que o A4X use o seguinte:
- R580, a versão mínima do driver da GPU para A4X.
- Gerenciamento de memória coerente baseado em driver (CDMM), que é ativado por padrão. A NVIDIA recomenda que os clusters do Kubernetes ativem esse modo para resolver o excesso de relatórios de memória. O CDMM permite que a memória da GPU seja gerenciada pelo driver em vez do sistema operacional (SO). Essa abordagem ajuda a evitar a ativação on-line da memória da GPU pelo SO e expõe a memória da GPU como um nó de acesso à memória não uniforme (NUMA) para o SO. Não há suporte para GPUs de várias instâncias quando o CDMM está ativado. Para mais informações sobre o CDMM, consulte Suporte de hardware e software.
- GPUDirect RDMA, recomendado para permitir que os pools de nós A4X usem os recursos de rede do A4X.
Os nós do GKE precisam usar uma imagem de nó do Container-Optimized OS. As imagens de nós do Ubuntu e do Windows não são compatíveis.
Sua carga de trabalho do GKE precisa usar todas as GPUs disponíveis, e o pod precisa usar todas as NICs secundárias disponíveis em um único nó do GKE. Vários pods não podem compartilhar RDMA em um único nó do GKE.
Essa configuração executa um teste da NCCL. Para executar esse teste do NCCL, você precisa ter uma cota mínima de VM de 2 (4 GPUs cada ao usar a4x-highgpu-4g ou a4x-highgpu-4g-nolssd).
Você precisa usar o modelo de provisionamento vinculado à reserva para criar clusters com o A4X. Outros modelos de provisionamento não são compatíveis.
O GPUDirect RDMA não é compatível com o NCCL Fast Socket ou o GPUDirect TCPX/TCPXO. Não ative o Fast Socket do NCCL nem instale o plug-in TCPX/TCPXO em clusters que usam o GPUDirect RDMA.

Considerações para criar um cluster

Ao criar um cluster, considere as seguintes informações:

Escolha um local para o cluster:
- Verifique se você está usando um local que tem disponibilidade para o tipo de máquina escolhido. Para mais informações, consulte Locais de GPU.
- Para reservas densas, é possível criar um cluster zonal. Nesse caso, substitua a flag --region pela flag --zone=COMPUTE_ZONE, em que COMPUTE_ZONE é a zona do plano de controle.
- Ao criar pools de nós em um cluster regional, use a flag --node-locations para especificar as zonas dos nós do GKE.
Escolha uma versão do driver:
- A versão do driver pode ser um dos seguintes valores:
  - default: instale a versão padrão do driver para a versão do nó do GKE. Para mais informações sobre os requisitos das versões padrão de driver, consulte a seção Requisitos.
  - latest: instale a versão mais recente disponível do driver para a versão do GKE. Essa opção está disponível apenas para nós que usam o Container-Optimized OS.
  - disabled: pule a instalação automática do driver. Você precisa instalar manualmente um driver depois de criar o pool de nós.
- Para mais informações sobre as versões padrão e mais recentes do driver de GPU para versões de nós do GKE, consulte a tabela na seção Instalar manualmente os drivers de GPU NVIDIA.
Escolha uma afinidade de reserva:
- Você pode encontrar informações sobre sua reserva, como o nome dela ou de um bloco específico. Para encontrar esses valores, consulte Conferir solicitações de reserva adiantada.
- A flag --reservation-affinity pode ter os valores specific ou any. No entanto, para cargas de trabalho de IA distribuídas de alta performance, recomendamos usar uma reserva específica.
- Ao usar uma reserva específica, incluindo reservas compartilhadas, especifique o valor da flag --reservation no seguinte formato:
```
projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
  Substitua os seguintes valores:
  - PROJECT_ID: o ID do projeto Google Cloud .
  - RESERVATION_NAME: o nome da sua reserva.
  - BLOCK_NAME: o nome de um bloco específico na reserva.
  Para usar uma reserva segmentada por sub-bloco e colocar as VMs em um único sub-bloco dentro do BLOCK_NAME, adicione o seguinte ao final do caminho:
```
/reservationSubBlocks/SUB_BLOCK_NAME
```
  Substitua SUB_BLOCK_NAME pelo nome do sub-bloco.
Dica: se a reserva estiver no projeto atual, omita projects/PROJECT_ID/reservations/do valor da reserva.

Criar um cluster do GKE otimizado para IA que usa A4X e GPUDirect RDMA

Para cargas de trabalho de IA distribuídas, vários nós de GPU são vinculados para funcionar como um único computador. A A4X é uma plataforma de exaescala baseada na arquitetura de rack NVIDIA GB200 NVL72. Esse tipo de máquina permite escalonamento e colaboração em várias GPUs, oferecendo uma experiência de nuvem de alta performance para cargas de trabalho de IA. Para mais informações sobre a arquitetura de rede do A4X, incluindo a largura de banda da rede e o arranjo de NICs, consulte Tipos de máquinas A4X.

Para criar clusters do GKE Standard com A4X e GPUDirect RDMA, siga as etapas descritas nas próximas seções:

Criar VPCs e sub-redes
Criar o cluster do GKE com várias redes
Criar os objetos de rede do GKE
Criar uma política de carga de trabalho
Criar um pool de nós com A4X
Instalar o binário RDMA e configurar o NCCL
Instale o driver NVIDIA Compute Domain CRD e DRA

Criar VPCs e sub-redes

As VMs A4X têm a seguinte configuração:

Quatro GPUs NVIDIA B200 por máquina virtual conectadas com NVLink
Duas CPUs NVIDIA Grace baseadas em Arm
Quatro placas de interface de rede (NICs) CX-7 de 400 Gbps para rede de GPU para GPU
Duas placas de interface de rede (NICs) Google Titanium de 200 Gbps para serviços externos

As cargas de trabalho de IA e ML, como o treinamento distribuído, exigem uma aceleração poderosa para otimizar o desempenho, reduzindo os tempos de conclusão de jobs. Para cargas de trabalho que exigem alto desempenho, alta capacidade de processamento e baixa latência, o GPUDirect RDMA reduz os saltos de rede necessários para transferir payloads de e para GPUs. Essa abordagem usa de maneira mais eficiente a largura de banda da rede disponível.

Uma das NICs do Google Titanium associadas à CPU usa a rede padrão no GKE. Portanto, não é necessário criar uma nova VPC para essa NIC, desde que você tenha intervalos de endereços IP suficientes para a rede padrão.

É possível criar uma VPC para a segunda NIC Titanium da CPU (gVNIC) e outra para as quatro NICs CX-7 RDMA usando os comandos a seguir.

Para maximizar a largura de banda da rede, o comando para criar uma VPC para os GVNICs adicionais define a unidade máxima de transmissão (MTU) como 8896. A VPC do RDMA usa a configuração recomendada de 8.896 por padrão. Para mais informações, consulte Configurações de MTU e tipos de máquinas com GPU.

Defina as variáveis de ambiente para corresponder à sua implantação:
```
export REGION="COMPUTE_REGION"
export ZONE="COMPUTE_ZONE"
export PROJECT="PROJECT_ID"
export GVNIC_NETWORK_PREFIX="GVNIC_NETWORK_PREFIX"
export RDMA_NETWORK_PREFIX="RDMA_NETWORK_PREFIX"
```
Substitua as seguintes variáveis:
- COMPUTE_REGION: a região do cluster.
- COMPUTE_ZONE: a zona do pool de nós.
- PROJECT_ID: o ID do projeto Google Cloud .
- GVNIC_NETWORK_PREFIX: o prefixo da rede gVNIC (por exemplo, a4x-gvnic).
- RDMA_NETWORK_PREFIX: o prefixo da rede RDMA (por exemplo, a4x-rdma).

Crie duas redes VPC:

# Create a VPC for the additional GVNIC
gcloud compute --project=${PROJECT} \
  networks create \
  GVNIC_NETWORK_PREFIX-net \
  --subnet-mode=custom \
  --mtu=8896

gcloud compute --project=${PROJECT} \
  networks subnets create \
  GVNIC_NETWORK_PREFIX-sub \
  --network=GVNIC_NETWORK_PREFIX-net \
  --region=${REGION} \
  --range=192.168.0.0/24

gcloud compute --project=${PROJECT} \
  firewall-rules create \
  GVNIC_NETWORK_PREFIX-internal \
  --network=GVNIC_NETWORK_PREFIX-net \
  --action=ALLOW \
  --rules=tcp:0-65535,udp:0-65535,icmp \
  --source-ranges=192.168.0.0/16

# Create HPC VPC for the RDMA NICs with 4 subnets.
gcloud compute --project=${PROJECT} \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=${ZONE}-vpc-roce \
  --subnet-mode=custom

# Create subnets for the HPC VPC.
for N in $(seq 0 3); do
  gcloud compute --project=${PROJECT} \
    networks subnets create \
    RDMA_NETWORK_PREFIX-sub-$N \
    --network=RDMA_NETWORK_PREFIX-net \
    --region=${REGION} \
    --range=192.168.$((N+1)).0/24 &  # offset to avoid overlap with gvnics
done

Criar o cluster do GKE com várias redes

Crie um cluster do GKE Standard com várias redes:
```
gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 --enable-ip-alias --location=COMPUTE_REGION \
    --enable-multi-networking --cluster-version=CLUSTER_VERSION \
    --enable-kubernetes-unstable-apis=resource.k8s.io/v1beta1/deviceclasses,resource.k8s.io/v1beta1/resourceclaims,resource.k8s.io/v1beta1/resourceclaimtemplates,resource.k8s.io/v1beta1/resourceslices \
    [--services-ipv4-cidr=SERVICE_CIDR \
    --cluster-ipv4-cidr=POD_CIDR]
```
Ao preparar esse comando, faça o seguinte:
- Remova a flag --enable-kubernetes-unstable-apis, usada para ativar o DRA, ao criar um cluster executando o GKE versão 1.34 ou posterior. Essa flag só é necessária ao criar um cluster que executa a versão 1.32 ou 1.33. Quando você ativa uma API Beta, é necessário migrar dela quando ela for suspensa e removida com versões secundárias posteriores do Kubernetes. Para mais informações, consulte Suspensões de uso da API Beta.
- Substitua:
  - CLUSTER_NAME: o nome do cluster.
  - CLUSTER_VERSION: a versão do novo cluster. Para mais informações sobre qual versão do GKE é compatível com sua configuração, consulte os Requisitos neste documento.
  - COMPUTE_REGION: o nome da região de computação.
- Se quiser, você pode fornecer explicitamente os intervalos CIDR secundários para serviços e pods. Se você usar essas flags opcionais, substitua as seguintes variáveis:
  - SERVICE_CIDR: o intervalo CIDR secundário para serviços.
  - POD_CIDR: o intervalo CIDR secundário para pods.
  Ao usar essas flags, verifique se os intervalos CIDR não se sobrepõem aos intervalos de sub-rede para redes de nós adicionais. Por exemplo, considere SERVICE_CIDR=10.65.0.0/19 e POD_CIDR=10.64.0.0/19. Para mais informações, consulte Adicionar intervalos de endereços IPv4 de pods.

Criar os objetos de rede do GKE

É necessário configurar as redes VPC criadas na seção anterior usando conjuntos de parâmetros de rede do GKE. Especificamente, a segunda NIC Titanium (gVNIC) da CPU precisa ser configurada no modo NetDevice, e cada uma das quatro NICs RDMA CX-7 precisa ser configurada no modo RDMA.

Esse comando usa os seguintes nomes:

A VPC da NIC Titanium da CPU (gVNIC) é chamada de GVNIC_NETWORK_PREFIX-net com a sub-rede chamada GVNIC_NETWORK_PREFIX-sub
A VPC das NICs RDMA CX-7 é chamada de RDMA_NETWORK_PREFIX-net, e as sub-redes são chamadas de RDMA_NETWORK_PREFIX-sub-[0…3].

Crie os objetos de rede do GKE executando o seguinte comando:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: gvnic-1
spec:
  vpc: GVNIC_NETWORK_PREFIX-net
  vpcSubnet: GVNIC_NETWORK_PREFIX-sub
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: gvnic-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: gvnic-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-1
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-1
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-2
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-2
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-2
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-2
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-3
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-3
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-3
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-3
EOF

Criar uma política de carga de trabalho

É necessário ter uma política de carga de trabalho para criar uma partição. Para mais informações, consulte Política de carga de trabalho para MIGs.

Crie uma política de carga de trabalho HIGH_THROUGHPUT com o campo accelerator_topology definido como 1x72.

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

Substitua:

WORKLOAD_POLICY_NAME: o nome da política de carga de trabalho.
PROJECT: o nome do projeto.
COMPUTE_REGION: o nome da região de computação.

Criar um pool de nós com A4X

Recomendamos que você crie um pool de nós que use o plug-in de dispositivo de GPU do GKE. Esse plug-in oferece gerenciamento de recursos de GPU gerenciados pelo GKE. Essa abordagem tem os seguintes benefícios:

Facilidade de implantação e upgrades
Instalação automática de drivers
Recursos da GPU gerenciados pelo GKE, como métricas e GPUs particionadas
Correções essenciais de vulnerabilidades de segurança

Se preferir, use o operador de GPU NVIDIA, se necessário para seu caso de uso. Para mais informações, consulte Por que usar o operador de GPU NVIDIA?.

Criar um pool de nós A4X com o plug-in de dispositivo de GPU do GKE

Crie um pool de nós A4X que usa o plug-in de dispositivo de GPU do GKE:

gcloud container node-pools create NODE_POOL_NAME \
    --location COMPUTE_REGION \
    --node-locations COMPUTE_ZONE \
    --cluster CLUSTER_NAME \
    --num-nodes=NODE_COUNT \
    --machine-type MACHINE_TYPE \
    --accelerator type=nvidia-gb200,count=4,gpu-driver-version=DRIVER_VERSION \
    --additional-node-network network=GVNIC_NETWORK_PREFIX-net,subnetwork=GVNIC_NETWORK_PREFIX-sub \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-1 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-2 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-3 \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME \
    --placement-policy=WORKLOAD_POLICY_NAME

Substitua:

NODE_POOL_NAME: o nome do pool de nós.
COMPUTE_REGION: a região do cluster.
COMPUTE_ZONE: a zona do pool de nós.
CLUSTER_NAME: o nome do cluster.
NODE_COUNT: o número de nós para o pool de nós, que precisa ser de 18 nós ou menos. Recomendamos usar 18 nós para obter a topologia de GPU de 1x72 em um subbloco usando um domínio NVLink.
MACHINE_TYPE: a4x-highgpu-4g ou a4x-highgpu-4g-nolssd, dependendo se você quer SSDs locais.
DRIVER_VERSION: a versão do driver NVIDIA a ser instalado. Ele pode ser um dos seguintes valores: default, latest ou disabled.
RESERVATION_NAME: o nome da sua reserva. Para encontrar esse valor, consulte Visualizar solicitações de reserva adiantadas.
BLOCK_NAME: o nome de um bloco específico na reserva. Para encontrar esse valor, consulte Visualizar solicitações de reserva adiantadas.
WORKLOAD_POLICY_NAME: o nome da política de carga de trabalho que você criou anteriormente.

Criar um pool de nós A4X com o operador de GPU da NVIDIA

Como alternativa, para usar o operador de GPU NVIDIA, siga estas etapas:

Execute o comando gcloud container node-pools create da seção anterior com as seguintes mudanças:
- Altere gpu-driver-version=latest para gpu-driver-version=disabled. Essa modificação pula a instalação automática do driver de GPU porque ela não é compatível com o operador de GPU NVIDIA.
- Defina --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" como desativar o plug-in do dispositivo de GPU gerenciado do GKE Daemonset.

Aplique o manifesto do DaemonSet do instalador de driver de GPU do GKE. Este manifesto implanta um pod instalador de driver de GPU em cada nó A4X:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

Gerenciar a pilha de GPU com o operador de GPU NVIDIA no Google Kubernetes Engine (GKE):

Na seção para criar e configurar o pool de nós da GPU, siga as instruções a partir da etapa para receber credenciais de autenticação.

Instale o operador de GPU NVIDIA. Conclua todas as etapas, mas substitua o comando na seção referenciada que instala o operador de GPU NVIDIA usando o Helm. Use o seguinte comando:

helm install --wait --generate-name \
  -n gpu-operator \
  nvidia/gpu-operator \
  --version="25.3.0" \
  -f <(cat <<EOF
hostPaths:
  driverInstallDir: /home/kubernetes/bin/nvidia
toolkit:
  installDir: /home/kubernetes/bin/nvidia
cdi:
  enabled: true
  default: true
driver:
  enabled: false

daemonsets:
  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

node-feature-discovery:
  worker:
    tolerations:
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      - key: "node-role.kubernetes.io/master"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
EOF
)

Instalar o binário RDMA e configurar o NCCL

Aplique o seguinte DaemonSet para instalar os binários do RDMA e a biblioteca NCCL em cada nó. Em cada VM subjacente, os binários RDMA são instalados no diretório /home/kubernetes/bin/gib, e a biblioteca NCCL é instalada no diretório /home/kubernetes/bin/nvidia/lib64.

  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-rdma/nccl-rdma-installer-a4x.yaml

Instalar o driver NVIDIA Compute Domain CRD e DRA

Instale o driver DRA e o CRD do domínio de computação da NVIDIA. Para mais informações, consulte Driver NVIDIA DRA para GPUs.

Verifique se o Helm está instalado no ambiente de desenvolvimento. O Helm vem pré-instalado no Cloud Shell.

Embora não haja um requisito específico de versão do Helm, você pode usar o comando abaixo para verificar se o Helm está instalado.
```
helm version
```
Se a saída for semelhante a Command helm not found, será possível instalar a CLI do Helm executando este comando:
```
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && ./get_helm.sh
```

Adicione o repositório do Helm da NVIDIA:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

Crie um ResourceQuota para o driver da DRA:

export POD_QUOTA=POD_QUOTA

kubectl create ns nvidia-dra-driver-gpu

kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nvidia-dra-driver-gpu-quota
spec:
  hard:
    pods: ${POD_QUOTA}
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
        - system-node-critical
        - system-cluster-critical
EOF

Substitua POD_QUOTA por um número pelo menos duas vezes o número de nós A4X no cluster mais 1. Por exemplo, você precisa definir a variável como pelo menos 37 se tiver 18 nós A4X no cluster.

Instale o driver DRA:

helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
    --version="DRIVER_VERSION" \
    --create-namespace \
    --namespace nvidia-dra-driver-gpu \
    -f <(cat <<EOF
nvidiaDriverRoot: /home/kubernetes/bin/nvidia
resources:
  gpus:
    enabled: false

controller:
  affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "nvidia.com/gpu"
              operator: "DoesNotExist"

kubeletPlugin:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: In
                values:
                  - nvidia-gb200
              - key: kubernetes.io/arch
                operator: In
                values:
                  - arm64

  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
EOF
)

Substitua DRIVER_VERSION pela versão 25.3.1 ou mais recente.

Configurar o manifesto da carga de trabalho para várias redes, RDMA e o domínio IMEX

Adicione as seguintes anotações aos metadados do pod:

metadata:
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"}
      ]

Adicione uma regra de afinidade de nó para programar em nós Arm:

spec:
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

Para mais informações, consulte Programar carga de trabalho para uma única arquitetura.

Adicione os seguintes volumes à especificação do pod:

spec:
volumes:
  - name: library-dir-host
    hostPath:
      path: /home/kubernetes/bin/nvidia
  - name: gib
    hostPath:
      path: /home/kubernetes/bin/gib

Adicione as seguintes montagens de volume, variável de ambiente e recurso ao contêiner que solicita GPUs. O contêiner da carga de trabalho precisa solicitar todas as quatro GPUs:

containers:
- name: my-container
  volumeMounts:
    - name: library-dir-host
      mountPath: /usr/local/nvidia
    - name: gib
   mountPath: /usr/local/gib
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
  resources:
    limits:
      nvidia.com/gpu: 4

Crie o recurso ComputeDomain para a carga de trabalho:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel

Substitua NUM_NODES pelo número de nós que a carga de trabalho exige.

Especifique o resourceClaimTemplate que o pod vai usar:

spec:
  ...
  volumes:
    ...
  containers:
    - name: my-container
      ...
      resources:
        limits:
          nvidia.com/gpu: 4
  claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

Defina todas as variáveis de ambiente necessárias para configurar a NCCL. Use o seguinte script de shell do contêiner de carga de trabalho:
```
source /usr/local/gib/scripts/set_nccl_env.sh
```

Uma especificação de pod completa tem esta aparência:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"},
      ]
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
    - name: gib
      hostPath:
        path: /home/kubernetes/bin/gib
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

Testar o desempenho da rede

Recomendamos que você valide a funcionalidade dos clusters provisionados. Para isso, use os testes NCCL/gIB, que são testes da NVIDIA Collective Communications Library (NCCL) otimizados para o ambiente do Google.

A seguir

Para saber como agendar cargas de trabalho nos clusters do GKE usando o TAS e o Kueue, consulte Agendar cargas de trabalho do GKE com o Agendamento com reconhecimento de topologia.
Para saber como gerenciar eventos comuns relevantes para clusters do GKE e cargas de trabalho de IA, consulte Gerenciar clusters do GKE otimizados para IA.