Asigna recursos de red con DRANET administrado por GKE

Estándar

Versión preliminar

Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

DRANET de Google Kubernetes Engine (GKE) es una función administrada de GKE que se basa en el proyecto de código abierto DRANET, que implementa la API de DRA de Kubernetes para los recursos de redes. DRANET te permite solicitar y asignar recursos de redes de alto rendimiento para tus Pods, incluidas las interfaces de red que admiten el acceso directo a la 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 GKE DRANET 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 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 más 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 de los usuarios de GKE.

Antes de leer este documento, asegúrate de estar familiarizado con lo siguiente:

• 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 redes de GKE

Cómo funciona la DRANET administrada de GKE

El DRANET administrado por GKE se implementa a través de un DaemonSet networking-dra-driver. Este DaemonSet se ejecuta en nodos con GPU o TPU que tienen habilitado GKE DRANET. Funciona como un agente a nivel del nodo para que las interfaces de red sean detectables y asignables 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 automáticamente 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 dispositivos compatibles con RDMA y la clase netdev.google.com para otros dispositivos de red.

Para usar GKE DRANET, primero debes habilitar el controlador de GKE DRANET en un grupo de nodos con GPUs o TPUs.

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 otorgarle 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 tienen en cuenta la topología y las dependencias. Esta estandarización la convierte en una solución adecuada para las cargas de trabajo de IA y AA que requieren redes de alto rendimiento.

Estos son algunos casos de uso habituales para solicitar interfaces de red para un Pod:

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

Consideraciones clave cuando se usa DRANET administrado por GKE para redes

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

• Interfaces de red dedicadas

  Cuando usas GKE DRANET 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. Esto 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.

• Usa el controlador 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 GPUs y TPUs.

• Usa otros controladores de DRA de GKE

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

• Evita configuraciones en conflicto

  El controlador DRANET de GKE administra las interfaces RDMA y las gVNIC que no tienen rangos de direcciones IP secundarias configurados. 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.

Requisitos

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

• Versión de GKE 1.34.1-gke.1829001 o posterior
• GKE Dataplane V2 está habilitado en el clúster.
• (Versión preliminar) GKE DRANET está disponible en máquinas A4X Max.

Limitaciones

GKE DRANET tiene las siguientes limitaciones:

• No puedes usar GKE DRANET para asignar la tarjeta de interfaz de red (NIC) predeterminada ni las NIC virtuales (como veth).
• No se admiten el ajuste de escala automático del clúster ni Autopilot.
• No puedes usar GKE DRANET con interfaces en las que configuraste un secondaryPodRange.

Antes de comenzar

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

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

Roles obligatorios

Para obtener los permisos que necesitas para crear 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 zona del plano de control del clúster, como us-central1 o us-central1-a.
• PROJECT_ID: El ID de tu proyecto Google Cloud .
• CLUSTER_VERSION: Es la versión de GKE de tu clúster. Esta versión debe ser 1.34.1-gke.1829001 o posterior.

Usa interfaces RDMA desde un grupo de nodos de GPU

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

Usa interfaces de red que no sean 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 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
   

Solicita una cantidad específica de dispositivos de red

En los ejemplos anteriores, se muestra cómo solicitar todos los dispositivos de red disponibles de un tipo determinado configurando allocationMode en All. Si necesitas solicitar una cantidad específica de dispositivos, puedes configurar allocationMode en ExactCount en tu ResourceClaimTemplate.

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 redes automatizadas para VMs con aceleradores.