Cómo configurar las redes automatizadas para las VMs de aceleradores

Autopilot Standard

En este documento, se muestra cómo usar las redes automatizadas para las VMs de aceleradores, como las GPU y las TPU, para simplificar la configuración de red de las cargas de trabajo de aceleradores de Google Kubernetes Engine (GKE). Esto es esencial para ejecutar inteligencia artificial (IA), aprendizaje automático (AA) y computación de alto rendimiento (HPC) en máquinas optimizadas para aceleradores.

En este documento, se supone que estás familiarizado con los conceptos fundamentales de GKE, las cargas de trabajo de GPU y TPU, y las redes de VPC. Específicamente, debes conocer los siguientes conceptos:

• Kubernetes
• Herramientas de redes de GKE
• Conceptos de redes de VPC

Esta página está dirigida a arquitectos de nube y especialistas en herramientas de redes que diseñan la red de su organización. Para obtener una descripción general de todos los conjuntos de documentación de GKE, consulta Explora la documentación de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

GKE simplifica la ejecución de IA y AA de alto rendimiento en aceleradores especializados. Con las redes automatizadas para VMs de aceleradores, puedes habilitar la conectividad de alta velocidad y de varias redes, que es esencial para protocolos como RDMA, con una sola marca de configuración. Esta automatización elimina el proceso manual y complejo de configurar varias redes de VPC, administrar rangos de direcciones IP y configurar interfaces de red para cada grupo de nodos y Pod. Con un solo parámetro cuando se crea un grupo de nodos, GKE proporciona todos los recursos de red de Kubernetes y de la nube necesarios.

Terminología

Los siguientes términos son clave para comprender la arquitectura de red de las VMs aceleradoras.

• Nube privada virtual (VPC): Una VPC es una versión virtual de una red física, implementada dentro de la red de producción de Google. Proporciona conectividad para tus instancias de máquina virtual (VM) de Compute Engine, clústeres de GKE y otros recursos.
• NIC de Titanium: Es una NIC inteligente que transfiere las tareas de procesamiento de red de la CPU, lo que la libera para que se concentre en tus cargas de trabajo. En las máquinas con GPU, controlan todo el tráfico que no es comunicación directa de GPU a GPU. En las máquinas TPU, todas las NIC son NIC Titanium.
• Subred: Una subred es una parte segmentada de una VPC más grande. Cada subred está asociada a una región y tiene un rango de direcciones IP definido.
• Controlador de interfaz de red (NIC): Una NIC es una interfaz de red virtual que conecta una instancia de VM a una red. Cada NIC se conecta a una VPC y una subred específicas.
• Red de host: Es la red principal que usan las interfaces de red (NIC) principales del nodo para la comunicación general del clúster, como el tráfico del plano de control y las redes de Pods normales.
• Red de datos: Es una red dedicada para la transferencia de datos de alto rendimiento entre las VMs de acelerador. Para las GPU, suele ser una VPC de GPUDirect con RDMA. En el caso de las TPU, podría ser una segunda red de host.
• Acceso directo a memoria remota(RDMA): RDMA es una tecnología que permite que los dispositivos de red intercambien datos directamente con la memoria principal de una computadora sin involucrar al sistema operativo ni a la CPU. Esto reduce significativamente la latencia y mejora la capacidad de procesamiento, lo que es fundamental para las cargas de trabajo de HPC y AA.
• NVLink: NVLink es una tecnología de interconexión de alta velocidad desarrollada por NVIDIA para conectar varias GPU dentro de un solo nodo, lo que les permite compartir memoria y trabajar juntas en conjuntos de datos grandes.
• Asignación dinámica de recursos (DRA) de Kubernetes: La DRA es una función de Kubernetes que proporciona una forma más flexible para que los Pods soliciten y consuman recursos, como GPUs y otro hardware especializado. Permite un control detallado sobre la asignación de recursos.

