Asigna recursos de red con DRANET administrado por GKE

Autopilot Standard

DRANET de Google Kubernetes Engine (GKE) es una función de GKE administrada que se basa en el proyecto DRANET de código abierto, que implementa la API de DRA de Kubernetes para los recursos de red. DRANET te permite solicitar y asignar recursos de red de alto rendimiento para tus Pods, incluidas las interfaces de red que admiten el acceso directo a memoria remota (RDMA). Este enfoque proporciona una API portátil y alineada con la versión upstream para la administración de recursos de red.

En este documento, se proporciona una descripción general conceptual de DRANET de GKE y se muestra cómo asignar recursos de red a las cargas de trabajo en tus clústeres de GKE.

Este documento está dirigido a arquitectos de nube y especialistas en herramientas de redes que diseñan redes para sus organizaciones. Para obtener una descripción general de toda la documentación de GKE, consulta Explora la documentación de GKE. Para obtener información sobre los roles y las tareas comunes a los que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

Antes de leer este documento, asegúrate de estar familiarizado con los siguientes temas:

• Asignación dinámica de recursos
• Acerca de la asignación dinámica de recursos en GKE
• Conceptos de Kubernetes
• Herramientas de redes de GKE
• Aspectos básicos de las herramientas de redes de GKE

Cómo funciona DRANET administrado por GKE

DRANET administrado por GKE se implementa a través de un DaemonSet de networking-dra-driver. Este DaemonSet se ejecuta en nodos con GPU, TPU o VMs optimizadas para el almacenamiento que tienen habilitada la DRANET de GKE.

Funciona como un agente a nivel del nodo para que las interfaces de red se puedan descubrir y asignar a los Pods a través de las APIs de asignación dinámica de recursos (DRA) de Kubernetes.

En las versiones 1.34.1-gke.1829001 y posteriores de GKE, GKE instala de forma automática recursos DeviceClass para las redes. Estas clases definen los tipos de dispositivos de red que puedes solicitar. Por ejemplo, GKE crea la clase mrdma.google.com para las VMs de GPU, la clase netdev.google.com para las TPU y otros dispositivos de red, y la clase irdma.google.com para las VMs optimizadas para el almacenamiento (como Z4M).

Para usar DRANET de GKE, primero debes habilitar el controlador de DRANET de GKE en un grupo de nodos con GPU, TPU o VMs optimizadas para el almacenamiento.

Para solicitar dispositivos de red para una carga de trabajo, define un ResourceClaimTemplate. Esta plantilla especifica el DeviceClass y el modo de asignación, como solicitar todos los dispositivos disponibles en un nodo. En la especificación del Pod, haz referencia a esta plantilla en un campo resourceClaims para otorgar al Pod acceso a las interfaces de red solicitadas en el nodo.

Cuándo usar DRANET administrado por GKE

GKE DRANET proporciona una forma estandarizada de administrar los recursos de red que conocen la topología y las dependencias. Esta estandarización lo convierte en una solución adecuada para la IA y el AA, los sistemas de archivos paralelos grandes y otras cargas de trabajo de almacenamiento con uso intensivo de datos que requieren redes de alto rendimiento.

Entre los casos de uso comunes para solicitar interfaces de red para un Pod, se incluyen los siguientes:

• Se solicitan todas las interfaces disponibles compatibles con RDMA.
• Solicitar una cantidad específica de interfaces compatibles con RDMA
• Solicitando todas las interfaces que no son de RDMA disponibles.
• Solicitar una cantidad específica de interfaces que no sean de RDMA.

Consideraciones clave para usar DRANET administrada por GKE para las herramientas de redes

Ten en cuenta los siguientes puntos cuando uses DRANET de GKE para las herramientas de redes:

• Interfaces de red dedicadas

  Cuando usas DRANET de GKE para reclamar una interfaz de red para un Pod, esa interfaz se dedica a ese Pod. Otros Pods en el mismo nodo no pueden compartirla. Este enfoque ayuda a garantizar que el Pod tenga acceso exclusivo al ancho de banda y los recursos completos de esa interfaz, lo que es un beneficio clave para las cargas de trabajo sensibles al rendimiento.

