Solucionar problemas de GPUs en GKE

En esta página se explica cómo resolver problemas relacionados con las GPUs en Google Kubernetes Engine (GKE).

Instalación de controladores de GPU

En esta sección se proporciona información para solucionar problemas relacionados con la instalación automática de controladores de dispositivos NVIDIA en GKE.

La instalación del controlador falla en los nodos de Ubuntu

Si usas nodos de Ubuntu que tienen GPUs L4, H100 o H200 conectadas, es posible que el controlador de GPU predeterminado que instala GKE no sea igual o posterior a la versión necesaria para esas GPUs. Por lo tanto, el pod del complemento de dispositivo de GPU se quedará en el estado Pending y es posible que tus cargas de trabajo de GPU en esos nodos tengan problemas.

Para solucionar este problema en las GPUs L4 y H100, te recomendamos que actualices a las siguientes versiones de GKE, que instalan la versión 535 del controlador de GPU como controlador predeterminado:

  • 1.26.15-gke.1483000 y versiones posteriores
  • 1.27.15-gke.1039000 y versiones posteriores
  • 1.28.11-gke.1044000 y versiones posteriores
  • 1.29.6-gke.1073000 y versiones posteriores
  • 1.30.2-gke.1124000 y versiones posteriores

También puedes instalar manualmente la versión 535 o una posterior del controlador ejecutando el siguiente comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

Para solucionar este problema en las GPUs H200, debes instalar manualmente la versión 550 o una posterior del controlador ejecutando el siguiente comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

Los complementos de dispositivos de GPU fallan con errores CrashLoopBackOff

El siguiente problema se produce si has usado el método de instalación manual de controladores en tu grupo de nodos antes del 25 de enero del 2023 y, posteriormente, has actualizado tu grupo de nodos a una versión de GKE que admite la instalación automática de controladores. Ambas cargas de trabajo de instalación existen al mismo tiempo e intentan instalar versiones de controladores conflictivas en tus nodos.

El contenedor de inicialización del complemento de dispositivo de GPU falla con el Init:CrashLoopBackOff estado. Los registros del contenedor son similares a los siguientes:

failed to verify installation: failed to verify GPU driver installation: exit status 18

Para solucionar este problema, prueba los métodos siguientes:

  • Elimina el DaemonSet de instalación manual de controladores de tu clúster. De esta forma, se elimina la carga de trabajo de instalación conflictiva y GKE instala automáticamente un controlador en tus nodos.

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Vuelve a aplicar el manifiesto de DaemonSet de instalación manual de controladores a tu clúster. El 25 de enero del 2023, actualizamos el manifiesto para ignorar los nodos que usan la instalación automática de controladores.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Inhabilita la instalación automática de controladores en el grupo de nodos. El DaemonSet de instalación del controlador actual debería funcionar correctamente una vez que se haya completado la operación de actualización.

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

    Haz los cambios siguientes:

    • POOL_NAME: el nombre del grupo de nodos.
    • GPU_TYPE: el tipo de GPU que ya usa el pool de nodos.
    • GPU_COUNT: número de GPUs que ya están asociadas al grupo de nodos.
    • CLUSTER_NAME: el nombre del clúster de GKE que contiene el grupo de nodos.
    • LOCATION: la ubicación de Compute Engine del clúster.

Para obtener más información sobre cómo asignar la versión del controlador de GPU a la versión de GKE, consulta el artículo Asignar la versión de GKE y la versión de la imagen de nodo de Container-Optimized OS a la versión del controlador de GPU.

Error: "Container image cos-nvidia-installer:fixed is not present with pull policy of Never." o "Container image ubuntu-nvidia-installer:fixed is not present with pull policy of Never."

Este problema se produce cuando los pods nvidia-driver-installer están en el estado PodInitializing y el dispositivo del complemento de GPU o los pods del instalador del controlador de GPU informan del siguiente error. El mensaje de error específico depende del sistema operativo que se ejecute en tu nodo:

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

Este problema puede producirse cuando el recolector de elementos no utilizados elimina la imagen del controlador NVIDIA precargada para liberar espacio en un nodo. Cuando se recrea el pod del controlador o se reinicia su contenedor, GKE no podrá localizar la imagen precargada.

Para mitigar el problema de la recogida de elementos no utilizados al ejecutar COS, actualiza tus nodos de GKE a una de estas versiones que contengan la corrección:

  • 1.25.15-gke.1040000 y versiones posteriores
  • 1.26.10-gke.1030000 y versiones posteriores
  • 1.27.6-gke.1513000 y versiones posteriores
  • 1.28.3-gke.1061000 y versiones posteriores