Cómo funcionan las herramientas de redes automatizadas

Las máquinas optimizadas para aceleradores tienen una arquitectura de red especializada para admitir la comunicación de alta capacidad de procesamiento y baja latencia entre las GPU y las TPU. Cada máquina física contiene varias GPU o TPU, que suelen estar conectadas por interconexiones de alta velocidad, como NVLink. Las máquinas también tienen una o más NIC para redes generales y varias NIC de GPU para interconexiones de alta velocidad.

Cuando creas un nodo de GKE que usa un tipo de máquina optimizado para aceleradores, GKE configura varias NIC en la VM subyacente. Las NIC de host se conectan a las redes de VPC de host para la comunicación y administración generales del clúster, y para comunicarse con el plano de control. Las NIC de GPU se conectan a una red de VPC dedicada y de alto rendimiento, a menudo con RDMA habilitado y un parámetro de configuración de MTU alto (8896), para facilitar la comunicación de GPUDirect.

Cuando un Pod solicita GPU o TPU, puedes configurarlo para que acceda a las interfaces de red de alto rendimiento en el nodo. Puedes solicitar todas las NIC disponibles o un subconjunto específico. Cada interfaz de red reclamada se dedica a un solo Pod y no se comparte. Esta configuración de red ayuda a garantizar que el Pod tenga acceso exclusivo al ancho de banda y los recursos completos de esa interfaz, un beneficio clave para las cargas de trabajo sensibles al rendimiento.

Limitaciones

• Las herramientas de redes automatizadas requieren que el clúster use GKE Dataplane V2.
• Las redes automatizadas son compatibles con las familias de máquinas optimizadas para aceleradores A3, A4 y TPU Trillium (v6e), así como con la serie de máquinas optimizadas para almacenamiento Z4M.
• Debes usar un grupo de nodos con una sola zona.
• No puedes usar redes automatizadas en un clúster que use VPC compartida.
• Cuando uses DRANET administrado por GKE para configurar cargas de trabajo, consulta las consideraciones clave y las limitaciones de DRANET administrado por GKE.
• No puedes usar la API de varias redes y DRANET en el mismo grupo de nodos. Debes elegir un método de conexión de red para tus Pods.
• En el caso de los clústeres regionales, debes especificar la zona de destino cuando habilites los perfiles de red de acelerador. Si tu carga de trabajo abarca varias zonas, debes habilitar el perfil de red para cada zona de forma independiente.

Configuraciones de red de la máquina

Las máquinas optimizadas para aceleradores y almacenamiento tienen diferentes configuraciones de red según su tipo. En las siguientes tablas, se resumen las especificaciones de red para varios tipos de máquinas.

VMs con acelerador de GPU

Tipo de máquina	Cantidad de GPU	Cantidad de NIC de Titanium	Cantidad de NIC de GPU	Tecnología GPUDirect	VPC adicionales
A3	8 (H100)	1	4	TCPX	4 para NIC de GPU
A3 Mega	8 (H100)	1	8	TCPXO	8 para NIC de GPU
A3 Ultra	8 (H200)	2	8	RDMA	2 (1 para la segunda NIC y 1 para las NIC de GPU)
A4	8 (B200)	2	8	RDMA	2 (1 para la segunda NIC y 1 para las NIC de GPU)
A4X	4 (GB200)	2	4	RDMA	2 (1 para la segunda NIC y 1 para las NIC de GPU)
A4X BM	8	2	8	BM-RDMA	2 (1 para la segunda NIC y 1 para las NIC de GPU)

VMs de acelerador de TPU

Tipo de máquina	Cantidad de chips TPU	Cantidad de NIC	VPC adicionales
TPU Trillium (v6e) (ct6e-standard-1t)	1	0.25	1
TPU Trillium (v6e) (ct6e-standard-4t)	4	2	2 (1 para la 2ª NIC y 1 para la VNIC adicional en la 1ª NIC)
TPU Trillium (v6e) (ct6e-standard-8t)	8	4	4
tpu7x-standard-4t	4	2	2

