Configurar la red automatizada para máquinas virtuales de acelerador

En este documento se explica cómo usar la red automatizada para las VMs de acelerador, como las GPUs y las TPUs, con el fin de simplificar la configuración de red de las cargas de trabajo de acelerador de Google Kubernetes Engine (GKE). Esto es fundamental para ejecutar inteligencia artificial (IA), aprendizaje automático (ML) y computación de alto rendimiento (HPC) en máquinas optimizadas para aceleradores.

En este documento se presupone que el lector está familiarizado con los conceptos básicos de GKE, las cargas de trabajo de GPU y TPU, y las redes VPC. En concreto, debes conocer lo siguiente:

Esta página está dirigida a arquitectos de Cloud y especialistas en redes que diseñan y desarrollan la red de su organización. Para obtener una descripción general de todos los conjuntos de documentación de GKE, consulta Explorar la documentación de GKE. Para obtener más información sobre los roles habituales y las tareas de ejemplo que se mencionan en el contenido deGoogle Cloud , consulta Roles y tareas de usuario habituales de GKE.

GKE simplifica la ejecución de IA y aprendizaje automático de alto rendimiento en aceleradores especializados. Con la creación de redes automatizada para VMs con aceleradores, puedes habilitar la conectividad de alta velocidad y multired, esencial para protocolos como RDMA, con una sola marca de configuración. Esta automatización elimina el complejo proceso manual de configurar varias redes de VPC, gestionar intervalos de direcciones IP y configurar interfaces de red para cada grupo de nodos y pod. Al usar un solo parámetro al crear 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 entender la arquitectura de red de las VMs con aceleradores.

  • Nube privada virtual (VPC): una VPC es una versión virtual de una red física, implementada en la red de producción de Google. Proporciona conectividad a tus instancias de máquina virtual (VM) de Compute Engine, clústeres de GKE y otros recursos.
  • NIC Titanium: una NIC inteligente que descarga las tareas de procesamiento de la red de la CPU, lo que permite que la CPU se centre en tus cargas de trabajo. En las máquinas con GPU, gestionan todo el tráfico que no sea comunicación directa entre GPUs. En las máquinas de TPU, todas las NICs son NICs 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 intervalo de direcciones IP definido.
  • Controlador de interfaz de red (NIC): un NIC es una interfaz de red virtual que conecta una instancia de VM a una red. Cada NIC está asociado a una VPC y una subred específicas.
  • Red del host: la red principal que usan las interfaces de red (NICs) de la red principal del nodo para la comunicación general del clúster, como el tráfico del plano de control y la red de pods normal.
  • Red de datos: una red dedicada para la transferencia de datos de alto rendimiento entre máquinas virtuales con aceleradores. En el caso de las GPUs, suele ser una VPC de GPUDirect con RDMA. En el caso de las TPU, puede tratarse de 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 un ordenador sin involucrar al sistema operativo ni a la CPU. Esto reduce significativamente la latencia y mejora el rendimiento, lo que es fundamental para las cargas de trabajo de HPC y aprendizaje automático.
  • NVLink NVLink es una tecnología de interconexión de alta velocidad desarrollada por NVIDIA para conectar varias GPUs en un mismo nodo, lo que les permite compartir memoria y trabajar juntas en grandes conjuntos de datos.
  • Asignación dinámica de recursos (DRA) de Kubernetes: DRA es una función de Kubernetes que ofrece una forma más flexible para que los pods soliciten y consuman recursos, como GPUs y otro hardware especializado. Permite controlar con precisión la asignación de recursos.

Cómo funciona la creación de redes automatizada

Las máquinas optimizadas para aceleradores tienen una arquitectura de red especializada para admitir la comunicación de alto rendimiento y baja latencia entre GPUs y TPUs. Cada máquina física contiene varias GPUs o TPUs, que suelen estar conectadas mediante interconexiones de alta velocidad, como NVLink. Las máquinas también tienen una o varias NICs para redes generales y varias NICs 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 NICs en la VM subyacente. Las NICs del host se conectan a las redes de VPC del host para la comunicación y la gestión generales del clúster con el fin de comunicarse con el plano de control. Las NICs de GPU se conectan a una red VPC de alto rendimiento específica, a menudo con RDMA habilitado y un ajuste de MTU alto (8896), para facilitar la comunicación de GPUDirect.

