Crea un clúster de GKE personalizado y optimizado para la IA que use A4X

En esta página, se muestra cómo crear un clúster de Google Kubernetes Engine (GKE) optimizado para IA que use máquinas virtuales (VM) A4X para admitir tus cargas de trabajo de IA y AA. Para obtener más información sobre las VMs A4X, consulta la serie A4X.

La serie de máquinas A4X está diseñada para permitirte ejecutar clústeres de IA/AA a gran escala con funciones como la colocación de cargas de trabajo segmentadas, controles avanzados de mantenimiento de clústeres y programación que considera la topología. Para obtener más información, consulta la descripción general de la administración de clústeres.

GKE proporciona una sola plataforma para ejecutar un conjunto diverso de cargas de trabajo para tus organizaciones, lo que reduce la carga operativa de administrar varias plataformas. Puedes ejecutar cargas de trabajo, como el entrenamiento previo distribuido de alto rendimiento, el ajuste de modelos, la inferencia de modelos, la entrega de aplicaciones y los servicios de asistencia.

En esta página, aprenderás a crear un clúster de GKE con Google Cloud CLI para tener la máxima flexibilidad a la hora de configurar tu clúster según las necesidades de tu carga de trabajo. Como alternativa, puedes usar Cluster Toolkit para implementar rápidamente tu clúster con la configuración predeterminada que refleja las prácticas recomendadas para muchos casos de uso.

Para obtener más información, consulta Crea un clúster de GKE optimizado para IA con la configuración predeterminada.
Para crear un clúster que use A4 o A3 Ultra, consulta Crea un clúster de GKE personalizado optimizado para IA que use A4 o A3 Ultra.

Opciones de configuración del clúster con GPUDirect RDMA

Para crear tu clúster con Google Cloud CLI, puedes elegir una de las siguientes opciones de configuración del clúster:

Si planeas ejecutar cargas de trabajo de IA distribuidas, crea un clúster de GKE con GPUDirect RDMA siguiendo las instrucciones de esta página.
Si no planeas ejecutar cargas de trabajo de IA distribuidas, crea un clúster de GKE sin usar GPUDirect RDMA. Para obtener más información, consulta Crea un clúster sin RDMA de GPUDirect.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Roles obligatorios

Para obtener los permisos que necesitas para crear y administrar un clúster de GKE, pídele a tu administrador que te otorgue los siguientes roles de IAM en el proyecto:

Administrador de Kubernetes Engine (roles/container.admin)
Editor de Cloud Build (roles/cloudbuild.builds.editor)
Administrador de Compute (roles/compute.admin)
Administrador de IAM de proyecto (roles/resourcemanager.projectIamAdmin)
Administrador de cuenta de servicio (roles/iam.serviceAccountAdmin)
Usuario de la cuenta de servicio (roles/iam.serviceAccountUser)
Consumidor de Service Usage (roles/serviceusage.serviceUsageConsumer)
Administrador de almacenamiento (roles/storage.admin)

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Cómo obtener capacidad

Puedes obtener capacidad para las VMs A4X creando una reserva futura. Para obtener más información sobre las reservas futuras, consulta la columna Reservas futuras en AI Hypercomputer de la tabla de Elige una opción de consumo.

Para obtener capacidad con una reserva futura, consulta la fila Reservas futuras en AI Hypercomputer de la tabla en Cómo obtener capacidad.

Requisitos

Los siguientes requisitos se aplican a un clúster de GKE optimizado para IA con VMs A4X:

