Distribuzione delle app nei cluster di Red Hat OpenShift

Con i cluster Red Hat® OpenShift® on IBM Cloud®, puoi distribuire le applicazioni da un file o un repository remoto come GitHub con un singolo comando. Inoltre, i tuoi cluster sono forniti con diversi servizi integrati che puoi utilizzare per gestire più agevolmente il tuo cluster.

Trasferire le tue app su Red Hat OpenShift

Per creare un'applicazione nel cluster Red Hat OpenShift on IBM Cloud, si può usare la console o la CLI di Red Hat OpenShift.

Red Hat OpenShift ha impostazioni predefinite diverse da quelle della comunità Kubernetes, come ad esempio vincoli di sicurezza più severi. Esamina gli scenari più comuni in cui potrebbe essere necessario modificare le tue app per poterle distribuire su cluster di Red Hat OpenShift.

Distribuzione delle applicazioni tramite la console

È possibile creare app in vari modi nella console di Red Hat OpenShift utilizzando la prospettiva "Sviluppatore". Per ulteriori informazioni, consultare il sito Red Hat OpenShift documentazione.

Dalla console, selezionare il proprio cluster.
Fai clic su " Red Hat OpenShift " nella console web.
Dal commutatore della prospettiva, seleziona Developer. La console web di Red Hat OpenShift passa alla prospettiva "Sviluppatore" e il menu ora offre voci quali " +Aggiungi ", "Topologia " e "Build".
Fai clic su +Add.
Nella barra dei menu del riquadro Add, seleziona il progetto (Project ) in cui vuoi creare la tua applicazione dall'elenco a discesa.
Fai clic sul metodo che vuoi utilizzare per aggiungere la tua applicazione e attieniti alle istruzioni. Ad esempio, fai clic su From Git.

Distribuzione delle applicazioni tramite la CLI

Per creare un'applicazione nel cluster Red Hat OpenShift on IBM Cloud, utilizzare il comando oc new-app. Ad esempio, potresti fare riferimento a un repository GitHub pubblico, a un repository GitLab pubblico con un URL che termina con .git o a un altro repository locale o remoto. Per ulteriori informazioni, provare il tutorial e consultare il sito Red Hat OpenShift documentazione.

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

Cosa fa il comando new-app ?: Il comando new-app crea una configurazione di build e un'immagine dell'applicazione dal codice sorgente, una configurazione di distribuzione per distribuire il contenitore ai pod nel tuo cluster e un servizio per esporre l'applicazione all'interno del cluster. Per maggiori informazioni sul processo di compilazione e su altre fonti oltre Git, consultare la documentazione di Red Hat OpenShift.

Distribuzione delle applicazioni a specifici nodi di lavoro utilizzando le etichette

Quando distribuisci un'applicazione, i pod dell'applicazione vengono distribuiti indiscriminatamente ai vari nodi di lavoro nel tuo cluster. A volte, potrebbe essere necessario limitare i nodi di lavoro su cui devono essere distribuiti i pod dell'applicazione. Ad esempio, potresti voler distribuire i pod dell'applicazione solo ai nodi di lavoro di un determinato pool di nodi di lavoro, in quanto tali nodi si trovano su macchine bare metal. Per indicare i nodi di lavoro a cui devono essere distribuiti tali pod dell'applicazione, aggiungi una regola di affinità alla tua distribuzione dell'applicazione.

Prima di iniziare

Accedi al tuo cluster Red Hat OpenShift.
Facoltativo: imposta un'etichetta per il pool di nodi di lavoro su cui vuoi eseguire l'applicazione.

Per distribuire le app su nodi di lavoro specifici,

Ottieni l'ID del pool di nodi di lavoro a cui desideri distribuire i pod dell'applicazione.
```
ibmcloud oc worker-pool ls --cluster CLUSTER_NAME_OR_ID
```
Elenca i nodi di lavoro che si trovano nel pool di nodi di lavoro e prendi nota di uno degli indirizzi IP privati.
```
ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
```

Descrivi il nodo di lavoro. Nell'output Labels, prendi nota dell'etichetta dell'ID pool di nodi di lavoro, ibm-cloud.kubernetes.io/worker-pool-id.

I passi in questo argomento utilizzano un ID pool di nodi di lavoro per distribuire i pod dell'applicazione solo ai nodi di lavoro che si trovano all'interno di tale pool di nodi di lavoro. Per distribuire i pod dell'applicazione a specifici nodi di lavoro utilizzando un'etichetta diversa, prendi nota di questa etichetta. Ad esempio, per distribuire i pod dell'applicazione solo a nodi di lavoro su una specifica VLAN privata, utilizza l'etichetta privateVLAN=.

oc describe node <worker_node_private_IP>

