Déploiement d'applications dans les grappes Red Hat OpenShift

Avec des clusters Red Hat® OpenShift® on IBM Cloud®, vous pouvez déployer des applications depuis un fichier ou un référentiel distant, tel que GitHub, avec une seule commande. De plus, vos clusters sont fournis avec divers services intégrés que vous pouvez utiliser pour faire fonctionner votre cluster.

Déplacement de vos applications vers Red Hat OpenShift

Pour créer une application dans votre cluster Red Hat OpenShift on IBM Cloud, utilisez la console ou l'interface de ligne de commande Red Hat OpenShift.

Vous voyez des erreurs lorsque vous déployez votre application ? Red Hat OpenShift a des paramètres par défaut différents de ceux de la communauté Kubernetes, par exemple des contraintes de contexte de sécurité plus strictes. Passez en revue les scénarios courants ci-après. Vous devrez peut-être modifier vos applications afin de pouvoir les déployer sur des clusters Red Hat OpenShift.

Déploiement d'applications via la console

Vous pouvez créer des applications en utilisant différentes méthodes dans la console Red Hat OpenShift à l'aide de la perspective Développeur. Pour plus d'informations, voir la documentation de Red Hat OpenShift.

Depuis la console, sélectionnez votre cluster.
Cliquez sur Console Web Red Hat OpenShift.
Dans le sélecteur de perspective, sélectionnez Développeur. La console Web Red Hat OpenShift bascule dans la perspective Développeur et le menu contient désormais des options telles que +Ajouter, Topologie et Générations.
Cliquez sur +Ajouter.
Dans la barre de menus du panneau Ajouter, sélectionnez dans la liste déroulante le projet dans lequel vous souhaitez créer votre application.
Cliquez sur la méthode que vous souhaitez utiliser pour ajouter votre application et suivez les instructions. Par exemple, cliquez sur Depuis Git.

Déploiement d'applications via l'interface CLI

Pour créer une application dans votre cluster Red Hat OpenShift on IBM Cloud, utilisez la commande oc new-app. Par exemple, vous pouvez faire référence à un référentiel GitHub public, à un référentiel GitLab public avec une adresse URL qui se termine par .git, ou à un autre référentiel local ou distant. Pour plus d'informations, essayez le tutoriel et consultez la documentation de Red Hat OpenShift.

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

Que fait la commande new-app ?: La commande new-app crée une configuration de génération et une image d'application à partir du code source, une configuration de déploiement pour déployer le conteneur sur des pods dans votre cluster, et un service qui permet d'exposer l'application dans le cluster. Pour plus d'informations sur le processus de construction et sur d'autres sources que Git, voir la documentation Red Hat OpenShift.

Déploiement d'applications sur des noeuds worker spécifiques à l'aide de libellés

Lorsque vous déployez une application, les pods d'application déploient plusieurs noeuds worker dans votre cluster sans discernement. Parfois, vous voudrez peut-être limiter les nœuds worker à déployer sur les serveurs d'applications. Par exemple, vous pouvez opter pour le déploiement des pods d'application uniquement sur les noeuds worker d'un certain pool de noeuds worker car ces noeuds se trouvent sur des machines bare metal. Pour désigner les noeuds worker sur lesquels doivent se déployer les pods d'application, ajoutez une règle d'affinité dans le déploiement de votre application.

Avant de commencer

Accédez à votre cluster Red Hat OpenShift.
Facultatif : définissez un libellé pour le pool de noeuds worker sur lequel vous souhaitez exécuter l'application.

Pour déployer des applications sur des nœuds worker spécifiques,

Récupérez l'ID du pool de noeuds worker sur lequel vous souhaitez déployer des pods d'application.
```
ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>
```
Répertoriez les noeuds worker figurant dans le pool de noeuds worker et notez l'une des adresses IP privées.
```
ibmcloud oc worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
```

Décrivez le noeud worker. Dans la sortie Labels, notez le libellé de l'ID du pool de noeuds worker, ibm-cloud.kubernetes.io/worker-pool-id.

Les étapes indiquées dans cette rubrique utilisent un ID de pool de noeuds worker pour déployer les pods d'application uniquement sur des noeuds worker figurant dans ce pool. Pour déployer des pods d'application sur des noeuds worker en utilisant un autre libellé, notez le libellé à utiliser. Par exemple, pour déployer des pods d'application uniquement sur des noeuds worker sur un VLAN privé spécifique, utilisez le libellé privateVLAN=.

oc describe node <worker_node_private_IP>

Exemple de sortie

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

Ajoutez une règle d'affinité pour l'étiquette ID du pool de travailleurs au déploiement de l'application.

