Asignar recursos de red con DRANET gestionado de GKE

Estándar

Vista previa

Esta función está sujeta a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

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

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

Este documento está dirigido a arquitectos de la nube y especialistas en redes que diseñan redes para sus organizaciones. Para obtener una visión general de toda la documentación de GKE, consulta Explorar la documentación de GKE. Para obtener información sobre los roles y las tareas habituales que se mencionan en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Antes de leer este documento, asegúrese de que conoce los siguientes conceptos:

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

Cómo funciona la DRANET gestionada de GKE

La DRANET gestionada de GKE se implementa mediante un networking-dra-driver DaemonSet. Este DaemonSet se ejecuta en nodos con GPUs o TPUs que tienen habilitado GKE DRANET. Funciona como un agente a nivel de nodo para que las interfaces de red se puedan descubrir y asignar a los pods mediante 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 la red. 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 de tu pod, haz referencia a esta plantilla en un campo resourceClaims para conceder a tu pod acceso a las interfaces de red solicitadas en el nodo.

Cuándo usar DRANET gestionado de GKE

GKE DRANET proporciona una forma estandarizada de gestionar 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 cargas de trabajo de IA y aprendizaje automático que requieren redes de alto rendimiento.

Estos son algunos de los casos prácticos habituales en los que se solicitan interfaces de red para un pod:

• Solicitando todas las interfaces disponibles compatibles con RDMA.
• Solicitar un número específico de interfaces compatibles con RDMA.
• Solicitar todas las interfaces no RDMA disponibles.
• Solicitar un número específico de interfaces no RDMA.

Consideraciones clave al usar DRANET gestionado de GKE para las redes

Ten en cuenta los siguientes puntos al usar 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 del mismo nodo no pueden compartirlo. De esta forma, el pod tiene 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.

• Usar el controlador DRANET gestionado de GKE de forma independiente

  Puedes habilitar el controlador DRA de GKE para gestionar recursos de red sin habilitar otros controladores DRANET de GKE. Para ello, añade la etiqueta cloud.google.com/gke-networking-dra-driver=true a un grupo de nodos con GPUs y TPUs.

• Usar otros controladores de DRA de GKE

  Para conseguir un mayor rendimiento en cargas de trabajo exigentes de IA o aprendizaje automático, combina la API DRA para aceleradores (como GPUs y TPUs) con la red gestionada DRANET de GKE. Este enfoque combinado mejora la alineación de los recursos y la detección de la topología. Para obtener información sobre cómo usar DRA en otros recursos, consulta Preparar la infraestructura de GKE para cargas de trabajo de DRA.

• Evitar configuraciones contradictorias

  El controlador DRANET de GKE gestiona las interfaces RDMA y las gNICs virtuales que no tienen configurados intervalos de direcciones IP secundarias. No uses el controlador DRANET de GKE y 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 gestionar el mismo conjunto de NICs, lo que puede provocar una configuración incorrecta y un comportamiento impredecible.

Requisitos

Para usar GKE Managed DRANET, tu entorno debe cumplir los siguientes requisitos:

• GKE 1.34.1-gke.1829001 o una versión posterior.
• GKE Dataplane V2 está habilitado en el clúster.
• (Vista previa) 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 NICs virtuales (como veth).
• No se admiten el autoescalado de clústeres ni Autopilot.
• No puedes usar GKE DRANET con interfaces en las que hayas configurado un secondaryPodRange.

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.
  Nota: En las instalaciones de gcloud CLI, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines 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 tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Roles obligatorios

Para obtener los permisos que necesitas para crear grupos de nodos y asignar recursos de red, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Administrador de Kubernetes Engine (roles/container.admin) en tu proyecto. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Crear un clúster

Crea un clúster estándar de GKE 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

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre del nuevo clúster.
• CONTROL_PLANE_LOCATION: la región o zona del plano de control del clúster, como us-central1 o us-central1-a.
• PROJECT_ID: tu ID de proyecto Google Cloud .
• CLUSTER_VERSION: la versión de GKE de tu clúster. Esta versión debe ser 1.34.1-gke.1829001 o una posterior.

Usar interfaces 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 RDMA con GKE DRANET.

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 asignadas adicionales 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
   

Usar interfaces de red que no sean RDMA en un grupo de nodos de TPU

En las siguientes secciones se describe cómo configurar un grupo de nodos de TPU y una carga de trabajo para usar interfaces de red que no sean RDMA con GKE DRANET.

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
   

Solicitar un número específico 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 como All. Si necesitas solicitar un número específico de dispositivos, puedes definir allocationMode como 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

Siguientes pasos

• Consulta más información sobre la asignación dinámica de recursos.
• Consulte más información sobre cómo configurar la red automatizada para VMs de acelerador.