Output di esempio

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.35_1534
                    kubernetes.io/hostname=10.xxx.xx.xxx
                    privateVLAN=1234567
                    publicVLAN=7654321
Annotations:        node.alpha.kubernetes.io/ttl=0
...

Aggiungi una regola di affinità per l'etichetta dell'ID del pool di worker alla distribuzione dell'app.

YAML di esempio

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

Nella sezione “affinity” dell’esempio YAML, ibm-cloud.kubernetes.io/worker-pool-id è l’ key e <worker_pool_ID> è l’ value.

Applica il file di configurazione della distribuzione aggiornato.
```
oc apply -f with-node-affinity.yaml
```

Verifica che i pod dell'applicazione vengano distribuiti ai nodi di lavoro corretti.

Elenca i pod nel tuo cluster.

    oc get pods -o wide
    ```
    Output di esempio
    ```sh {: screen}
    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. Nell'output, identifica un pod per la tua applicazione. Prendi nota dell'indirizzo IP privato **NODE** del nodo di lavoro in cui il pod è attivo.

    Nel precedente output di esempio, il pod dell'applicazione `cf-py-d7b7d94db-vp8pq` si trova su un nodo di lavoro con indirizzo IP `10.xxx.xx.xxx`.

3. Elenca i nodi di lavoro nel pool di nodi di lavoro che hai indicato nella tua distribuzione dell'applicazione.

```sh {: pre}
    ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
    Output di esempio

    ```sh {: screen}
    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
    ```
    Se hai creato una regola di affinità dell'applicazione basata su un altro fattore, utilizza tale valore. Ad esempio, per verificare che il pod dell'app sia stato distribuito su un nodo di lavoro in una VLAN specifica, visualizza la VLAN a cui appartiene il nodo di lavoro eseguendo il comando ` `ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID``.
    {: tip}

4. Nell'output, verifica che il nodo di lavoro con l'indirizzo IP privato che hai identificato nel passo precedente venga distribuito in questo pool di nodi di lavoro.

Distribuzione di un'app su una macchina con GPU NVIDIA

Se hai un tipo di macchina GPU, puoi accelerare il tempo di elaborazione richiesto per i carichi di lavoro intensivi di calcolo come l'intelligenza artificiale, l'apprendimento automatico, l'inferenza e altro ancora.

Nella seguente procedura, imparerai come distribuire i carichi di lavoro che richiedono la GPU. Tuttavia, è anche possibile distribuire applicazioni che non richiedono l'elaborazione dei propri carichi di lavoro sia sulla GPU che sulla CPU.

È inoltre possibile provare carichi di lavoro matematicamente intensivi, come il framework di TensorFlow machine learning con questa demo Kubernetes.

Prerequisiti

Prima di iniziare

Crea un cluster o un pool di nodi di lavoro che utilizza un flavor GPU. Tieni presente che l'impostazione di una macchina bare metal può richiedere più di un giorno lavorativo per essere completata. Per un elenco dei flavor disponibili, consultare i seguenti link.
- Versione classica
- VPC
Assicurati di disporre di un ruolo di accesso al servizio che ti conceda il ruolo RBAC “ Kubernetes ” appropriato, in modo da poter utilizzare le risorse “ Kubernetes ” presenti nel cluster.

Limitazioni del cluster solo privato: se il tuo cluster non dispone di connettività di rete pubblica, devi consentire la connettività di rete pubblica o le immagini di mirroring da registri esterni e flussi di immagini a icr.io. Nel seguente esempio, l'app GPU utilizza il marketplace OLM con flussi di immagini. Questo esempio non funziona se il cluster non può accedere al registro NVIDIA ( nvcr.io ).

Installare gli operatori Node Feature Discovery e NVIDIA GPU per la versione del cluster in uso.

È necessario utilizzare l'operatore GPU NVIDIA versione 1.3.1 o successiva. Quando si installa l'operatore Node Feature Discovery, selezionare il canale di aggiornamento corrispondente alla versione del cluster Red Hat OpenShift. Non installare gli operatori con un altro metodo, come ad esempio il grafico Helm.

Nodi worker RHEL 9: Se si stanno installando i driver delle GPU NVIDIA sui nodi worker RHEL 9, è necessario applicare un workaround per abilitare tutti i repository Extended Update Support (EUS) richiesti. Il GPU Operator di NVIDIA non abilita tutti i repository EUS richiesti per impostazione predefinita, causando un errore nell'installazione dei driver. Per ulteriori informazioni, vedere Perché l'installazione del driver della GPU NVIDIA fallisce sui nodi worker di RHEL 9?

Se riscontri problemi durante l'installazione dell'operatore Feature Discovery di Node o dell'operatore GPU di NVIDIA, contatta l'assistenza di NVIDIA per ricevere aiuto oppure apri una segnalazione nel repository dell'operatore GPU diNVIDIA

Distribuzione di un carico di lavoro

Crea un file YAML. In questo esempio, un file YAML di tipo " Job " gestisce carichi di lavoro di tipo batch creando un pod di breve durata che rimane attivo fino al completamento del comando e alla sua chiusura corretta.

Per i carichi di lavoro su GPU, è necessario specificare il campo “ resources: limits: nvidia.com/gpu ” nel file YAML del job.

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

Capire i componenti YAML
Componente	Descrizione
Nomi etichetta e metadati	Inserisci un nome e un'etichetta per il lavoro e utilizza lo stesso nome sia nei metadati del file che in quelli di `spec template`. Ad esempio, `nvidia-devicequery`.
`containers.image`	Fornisci l'immagine di cui il contenitore è un'istanza in esecuzione. In questo esempio, il valore è impostato per utilizzare l'immagine di query del dispositivo CUDA DockerHub:`nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04`.
`containers.imagePullPolicy`	Per scaricare una nuova immagine solo se questa non è attualmente presente sul nodo di lavoro, specificare IfNotPresent``.
`resources.limits`	Per le macchine GPU, devi specificare il limite della risorsa. L' Kubernetes Plug-in del dispositivo e imposta la richiesta di risorse predefinita in modo che corrisponda al limite. È necessario specificare la chiave come `nvidia.com/gpu`. Immettere il numero intero di GPU richieste, ad esempio `2`. Nota che i pod del container non condividono GPU e che le GPU non possono essere eccessivamente impegnate. Ad esempio, se hai solo 1 macchina `mg1c.16x128`, allora hai solo 2 GPU in tale macchina e puoi specificare un massimo di `2`.

Applica il file YAML. Ad esempio:
```
oc apply -f nvidia-devicequery.yaml
```

Controlla il pod di lavoro filtrando i tuoi pod in base all'etichetta " nvidia-devicequery ". Verifica che lo STATO sia Completato.

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

Output di esempio

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

Descrivi il pod per visualizzare come il plugin del dispositivo GPU ha pianificato il pod.

Nei campi Limits e Requests, controlla che il limite della risorsa che hai specificato corrisponda alla richiesta che imposta automaticamente il plugin del dispositivo.
Negli eventi, verifica che il pod sia assegnato al tuo nodo di lavoro GPU.

    oc describe pod nvidia-devicequery-ppkd4
    ```
    Output di esempio
    ```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
    ...
    ```

