Inicio del panel de control de Kubernetes desde la consola de IBM Cloud

1. Inicie una sesión en la consola de IBM Cloud.
2. En la barra de menús, seleccione la cuenta que desea utilizar.
3. En el menú , haga clic en Contenedores > Clusters.
4. En la página Clústeres, pulse el clúster al que desea acceder.
5. En la página de detalles del clúster, pulse el botón Panel de control de Kubernetes.

Inicio del panel de control de Kubernetes desde la CLI

El método CLI permite la automatización y la integración CI/CD. Instale la CLI antes de empezar.

1. Consigue tus credenciales de Kubernetes.

   kubectl config view -o jsonpath='{.users[0].user.auth-provider.config.id-token}'
   

2. Copia el valor id-token de la salida.

3. Inicie el proxy.

   kubectl proxy
   

   Salida de ejemplo

   Starting to serve on 127.0.0.1:8001
   

4. Inicie sesión en el panel de control.

   1. Accede a la siguiente dirección URL en tu navegador:

       http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
       ```
   2. Seleccione el método de autenticación **Token** en la página de inicio de sesión.
   
   3. Pega el valor **del id-token** en el campo **Token** y haz clic en **INICIAR SESIÓN**.
   
   

Utilice CTRL+C para salir del comando proxy. Vuelva a ejecutar kubectl proxy para reiniciar el cuadro de mandos.

Requisitos previos

Antes de empezar

• Cree un clúster o una agrupación de nodos trabajadores que utilice un tipo de GPU. Tenga en cuenta que la configuración de una máquina nativa puede tardar más de un día laborable en completarse. Para obtener una lista de los tipos disponibles, consulte los enlaces siguientes.

  • Tipos clásicos
  • Tipos de VPC

• Asegúrese de que tiene asignado un rol de acceso al servicio que otorgue el rol de RBAC de Kubernetes adecuado para que pueda trabajar con los recursos de Kubernetes en el clúster.

Para Kubernetes versión 1.36 y posteriores: Debe instalar y gestionar la pila de controladores de GPU NVIDIA por su cuenta. IBM Cloud Kubernetes Service ya no proporciona controladores de GPU preinstalados en los nodos trabajadores. Siga la guía de instalación de NVIDIA GPU Operator para instalar los componentes necesarios:

• NVIDIA controlador del núcleo
• Componentes de ejecución de contenedores (por ejemplo, nvidia-container-toolkit)
• Kubernetes complemento de dispositivo

Hasta que se instale el controlador, los pods que soliciten GPU permanecerán en el estado Pending. Pasarán a Running automáticamente una vez que esté disponible un controlador compatible en el nodo.

Para Kubernetes versión 1.35 y anteriores: IBM-siempre que los controladores de GPU se instalen automáticamente en los nodos trabajadores de GPU. No es necesario instalar ningún controlador adicional.

Despliegue de una carga de trabajo

1. Cree un archivo YAML. En este ejemplo, un YAML Job gestiona cargas de trabajo de tipo por lotes creando un pod de corta duración que se ejecuta hasta que el comando se completa y finaliza correctamente.

   Para las cargas de trabajo de GPU, debe especificar el campo resources: limits: nvidia.com/gpu en el archivo YAML del trabajo.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: nvidia-devicequery
     labels:
       name: nvidia-devicequery
   spec:
     template:
       metadata:
         labels:
           name: nvidia-devicequery
       spec:
         containers:
         - name: nvidia-devicequery
           image: nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04
           imagePullPolicy: IfNotPresent
           resources:
             limits:
               nvidia.com/gpu: 2
         restartPolicy: Never
   

   Comprender sus componentes YAML

   Componente	Descripción
   Metadatos y nombres de etiqueta	Especifique un nombre y una etiqueta para el trabajo y use el mismo nombre en los metadatos del archivo y en los metadatos de la spec template. Por ejemplo, nvidia-devicequery.
   containers.image	Proporcione la imagen de la que el contenedor es su instancia en ejecución. En este ejemplo, el valor se establece para utilizar la imagen de consulta de dispositivo DockerHub CUDA:nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04.
   containers.imagePullPolicy	Para obtener mediante pull una nueva imagen solo si actualmente dicha imagen no está en el nodo trabajador, especifique IfNotPresent.
   resources.limits	Para máquinas con GPU, debe especificar el límite del recurso. El complemento de dispositivoKubernetes configura la solicitud de recursos predeterminada para que coincida con el límite. Debes especificar la clave como nvidia.com/gpu. Introduce el número entero de GPU que solicitas, por ejemplo, 2. Tenga en cuenta que los pods de contenedor no comparten GPU, y que las GPU no se pueden sobreutilizar. Por ejemplo, si solo tiene una máquina mg1c.16x128, solo tiene 2 GPU en dicha máquina y puede especificar un máximo de 2.

2. Aplique el archivo YAML. Por ejemplo:

   kubectl apply -f nvidia-devicequery.yaml
   

3. Comprueba el pod de trabajo filtrando tus pods por la etiqueta nvidia-devicequery. Verifique que STATUS es Completed.

   kubectl get pod -A -l 'name in (nvidia-devicequery)'
   

   Salida de ejemplo

   NAME                  READY     STATUS      RESTARTS   AGE
   nvidia-devicequery-ppkd4      0/1       Completed   0          36s
   

4. Describa el pod para ver cómo el plugin de dispositivo de GPU planificó el pod.

   • En los campos Limits y Requests podrá ver el límite de recurso que especificó coincide con la solicitud que el plugin de dispositivo estableció de forma automática.
   • En los sucesos, verifique que el pod está asignado a su nodo trabajador con GPU.

       kubectl describe pod nvidia-devicequery-ppkd4
       ```
       Salida de ejemplo
       ```sh {: screen}
       NAME:           nvidia-devicequery-ppkd4
       Namespace:      default
       ...
       Limits:
           nvidia.com/gpu:  1
       Requests:
           nvidia.com/gpu:  1
       ...
       Events:
       Type    Reason                 Age   From                     Message
       ----    ------                 ----  ----                     -------
       Normal  Scheduled              1m    default-scheduler        Successfully assigned nvidia-devicequery-ppkd4 to 10.xxx.xx.xxx
       ...
       ```
   

