Despliegue de aplicaciones en clústeres Red Hat OpenShift

Con los clústeres de Red Hat® OpenShift® on IBM Cloud®, puede desplegar apps desde un archivo o repositorio remoto, como GitHub, con un solo mandato. Además, los clústeres se suministran con varios servicios incorporados que puede utilizar para ayudar a gestionar el clúster.

Cómo mover las apps a Red Hat OpenShift

Para crear una app en el clúster de Red Hat OpenShift on IBM Cloud, puede utilizar la consola o la CLI de Red Hat OpenShift.

¿Ve errores al desplegar la aplicación? Red Hat OpenShift tiene valores predeterminados distintos de Kubernetes de comunidad, por ejemplo, unas restricciones de contexto de seguridad más estrictas. Revise los escenarios prácticos en los que es posible que tenga que modificar las apps para poderlas desplegar en clústeres de Red Hat OpenShift.

Despliegue de apps mediante la consola

Puede crear apps mediante varios métodos en la consola de Red Hat OpenShift utilizando la perspectiva Desarrollador. Para obtener más información, consulte la documentación deRed Hat OpenShift.

Desde la consola, seleccione su grupo.
Pulse Consola web de Red Hat OpenShift.
En el conmutador de perspectiva, seleccione Desarrollador. La consola web de Red Hat OpenShift cambia a la perspectiva Desarrollador y el menú ahora muestra elementos como +Añadir, Topología y Compilaciones.
Pulse +Añadir.
En la barra de menús del panel Añadir, seleccione el Proyecto en el que desea crear la app en la lista desplegable.
Pulse el método que desea utilizar para añadir la app y siga las instrucciones. Por ejemplo, pulse Desde Git.

Despliegue de apps mediante la CLI

Para crear una aplicación en su clúster Red Hat OpenShift on IBM Cloud, utilice el comando oc new-app. Por ejemplo, puede hacer referencia a un repositorio de GitHub público, a un repositorio de GitLab público con un URL que termine en .git o a otro repositorio local o remoto. Para obtener más información, pruebe el tutorial y revise la documentación de Red Hat OpenShift.

oc new-app --name <app_name> https://github.com/<path_to_app_repo> [--context-dir=<subdirectory>]

¿Qué hace el comando new-app ?: El mandato new-app crea una configuración de compilación y una imagen de app a partir del código fuente, una configuración de despliegue para desplegar el contenedor en pods del clúster y un servicio para exponer la app dentro del clúster. Para más información sobre el proceso de compilación y otras fuentes además de Git, consulte la documentación de Red Hat OpenShift.

Despliegue de apps en nodos trabajadores específicos mediante la utilización de etiquetas

Cuando despliega una app, los pods de la app se despliegan de forma indiscriminada en varios nodos trabajadores del clúster. A veces, es posible que desee restringir los nodos de trabajador en los que desplegar los pods de la aplicación. Por ejemplo, es posible que desee que los pods de la app solo se desplieguen en nodos trabajadores de una determinada agrupación de nodos trabajadores porque dichos nodos trabajadores están en máquinas vacías. Para designar los nodos trabajadores en los que deben desplegarse los pods de la app, añada una regla de afinidad al despliegue de la app.

Antes de empezar

Acceda al clúster de Red Hat OpenShift.
Opcional: establezca una etiqueta para la agrupación de nodos trabajadores en el que desea ejecutar la app.

Para desplegar aplicaciones en nodos de trabajador específicos,

Obtenga el ID de la agrupación de nodos trabajadores en la que desea desplegar los pods de la app.
```
ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>
```
Obtenga una lista de los nodos trabajadores que están en la agrupación de nodos trabajadores y anote una de las direcciones IP privadas.
```
ibmcloud oc worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
```

Describa el nodo trabajador. En la salida de Labels, anote la etiqueta del ID de agrupación de nodos trabajadores, ibm-cloud.kubernetes.io/worker-pool-id.

En los pasos de este tema se utiliza un ID de agrupación de nodos trabajadores para desplegar pods de apps solo en nodos trabajadores dentro de dicha agrupación de nodos trabajadores. Para desplegar los pods de app en nodos trabajadores específicos utilizando otra etiqueta, anote esta etiqueta en su lugar. Por ejemplo, para desplegar pods de app solo en nodos trabajadores en una VLAN privada específica, utilice la etiqueta privateVLAN=.

oc describe node <worker_node_private_IP>

Salida de ejemplo