Per verificare che il lavoro abbia utilizzato la GPU per calcolare il proprio carico di lavoro, puoi controllare i log.

oc logs nvidia-devicequery-ppkd4

Output di esempio

/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

In questo esempio, vedi che una GPU è stata utilizzata per eseguire il lavoro perché la GPU era stata pianificata nel nodo di lavoro. Se il limite è impostato su 2, vengono visualizzate solo 2 GPU.

Ora che hai distribuito un carico di lavoro GPU di test, potresti voler configurare il tuo cluster per eseguire uno strumento che si basa sull'elaborazione GPU, come IBM Maximo Visual Inspection.

Distribuzione di un'applicazione su una macchina Intel AI Accelerator (Gaudi 3)

Questa funzione è disponibile solo per gli account inseriti nell'elenco dei permessi. Per richiedere l'accesso, vedere Richiesta di accesso alle funzioni consentite.

Completare il seguente esempio per distribuire l'immagine del contenitore PyTorch di Intel Gaudi che recupera un dispositivo Gaudi utilizzando il campo resource.limits. Prima di iniziare, assicurati che il tuo cluster soddisfi i seguenti requisiti.

Versione 4.18 e e successive
Solo cluster VPC
Solo nodi worker RHCOS
Operatore Intel Gaudi Base v1.20.1 e versioni successive

Per ulteriori informazioni ed esempi, consultare i documenti di Habana e l'esempio di avvio rapido.

Copiate la seguente configurazione di lavoro di esempio e salvatela in un file chiamato 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

Applica il processo nel tuo cluster.
```
oc apply -f config.yaml
```

Attendere l'avvio dei pod, quindi verificare il completamento del lavoro.

oc get po -n default

Esempio

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

Per maggiori dettagli, descrivete l'unità di lavoro.

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

Ottenere i log del pod per vedere i dettagli del dispositivo Gaudi.

oc logs habanalabs-gaudi-demo-kmdcp

Output di esempio

+-----------------------------------------------------------------------------+
| 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        |
+=============================================================================+

Distribuzione di un'applicazione su una macchina AMD MI300x

Red Hat CoreOS 4.18 e successivamente VPC

