Soluciona problemas de GPU en GKE

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

Instalación del controlador de GPU

En esta sección, se proporciona información sobre la solución de problemas para dispositivos NVIDIA automáticos de la instalación de controladores en GKE.

Falla la instalación del controlador en 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 requerida para esas GPUs. Como resultado, el Pod del complemento de dispositivo de GPU permanece en estado pendiente y es posible que tus cargas de trabajo de GPU en esos nodos experimenten problemas.

Para resolver 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

Como alternativa, puedes instalar manualmente la versión 535 o 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 resolver este problema en las GPUs H200, debes instalar manualmente la versión 550 o 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 del dispositivo GPU fallan con errores CrashLoopBackOff.

El siguiente problema ocurre si usaste el método de instalación manual de controladores en tu grupo de nodos antes del 25 de enero de 2023 y luego actualizaste tu grupo de nodo a una versión de GKE compatible con la instalación automática de controladores. Ambas cargas de trabajo de instalación existen al mismo tiempo y tratan de instalar versiones de controladores en conflicto en tus nodos.

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

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

Para resolver este problema, realiza las siguientes acciones:

  • Quita el DaemonSet de instalación manual del controlador de tu clúster. Esto borra la carga de trabajo de instalación en conflicto y permite que GKE instale 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 para la instalación manual de controladores a tu clúster. El 25 de enero de 2023, actualizamos el manifiesto para que ignore 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 para tu grupo de nodos. El DaemonSet de instalación de controladores existente debería funcionar como se espera después de que se complete 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

    Reemplaza lo siguiente:

    • POOL_NAME: el nombre del grupo de nodos
    • GPU_TYPE: Es el tipo de GPU que ya se usa en el grupo de nodos.
    • GPU_COUNT: Es la cantidad de GPU que ya están conectadas al grupo de nodos.
    • CLUSTER_NAME: Es 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 Cómo asignar la versión de GKE y la versión de imagen de nodo de Container-Optimized OS a la versión del controlador de GPU.

Error: "La imagen del contenedor cos-nvidia-installer:fixed no está presente con la política de extracción Never" o "La imagen del contenedor ubuntu-nvidia-installer:fixed no está presente con la política de extracción Never".

Este problema se produce cuando los Pods de nvidia-driver-installer están en estado PodInitializing y los Pods del complemento del dispositivo GPU o del instalador del controlador de GPU informan el siguiente error. El mensaje de error específico depende del sistema operativo que se ejecuta 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 ocurrir cuando el recolector de elementos no utilizados quita la imagen del controlador de NVIDIA precargada para liberar espacio en un nodo. Cuando se recree el Pod del controlador o se reinicie su contenedor, GKE no podrá ubicar la imagen precargada.

Para mitigar el problema de recolección de elementos no utilizados cuando ejecutas COS, actualiza tus nodos de GKE a una de estas versiones que contienen 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 Cómo asignar la versión de GKE y la versión de imagen de nodo de Container-Optimized OS a la versión del controlador de GPU.

Si tus nodos ejecutan Ubuntu, aún no hay una 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 garantizar la configuración correcta de los controladores de GPU de NVIDIA. 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 realizar el mantenimiento del host. Esto puede ocurrir en nodos confidenciales o nodos con GPUs que usan almacenamiento efímero en SSD locales. 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 produjo un evento de mantenimiento del host, usa 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 las siguientes:

  • 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 pudieron configurar los directorios de instalación del controlador de GPU: No se pudo crear la superposición de lib64: No se pudo crear el directorio /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

Encuentras este error en el contenedor del instalador del controlador de GPU dentro del complemento de dispositivo 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 ocurre 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 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, lee las Notas de la versión de GPUDirect-TCPXO.

Error: No se pudo obtener el dispositivo para nvidia0: no se encontró el dispositivo nvidia0.

El siguiente error indica que XID 62 y RmInitAdapter fallaron para 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) y evitar que la GPU se inicialice correctamente, lo que genera una falla en la inicialización de la GPU.

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

Asigna la versión de GKE y la versión de 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 asignan a las versiones de GKE y a las versiones de imagen de nodo de Container-Optimized OS, sigue estos pasos:
  1. Asigna versiones de imagen de nodo de Container-Optimized OS a versiones de parche de GKE para la versión específica de GKE en la que deseas 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 del 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 del evento importante específico, busca la nota de la versión correspondiente a la versión específica de la imagen del nodo de Container-Optimized OS. Por ejemplo, en Container-Optimized OS Release Notes: 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.

Restablece las GPUs en VMs A3

Algunos problemas pueden requerir que restablezcas la GPU en una VM A3.

Para restablecer la GPU, sigue estos pasos:

  1. Quita los Pods que solicitan recursos de GPU del nodo en el que necesitas restablecer la GPU.

  2. Inhabilita el complemento del dispositivo 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

    Reemplaza NODE_NAME por el nombre del conjunto de datos.

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

  4. En la sesión de SSH, restablece la GPU:

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

  5. Vuelve a habilitar el complemento del 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

GPU en Confidential GKE Nodes

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

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

Los Confidential GKE Nodes 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 los 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 el resultado muestra un error de NotFound, instala el controlador.

Si el DaemonSet está en ejecución, el resultado es 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, verifica que el campo nodeAffinity contenga la clave cloud.google.com/gke-confidential-nodes-instance-type. Si el resultado no contiene esta clave, el DaemonSet de instalación del controlador no admite nodos de GKE confidenciales.

Implementa el DaemonSet que admite GPUs en Confidential GKE Nodes:

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, verifica si tus cargas de trabajo de GPU se inician correctamente.