VMs con optimización de almacenamiento

En las instancias Z4M, las dos NIC físicas de Titanium admiten el tráfico de red general (gVNIC) y hasta dos interfaces de red virtuales (vNIC) de IRDMA para la comunicación de Cloud RDMA.

Tipo de máquina	Cantidad de NICs físicas de Titanium	Cantidad de vNIC de RDMA	Tecnología de redes	VPC adicionales
Z4M (z4m-highmem-192)	2	Hasta 2 (compartidas en NIC físicas)	RDMA	2 para vNIC de RDMA

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 de 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.

• Asegúrate de que tu clúster use la versión 1.34.1-gke.2037000 de GKE o una posterior.

• Para habilitar el aprovisionamiento automático de nodos y las ComputeClasses personalizadas, asegúrate de que tu clúster use la versión 1.35.2-gke.1302000 o una posterior de GKE.

• Asegúrate de que la cuenta de servicio de GKE de tu proyecto tenga el rol compute.networkAdmin.

• Asegúrate de que tu clúster tenga habilitado GKE Dataplane V2. Puedes habilitar GKE Dataplane V2 solo cuando creas un clúster nuevo en la versión 1.34.1-gke.2037000 o posterior de GKE. No puedes habilitar GKE Dataplane V2 en clústeres anteriores a esta versión.

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

• Si planeas implementar cargas de trabajo de GPU o Z4M que usen RDMA, verifica la existencia de los recursos DeviceClass (mrdma.google.com para GPU o irdma.google.com para Z4M):

  kubectl get deviceclass mrdma.google.com
  

Configura las herramientas de redes automatizadas

Puedes habilitar las redes automatizadas especificando un perfil de red de acelerador cuando creas un grupo de nodos. También puedes crear un recurso ComputeClass para los clústeres que usan el aprovisionamiento automático de nodos.

Crea un grupo de nodos con un perfil de red predeterminado

Para crear automáticamente una red que conecte todas las máquinas de GPU o TPU dentro de una sola zona, crea un grupo de nodos con el perfil de red del acelerador auto.

gcloud

Para crear un grupo de nodos con un perfil de red configurado automáticamente, ejecuta el siguiente comando:

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

Cuando creas un grupo de nodos con la marca --accelerator-network-profile=auto, GKE agrega automáticamente la etiqueta gke.networks.io/accelerator-network-profile: auto a los nodos. Para programar cargas de trabajo en estos nodos, debes incluir esta etiqueta en el nodeSelector de tu carga de trabajo.

Para obtener más información sobre cómo crear grupos de nodos con aceleradores, consulta Ejecuta GPUs en grupos de nodos de Autopilot y Implementa cargas de trabajo de TPU en Autopilot. Cuando sigas las instrucciones de estos documentos, agrega la marca --accelerator-network-profile=auto al comando gcloud container node-pools create.

Para los grupos de nodos de porción de TPU de varios hosts, también debes agregar la marca --tpu-topology.

Reemplaza lo siguiente:

• NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
• ZONE: Es la zona del grupo de nodos.
• MACHINE_TYPE: Es el tipo de máquina para los nodos, por ejemplo, a3-ultragpu-8g.

REST

En una solicitud al método nodePools.create, especifica el campo accelerator_network_profile:

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

Reemplaza lo siguiente:

• NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
• MACHINE_TYPE: el tipo de máquina para los nodos, por ejemplo, a3-ultragpu-8g.

Habilita las redes automatizadas con el aprovisionamiento automático de nodos

Para configurar las herramientas de redes automatizadas en clústeres de Autopilot o clústeres de Standard que usan el aprovisionamiento automático de nodos, agrega el campo acceleratorNetworkProfile a un recurso ComputeClass.