Para obtener más información sobre cómo asignar la versión del controlador de GPU a la versión de GKE, consulta el artículo Asignar la versión de GKE y la versión de la imagen de nodo de Container-Optimized OS a la versión del controlador de GPU.

Si tus nodos ejecutan Ubuntu, aún no hay ninguna solución disponible para este problema de recolección de elementos no utilizados. Para mitigar este problema en Ubuntu, puedes ejecutar un contenedor con privilegios que interactúe con el host para asegurarte de que los controladores de la GPU de NVIDIA se configuren correctamente. Para ello, ejecuta sudo /usr/local/bin/nvidia-container-first-boot desde tu nodo o aplica el siguiente manifiesto:

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

Otra posible causa del problema es que las imágenes del controlador de NVIDIA se pierdan después de reiniciar el nodo o de realizar el mantenimiento del host. Esto puede ocurrir en nodos confidenciales o nodos con GPUs que usen almacenamiento SSD local efímero. En esta situación, GKE precarga las imágenes de contenedor nvidia-installer-driver en los nodos y las mueve del disco de arranque al SSD local en el primer arranque.

Para confirmar que se ha producido un evento de mantenimiento del host, utiliza el siguiente filtro de registro:

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

Para mitigar el problema de mantenimiento del host, actualiza tu versión de GKE a una de estas versiones:

  • 1.27.13-gke.1166000 y versiones posteriores
  • 1.29.3-gke.1227000 y versiones posteriores
  • 1.28.8-gke.1171000 y versiones posteriores

Error: no se han podido configurar los directorios de instalación del controlador de la GPU: no se ha podido crear la superposición lib64: no se ha podido crear el directorio /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: no es un directorio.

Este error se produce en el contenedor del instalador del controlador de la GPU dentro del complemento del dispositivo de la GPU cuando se habilita fastsocket de NCCL:

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

Este problema solo se produce en clústeres y nodos que ejecutan GKE 1.28 y 1.29.

El problema se debe a una condición de carrera de fastsocket de NCCL con el instalador del controlador de la GPU.

Para mitigar este problema, actualiza tu versión de GKE a una de las siguientes:

  • 1.28.8-gke.1206000 y versiones posteriores
  • 1.29.3-gke.1344000 y versiones posteriores

Para obtener más información, consulta las notas de la versión de GPUDirect-TCPXO.

Error: Failed to get device for nvidia0: device nvidia0 not found.

El siguiente error indica que XID 62 y RmInitAdapter han fallado en la GPU con el número secundario 0:

Failed to get device for nvidia0: device nvidia0 not found.

La versión 525.105.17 del controlador de NVIDIA tiene un error que puede provocar errores de comunicación (XID) e impedir que la GPU se inicialice correctamente, lo que provoca un fallo en la inicialización de la GPU.

Para solucionar este problema, actualiza el controlador de NVIDIA a la versión 525.110.11 o posterior.

Asignar la versión de GKE y la versión de la imagen de nodo de Container-Optimized OS a la versión del controlador de GPU

Para encontrar las versiones del controlador de GPU que se corresponden con las versiones de GKE y las versiones de la imagen de nodo de Container-Optimized OS, sigue estos pasos:
  1. Asocia las versiones de la imagen de nodo de Container-Optimized OS a las versiones de parche de GKE de la versión de GKE específica en la que quieras encontrar la versión del controlador de GPU. Por ejemplo, 1.33.0-gke.1552000 usa cos-121-18867-90-4.
  2. Elige el hito de la versión de la imagen de nodo de Container-Optimized OS en las notas de la versión de Container-Optimized OS. Por ejemplo, elige el hito 121 para cos-121-18867-90-4.
  3. En la página de notas de la versión de la milestone específica, busca la nota de la versión correspondiente a la versión de la imagen de nodo de Container-Optimized OS. Por ejemplo, en las notas de la versión de Container-Optimized OS: Milestone 121, consulta cos-121-18867-90-4. En la tabla de la columna Controladores de GPU, haz clic en Ver lista para ver la información de la versión del controlador de GPU.

Restablecer GPUs en máquinas virtuales A3

Para solucionar algunos problemas, es posible que tengas que restablecer la GPU en una VM A3.

Para restablecer la GPU, sigue estos pasos:

  1. Elimina los pods que soliciten recursos de GPU del nodo en el que necesites restablecer la GPU.

  2. Inhabilita el complemento de dispositivo de GPU en el nodo:

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    Sustituye NODE_NAME por el nombre del nodo.

  3. Conéctate a la VM que respalda el nodo.

  4. En la sesión SSH, reinicia la GPU:

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

  5. Vuelve a habilitar el complemento de dispositivo de GPU:

    kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers \| awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
    --overwrite