Error: No se pudo asignar el vector del dispositivo

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

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

Este desprendimiento puede deberse a un error de hardware o a un problema con las claves de encriptación.

Para resolver este problema, reinicia la instancia del nodo. Esta operación es disruptiva y afecta todas las cargas de trabajo en 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"

    Reemplaza POD_NAME por el nombre del Pod que falla.

    El resultado es similar a este:

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

  2. Restablece la instancia de Compute Engine:

    gcloud compute instances reset NODE_NAME

    Reemplaza NODE_NAME por el nombre del nodo que se muestra en el resultado del paso anterior.

    Gcloud CLI busca VMs con ese nombre en tu proyecto activo. Si ves un mensaje para seleccionar una zona, especifica Y.

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

Error: No se pudo desencriptar con el error -74

El siguiente mensaje de error en los registros del nodo indica que se perdieron las claves de encriptación de la GPU:

Decryption failed with error -74

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

gcloud compute instances reset NODE_NAME

Reemplaza NODE_NAME por el nombre del nodo con errores.

Gcloud CLI busca VMs con ese nombre en tu proyecto activo. Si ves un mensaje para seleccionar una zona, especifica Y.

Si restablecer la instancia no soluciona el problema, comunícate con Atención al cliente de Cloud o envía un error del producto. Para obtener más información, consulta Obtén asistencia.

Cómo encontrar errores de XID

El daemonset gpu-device-plugin se ejecuta dentro del 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
  • Verificación de estado de la GPU: Supervisa el estado de tus GPUs.
  • Recopilación de métricas de GPU: Recopila métricas relacionadas con la GPU, como el ciclo de trabajo y el uso de memoria.

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

  • Errores de XID no críticos:
    • Formato de registro: Skip error Xid=%d as it is not Xid Critical
    • Significado: Estos errores se consideran no críticos. Pueden deberse a varios problemas de software o hardware.
    • Acción: GKE no realiza ninguna acción automatizada para los errores de XID no críticos.
  • Errores críticos de XID:
    • Formato de 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 en mal estado.
      • GKE evita que se programen cargas de trabajo de GPU 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 relacionados con GPUDirect-TCPX(O).

Notas de la versión e instrucciones de actualización

Para los usuarios nuevos, Maximiza el ancho de banda de red de la GPU en clústeres en modo estándar proporciona orientación para usar GPUDirect-TCPX(O). Si ya eres usuario, lee 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 de forma continua.

Cómo depurar con registros de NCCL

Si no puedes resolver un problema con NCCL, recopila 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 el origen del problema. Si no puedes resolver el problema, recopila estos registros antes de abrir un caso con Atención al cliente de Cloud. Estos registros pueden ayudar a la Atención al cliente de Cloud a resolver tu problema más rápido.

Para generar y recopilar los registros, completa los siguientes pasos:

  1. Configura las siguientes variables de entorno dentro del 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 cómo recopilar registros de depuración de NCCL.

  2. Para generar datos para tus registros, ejecuta una prueba de NCCL. La forma de ejecutar esta prueba depende del tipo de clúster que uses. En el caso de los clústeres de GKE, puedes implementar y ejecutar la prueba de NCCL con la programación consciente de la topología (TAS). Después de ejecutar la prueba de NCCL, esta herramienta genera automáticamente los registros en todos los nodos participantes.

  3. Recopila los registros de todos los nodos. Verifica que hayas recopilado los registros de NCCL de todos los nodos. Para ello, asegúrate de que los registros contengan la siguiente información:

    • Son los nombres de host de todas las VMs que participan en una carga de trabajo.
    • Son los PIDs de todos los procesos relevantes en la VM.
    • Son los rangos 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 NCCL crea los archivos de registro cuando la variable NCCL_DEBUG_FILE se establece en /tmp/nccl_log.%h.%p. Tienes dos VMs llamadas a3plus-vm-1 y a3plus-vm-2, y cada VM ejecuta ocho procesos dentro del contenedor de carga de trabajo. En este caso, NCCL crea los siguientes archivos de registro en el directorio /tmp dentro del contenedor de la carga de trabajo en cada VM:

    • 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: Es el nombre de host de la VM. Este valor identifica qué VM se estaba usando cuando NCCL generó la entrada de registro.
    • PID: Es el PID. Este valor identifica qué proceso generó la entrada de registro.
    • TID: Es el ID del subproceso. Este valor identifica qué subproceso dentro del proceso se usaba cuando NCCL generó la entrada de registro.
    • RANK: Es el ID de clasificación local. Este valor identifica qué GPU se usaba cuando NCCL generó la entrada de registro. Los rangos se numeran del 0 al N, donde N es la cantidad total de GPUs involucradas en el proceso. Por ejemplo, si tu carga de trabajo se ejecuta con ocho GPUs por VM, cada VM debe tener ocho valores de clasificación diferentes (del 0 al 7).
    • NCCL_MESSAGE: Es un mensaje descriptivo que proporciona más información sobre el evento y que incluye la marca de tiempo de cuándo 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: Es el nombre de host.
    • 1581: Es el ID del proceso.
    • 1634: Es el ID del subproceso.
    • 1: Es el ID de clasificación local.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: Es el mensaje que explica lo que sucedió.

  5. Si abres un caso de asistencia, empaqueta los registros que recopilaste, 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 Atención al cliente de Cloud.

  6. Para dejar de recopilar registros de depuración de NCCL, quita las variables que agregaste en el paso 1.

¿Qué sigue?