• Usa el controlador de DRANET administrado por GKE de forma independiente

  Puedes habilitar el controlador de DRA de GKE para administrar recursos de red sin habilitar otros controladores de DRANET de GKE. Para ello, agrega la etiqueta cloud.google.com/gke-networking-dra-driver=true a un grupo de nodos con GPU, TPU o VMs optimizadas para el almacenamiento.

• Usa otros controladores de DRA de GKE

  Para lograr una mayor capacidad de procesamiento en cargas de trabajo de IA/AA exigentes, combina la API de DRA para aceleradores (como GPUs y TPUs) con las redes administradas de DRANET de GKE. Este enfoque combinado mejora la alineación de recursos y el conocimiento de la topología. Para obtener más información sobre el uso de la DRA para otros recursos, consulta Prepara la infraestructura de GKE para las cargas de trabajo de DRA.

• Evita las configuraciones en conflicto

  El controlador DRANET de GKE administra las interfaces de RDMA y las gVNIC que no tienen configurados rangos de direcciones IP secundarios. No uses el controlador DRANET de GKE ni la API de varias redes de GKE con un recurso de red de tipo Device en el mismo clúster. No se admite el uso conjunto del controlador y la API, ya que ambas APIs intentan administrar el mismo conjunto de NIC, lo que puede generar una configuración incorrecta y un comportamiento impredecible.

• Ciclo de vida administrado del controlador de DRANET

  En la versión 1.34 y posteriores de GKE, GKE crea automáticamente el espacio de nombres gke-managed-networking-dra-driver administrado en tu clúster. Al igual que otras cargas de trabajo del sistema de GKE, los Pods del controlador de DRANET solo se ejecutan en los nodos en los que son relevantes (como los nodos con GPU, TPU y otro hardware especializado). En los nodos en los que el controlador no es relevante, no se ejecutan Pods para este controlador. No modifiques manualmente el DaemonSet networking-dra-driver. Los cambios manuales, como la actualización del campo nodeAffinity, pueden interferir en la administración que hace GKE de la función de DRANET y hacer que los Pods del daemon de DRANET se programen en nodos no compatibles.

Requisitos

Para usar DRANET administrado por GKE, tu entorno debe cumplir con los siguientes requisitos:

• Standard: 1.34.1-gke.1829001 o posterior (1.36.3-gke.1767000 o posterior para VMs Z4M).
• Autopilot: 1.35.2-gke.1842000 o posterior (1.37.0-gke.4713000 o posterior para VMs Z4M).
• GKE Dataplane V2 está habilitado en el clúster.

También debes usar uno de los siguientes tipos de máquinas optimizadas para aceleradores o para almacenamiento:

Series de máquinas	Tipo de máquina	Modelo de acelerador	Tecnología de redes	DeviceClass
A3 Ultra	a3-ultragpu-8g	GPU NVIDIA H200	RDMA	mrdma.google.com
A4	a4-highgpu-8g	GPU NVIDIA B200	RDMA	mrdma.google.com
A4X	a4x-highgpu-4g	GPU NVIDIA GB200	RDMA	mrdma.google.com
A4X Max	a4x-maxgpu-4g-metal	GPU NVIDIA B300	RDMA	mrdma.google.com
TPU v7	tpu7x-standard-4t	TPU v7	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-8t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-4t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-1t	TPU Trillium	NetDevice	netdev.google.com
Z4M	Cualquier tipo de máquina Z4M que admita IRDMA	No aplicable (optimizada para almacenamiento)	RDMA	irdma.google.com

Limitaciones

La DRANET de GKE tiene las siguientes limitaciones:

• No puedes usar DRANET de GKE para asignar la tarjeta de interfaz de red (NIC) predeterminada o las NIC virtuales (como veth).
• Ciertos tipos de instancias, específicamente los nodos de equipos físicos como a4x-max, son incompatibles con los clústeres de ajuste de escala automático y Autopilot.

Consideraciones específicas de la máquina

Según la arquitectura de hardware subyacente de tus nodos, algunas series de máquinas requieren marcas de grupos de nodos, paquetes de imágenes de contenedor o DaemonSets del sistema adicionales para configurar interfaces de RDMA con DRANET de GKE.