GPUs en nodos confidenciales de GKE

En las siguientes secciones se explica cómo identificar y solucionar problemas con las GPUs que se ejecutan en nodos de GKE confidenciales.

Las cargas de trabajo de GPU no se programan en nodos de Confidential GKE

Los nodos de GKE confidenciales requieren que instales manualmente un controlador de GPU que corresponda al tipo de GPU seleccionado y a tu versión de GKE. Si tus pods de GPU no se programan en nodos de GKE confidenciales y permanecen en el estado Pending, describe el DaemonSet de instalación del controlador:

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

Si la salida devuelve un error NotFound, instala el controlador.

Si el DaemonSet está en ejecución, el resultado será similar al siguiente:

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

En este resultado, comprueba que el campo nodeAffinity contiene la clave cloud.google.com/gke-confidential-nodes-instance-type. Si la salida no contiene esta clave, significa que el DaemonSet de instalación del controlador no admite nodos de GKE confidenciales.

Despliega el DaemonSet que admite GPUs en nodos de GKE confidenciales:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

Después de instalar los controladores, comprueba si tus cargas de trabajo de GPU se inician correctamente.

Error: No se ha podido asignar el vector del dispositivo

El siguiente mensaje de error en los registros del contenedor de GPU indica que la GPU se ha separado de la instancia de VM del nodo:

Failed to allocate device vector A (error code unknown error)!

Este desvinculamiento puede deberse a un error de hardware o a un problema con las claves de cifrado.

Para solucionar este problema, reinicia la instancia del nodo. Esta operación es disruptiva y afecta a todas las cargas de trabajo de ese nodo. Para reiniciar la instancia, sigue estos pasos:

  1. Obtén el nombre del nodo que ejecuta el pod de GPU:

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    Sustituye POD_NAME por el nombre del pod que falla.

    El resultado debería ser similar al siguiente:

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. Restablece la instancia de Compute Engine:

    gcloud compute instances reset NODE_NAME

    Sustituye NODE_NAME por el nombre del nodo de la salida del paso anterior.

    La CLI de gcloud busca VMs con ese nombre en tu proyecto activo. Si se te pide que selecciones una zona, especifica Y.

  3. Comprueba si tus cargas de trabajo de GPU se ejecutan sin errores.

Error: no se ha podido descifrar (error -74)

El siguiente mensaje de error en los registros de nodos indica que se han perdido las claves de cifrado de la GPU:

Decryption failed with error -74

Este error se produce cuando falla el daemon de persistencia de NVIDIA, que se ejecuta en la instancia de VM del nodo. Si aparece este mensaje de error, reinicia la instancia:

gcloud compute instances reset NODE_NAME

Sustituye NODE_NAME por el nombre del nodo que falla.

La CLI de gcloud busca VMs con ese nombre en tu proyecto activo. Si se te pide que selecciones una zona, especifica Y.

Si el problema persiste después de restablecer la instancia, ponte en contacto con el servicio de atención al cliente de Cloud o envía un error del producto. Para obtener más información, consulta el artículo Obtener asistencia.

Buscar errores de XID

El conjunto de daemons gpu-device-plugin se ejecuta en el espacio de nombres kube-system y es responsable de lo siguiente:

  • Programación de cargas de trabajo de GPU: asignación de recursos de GPU a pods.
  • Comprobación del estado de la GPU: monitoriza el estado de tus GPUs.
  • Recogida de métricas de GPU: recoge métricas relacionadas con la GPU, como el ciclo de actividad y el uso de memoria.

gpu-device-plugin usa la biblioteca de gestión de NVIDIA (NVML) para detectar errores XID. Cuando se produce un error de XID, el pod gpu-device-plugin que se ejecuta en el nodo afectado registra el error. Hay dos tipos de registros de errores de XID:

  • Errores de XID no críticos:
    • Formato del registro: Skip error Xid=%d as it is not Xid Critical
    • Significado: estos errores no se consideran críticos. Pueden deberse a varios problemas de software o hardware.
    • Acción: GKE no toma ninguna medida automatizada en caso de errores XID no críticos.
  • Errores críticos de XID:
    • Formato del registro: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Significado: Estos errores indican un problema de hardware de la GPU.
    • Acción:
      • GKE marca los recursos de GPU del nodo como no disponibles.
      • GKE impide que las cargas de trabajo de GPU se programen en el nodo.
      • Si la reparación automática de nodos está habilitada, GKE volverá a crear el nodo.