5. Para verificar que el trabajo utilizó la GPU para los cálculos de su carga de trabajo, compruebe los registros.

   kubectl logs nvidia-devicequery-ppkd4
   

   Salida de ejemplo

   /cuda-samples/sample Starting...
   CUDA Device Query (Runtime API) version (CUDART static linking)
   Detected 1 CUDA Capable device(s)
   Device 0: "Tesla P100-PCIE-16GB"
   CUDA Driver Version / Runtime Version          11.4 / 11.7
   CUDA Capability Major/Minor version number:    6.0
   Total amount of global memory:                 16281 MBytes (17071734784 bytes)
   (056) Multiprocessors, (064) CUDA Cores/MP:    3584 CUDA Cores
   GPU Max Clock rate:                            1329 MHz (1.33 GHz)
   Memory Clock rate:                             715 Mhz
   Memory Bus Width:                              4096-bit
   L2 Cache Size:                                 4194304 bytes
   Maximum Texture Dimension Size (x,y,z)         1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
   Maximum Layered 1D Texture Size, (num) layers  1D=(32768), 2048 layers
   Maximum Layered 2D Texture Size, (num) layers  2D=(32768, 32768), 2048 layers
   Total amount of constant memory:               65536 bytes
   Total amount of shared memory per block:       49152 bytes
   Total shared memory per multiprocessor:        65536 bytes
   Total number of registers available per block: 65536
   Warp size:                                     32
   Maximum number of threads per multiprocessor:  2048
   Maximum number of threads per block:           1024
   Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
   Max dimension size of a grid size    (x,y,z): (2147483647, 65535, 65535)
   Maximum memory pitch:                          2147483647 bytes
   Texture alignment:                             512 bytes
   Concurrent copy and kernel execution:          Yes with 2 copy engine(s)
   Run time limit on kernels:                     No
   Integrated GPU sharing Host Memory:            No
   Support host page-locked memory mapping:       Yes
   Alignment requirement for Surfaces:            Yes
   Device has ECC support:                        Enabled
   Device supports Unified Addressing (UVA):      Yes
   Device supports Managed Memory:                Yes
   Device supports Compute Preemption:            Yes
   Supports Cooperative Kernel Launch:            Yes
   Supports MultiDevice Co-op Kernel Launch:      Yes
   Device PCI Domain ID / Bus ID / location ID:   0 / 175 / 0
   Compute Mode:
   < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
   deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 11.4, CUDA Runtime Version = 11.7, NumDevs = 1
   Result = PASS
   

   En este ejemplo, verá que se ha utilizado una GPU para ejecutar el trabajo porque la GPU se ha planificado en el nodo trabajador. Si el límite se establece en 2, sólo se muestran 2 GPU.

Ahora que ha implementado una carga de trabajo de prueba con GPU, quizá le interese configurar su clúster para ejecutar una herramienta que utilice el procesamiento por GPU, como IBM Maximo Visual Inspection.