A4X Max sin sistema operativo

• Implementa asapd-lite: Cuando uses nodos de GPU de equipos físicos, como A4X Max, debes implementar el DaemonSet asapd-lite en tu clúster. El DaemonSet asapd-lite configura las tarjetas de interfaz de red (NIC) de RDMA. Sin él, no se crean interfaces secundarias y el controlador dranet filtra las NIC de RDMA, lo que impide la funcionalidad de RDMA dentro de tus Pods. Para obtener instrucciones de configuración completas, consulta Configura las NIC de MRDMA con asapd-lite.

VMs Z4M con optimización de almacenamiento

• Requisitos de la imagen de contenedor: Para usar RDMA en instancias Z4M, debes usar una imagen de contenedor de Rocky Linux 8 configurada con los paquetes de RDMA de espacio de usuario necesarios. No se admiten otras distribuciones, como Ubuntu o Debian. Los paquetes upstream estándar para estas distribuciones carecen de las extensiones de ABI personalizadas que requiere el controlador de IRDMA. Sin estas extensiones, los paquetes fallan en el entorno de ejecución con un error -ENOSPC. Para obtener instrucciones de configuración, consulta Usa interfaces de RDMA en un grupo de nodos optimizado para el almacenamiento.

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.

Roles obligatorios

Para obtener los permisos que necesitas para crear grupos de nodos y asignar recursos de red, pídele a tu administrador que te otorgue el rol de IAM de administrador de Kubernetes Engine (roles/container.admin) en tu proyecto. 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.

Crea un clúster

Crea un clúster de GKE Standard que use GKE Dataplane V2:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --region=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster nuevo.
• CONTROL_PLANE_LOCATION: Es la región o la zona del plano de control del clúster, como us-central1 o us-central1-a.
• PROJECT_ID: Es el ID del proyecto de Google Cloud .
• CLUSTER_VERSION: Es la versión de GKE para tu clúster:
  • VMs Z4M: 1.36.3-gke.1767000 o posterior
  • Todas las demás VMs o instancias de Bare Metal compatibles: 1.34.1-gke.1829001 o posterior

Usa interfaces de RDMA desde un grupo de nodos de GPU

En las siguientes secciones, se describe cómo configurar un grupo de nodos de GPU y una carga de trabajo para usar interfaces de red de RDMA con DRANET de 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
   

Usa interfaces de red que no sean de RDMA en un grupo de nodo TPU

En las siguientes secciones, se describe 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 de 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
   

Usa interfaces de RDMA en un grupo de nodos optimizado para el almacenamiento

En las siguientes secciones, se describe cómo configurar un grupo de nodos optimizado para el almacenamiento y una carga de trabajo para usar interfaces de red RDMA con DRANET de GKE, con una VM Z4M (z4m-highmem-192) como ejemplo.

Crea un grupo de nodos optimizado para el almacenamiento

Crea un grupo de nodos optimizado para el almacenamiento con la marca --accelerator-network-profile=auto para que GKE aprovisione y conecte de forma automática las redes de VPC, las subredes y las interfaces de red secundarias de Falcon subyacentes. En los grupos de nodos de Z4M, GKE habilita DRANET de forma predeterminada, por lo que no necesitas especificar la etiqueta de nodo cloud.google.com/gke-networking-dra-driver=true cuando creas el grupo de nodos. En este ejemplo, se usa el tipo de máquina z4m-highmem-192, que tiene NIC físicas Titanium dobles y proporciona dos interfaces de RDMA. Para obtener la lista de tipos de máquinas compatibles, consulta Requisitos.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --machine-type=z4m-highmem-192 \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto

Reemplaza lo siguiente:

• NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
• CLUSTER_NAME: El nombre de tu clúster.
• PROJECT_ID: Es el ID del proyecto de Google Cloud .
• ZONE: Es la zona de Google Cloud para tu grupo de nodos.
• NUM_NODES: Es la cantidad de nodos en el grupo de nodos. Para probar el tráfico de RDMA en los nodos con los Pods rdma-server y rdma-client de ejemplo, especifica al menos 2.