NAME:               10.xxx.xx.xxx
Roles:              <none>
Labels:             arch=amd64
                    beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=b3c.4x16.encrypted
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=us-south
                    failure-domain.beta.kubernetes.io/zone=dal10
                    ibm-cloud.kubernetes.io/encrypted-docker-data=true
                    ibm-cloud.kubernetes.io/ha-worker=true
                    ibm-cloud.kubernetes.io/iaas-provider=softlayer
                    ibm-cloud.kubernetes.io/machine-type=b3c.4x16.encrypted
                    ibm-cloud.kubernetes.io/sgx-enabled=false
                    ibm-cloud.kubernetes.io/worker-pool-id=00a11aa1a11aa11a1111a1111aaa11aa-11a11a
                    ibm-cloud.kubernetes.io/worker-version=1.32_1534
                    kubernetes.io/hostname=10.xxx.xx.xxx
                    privateVLAN=1234567
                    publicVLAN=7654321
Annotations:        node.alpha.kubernetes.io/ttl=0
...

Añade una regla de afinidad para la etiqueta ID del pool de trabajadores al despliegue de la aplicación.

Ejemplo de YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: ibm-cloud.kubernetes.io/worker-pool-id
                operator: In
                values:
                - <worker_pool_ID>
...

En la sección affinity del YAML de ejemplo, ibm-cloud.kubernetes.io/worker-pool-id es el valor de key y <worker_pool_ID> es el valor de value.

Aplique el archivo de configuración de despliegue actualizado.
```
oc apply -f with-node-affinity.yaml
```
Verifique que los pods de la app se han desplegado en los nodos trabajadores correctos.
1. Obtenga una lista de pods en el clúster.
```
oc get pods -o wide
```
  Salida de ejemplo
```
NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
cf-py-d7b7d94db-vp8pq  1/1       Running             0          15d       172.30.xxx.xxx   10.176.48.78
```
2. En la salida, identifique un pod para su app. Anote la dirección IP privada de NODE del nodo trabajador en el que está el pod.
  
  En la salida de ejemplo anterior, el pod de app cf-py-d7b7d94db-vp8pq está en un nodo trabajador con la dirección IP 10.xxx.xx.xxx.
3. Obtenga una lista de los nodos trabajadores de la agrupación de nodos trabajadores que ha designado en el despliegue de la app.
```
ibmcloud oc worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
```
  Salida de ejemplo
```
ID                                                 Public IP       Private IP     Machine Type      State    Status  Zone    Version
kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w7   169.xx.xxx.xxx  10.176.48.78   b3c.4x16          normal   Ready   dal10   1.8.6_1504
kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w8   169.xx.xxx.xxx  10.176.48.83   b3c.4x16          normal   Ready   dal10   1.8.6_1504
kube-dal12-crb20b637238bb471f8b4b8b881bbb4962-w9   169.xx.xxx.xxx  10.176.48.69   b3c.4x16          normal   Ready   dal12   1.8.6_1504
```
  Si ha creado una regla de afinidad de app basada en otro factor, obtenga ese valor en su lugar. Por ejemplo, para verificar que el pod de aplicación se ha desplegado en un nodo de trabajador en una VLAN específica, compruebe si la VLAN en la que está el nodo de trabajador está activa ejecutando ibmcloud oc worker get --cluster <cluster_name_or_ID> --worker <worker_ID>.
4. En la salida, verifique que el nodo trabajadores con la dirección IP privada que ha identificado en el paso anterior se ha desplegado en esta agrupación de nodos trabajadores.

Implementación de una aplicación en una máquina GPU NVIDIA

Si tiene un tipo de máquina GPU, puede acelerar el tiempo de proceso necesario para cargas de trabajo de gran intensidad de cálculo como, por ejemplo, IA, aprendizaje automático, inferencia, etc.

En los pasos siguientes, aprenderá a desplegar cargas de trabajo que requieren la GPU. Sin embargo, también puedes implantar aplicaciones que no necesiten procesar sus cargas de trabajo tanto en la GPU como en la CPU.

También puede intentar cargas de trabajo matemáticamente intensivas como, por ejemplo, la infraestructura de aprendizaje automático de TensorFlow con esta demo de Kubernetes.

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.

Limitaciones de clúster solo privado: si el clúster no tiene conectividad de red pública, debe permitir la conectividad de red pública o duplicar imágenes de registros externos y corrientes de imágenes en icr.io. En el ejemplo siguiente, la aplicación GPU utiliza el mercado OLM con secuencias de imágenes. Este ejemplo no funciona si su clúster no puede acceder al registro NVIDIA ( nvcr.io ).

Debe utilizar el operador GPU NVIDIA versión 1.3.1 o posterior. Cuando instale el operador de Discovery Feature Discovery, seleccione el canal de actualización que coincida con la versión de su clúster de Red Hat OpenShift. No instale los operadores a través de otro método, como una carta Helm.

