Configura redes automatizadas para VMs con aceleradores

En este documento, se muestra cómo usar las redes automatizadas para las VMs con aceleradores, como las GPUs y las TPUs, para simplificar la configuración de red de las cargas de trabajo con aceleradores de Google Kubernetes Engine (GKE). Esto es fundamental 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 conoces los conceptos fundamentales de GKE, las cargas de trabajo de GPU y TPU, y las redes de VPC. Específicamente, debes conocer los siguientes temas:

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 los que se hace referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

GKE simplifica la ejecución de IA y AA de alto rendimiento en aceleradores especializados. Con las redes automatizadas para las VMs con acelerador, puedes habilitar la conectividad de alta velocidad y varias redes, lo que es 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, administrar rangos de direcciones IP y configurar interfaces de red para cada grupo de nodos y Pod. Cuando usas un solo parámetro para crear un grupo de nodos, GKE proporciona todos los recursos de redes de Kubernetes y de la nube necesarios.

Terminología

Los siguientes términos son clave para comprender la arquitectura de redes de las VMs con aceleradores.

  • 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 Titanium: Es una NIC inteligente que descarga las tareas de procesamiento de red de la CPU, lo que permite que la CPU se concentre en tus cargas de trabajo. En las máquinas con GPU, controlan todo el tráfico que no es comunicación directa entre GPU. En las máquinas TPU, todas las NIC son NIC de Titanium.
  • Subred: Una subred es un segmento 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 está conectada a una VPC y una subred específicas.
  • Red del 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 VMs de aceleradores. En el caso de las GPUs, 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 la memoria remoto(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 GPUs 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 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 las GPUs y las TPUs. Cada máquina física contiene varias GPU o TPU, a menudo 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 del host se conectan a las redes de VPC del 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 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 está dedicada a un solo Pod y no se comparte. Esta configuración de red garantiza que el Pod tenga acceso exclusivo al ancho de banda y los recursos completos de esa interfaz, lo que representa un beneficio clave para las cargas de trabajo sensibles al rendimiento.

Limitaciones

  • Las redes automatizadas para las VMs con acelerador no son compatibles con los clústeres de Autopilot.
  • Las redes automatizadas requieren que el clúster use GKE Dataplane V2.
  • Tipos de máquinas compatibles: Las redes automatizadas son compatibles con las familias de máquinas optimizadas para aceleradores A3, A4 y TPU Trillium (v6e).
  • Se requieren grupos de nodos de zona única: Debes usar un grupo de nodos con una sola zona.
  • 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 para la conexión de red de tus Pods.

Configuraciones de red de máquinas optimizadas para aceleradores

Las máquinas optimizadas para aceleradores tienen diferentes configuraciones de red según su tipo. En la siguiente tabla, 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 NICs de Titanium Cantidad de NIC de GPU Tecnología GPUDirect VPC adicionales
A3 8 (H100) 1 4 TCPX 4 para las 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) 1 4 RDMA 2 (1 para la segunda NIC y 1 para las NIC de GPU)

VMs con aceleradores de TPU

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

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.

  • 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 cuando creas un clúster nuevo o actualizas uno existente.

    • Crea un clúster nuevo:

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

      Reemplaza lo siguiente:

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

    • Actualiza un clúster existente:

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

      Reemplaza CLUSTER_NAME por el nombre del clúster.

  • Si planeas implementar cargas de trabajo de GPU que usan RDMA, verifica la existencia de los recursos de DeviceClass:

    kubectl get deviceclass mrdma.google.com

Crea un grupo de nodos con un perfil de red predeterminado

Para crear automáticamente una red que conecte todas las máquinas con 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

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.

En el caso de 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: Es el tipo de máquina para los nodos, por ejemplo, a3-ultragpu-8g.

Programa una carga de trabajo que use GPUs

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

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

Para habilitar el controlador DRANET de GKE en un grupo de nodos de GPU que admite 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 Google Cloud de 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: Es el tipo de máquina del grupo de nodos, por ejemplo, a3-ultragpu-8g.

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

  • RESERVATION_PROJECT: Es el ID del proyecto de la reserva.

  • RESERVATION_NAME: El nombre de tu reserva. Para encontrar este valor, consulta Cómo ver solicitudes de reserva futuras.

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

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

Implementa recursos de RDMA de 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. El siguiente manifiesto solicita 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 a ResourceClaimTemplate. El siguiente manifiesto implementa un Pod que hace referencia a la plantilla all-mrdma, que otorga al Pod acceso a las interfaces 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 ejemplo de resultado, se muestran las interfaces eth0 y lo predeterminadas, así como las interfaces RDMA asignadas, como gpu0rdma0. La cantidad y los nombres de las tarjetas de interfaz 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 TPUs

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

Verifica las DeviceClasses de redes

Verifica que los recursos DeviceClass para 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 DRANET administrado por GKE en un grupo de nodos de segmentació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 Google Cloud región o zona de tu clúster.
  • CLUSTER_NAME: Es el nombre del clúster.
  • NODE_LOCATIONS: Son las Google Cloud zonas de los nodos en el 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 reclama 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 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 a 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 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 ejemplo de resultado, 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.

El resultado muestra las redes y subredes adicionales adjuntas al grupo de nodos.

¿Qué sigue?