Problemas de GPUDirect-TCPX(O)

En esta sección se proporciona información para solucionar problemas de GPUDirect-TCPX(O).

Notas de la versión e instrucciones para cambiar a una edición superior

Si eres un usuario nuevo, consulta Maximizar el ancho de banda de la red de GPU en clústeres en modo Estándar para obtener información sobre cómo usar GPUDirect-TCPX(O). Si ya eres usuario, consulta las notas de la versión de GPUDirect-TCPXO para obtener información sobre la versión y las instrucciones de actualización, ya que se lanzan nuevas versiones continuamente.

Depurar con registros de NCCL

Si no puedes resolver un problema con NCCL, recoge los registros de NCCL con información de depuración. Estos registros contienen información valiosa sobre las operaciones de NCCL y pueden ayudarte a encontrar la causa del problema. Si no puedes resolver el problema, recoge estos registros antes de abrir un caso con el equipo de Asistencia de Google Cloud. Estos registros pueden ayudar al equipo de Asistencia de Google Cloud a resolver tu problema más rápidamente.

Para generar y recoger los registros, sigue estos pasos:

  1. Define las siguientes variables de entorno en el manifiesto de tu pod o aplicación:

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    Para obtener más información sobre estas variables de entorno, consulta el artículo sobre cómo recoger registros de depuración de NCCL.

  2. Para generar datos para tus registros, ejecuta una prueba NCCL. La forma de ejecutar esta prueba depende del tipo de clúster que utilices. En los clústeres de GKE, puedes desplegar y ejecutar pruebas de NCCL con Topology Aware Scheduling (TAS). Después de ejecutar la prueba NCCL, esta genera automáticamente los registros en todos los nodos participantes.

  3. Recoge los registros de todos los nodos. Verifica que has recogido los registros de NCCL de todos los nodos comprobando que contienen la siguiente información:

    • Los nombres de host de todas las VMs implicadas en una carga de trabajo.
    • Los PIDs de todos los procesos relevantes de la VM.
    • El rango de todas las GPUs que usa la carga de trabajo en cada VM.

    Si no sabes dónde se encuentran los archivos de registro, en el siguiente ejemplo se muestra dónde crea NCCL los archivos de registro cuando la variable NCCL_DEBUG_FILE se define como /tmp/nccl_log.%h.%p. Tienes dos VMs llamadas a3plus-vm-1 y a3plus-vm-2, y cada una ejecuta ocho procesos en el contenedor de carga de trabajo. En este caso, NCCL crea los siguientes archivos de registro en el directorio /tmp del contenedor de la carga de trabajo de cada máquina virtual:

    • En a3plus-vm-1: ocho archivos de registro llamados nccl_log.a3plus-vm-1.PID, donde PID es el ID del proceso.
    • En a3plus-vm-2: ocho archivos de registro llamados nccl_log.a3plus-vm-2.PID.

  4. Revisa los registros. Las entradas de registro de NCCL tienen el siguiente formato:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Estas entradas de registro contienen los siguientes valores:

    • HOSTNAME: el nombre de host de la VM. Este valor identifica qué máquina virtual se estaba usando cuando NCCL generó la entrada de registro.
    • PID: el PID. Este valor identifica el proceso que ha generado la entrada de registro.
    • TID: el ID de la conversación. Este valor identifica qué hilo del proceso se estaba usando cuando NCCL generó la entrada de registro.
    • RANK: ID de rango local. Este valor identifica qué GPU se estaba usando cuando NCCL generó la entrada de registro. Los rangos se numeran de 0 a N, donde N es el número total de GPUs que participan en el proceso. Por ejemplo, si tu carga de trabajo se ejecuta con ocho GPUs por VM, cada VM debe tener ocho valores de rango diferentes (del 0 al 7).
    • NCCL_MESSAGE: mensaje descriptivo que proporciona más información sobre el evento e incluye la marca de tiempo de cuando NCCL creó el registro.

    Por ejemplo:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    Este ejemplo tiene los siguientes valores:

    • gke-a3plus-mega-np-2-aa33fe53-7wvq: el nombre de host.
    • 1581: el ID de proceso.
    • 1634: el ID de la conversación.
    • 1: ID de rango local.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: el mensaje que explica lo que ha ocurrido.

  5. Si vas a abrir un caso de asistencia, empaqueta los registros que has recogido junto con el resultado de la prueba de NCCL en un archivo ZIP. Incluye el archivo ZIP cuando envíes un caso de asistencia a Cloud Customer Care.

  6. Para dejar de recoger registros de depuración de NCCL, elimina las variables que has añadido en el paso 1.

Siguientes pasos