Prepara la imagen de contenedor de la carga de trabajo optimizada para el almacenamiento

Las cargas de trabajo que usan Cloud RDMA en nodos optimizados para el almacenamiento requieren una imagen de contenedor de Rocky Linux 8 con las bibliotecas de RDMA de espacio de usuario personalizadas (rdma-core) para Cloud RDMA instaladas. No uses paquetes ascendentes predeterminados, ya que carecen de las extensiones de ABI personalizadas que requiere el controlador IRDMA del host y fallan en el entorno de ejecución con errores -ENOSPC. Para verificar las asignaciones de direcciones IP y probar la conectividad de RDMA, también instala iproute, libibverbs-utils, librdmacm-utils, infiniband-diags y perftest.

Para ver un ejemplo de Dockerfile que configura el repositorio de paquetes requerido, consulta Prepara tu imagen de Docker. En el comando dnf install, incluye iproute para que puedas inspeccionar las asignaciones de IP con el comando ip. Para obtener más información sobre los paquetes obligatorios, consulta RPM de RDMA de Cloud.

Implementa una carga de trabajo con recursos de RDMA

Para asignar interfaces de RDMA a un Pod en un nodo optimizado para el almacenamiento, crea un ResourceClaimTemplate que solicite el irdma.google.com DeviceClass:

1. Crea un manifiesto ResourceClaimTemplate y guárdalo como irdma-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: irdma-template
   spec:
     spec:
       devices:
         requests:
         - name: irdma
           exactly:
             deviceClassName: irdma.google.com
             allocationMode: ExactCount
             count: 2
   

   En el manifiesto se muestra lo siguiente:

   • deviceClassName: irdma.google.com: solicita interfaces de red de IRDMA administradas por DRANET de GKE en nodos optimizados para el almacenamiento.
   • allocationMode: ExactCount y count: 2: solicita las dos interfaces de IRDMA disponibles en un nodo z4m-highmem-192. Si tu carga de trabajo solo necesita una interfaz de RDMA o si usas un tipo de máquina Z4M que proporciona una interfaz de IRDMA, especifica 1.

2. Aplica el manifiesto

   kubectl apply -f irdma-template.yaml
   

3. Crea un manifiesto que defina dos Pods, rdma-server y rdma-client, para que puedas probar el tráfico de RDMA entre nodos. Cada Pod agrega la capacidad IPC_LOCK y hace referencia al ResourceClaimTemplate irdma-template. Guarda el manifiesto como irdma-pods.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-server
     labels:
       app: perftest
       role: server
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-client
     labels:
       app: perftest
       role: client
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   

   Reemplaza ambas instancias de IMAGE_URI por el URI de tu imagen de contenedor de Rocky Linux 8 RDMA.

   En el manifiesto se muestra lo siguiente:

   • metadata.labels: Etiqueta cada Pod con app: perftest y una etiqueta role. Ambos Pods comparten la etiqueta app: perftest para que se les aplique la regla de antiafinidad. La etiqueta role distingue el Pod rdma-server (role: server) del Pod rdma-client (role: client) para que puedas probar la conectividad de RDMA de Pod a Pod en los nodos.
   • affinity.podAntiAffinity: Impide que Kubernetes programe Pods que compartan la etiqueta app: perftest en el mismo nodo. Debido a que ambos Pods tienen esta etiqueta, se ejecutan en hosts físicos independientes para las pruebas de RDMA entre nodos, incluso cuando tu ResourceClaimTemplate solicita solo una interfaz (count: 1). Tu grupo de nodos debe tener al menos dos nodos para programar ambos Pods.
   • securityContext.capabilities.add: ["IPC_LOCK"]: Permite que el contenedor bloquee las páginas de memoria, lo que es necesario para que las bibliotecas de espacio de usuario de RDMA registren regiones de memoria para el acceso directo a la memoria.
   • spec.resourceClaims: Genera un ResourceClaim específico del Pod (llamado irdma) a partir del ResourceClaimTemplate de irdma-template.
   • containers.resources.claims: Otorga al contenedor perftest acceso a las interfaces asignadas por la reclamación irdma.