Para A4X, asegúrate de usar, para la versión 1.33 o posterior, la versión 1.33.4-gke.1036000 de GKE o una posterior. O bien, para la versión 1.32, usa la versión 1.32.8-gke.1108000 de GKE o una posterior. Estas versiones garantizan que A4X use lo siguiente:
- R580, la versión mínima del controlador de GPU para A4X.
- Administración de memoria coherente basada en el controlador (CDMM), que está habilitada de forma predeterminada. NVIDIA recomienda que los clústeres de Kubernetes habiliten este modo para resolver el exceso de informes de memoria. El CDMM permite que la memoria de la GPU se administre a través del controlador en lugar del sistema operativo (SO). Este enfoque te ayuda a evitar que el SO ponga en línea la memoria de la GPU y expone la memoria de la GPU como un nodo de acceso no uniforme a memoria (NUMA) para el SO. No se admiten GPUs de varias instancias cuando CDMM está habilitado. Para obtener más información sobre el CDMM, consulta Compatibilidad con hardware y software.
- GPUDirect RDMA, que se recomienda habilitar para que los grupos de nodos A4X usen las capacidades de redes de A4X
Los nodos de GKE deben usar una imagen de nodo de Container-Optimized OS. No se admiten las imágenes de nodos de Ubuntu ni Windows.
Tu carga de trabajo de GKE debe usar todas las GPUs disponibles, y tu Pod debe usar todas las NICs secundarias disponibles en un solo nodo de GKE. Varios Pods no pueden compartir RDMA en un solo nodo de GKE.
Esta configuración ejecuta una prueba de NCCL. Para ejecutar esta prueba de NCCL, debes tener una cuota mínima de VM de 2 (4 GPUs cada una cuando se usa a4x-highgpu-4g o a4x-highgpu-4g-nolssd).
Debes usar el modelo de aprovisionamiento vinculado a la reserva para crear clústeres con A4X. No se admiten otros modelos de aprovisionamiento.
GPUDirect RDMA no es compatible con NCCL Fast Socket ni con GPUDirect TCPX/TCPXO. No habilites NCCL Fast Socket ni instales el complemento TCPX/TCPXO en clústeres que usen GPUDirect RDMA.

Consideraciones para crear un clúster

Cuando crees un clúster, ten en cuenta la siguiente información:

Elige la ubicación de un clúster:
- Verifica que uses una ubicación que tenga disponibilidad para el tipo de máquina que elijas. Para obtener más información, consulta Ubicaciones de GPU.
- Para las reservas densas, puedes crear un clúster zonal. En este caso, reemplaza la marca --region por la marca --zone=COMPUTE_ZONE, en la que COMPUTE_ZONE es la zona de tu plano de control.
- Cuando creas grupos de nodos en un clúster regional, puedes usar la marca --node-locations para especificar las zonas de tus nodos de GKE.
Elige una versión del controlador:
- La versión del controlador puede ser uno de los siguientes valores:
  - default: Instala la versión predeterminada del controlador para tu versión de nodo de GKE. Para obtener más información sobre los requisitos de las versiones predeterminadas de los controladores, consulta la sección Requisitos.
  - latest: Instala la última versión del controlador disponible para tu versión de GKE. Esta opción solo está disponible para los nodos que usan Container-Optimized OS.
  - disabled: Omite la instalación automática del controlador. Debes instalar un controlador de forma manual después de crear el grupo de nodos.