Cuando un pod solicita GPUs o TPUs, puedes configurarlo para que acceda a las interfaces de red de alto rendimiento del nodo. Puedes solicitar todas las NICs disponibles o un subconjunto específico. Cada interfaz de red reclamada está dedicada a un solo pod y no se comparte. Esta configuración de red asegura que el pod tenga acceso exclusivo al ancho de banda y a los recursos completos de esa interfaz, lo que supone una ventaja clave para las cargas de trabajo sensibles al rendimiento.

Limitaciones

  • La creación de redes automatizada para VMs con aceleradores no está disponible en los clústeres de Autopilot.
  • Para usar la red automatizada, el clúster debe usar GKE Dataplane V2.
  • Tipos de máquinas admitidos: la creación de redes automatizada se admite en las familias de máquinas optimizadas para aceleradores A3, A4 y TPU Trillium (v6e).
  • Se requieren grupos de nodos de una sola zona: debes usar un grupo de nodos con una sola zona.
  • Cuando uses DRANET gestionado por GKE para configurar cargas de trabajo, consulta las consideraciones clave y las limitaciones de DRANET gestionado por GKE.
  • No puedes usar la API de varias redes y DRANET en el mismo grupo de nodos. Debes elegir un método de acoplamiento de red para tus pods.

Configuraciones de red de máquinas optimizadas para aceleradores

Las máquinas optimizadas para aceleradores tienen diferentes configuraciones de red en función de su tipo. En la siguiente tabla se resumen las especificaciones de red de varios tipos de máquinas.

Máquinas virtuales con acelerador de GPU

Tipo de máquina Número de GPUs Número de NICs de Titanium Número de NICs de GPU Tecnología GPUDirect VPCs adicionales
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 la segunda NIC y 1 para las NICs de GPU)
A4 8 (B200) 2 8 RDMA 2 (1 para la segunda NIC y 1 para las NICs de GPU)
A4X 4 (GB200) 1 4 RDMA 2 (1 para la segunda NIC y 1 para las NICs de GPU)

Máquinas virtuales con aceleradores de TPU

Tipo de máquina Número de chips de TPU Número de NICs VPCs adicionales
TPU Trillium (v6e) (ct6e-standard-4t) 4 2 2 (1 para la segunda NIC y 1 para la NIC virtual adicional en la primera NIC)

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la CLI de gcloud, obtén la versión más reciente ejecutando el comando gcloud components update. Es posible que las versiones anteriores de la interfaz de línea de comandos de gcloud no admitan la ejecución de los comandos de este documento.
  • Asegúrate de que tu clúster use la versión 1.34.1-gke.1829001 de GKE o una posterior.

  • Asegúrate de que tu clúster tenga GKE Dataplane V2. Puedes habilitar esta función al crear un clúster o actualizar uno que ya tengas.

    • Crea un clúster:

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

      Haz los cambios siguientes:

      • CLUSTER_NAME: el nombre del nuevo clúster.
      • CLUSTER_VERSION: la versión de tu clúster, que debe ser 1.34.1-gke.1829001 o posterior.
    • Actualizar un clúster:

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

      Sustituye CLUSTER_NAME por el nombre de tu clúster.

  • Si tienes previsto implementar cargas de trabajo de GPU que usen RDMA, verifica que existen los recursos DeviceClass:

    kubectl get deviceclass mrdma.google.com
    

Crear un grupo de nodos con un perfil de red predeterminado

Para crear automáticamente una red que conecte todas las máquinas con GPUs o TPUs de una misma zona, crea un grupo de nodos con el perfil de red de aceleradores 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

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

En el caso de los grupos de nodos de las slices de TPU de varios hosts, también debes añadir la marca --tpu-topology.

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
  • ZONE: la zona del grupo de nodos.
  • MACHINE_TYPE: el tipo de máquina de 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"
  }
}

Haz los cambios siguientes:

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

Programar una carga de trabajo que use GPUs

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 RDMA con DRANET gestionado de GKE. Para obtener más información, consulta Asignar recursos de red mediante DRANET gestionado de GKE.

Habilitar el controlador DRANET gestionado de GKE en un grupo de nodos de GPU

Para habilitar el controlador DRANET de GKE en un grupo de nodos de GPU que admita RDMA, añade 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

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
  • REGION: la Google Cloud región de tu clúster.
  • CLUSTER_NAME: el nombre de tu clúster.
  • ACCELERATOR_TYPE: el tipo de acelerador de GPU:

    Por ejemplo:

    • Máquinas virtuales A4: introduce nvidia-b200.
    • Máquinas virtuales A3 Ultra: introduce nvidia-h200-141gb.
  • ACCELERATOR_COUNT: número de GPUs que se van a asociar a los nodos del grupo de nodos. Por ejemplo, en las máquinas virtuales a4-highgpu-8g y a3-ultragpu-8g, el número de GPUs es 8.

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

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

  • NUM_NODES: el número de nodos del grupo de nodos. En el caso de flex-start, este valor debe ser 0.

  • RESERVATION_PROJECT: el ID del proyecto de la reserva.

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

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