Per installare gli operatori necessari, è necessario consentire il traffico in uscita verso Red Hat Marketplace e OperatorHub.
Installare i seguenti operatori nel cluster:
Dopo aver installato gli operatori, seguire la documentazione AMD per configurare i driver. Nota: La rimozione del modulo kernel in-tree amdgpu dall'elenco dei permessi non è necessaria.

Per ulteriori informazioni ed esempi, consultare i documenti AMD e l'esempio di avvio rapido.

Copiare il seguente esempio di configurazione del pod e salvarlo in un file chiamato config.yaml

apiVersion: v1
kind: Pod
metadata:
  name: amd-smi
spec:
  containers:
  - image: docker.io/rocm/rocm-terminal:latest
    name: amd-smi
    command: ["/bin/bash"]
    args: ["-c","amd-smi version && amd-smi monitor -ptum"]
    resources:
      limits:
        amd.com/gpu: 8
      requests:
        amd.com/gpu: 8
  restartPolicy: Never

Applica il pod nel tuo cluster.
```
oc apply -f config.yaml
```

Attendere l'avvio dei pod, quindi verificare il completamento del lavoro.

oc get po -n default

Esempio

NAME       READY   STATUS      RESTARTS   AGE
amd-smi    0/1     Completed   0          19m

Per maggiori dettagli, descrivete l'unità di lavoro.

oc describe po amd-smi

Name:         amd-smi
Namespace:    default
Priority:     0
Node:         test-d18ofps20v1lr6in6ta0-btsstagevpc-gx3d208-00001687/10.240.1.4
Start Time:   Mon, 07 Jul 2025 13:32:18 -0500
Labels:       <none>
Annotations:  cni.projectcalico.org/containerID: 5b5d39f8ebe5ea14250af02031084961285f8b210eea14d2c22704784d957de3
              cni.projectcalico.org/podIP:
              cni.projectcalico.org/podIPs:
Status:       Succeeded
IP:           172.17.55.73
IPs:
  IP:  172.17.55.73
Containers:
  amd-smi:
    Container ID:  cri-o://3260f5a2788cc189adbe53d3d49c1bdccc7001df27f0c747d6fa86a3068c9eda
    Image:         docker.io/rocm/rocm-terminal:latest
    Image ID:      docker.io/rocm/rocm-terminal@sha256:72b323c5d56c511ea75f7353d0fee04e637390dd4874d414020284627a658014
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/bash
    Args:
      -c
      amd-smi version && amd-smi monitor -ptum
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 07 Jul 2025 13:32:20 -0500
      Finished:     Mon, 07 Jul 2025 13:32:20 -0500
    Ready:          False
    Restart Count:  0
    Limits:
      amd.com/gpu:  8
    Requests:
      amd.com/gpu:  8
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-tshnq (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   False
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
Volumes:
  kube-api-access-tshnq:
    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:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 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       19m   default-scheduler  Successfully assigned default/amd-smi to test-d18ofps20v1lr6in6ta0-btsstagevpc-gx3d208-00001687
  Normal  AddedInterface  19m   multus             Add eth0 [172.17.55.73/32] from k8s-pod-network
  Normal  Pulling         19m   kubelet            Pulling image "docker.io/rocm/rocm-terminal:latest"
  Normal  Pulled          19m   kubelet            Successfully pulled image "docker.io/rocm/rocm-terminal:latest" in 782ms (782ms including waiting). Image size: 3016399213 bytes.
  Normal  Created         19m   kubelet            Created container: amd-smi
  Normal  Started         19m   kubelet            Started container amd-smi

Ottenere i log del pod per vedere i dettagli della GPU AMD.

oc logs amd-smi

Output di esempio

AMDSMI Tool: 25.3.0+ede62f2 | AMDSMI Library version: 25.3.0 | ROCm version: 6.4.0 | amdgpu version: 6.10.5 | amd_hsmp version: N/A
WARNING: User is missing the following required groups: render. Please add user to these groups.
GPU  POWER   GPU_T   MEM_T   GFX_CLK   GFX%   MEM%  MEM_CLOCK
  0  141 W   40 °C   36 °C   140 MHz    0 %    0 %    900 MHz
  1  144 W   42 °C   33 °C   138 MHz    0 %    0 %    900 MHz
  2  140 W   38 °C   34 °C   142 MHz    0 %    0 %    900 MHz
  3  142 W   39 °C   34 °C   140 MHz    0 %    0 %    900 MHz
  4  140 W   38 °C   35 °C   138 MHz    0 %    0 %    900 MHz
  5  142 W   36 °C   30 °C   138 MHz    0 %    0 %    900 MHz
  6  137 W   40 °C   35 °C   138 MHz    0 %    0 %    900 MHz
  7  137 W   38 °C   32 °C   142 MHz    0 %    0 %    900 MHz