Exemple de fichier 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>
...

Dans la section Affinité de l'exemple YAML, ibm-cloud.kubernetes.io/worker-pool-id est key et <worker_pool_ID> est le value.

Appliquez le fichier de configuration de déploiement mis à jour.
```
oc apply -f with-node-affinity.yaml
```
Vérifiez que les pods d'application se sont déployés sur les noeuds worker appropriés.
1. Affichez la liste des pods de votre cluster.
```
oc get pods -o wide
```
  Exemple de sortie
```
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. Dans la sortie, identifiez un pod pour votre application. Notez l'adresse IP privée du noeud (NODE) correspondant au noeud worker dans lequel figure le pod.
  
  Dans la sortie de l'exemple précédent, le pod d'application cf-py-d7b7d94db-vp8pq se trouve sur un noeud worker dont l'adresse IP est 10.xxx.xx.xxx.
3. Répertoriez les noeuds worker figurant dans le pool de noeuds worker que vous avez désigné dans le déploiement de votre application.
```
ibmcloud oc worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
```
  Exemple de sortie
```
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 vous avez créé une règle d'affinité pour l'application en fonction d'un autre facteur, récupérez cette valeur à la place. Par exemple, pour vérifier que le pod d'application a été déployé sur un nœud worker sur un VLAN, affichez le VLAN où se trouve le nœud worker en exécutant ibmcloud oc worker get --cluster <cluster_name_or_ID> --worker <worker_ID>.
4. Dans la sortie, vérifiez que le noeud worker avec l'adresse IP que vous avez identifiée à l'étape précédente est déployé dans ce pool de noeuds worker.

Déployer une application sur une machine GPU NVIDIA

Si vous disposez d'un type de machine GPU, vous pouvez accélérer le temps de traitement requis pour les charges de travail de calcul intensif telles que l'IA, l'apprentissage automatique, l'inférence, etc.

Dans les étapes suivantes, vous apprendrez à déployer des charges de travail nécessitant le processeur graphique (GPU). Cependant, vous pouvez également déployer des applications qui n'ont pas besoin de traiter leurs charges de travail à la fois sur le GPU et le CPU.

Vous pouvez également essayer des charges de travail mathématiques intensives telles que le cadre d'apprentissage automatique (machine learning) avec cette démo TensorFlow machine learning framework avec cette démo Kubernetes.

Prérequis

Avant de commencer

Créez un cluster ou un pool de noeuds worker qui utilise une version GPU. N'oubliez pas que la configuration d'une machine bare metal peut prendre plus d'un jour ouvrable. Pour obtenir la liste des versions disponibles, voir les liens suivants.
- Versions classiques
- Versions VPC
Vérifiez que vous disposez d'un rôle d'accès au service qui vous octroie le rôle RBAC Kubernetes approprié pour gérer des ressources Kubernetes dans le cluster.

Limitations des clusters privés uniquement: si votre cluster n'a pas de connectivité de réseau public, vous devez autoriser la connectivité de réseau public ou la mise en miroir d'images à partir de registres externes et de flux d'images vers icr.io. Dans l'exemple suivant, l'application GPU utilise la place de marché OLM avec des flux d'images. Cet exemple ne fonctionne pas si votre cluster ne peut pas accéder au registre NVIDIA ( nvcr.io ).

Vous devez utiliser l'opérateur GPU NVIDIA version 1.3.1 ou ultérieure. Lorsque vous installez l'opérateur Node Feature Discovery, sélectionnez le canal de mise à jour qui correspond à votre version de cluster Red Hat OpenShift. N'installez pas les opérateurs par le biais d'une autre méthode, telle qu'une carte Helm.

Si vous rencontrez des problèmes lors de l'installation de Node Feature Discovery Operator ou de NVIDIA GPU Operator, contactez le support NVIDIA pour obtenir de l'aide ou ouvrez un problème dans le repo NVIDIA GPU Operator

Déploiement d'une charge de travail

Créez un fichier YAML. Dans cet exemple, un YAML Job gère les charges de travail de type batch en créant un pod éphémère qui s'exécute jusqu'à la fin de la commande et se termine avec succès.

Pour les charges de travail GPU, vous devez spécifier le champ resources: limits: nvidia.com/gpu dans le fichier YAML de la tâche.

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