1. En el siguiente ejemplo de manifiesto de ComputeClass, se habilitan las herramientas de redes automatizadas para las máquinas A3 Mega. Guarda el siguiente manifiesto 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. Aplica el manifiesto al clúster:

   kubectl apply -f anp-compute-class.yaml
   

Cuando implementas una carga de trabajo que selecciona este recurso ComputeClass, GKE configura automáticamente las interfaces de red necesarias para los nodos aprovisionados.

Programa una carga de trabajo que use GPU

En las siguientes secciones, se muestra cómo configurar un grupo de nodos de GPU y una carga de trabajo para usar interfaces de red de RDMA con DRANET administrada por GKE. Para obtener más detalles, consulta Asigna recursos de red con DRANET administrado por GKE.

Habilita el controlador de DRANET administrado por GKE en un grupo de nodos de GPU

Para habilitar el controlador de DRANET de GKE en un grupo de nodos de GPU que admita RDMA, agrega la etiqueta cloud.google.com/gke-networking-dra-driver=true cuando crees el grupo de nodos.

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

Reemplaza lo siguiente:

• NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
• REGION: Es la región de Google Cloud para tu clúster.
• CLUSTER_NAME: El nombre de tu clúster.

• ACCELERATOR_TYPE: Es el tipo de acelerador de GPU:

  Por ejemplo:

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

• ACCELERATOR_COUNT: Es la cantidad de GPU que se deben adjuntar a los nodos del grupo de nodos. Por ejemplo, para las VMs a4-highgpu-8g y a3-ultragpu-8g, la cantidad de GPUs es 8.

• DRIVER_VERSION: Es la versión del controlador de GPU que se usará. Por ejemplo, default o latest.

• MACHINE_TYPE: el tipo de máquina para el grupo de nodos, por ejemplo, a3-ultragpu-8g.

• NUM_NODES: Es la cantidad de nodos para el grupo de nodos. Para flex-start, este valor debe establecerse en 0.

• RESERVATION_PROJECT: el ID del proyecto de la reserva.

• RESERVATION_NAME: Es el nombre de tu reserva. Para encontrar este valor, consulta Visualiza las solicitudes de reserva futuras.

• RESERVATION_BLOCK: Es el nombre de un bloque específico dentro de la reserva. Para encontrar este valor, consulta Visualiza las solicitudes de reserva futuras.

Este comando usa perfiles de red de acelerador para configurar automáticamente redes de VPC y subredes para tus VMs de acelerador. Como alternativa, puedes especificar de forma explícita tu red de VPC y las subredes.

Implementa recursos de RDMA para una carga de trabajo

Para asignar recursos de RDMA a un Pod, especifica un ResourceClaimTemplate.

1. Crea un ResourceClaimTemplate para definir cómo asignar los dispositivos RDMA. En el siguiente manifiesto, se solicitan todos los dispositivos mrdma disponibles en el nodo. Guarda el manifiesto 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. Aplica el manifiesto

   kubectl apply -f all-mrdma-template.yaml
   

3. Implementa tu carga de trabajo y haz referencia al ResourceClaimTemplate. En el siguiente manifiesto, se implementa un Pod que hace referencia a la plantilla all-mrdma, que otorga al Pod acceso a las interfaces de RDMA en el nodo. Guarda el manifiesto 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. Aplica el manifiesto

   kubectl apply -f agnhost-rdma-pod.yaml
   

5. Verifica que las interfaces de red asignadas adicionales sean visibles dentro del Pod.

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

   En el siguiente resultado de ejemplo, se muestran las interfaces predeterminadas eth0 y lo, así como las interfaces de RDMA asignadas, como gpu0rdma0. La cantidad y los nombres de las interfaces de red (NIC) varían según el tipo de máquina del nodo de GKE.

   eth0
   gpu0rdma0
   gpu1rdma0
   gpu2rdma0
   gpu3rdma0
   lo
   

Programa una carga de trabajo que use TPU