Si tiene problemas para instalar el operador de descubrimiento de funciones ( Node ) o el operador de GPU ( NVIDIA ), póngase en contacto con el servicio de asistencia de NVIDIA para obtener ayuda o abra un problema en el repositorio del operador de GPU(NVIDIA)

Despliegue de una carga de trabajo

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

Para cargas de trabajo de GPU, debe especificar el campo resources: limits: nvidia.com/gpu en el 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 los 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 dispositivos Kubernetes establece la solicitud de recursos por defecto para que coincida con el límite. Debe especificar la clave como `nvidia.com/gpu`. Introduzca el número entero de GPUs que solicita, 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`.

Aplique el archivo YAML. Por ejemplo:
```
oc apply -f nvidia-devicequery.yaml
```

Compruebe el pod de trabajo filtrando sus pods por la etiqueta nvidia-devicequery. Verifique que STATUS es Completed.

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

Salida de ejemplo

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

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.

oc describe pod nvidia-devicequery-ppkd4

Salida de ejemplo

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
...

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

oc 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 GPU de prueba, es posible que desee configurar su clúster para ejecutar una herramienta que dependa del procesamiento de la GPU, como por ejemplo IBM Maximo Visual Inspection.

Implementación de una aplicación en una máquina Intel AI Accelerator (Gaudi 3)

Esta función sólo está disponible para las cuentas autorizadas. Para solicitar acceso, consulte Solicitud de acceso a las funciones permitidas.

Complete el siguiente ejemplo para desplegar la imagen de contenedor PyTorch de Intel Gaudí que un recupera un dispositivo Gaudí mediante el campo resource.limits. Antes de empezar, asegúrese de que su clúster cumple los siguientes requisitos.

Versión 4.18 y posteriores
Sólo clusters VPC
Sólo nodos trabajadores RHCOS
Operador Intel Gaudi Base v1.20.1 y posteriores

Para más información y ejemplos, consulte la documentación de Habana y el ejemplo de inicio rápido.

Copie el siguiente ejemplo de configuración de trabajo y guárdelo como un archivo llamado config.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: habanalabs-gaudi-demo
spec:
  template:
      spec:
        hostIPC: true
        restartPolicy: OnFailure
        containers:
          - name: habana-ai-base-container
            image: vault.habana.ai/gaudi-docker/1.21.0/ubuntu22.04/habanalabs/pytorch-installer-2.6.0:latest
            workingDir: /root
            command: ["hl-smi"]
            securityContext:
              capabilities:
                  add: ["SYS_NICE"]
            resources:
              limits:
                  habana.ai/gaudi: 8
                  memory: 409Gi
                  hugepages-2Mi: 9500Mi

Aplique el trabajo en su clúster.
```
oc apply -f config.yaml
```

Espere a que se inicien los pods y compruebe que el trabajo se ha completado.

oc get po -n default

Ejemplo

NAME                          READY   STATUS      RESTARTS   AGE
habanalabs-gaudi-demo-kmdcp   0/1     Completed   0          2m32s

Describa el módulo de empleo para obtener más detalles.

oc describe po habanalabs-gaudi-demo-kmdcp

Name:             habanalabs-gaudi-demo-kmdcp
Namespace:        default
Priority:         0
Service Account:  default
Node:             test-csrq76620trmo9r8j7u0-btsstagevpc-gaudi3s-00013059/10.180.0.83
Start Time:       Tue, 27 May 2025 14:41:50 -0400
Labels:           batch.kubernetes.io/controller-uid=c3b33c8a-5fef-4312-9d59-c8b13c03313a
                  batch.kubernetes.io/job-name=habanalabs-gaudi-demo
                  controller-uid=c3b33c8a-5fef-4312-9d59-c8b13c03313a
                  job-name=habanalabs-gaudi-demo
Annotations:      cni.projectcalico.org/containerID: 7c883dfa9c681ee2c4128b1a5412d4dc181842d0de2a4b7b8019eefc06df37ca
                  cni.projectcalico.org/podIP:
                  cni.projectcalico.org/podIPs:
Status:           Succeeded
IP:               172.17.151.97
IPs:
  IP:           172.17.151.97
Controlled By:  Job/habanalabs-gaudi-demo
Containers:
  habana-ai-base-container:
    Container ID:  cri-o://d75288e9b467f3f820e05e770bbc3d9a2b11cbf8155a54a129fc083d5d507571
    Image:         vault.habana.ai/gaudi-docker/1.21.0/ubuntu22.04/habanalabs/pytorch-installer-2.6.0:latest
    Image ID:      vault.habana.ai/gaudi-docker/1.21.0/ubuntu22.04/habanalabs/pytorch-installer-2.6.0@sha256:cd599626a8f4d1c3a7b354ccf4ef73e19196f09030d02261d4900bf3467a964c
    Port:          <none>
    Host Port:     <none>
    Command:
      hl-smi
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Tue, 27 May 2025 14:41:53 -0400
      Finished:     Tue, 27 May 2025 14:41:54 -0400
    Ready:          False
    Restart Count:  0
    Limits:
      habana.ai/gaudi:  8
      hugepages-2Mi:    9500Mi
      memory:           409Gi
    Requests:
      habana.ai/gaudi:  8
      hugepages-2Mi:    9500Mi
      memory:           409Gi
    Environment:        <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-8vn42 (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   False
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
Volumes:
  kube-api-access-8vn42:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                              node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                              node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason          Age   From               Message
  ----    ------          ----  ----               -------
  Normal  Scheduled       53s   default-scheduler  Successfully assigned default/habanalabs-gaudi-demo-kmdcp to test-csrq76620trmo9r8j7u0-btsstagevpc-gaudi3s-00013059
  Normal  AddedInterface  52s   multus             Add eth0 [172.17.151.97/32] from k8s-pod-network
  Normal  Pulling         52s   kubelet            Pulling image "vault.habana.ai/gaudi-docker/1.21.0/ubuntu22.04/habanalabs/pytorch-installer-2.6.0:latest"
  Normal  Pulled          50s   kubelet            Successfully pulled image "vault.habana.ai/gaudi-docker/1.21.0/ubuntu22.04/habanalabs/pytorch-installer-2.6.0:latest" in 2.146s (2.146s including waiting). Image size: 5188441181 bytes.
  Normal  Created         50s   kubelet            Created container: habana-ai-base-container
  Normal  Started         50s   kubelet            Started container habana-ai-base-container

Obtenga los pod logs para ver los detalles del dispositivo Gaudí.

oc logs habanalabs-gaudi-demo-kmdcp

Salida de ejemplo

+-----------------------------------------------------------------------------+
| HL-SMI Version:                              hl-1.21.0-fw-59.2.1.0          |
| Driver Version:                                     1.20.1-366eb9c          |
| Nic Driver Version:                                 1.20.1-213b09b          |
|-------------------------------+----------------------+----------------------+
| AIP  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncor-Events|
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | AIP-Util  Compute M. |
|===============================+======================+======================|
|   0  HL-325L             N/A  | 0000:e9:00.0     N/A |                   0  |
| N/A   36C   P0  228W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   1  HL-325L             N/A  | 0000:c1:00.0     N/A |                   0  |
| N/A   37C   P0  226W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   2  HL-325L             N/A  | 0000:b7:00.0     N/A |                   0  |
| N/A   36C   P0  225W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   3  HL-325L             N/A  | 0000:ad:00.0     N/A |                   0  |
| N/A   40C   P0  228W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   4  HL-325L             N/A  | 0000:a3:00.0     N/A |                   0  |
| N/A   36C   P0  228W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   5  HL-325L             N/A  | 0000:df:00.0     N/A |                   0  |
| N/A   39C   P0  229W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   6  HL-325L             N/A  | 0000:d5:00.0     N/A |                   0  |
| N/A   36C   P0  231W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
|   7  HL-325L             N/A  | 0000:cb:00.0     N/A |                   0  |
| N/A   38C   P0  227W /  900W  |   672MiB / 131072MiB |     0%            0% |
|-------------------------------+----------------------+----------------------+
| Compute Processes:                                               AIP Memory |
|  AIP       PID   Type   Process name                             Usage      |
|=============================================================================|
|   0        N/A   N/A    N/A                                      N/A        |
|   1        N/A   N/A    N/A                                      N/A        |
|   2        N/A   N/A    N/A                                      N/A        |
|   3        N/A   N/A    N/A                                      N/A        |
|   4        N/A   N/A    N/A                                      N/A        |
|   5        N/A   N/A    N/A                                      N/A        |
|   6        N/A   N/A    N/A                                      N/A        |
|   7        N/A   N/A    N/A                                      N/A        |
+=============================================================================+

Despliegue de una aplicación en un equipo AMD MI300x

Red Hat CoreOS 4.18 y más tarde VPC

Para instalar los operadores necesarios, debe permitir el tráfico saliente a Red Hat Marketplace y OperatorHub.
Instale los siguientes operadores en su clúster:
Después de instalar los operadores, siga la documentación de AMD para configurar los controladores. Nota: No es necesario poner en la lista negra el módulo kernel in-tree amdgpu.