- Para obtener más información sobre las versiones de controladores de GPU predeterminadas y más recientes para las versiones de nodos de GKE, consulta la tabla en la sección Instala controladores de GPU de NVIDIA de forma manual.
Elige una afinidad de reserva:
- Puedes encontrar información sobre tu reserva, como el nombre de la reserva o el nombre de un bloque específico en ella. Para encontrar estos valores, consulta Cómo ver las solicitudes de reserva futuras.
- La marca --reservation-affinity puede tomar los valores specific o any. Sin embargo, para las cargas de trabajo de IA distribuidas de alto rendimiento, te recomendamos que uses una reserva específica.
- Cuando uses una reserva específica, incluidas las reservas compartidas, especifica el valor de la marca --reservation en el siguiente formato:
```
projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
  Reemplaza los siguientes valores:
  - PROJECT_ID: Es el ID del proyecto de Google Cloud .
  - RESERVATION_NAME: Es el nombre de tu reserva.
  - BLOCK_NAME: Es el nombre de un bloque específico dentro de la reserva.
  Para usar una reserva segmentada en un sub-bloque de modo que las VMs se coloquen en un solo sub-bloque dentro de BLOCK_NAME, agrega lo siguiente al final de la ruta de acceso:
```
/reservationSubBlocks/SUB_BLOCK_NAME
```
  Reemplaza SUB_BLOCK_NAME por el nombre del subbloque.
Nota: Si la reserva se encuentra en el proyecto actual, puedes omitir projects/PROJECT_ID/reservations/ del valor de la reserva.

Crea un clúster de GKE optimizado para IA que use A4X y GPUDirect RDMA

En el caso de las cargas de trabajo de IA distribuidas, a menudo se vinculan varios nodos de GPU para que funcionen como una sola computadora. A4X es una plataforma de exaescala basada en la arquitectura a nivel de rack NVIDIA GB200 NVL72. Este tipo de máquina permite la colaboración y el escalamiento en varias GPUs, ya que ofrece una experiencia de nube de alto rendimiento para las cargas de trabajo de IA. Para obtener más información sobre la arquitectura de red de la A4X, incluido el ancho de banda de la red y la disposición de la NIC, consulta Tipos de máquinas A4X.

Para crear tus clústeres de GKE Standard con A4X y con GPUDirect RDMA, completa los siguientes pasos, que se describen en las próximas secciones:

Crea VPC y subredes
Crea el clúster de GKE con varias redes
Crea los objetos de red de GKE
Crea una política de cargas de trabajo
Crea un grupo de nodos con A4X
Instala el objeto binario de RDMA y configura NCCL
Instala el CRD de NVIDIA Compute Domain y el controlador de DRA

Crea VPC y subredes

Las VMs A4X tienen la siguiente configuración:

Cuatro GPUs NVIDIA B200 por máquina virtual conectadas con NVLink
Dos CPU NVIDIA Grace basadas en Arm
Cuatro tarjetas de interfaz de red (NIC) CX-7 de 400 Gbps para redes de GPU a GPU
Dos tarjetas de interfaz de red (NIC) Google Titanium de 200 Gbps para servicios externos

Las cargas de trabajo de IA y AA, como el entrenamiento distribuido, requieren una aceleración potente para optimizar el rendimiento reduciendo los tiempos de finalización de los trabajos. Para las cargas de trabajo que requieren alto rendimiento, alta capacidad de procesamiento y baja latencia, GPUDirect RDMA reduce los saltos de red necesarios para transferir cargas útiles hacia y desde las GPUs. Este enfoque usa de manera más eficiente el ancho de banda de la red disponible.

Una de las NIC de Google Titanium asociadas a la CPU usa la red predeterminada en GKE, por lo que no tienes que crear una VPC nueva para esta NIC, siempre y cuando tengas suficientes rangos de direcciones IP para la red predeterminada.

Puedes crear una VPC para la segunda NIC de Titanium de CPU (gVNIC) y otra VPC para las cuatro NIC de RDMA CX-7 con los siguientes comandos.

Para maximizar el ancho de banda de la red, el comando para crear una VPC para el conjunto de GVNIC adicional establece la unidad de transmisión máxima (MTU) en 8896. La VPC de RDMA se establece de forma predeterminada en el parámetro de configuración recomendado de 8896. Para obtener más información, consulta Configuración de MTU y tipos de máquinas con GPU.

Configura las variables de entorno para que coincidan con tu implementación:
```
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"
```
Reemplaza las siguientes variables:
- COMPUTE_REGION: Es la región del clúster.
- COMPUTE_ZONE: Es la zona de tu grupo de nodos.
- PROJECT_ID: Es el ID del proyecto de Google Cloud .
- GVNIC_NETWORK_PREFIX: Es el prefijo de red de la gVNIC (por ejemplo, a4x-gvnic).
- RDMA_NETWORK_PREFIX: Es el prefijo de la red RDMA (por ejemplo, a4x-rdma).

Crea dos redes de 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

Crea el clúster de GKE con varias redes

Crea un clúster de GKE Standard con varias 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]
```
Cuando prepares este comando, haz lo siguiente:
- Quita la marca --enable-kubernetes-unstable-apis, que se usa para habilitar DRA, cuando crees un clúster que ejecute la versión 1.34 o posterior de GKE. Esta marca solo es necesaria cuando creas un clúster que ejecuta la versión 1.32 o 1.33. Cuando habilitas una API beta, debes migrar de ella cuando quede obsoleta y se quite con versiones secundarias posteriores de Kubernetes. Para obtener más información, consulta Bajas de la API beta.
- Reemplaza lo siguiente:
  - CLUSTER_NAME: El nombre de tu clúster.
  - CLUSTER_VERSION: Es la versión del clúster nuevo. Para obtener más información sobre qué versión de GKE admite tu configuración, consulta los Requisitos en este documento.
  - COMPUTE_REGION: Es el nombre de la región de procesamiento.