En las siguientes secciones, se muestra cómo configurar un grupo de nodo TPU y una carga de trabajo para usar interfaces de red que no sean de RDMA con DRANET administrado por GKE. Para obtener más detalles, consulta Asigna recursos de red con DRANET administrado por GKE.

Verifica las DeviceClasses de redes

Verifica que los recursos de DeviceClass para las herramientas de redes existan en tu clúster.

kubectl get deviceclass netdev.google.com

El resultado es similar a lo siguiente:

NAME                AGE
netdev.google.com   2d22h

Habilita el controlador de DRANET administrado por GKE en un grupo de nodos de porción de TPU

Para habilitar el controlador DRANET de GKE cuando crees un grupo de nodos de porción de TPU, agrega la 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

Reemplaza lo siguiente:

• NODE_POOL_NAME: Es el nombre de tu grupo de nodos nuevo.
• LOCATION: Es la región o zona de Google Cloud para tu clúster.
• CLUSTER_NAME: Es el nombre del clúster.
• NODE_LOCATIONS: Son las zonas de Google Cloud para los nodos del grupo de nodos.
• MACHINE_TYPE: Es el tipo de máquina que se usará para los nodos. Para obtener más información sobre los tipos de máquinas compatibles con TPU, consulta Elige la versión de TPU.
• TPU_TOPOLOGY: Es la topología de TPU, por ejemplo, 2x4x4. El formato de la topología depende de la versión de la TPU. Para obtener más información sobre las topologías de TPU, consulta Elige una topología.
• NUM_NODES: la cantidad de nodos en el grupo de nodos.

Para obtener más información, consulta Crea un grupo de nodos de porción de TPU de host único.

Implementa una carga de trabajo que reclame todos los dispositivos de red

Para asignar dispositivos de red que no sean RDMA a un Pod, especifica un ResourceClaimTemplate.

1. Crea un ResourceClaimTemplate que haga referencia al DeviceClass netdev.google.com. En el siguiente manifiesto, se solicitan todos los dispositivos de red que no son de RDMA disponibles en el nodo.

   Guarda el manifiesto 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. Aplica el manifiesto

   kubectl apply -f all-netdev-template.yaml
   

3. Implementa tu carga de trabajo y haz referencia al ResourceClaimTemplate. En el siguiente manifiesto, se implementa un Pod que usa la plantilla all-netdev para otorgarle acceso a todos los dispositivos de red que no son de RDMA en el nodo. Guarda el manifiesto 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
   

   Reemplaza lo siguiente:

   • TPU_ACCELERATOR: Es el tipo de acelerador de TPU, por ejemplo, tpu-v5p-slice.
   • TPU_TOPOLOGY: Es la topología de TPU, por ejemplo, 2x4x4.

4. Aplica el manifiesto

   kubectl apply -f netdev-pod.yaml
   

5. Verifica que las interfaces de red asignadas adicionales sean visibles dentro del Pod.

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

   En el siguiente resultado de ejemplo, se muestran las interfaces predeterminadas eth0 y lo, junto con los dispositivos de red asignados, que tienen nombres como eth1 y eth2. La cantidad de NIC y sus nombres variarán según el tipo de máquina del nodo de GKE.

   eth0
   eth1
   eth2
   lo
   

Solucionar problemas

Para verificar la configuración de red de un grupo de nodos, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

• NODE_POOL_NAME: es el nombre de tu grupo de nodos.
• ZONE: Es la zona del grupo de nodos.
• CLUSTER_NAME: El nombre de tu clúster.

En el resultado, se muestran las redes y subredes adicionales conectadas al grupo de nodos.

¿Qué sigue?

• Obtén información sobre las máquinas optimizadas para aceleradores.
• Aprende a aprovisionar GPUs con DRA.
• Obtén más información para configurar la compatibilidad con varias redes para Pods.
• Obtén información para asignar recursos de red con DRANET administrado por GKE.