Este comando usa perfiles de red de aceleradores para configurar automáticamente redes de VPC y subredes para tus VMs de aceleradores. También puedes especificar tu red VPC y subredes de forma explícita.

Desplegar recursos RDMA de 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. La siguiente solicitud de manifiesto solicita todos los dispositivos mrdma disponibles en el nodo. Guarda el archivo de 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 archivo de manifiesto:

    kubectl apply -f all-mrdma-template.yaml
    
  3. Despliega tu carga de trabajo y consulta la ResourceClaimTemplate. El siguiente manifiesto implementa un pod que hace referencia a la plantilla all-mrdma, lo que le da acceso a las interfaces RDMA del 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 archivo de manifiesto:

    kubectl apply -f agnhost-rdma-pod.yaml
    
  5. Verifica que las interfaces de red adicionales asignadas estén visibles en el pod.

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

    En el siguiente ejemplo de salida se muestran las interfaces eth0 y lo predeterminadas, así como las interfaces RDMA asignadas, como gpu0rdma0. El número y los nombres de las interfaces de red (NICs) varían en función del tipo de máquina del nodo de GKE.

    eth0
    gpu0rdma0
    gpu1rdma0
    gpu2rdma0
    gpu3rdma0
    lo
    

Programar una carga de trabajo que use TPUs

En las siguientes secciones se muestra cómo configurar un grupo de nodos de TPU y una carga de trabajo para usar interfaces de red no RDMA con DRANET gestionado de GKE. Para obtener más información, consulta Asignar recursos de red mediante DRANET gestionado de GKE.

Verificar DeviceClasses de redes

Verifica que los recursos DeviceClass para la red existan en tu clúster.

kubectl get deviceclass netdev.google.com

El resultado debería ser similar al siguiente:

NAME                AGE
netdev.google.com   2d22h

Habilitar el controlador DRANET gestionado de GKE en un grupo de nodos de un segmento de TPU

Para habilitar el controlador DRANET de GKE al crear un grupo de nodos de segmento de TPU, añade 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

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre del nuevo grupo de nodos.
  • LOCATION: la Google Cloud región o zona de tu clúster.
  • CLUSTER_NAME: el nombre del clúster.
  • NODE_LOCATIONS: las Google Cloud zonas de los nodos del grupo de nodos.
  • MACHINE_TYPE: el tipo de máquina que se va a usar en los nodos. Para obtener más información sobre los tipos de máquinas compatibles con TPU, consulta Elegir la versión de TPU.
  • TPU_TOPOLOGY: la topología de la 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 Elegir una topología.
  • NUM_NODES: número de nodos del grupo de nodos.

Para obtener más información, consulta Crear un grupo de nodos de segmento de TPU de un solo host.

Desplegar 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 netdev.google.com DeviceClass. El siguiente manifiesto solicita todos los dispositivos de red no RDMA disponibles en el nodo.

    Guarda el archivo de 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 archivo de manifiesto:

    kubectl apply -f all-netdev-template.yaml
    
  3. Despliega tu carga de trabajo y consulta la ResourceClaimTemplate. El siguiente manifiesto implementa un pod que usa la plantilla all-netdev para concederle acceso a todos los dispositivos de red que no sean RDMA del nodo. Guarda el archivo de 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
    

    Haz los cambios siguientes:

    • TPU_ACCELERATOR: el tipo de acelerador de TPU, por ejemplo, tpu-v5p-slice.
    • TPU_TOPOLOGY: la topología de la TPU. Por ejemplo, 2x4x4.
  4. Aplica el archivo de manifiesto:

    kubectl apply -f netdev-pod.yaml
    
  5. Verifica que las interfaces de red adicionales asignadas estén visibles en el pod.

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

    En el siguiente ejemplo de salida se muestran las interfaces eth0 y lo predeterminadas, así como los dispositivos de red asignados, que tienen nombres como eth1 y eth2. El número de NICs y sus nombres variarán en función del tipo de máquina del nodo de GKE.

    eth0
    eth1
    eth2
    lo
    

Solucionar problemas

Para comprobar 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

Haz los cambios siguientes:

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

El resultado muestra las redes y subredes adicionales asociadas al nodo pool.

Siguientes pasos