- De manera opcional, puedes proporcionar de forma explícita los rangos de CIDR secundarios para los servicios y los Pods. Si usas estas marcas opcionales, reemplaza las siguientes variables:
  - SERVICE_CIDR: Es el rango de CIDR secundario para los servicios.
  - POD_CIDR: Es el rango de CIDR secundario para los Pods.
  Cuando uses estas marcas, debes verificar que los rangos CIDR no se superpongan con los rangos de subredes para redes de nodos adicionales. Por ejemplo, considera SERVICE_CIDR=10.65.0.0/19 y POD_CIDR=10.64.0.0/19. Para obtener más información, consulta Cómo agregar rangos de direcciones IPv4 de Pods.

Crea los objetos de red de GKE

Debes configurar las redes de VPC creadas en la sección anterior a través de conjuntos de parámetros de red de GKE. Específicamente, la segunda NIC de Titanium de la CPU (gVNIC) debe configurarse en modo NetDevice, y cada una de las cuatro NIC de RDMA CX-7 debe configurarse en modo RDMA.

Este comando usa los siguientes nombres:

La NIC de CPU Titanium (gVNIC) de la VPC se llama GVNIC_NETWORK_PREFIX-net y la subred se llama GVNIC_NETWORK_PREFIX-sub.
La VPC de las NIC de RDMA CX-7 se llama RDMA_NETWORK_PREFIX-net y las subredes se llaman RDMA_NETWORK_PREFIX-sub-[0…3].

Ejecuta el siguiente comando para crear los objetos de red de GKE:

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

Crear una política de cargas de trabajo

Se requiere una política de cargas de trabajo para crear una partición. Para obtener más información, consulta la política de cargas de trabajo para MIGs.

Crea una política de cargas de trabajo HIGH_THROUGHPUT con el campo accelerator_topology establecido en 1x72.

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

Reemplaza lo siguiente:

WORKLOAD_POLICY_NAME: El nombre de tu política de carga de trabajo.
PROJECT: nombre del proyecto.
COMPUTE_REGION: Es el nombre de la región de procesamiento.

Crea un grupo de nodos con A4X

Te recomendamos que crees un grupo de nodos que use el complemento de dispositivo de GPU de GKE. Este complemento proporciona administración de recursos de GPU administrados por GKE. Este enfoque tiene los siguientes beneficios:

Facilidad de implementación y actualizaciones
Instalación automática de controladores
Funciones de GPU administradas por GKE, como métricas y GPU particionadas
Correcciones esenciales de vulnerabilidades de seguridad

Como alternativa, puedes usar el operador de GPU de NVIDIA, si tu caso de uso lo requiere. Para obtener más información, consulta ¿Por qué usar el operador de GPU de NVIDIA?.

Crea un grupo de nodos A4X con el complemento de dispositivo de GPU de GKE

Crea un grupo de nodos A4X que use el complemento de dispositivo de GPU de 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

Reemplaza lo siguiente:

NODE_POOL_NAME: el nombre del grupo de nodos
COMPUTE_REGION: Es la región del clúster.
COMPUTE_ZONE: Es la zona de tu grupo de nodos.
CLUSTER_NAME: El nombre de tu clúster.
NODE_COUNT: Es la cantidad de nodos del grupo de nodos, que debe ser de 18 nodos o menos. Te recomendamos que uses 18 nodos para obtener la topología de la GPU de 1x72 en un subbloque con un dominio de NVLink.
MACHINE_TYPE: a4x-highgpu-4g o a4x-highgpu-4g-nolssd, según si deseas SSD locales.
DRIVER_VERSION: Es la versión del controlador NVIDIA que se instalará. Puede ser uno de los siguientes valores: default, latest o disabled.
RESERVATION_NAME: El nombre de tu reserva. Para encontrar este valor, consulta Cómo ver solicitudes de reserva futuras.
BLOCK_NAME: Es el nombre de un bloque específico dentro de la reserva. Para encontrar este valor, consulta Cómo ver solicitudes de reserva futuras.
WORKLOAD_POLICY_NAME: Es el nombre de la política de cargas de trabajo que creaste anteriormente.

Crea un grupo de nodos A4X con el operador de GPU de NVIDIA

Como alternativa, para usar el operador de GPU de NVIDIA, sigue estos pasos:

Ejecuta el comando gcloud container node-pools create de la sección anterior con los siguientes cambios:
- Cambia gpu-driver-version=latest a gpu-driver-version=disabled. Esta modificación omite la instalación automática del controlador de GPU porque no es compatible con el operador de GPU de NVIDIA.
- Establece --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" para inhabilitar el DaemonSet del complemento de dispositivo de GPU administrado de GKE.

Aplica el manifiesto del DaemonSet del instalador de controladores de GPU de GKE. Este manifiesto implementa un Pod de instalador de controladores de GPU en cada nodo A4X:

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

Administra la pila de GPU con el operador de GPU de NVIDIA en Google Kubernetes Engine (GKE):

En la sección para crear y configurar el grupo de nodos de GPU, sigue las instrucciones a partir del paso para obtener credenciales de autenticación.

Instala el operador de GPU de NVIDIA. Completa todos los pasos, pero reemplaza el comando de la sección de referencia que instala el operador de GPU de NVIDIA con Helm. En su lugar, usa el siguiente 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
)

Instala el objeto binario de RDMA y configura NCCL

Aplica el siguiente DaemonSet para instalar los archivos binarios de RDMA y la biblioteca de NCCL en cada nodo. En cada VM subyacente, los objetos binarios de RDMA se instalan en el directorio /home/kubernetes/bin/gib y la biblioteca de NCCL se instala en el directorio /home/kubernetes/bin/nvidia/lib64.

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

Instala el CRD del dominio de procesamiento de NVIDIA y el controlador de DRA

Instala el CRD de NVIDIA Compute Domain y el controlador de DRA. Para obtener más información, consulta Controlador DRA de NVIDIA para GPUs.

Verifica que tengas Helm instalado en tu entorno de desarrollo. Helm forma parte de las herramientas instaladas previamente en Cloud Shell.

Si bien no hay un requisito específico de una versión de Helm, puedes usar el siguiente comando para verificar que tengas Helm instalado.
```
helm version
```
Si el resultado es similar a Command helm not found, puedes instalar la CLI de Helm ejecutando 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
```

Agrega el repositorio de Helm para NVIDIA:

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

Crea un ResourceQuota para el controlador de 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

Reemplaza POD_QUOTA por un número que sea, al menos, 2 veces la cantidad de nodos A4X del clúster más 1. Por ejemplo, debes establecer la variable en al menos 37 si tienes 18 nodos A4X en tu clúster.

Instala el controlador de 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
)

Reemplaza DRIVER_VERSION por la versión 25.3.1 o posterior.

Configura el manifiesto de tu carga de trabajo para redes múltiples, RDMA y el dominio de IMEX

Agrega las siguientes anotaciones a los metadatos del 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"}
      ]

Agrega una regla de afinidad de nodos para programar en nodos Arm:

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

Para obtener más información, consulta Programa la carga de trabajo en una sola arquitectura.

Agrega los siguientes volúmenes a la especificación del Pod:

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

Agrega las siguientes activaciones de volumen, la variable de entorno y el recurso al contenedor que solicita GPUs. El contenedor de tu carga de trabajo debe solicitar las cuatro 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

Crea el recurso ComputeDomain para la carga de trabajo:

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

Reemplaza NUM_NODES por la cantidad de nodos que requiere la carga de trabajo.

Especifica el resourceClaimTemplate que usará el Pod:

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

Establece todas las variables de entorno necesarias para configurar NCCL. Usa la siguiente secuencia de comandos de shell del contenedor de cargas de trabajo:
```
source /usr/local/gib/scripts/set_nccl_env.sh
```

Una especificación de Pod completa se ve de la siguiente manera:

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

Prueba el rendimiento de la red

Te recomendamos que valides la funcionalidad de los clústeres aprovisionados. Para ello, usa las pruebas de NCCL/gIB, que son pruebas de la biblioteca de comunicación colectiva de NVIDIA (NCCL) optimizadas para el entorno de Google.

¿Qué sigue?

Para obtener información sobre la programación de cargas de trabajo en tus clústeres de GKE con TAS y Kueue, consulta Programa cargas de trabajo de GKE con la programación consciente de la topología.
Para obtener información sobre cómo administrar eventos comunes relevantes para los clústeres de GKE y las cargas de trabajo de IA, consulta Administra clústeres de GKE optimizados para IA.