Lancement du tableau de bord Kubernetes à partir de la console IBM Cloud

1. Connectez-vous à la consoleIBM Cloud.
2. Dans la barre de menu, sélectionnez le compte que vous souhaitez utiliser.
3. Dans le menu , cliquez sur Conteneurs > Clusters.
4. Sur la page Clusters, cliquez sur le cluster auquel vous souhaitez accéder.
5. Sur la page des détails du cluster, cliquez sur le bouton Tableau de bord Kubernetes.

Lancement du tableau de bord Kubernetes à partir de l'interface de ligne de commande (CLI)

La méthode CLI permet l'automatisation et l'intégration CI/CD. Installez le CLI avant de commencer.

1. Obtenez vos identifiants Kubernetes.

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

2. Copier la valeur de l 'id-token à partir de la sortie.

3. Démarrer le proxy.

   kubectl proxy
   

   Exemple de sortie

   Starting to serve on 127.0.0.1:8001
   

4. Connectez-vous au tableau de bord.

   1. Accédez à l' URL suivante dans votre navigateur :

       http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
       ```
   2. Sélectionnez la méthode d'authentification **par jeton** sur la page de connexion.
   
   3. Collez la valeur **de l'id-token** dans le champ **Token,** puis cliquez sur **SIGN IN**.
   
   

Utilisez CTRL+C pour quitter la commande proxy. Exécutez à nouveau kubectl proxy pour redémarrer le tableau de bord.

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.

Pour Kubernetes version 1.36 et suivantes: Vous devez installer et gérer vous-même la pile de pilotes GPU NVIDIA. IBM Cloud Kubernetes Service ne fournit plus de pilotes GPU préinstallés sur les nœuds de travail. Suivez le guide d'installation de NVIDIA GPU Operator pour installer les composants nécessaires :

• NVIDIA pilote du noyau
• Composants d'exécution des conteneurs (par exemple, nvidia-container-toolkit)
• Kubernetes plugin d'appareil

Jusqu'à ce que le pilote soit installé, les pods demandant des GPU resteront dans l'état Pending. Ils passeront automatiquement à Running dès qu'un pilote compatible sera disponible sur le nœud.

Pour la version Kubernetes 1.35 et les versions antérieures: IBM-les pilotes GPU fournis sont automatiquement installés sur les nœuds de travail GPU. Aucune installation de pilote supplémentaire n'est nécessaire.

Déploiement d'une charge de travail

1. Créez un fichier YAML. Dans cet exemple, un fichier YAML Job gère des charges de travail de type batch en créant un pod à durée de vie limitée qui s'exécute jusqu'à ce que la commande soit terminée et s'arrête correctement.

   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 plug-inKubernetes configure la demande de ressources par défaut pour qu’elle corresponde à la limite. Vous devez spécifier la clé sous la forme 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.

2. Appliquez le fichier YAML. Exemple :

   kubectl apply -f nvidia-devicequery.yaml
   

3. Vérifiez le pod de travail en filtrant vos pods par étiquette nvidia-devicequery. Vérifiez que la valeur de la zone STATUS est Completed.

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

   Exemple de sortie

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

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

       kubectl describe pod nvidia-devicequery-ppkd4
       ```
       Exemple de sortie
       ```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. Pour vérifier que votre travail a utilisé le processeur graphique (GPU) pour calculer sa charge de travail, vous pouvez consulter les journaux.

   kubectl 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 souhaiterez peut-être configurer votre cluster pour exécuter un outil qui s'appuie sur le traitement GPU, tel qu' IBM Maximo Visual Inspection.