Comprendre les composants YAML
Composant	Description
Noms et libellé des métadonnées	Entrez un nom et un libellé pour le travail et utilisez le même nom dans la zone metadata du fichier et de `spec template`. Par exemple, `nvidia-devicequery`.
`containers.image`	Fournissez l'image dont le conteneur est une instance d'exécution. Dans cet exemple, la valeur est définie pour utiliser l'image de requête de périphérique CUDA DockerHub:`nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04`.
`containers.imagePullPolicy`	Pour extraire une nouvelle image uniquement si l'image ne se trouve pas actuellement sur le noeud worker, indiquez `IfNotPresent`.
`resources.limits`	Pour les machines GPU, vous devez indiquer une limite de ressource. Le site Kubernetes Plug-in d'appareil définit la demande de ressources par défaut en fonction de la limite. Vous devez spécifier la clé comme `nvidia.com/gpu`. Saisissez le nombre entier de GPU que vous demandez, par exemple `2`. Notez que les pods de conteneur ne partagent pas les GPU et que ces dernières ne peuvent pas être sursollicitées. Par exemple, si vous ne disposez que d'une machine `mg1c.16x128`, vous n'avez que 2 GPU dans cette machine. Vous ne pouvez donc en spécifier que `2` maximum.

Appliquez le fichier YAML. Exemple :
```
oc apply -f nvidia-devicequery.yaml
```

Vérifiez le module de travail en filtrant vos modules par l'étiquette nvidia-devicequery. Vérifiez que la valeur de la zone STATUS est Completed.

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

Exemple de sortie

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

Décrivez le pod pour voir comment le plug-in d'unité GPU a planifié le pod.

Dans les zones Limits et Requests, observez que la limite de ressources que vous avez spécifiée correspond à la demande définie automatiquement par le plug-in d'unité.

Dans les événements, vérifiez que le pod est affecté au noeud worker de votre GPU.

oc describe pod nvidia-devicequery-ppkd4

Exemple de sortie

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

Pour vérifier que votre travail a utilisé le processeur graphique (GPU) pour calculer sa charge de travail, vous pouvez consulter les journaux.

oc logs nvidia-devicequery-ppkd4

Exemple de sortie

/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

Dans cet exemple, vous voyez qu'un processeur graphique a été utilisé pour exécuter le travail car le processeur graphique a été planifié dans le noeud worker. Si la limite est définie sur 2, seuls 2 processeurs graphiques sont affichés.

Maintenant que vous avez déployé une charge de travail GPU de test, vous pourriez vouloir configurer votre cluster pour exécuter un outil qui s'appuie sur le traitement GPU, tel que IBM Maximo Visual Inspection.

Déployer une application sur une machine Intel AI Accelerator (Gaudi 3)

Cette fonction n'est disponible que pour les comptes inscrits sur la liste des comptes autorisés. Pour demander l'accès, voir Demander l'accès aux fonctionnalités de la liste d'autorisation.

Complétez l'exemple suivant pour déployer l'image de conteneur PyTorch d'Intel Gaudi qui récupère un dispositif Gaudi en utilisant le champ resource.limits. Avant de commencer, assurez-vous que votre cluster répond aux exigences suivantes.

Version 4.18 et suivantes
Clusters VPC uniquement
Nœuds de travail RHCOS uniquement
Intel Gaudi Base operator v1.20.1 et suivants

Pour plus d'informations et d'exemples, voir la documentation Habana et l'exemple de démarrage rapide.

Copiez l'exemple de configuration de travail suivant et enregistrez-le dans un fichier appelé 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

Appliquez le travail dans votre cluster.
```
oc apply -f config.yaml
```

Attendez que les pods démarrent, puis vérifiez que le travail est terminé.

oc get po -n default

Exemple

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

Décrivez la fiche de poste pour plus de détails.

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

Obtenez les journaux de pods pour voir les détails de l'appareil Gaudi.

oc logs habanalabs-gaudi-demo-kmdcp

Exemple de sortie

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

Déploiement d'une application sur une machine AMD MI300x

Red Hat CoreOS 4.18 et plus tard VPC

Pour installer les opérateurs nécessaires, vous devez autoriser le trafic sortant vers Red Hat Marketplace et OperatorHub.
Installez les opérateurs suivants dans votre cluster :
Après avoir installé les opérateurs, suivez la documentation AMD pour configurer les pilotes. Remarque: il n'est pas nécessaire de supprimer le module du noyau amdgpu de la liste des autorisations.

Pour plus d'informations et d'exemples, voir la documentation AMD et l'exemple de démarrage rapide.

Copiez l'exemple de configuration de pod suivant et enregistrez-le dans un fichier appelé 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

Appliquez le pod dans votre cluster.
```
oc apply -f config.yaml
```

Attendez que les pods démarrent, puis vérifiez que le travail est terminé.

oc get po -n default

Exemple

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

Décrivez la fiche de poste pour plus de détails.

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

Obtenez les journaux de pods pour voir les détails du GPU AMD.

oc logs amd-smi

Exemple de sortie

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