4. Aplica el manifiesto

   kubectl apply -f irdma-pods.yaml
   

5. Verifica que las interfaces de RDMA asignadas (rdma0 y rdma1) estén visibles dentro del Pod del servidor:

   kubectl exec rdma-server -- ip -br addr show
   

   El resultado es similar a lo siguiente:

   lo               UNKNOWN        127.0.0.1/8
   rdma1            UP             10.5.0.3/32
   rdma0            UP             10.31.0.3/32
   eth0@if18        UP             10.120.2.6/32
   

Para verificar el tráfico de RDMA entre los dos Pods, ejecuta rping entre rdma-server y rdma-client:

1. Inicia el servidor rping en el Pod del servidor:

   kubectl exec -it rdma-server -- rping -s -a RDMA_IP -v -d
   

   Reemplaza RDMA_IP por la dirección IP rdma0 o rdma1 del Pod del servidor, como 10.31.0.3.

2. En una segunda terminal, ejecuta el cliente rping en el Pod del cliente:

   kubectl exec -it rdma-client -- rping -c -a RDMA_IP -C 5 -v -d
   

   En el resultado del cliente, verifica los siguientes indicadores de una conexión de RDMA correcta:

   • RDMA_CM_EVENT_ADDR_RESOLVED y RDMA_CM_EVENT_ROUTE_RESOLVED: confirma que el administrador de comunicación de RDMA resolvió la dirección IP y la ruta de RDMA de destino.
   • ESTABLISHED y rdma_connect successful: Confirma que el cliente creó el par de colas (qp), la cola de finalización (cq) y el dominio de protección (pd), y estableció la conexión de RDMA.
   • Cinco entradas send completion, recv completion y ping data: rdma-ping-: Confirma que se completaron cinco iteraciones de ida y vuelta de lectura y escritura de RDMA en la interfaz de RDMA antes de cerrar la conexión (destroy cm_id).

Habilita DRANET con ComputeClass personalizada

Para usar DRANET administrado por GKE en clústeres de Autopilot o con el aprovisionamiento automático de nodos en clústeres de Standard, debes usar un recurso ComputeClass personalizado para habilitar la función.

1. Crea un manifiesto de ComputeClass que habilite el controlador de DRANET y establezca el perfil de red del acelerador en auto:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: dranet-compute-class
   spec:
     nodePoolAutoCreation:
       enabled: true
     nodePoolConfig:
       dra:
         networking:
           enabled: true
     priorities:
     - machineType: MACHINE_TYPE
       # Omit the gpu section for storage-optimized VMs (such as Z4M).
       gpu:
         count: GPU_COUNT
         type: GPU_TYPE
       acceleratorNetworkProfile: auto
   

   Reemplaza lo siguiente:

   • MACHINE_TYPE: Es el tipo de máquina para el grupo de nodos, como a3-ultragpu-8g o z4m-highmem-192.
   • GPU_COUNT: Es la cantidad de GPU para el tipo de máquina.
   • GPU_TYPE: Es el tipo de GPU, como nvidia-h200.

2. Aplica el manifiesto

   kubectl apply -f COMPUTE_CLASS_FILENAME.yaml
   

3. En la especificación del Pod, haz referencia a la ComputeClass con el selector de nodos cloud.google.com/compute-class:

   apiVersion: v1
   kind: Pod
   metadata:
     name: dranet-pod
   spec:
     nodeSelector:
       cloud.google.com/compute-class: "dranet-compute-class"
     ...
   

Solicita una cantidad específica de dispositivos de red

En los ejemplos anteriores de GPU y TPU, se muestra cómo solicitar todos los dispositivos de red disponibles de un tipo determinado configurando allocationMode como All. Para solicitar una cantidad específica de dispositivos, establece allocationMode en ExactCount en tu ResourceClaimTemplate, como se muestra en Implementa una carga de trabajo con recursos de RDMA.

En el siguiente ejemplo, se solicitan dos dispositivos de red RDMA:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: two-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 2

¿Qué sigue?

• Obtén más información sobre la asignación dinámica de recursos.
• Obtén más información para configurar las redes automatizadas para las VMs de aceleradores.