Déploiement d'applications natives Kubernetes dans des clusters

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. Naviguez vers le site suivant URL 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 et cliquez sur SIGN INSCRIPTION.

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.

Déploiement d'une charge de travail

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

2. Appliquez le fichier YAML. Exemple :

   kubectl apply -f nvidia-devicequery.yaml
   

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

   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

     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 pourriez vouloir configurer votre cluster pour exécuter un outil qui s'appuie sur le traitement GPU, tel que IBM Maximo Visual Inspection.