Migration vers les pilotes GPU autogérés NVIDIA pour Kubernetes 1.36

À partir de la version Kubernetes 1.36, IBM Cloud Kubernetes Service n'installe plus automatiquement les pilotes de GPU NVIDIA sur les nœuds de travail GPU. Vous devez installer et gérer vous-même les pilotes GPU pour exécuter les charges de travail GPU.

Qu'est-ce qui change ?

Version 1.36 et versions ultérieures
Les pilotes de GPU ne sont pas préinstallés sur les nœuds de travail GPU nouveaux ou remplacés. Vous devez installer et maintenir les composants suivants :
  • NVIDIA pilote du noyau
  • Composants d'exécution du conteneur (tels que nvidia-container-toolkit)
  • Kubernetes plugin d'appareil
Versions 1.35 et antérieures
Les pilotes de GPU sont automatiquement installés et gérés par IBM sur tous les nœuds de travail GPU.

Quel est l'impact?

Les pods qui demandent des ressources GPU restent dans l'état Pending jusqu'à ce que vous installiez les pilotes GPU requis sur le nœud de travail. Une fois les pilotes installés, les pods en attente passent automatiquement à l'état Running.

Comprendre le processus de migration

La migration vers des pilotes de GPU autogérés suit une séquence spécifique pour garantir que les charges de travail de votre GPU continuent à fonctionner pendant la mise à niveau :

  1. Phase de pré-installation: Vous installez le GPU Operator NVIDIA sur votre cluster alors qu'il fonctionne encore avec la version 1.35 ou une version antérieure. Lors de l'installation, vous étiquetez les nœuds GPU existants afin d'empêcher l'opérateur de déployer des ressources de pilotes qui entreraient en conflit avec les pilotes préinstallés.

  2. Mise à niveau du plan de contrôle : Vous allez mettre à niveau le plan de contrôle de la grappe vers la version 1.36.

  3. Mise à niveau des nœuds de travail: Remplacer chaque nœud de travailleur pour le mettre à niveau vers la version 1.36. Dans ce cas, les étiquettes qui empêchaient le déploiement du pilote sont automatiquement supprimées. Cela permet à l'opérateur de GPU NVIDIA de déployer sa pile de pilotes sur les nouveaux nœuds.

  4. Récupération automatique de la charge de travail: Une fois que l'opérateur installe les pilotes sur un nœud remplacé, toutes les charges de travail GPU en attente passent automatiquement à l'état Running.

Préparer la migration avant que la version 1.36 ne soit disponible

Vous pouvez effectuer les étapes de pré-installation avant la sortie de la version 1.36 afin de préparer votre cluster à une migration en douceur :

  1. Étiqueter vos nœuds de travail GPU existants pour empêcher l'opérateur de déployer des ressources qui entreraient en conflit avec les pilotes préinstallés.

    kubectl label node/<node_name> nvidia.com/gpu.deploy.operands=false
    kubectl label node/<node_name> nvidia.com/gpu.deploy.driver=false
    
  2. Installez le GPU Operator NVIDIA en suivant le guide d'installation du GPU Operator NVIDIA.

  3. Vérifiez que l'opérateur est installé mais qu'il ne déploie pas de ressources de pilote sur les nœuds étiquetés.

    kubectl get pods -n gpu-operator -o wide
    

En réalisant ces étapes de préparation à l'avance, vous réduisez le travail nécessaire lors de la mise à niveau vers la version 1.36. Lorsque la version 1.36 est disponible, il suffit de mettre à niveau le plan de contrôle et de remplacer les nœuds de travail.

Avant de commencer

  • Consultez la documentation de l'opérateur GPU sur le site NVIDIA.
  • Assurez-vous que vous disposez d'un accès d'administrateur de cluster.
  • Planifiez votre stratégie de mise à niveau en fonction de la configuration de votre cluster (nœud à GPU unique ou nœuds à GPU multiples).

Exemples de migration

Les exemples suivants montrent comment migrer votre cluster en fonction du nombre de nœuds GPU.

Exemple 1 : un seul nœud GPU dans la grappe

Cet exemple montre la migration d'un cluster avec un seul nœud GPU. Comme le seul nœud GPU sera indisponible pendant la mise à niveau, vous ajoutez un second travailleur GPU temporaire pour maintenir la capacité.

Étape 1 : Obtenir l'état initial de la grappe

  1. Vérifiez la version du plan de contrôle du cluster.

    ibmcloud ks cluster get -c CLUSTER_NAME
    

    Exemple de sortie montrant la version 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Vérifier la version du nœud de travail.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie montrant un seul nœud GPU :

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    

Étape 2 : Installer le GPU Operator NVIDIA

Si vous avez suivi les étapes de la section Préparer la migration avant que la version 1.36 ne soit disponible, vous avez peut-être déjà effectué cette étape.

  1. Étiqueter le nœud de travail GPU existant pour empêcher l'opérateur de déployer des ressources qui entreraient en conflit avec les pilotes préinstallés.

    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.driver=false
    
  2. Ajoutez le dépôt NVIDIA Helm et installez l'opérateur GPU.

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
    helm repo update
    helm install --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
    
  3. Vérifiez que les pods de l'opérateur GPU sont en cours d'exécution. Notez que l'installateur de pilote, le plugin de périphérique, la boîte à outils de conteneur et l'exportateur DCGM ne doivent PAS être exécutés sur le nœud étiqueté.

    kubectl get pods -n gpu-operator -o wide
    

    Exemple de sortie :

    NAME                                                              READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-operator-1778819096-node-feature-discovery-gc-84d98bd6nqw2z   1/1     Running   0          2m21s   172.17.64.94    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-master-6b6cpnm9w   1/1     Running   0          2m21s   172.17.64.93    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-hm7ft       1/1     Running   0          2m21s   172.17.64.91    10.240.0.64   <none>           <none>
    gpu-operator-76c686b9df-kn4dw                                     1/1     Running   0          2m21s   172.17.64.92    10.240.0.64   <none>           <none>
    

Étape 3 : Mise à niveau du plan de contrôle de la grappe

  1. Mettre à jour le plan de contrôle du cluster vers la version 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Vérifiez la mise à niveau du plan de contrôle.

    ibmcloud ks cluster get -c <cluster_name>
    

    Exemple de sortie :

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.36.0_1506
    

Étape 4 : Ajouter un nœud de travail GPU temporaire

  1. Ajouter temporairement un second travailleur GPU au cluster avec Kubernetes version 1.36.

    ibmcloud ks worker-pool create vpc-gen2 --name temp-gpu-pool --cluster <cluster_name> --flavor gx3.16x80.l4 --size-per-zone 1 --zone us-south-1
    
  2. Vérifiez que le nœud temporaire est prêt.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie montrant les nœuds d'origine et les nœuds temporaires :

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-tempgpupool-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Vérifier que les pods de l'opérateur GPU fonctionnent sur le nouveau nœud temporaire.

    kubectl get pods -n gpu-operator -o wide
    

    Exemple de sortie montrant le pilote et le plugin de périphérique fonctionnant sur le nœud temporaire :

    NAME                                                              READY   STATUS      RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-feature-discovery-mw5km                                       1/1     Running     0          4m36s   172.17.116.201   10.240.0.72   <none>           <none>
    nvidia-container-toolkit-daemonset-ns6p8                          1/1     Running     0          4m36s   172.17.116.199   10.240.0.72   <none>           <none>
    nvidia-cuda-validator-vgj45                                       0/1     Completed   0          96s     172.17.116.203   10.240.0.72   <none>           <none>
    nvidia-dcgm-exporter-52cwh                                        1/1     Running     0          4m36s   172.17.116.204   10.240.0.72   <none>           <none>
    nvidia-device-plugin-daemonset-2ql7x                              1/1     Running     0          4m36s   172.17.116.202   10.240.0.72   <none>           <none>
    nvidia-driver-daemonset-zql6m                                     1/1     Running     0          5m29s   172.17.116.197   10.240.0.72   <none>           <none>
    nvidia-operator-validator-44xtz                                   1/1     Running     0          4m36s   172.17.116.200   10.240.0.72   <none>           <none>
    
  4. Vérifier la disponibilité du GPU sur le nœud temporaire.

    kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable}'
    

Étape 5 : Migration des charges de travail et mise à niveau du nœud d'origine

  1. Migrez vos charges de travail GPU vers le nœud de travail temporaire 1.36. Vous pouvez utiliser des sélecteurs de nœuds, des taints ou la suppression manuelle de pods pour déplacer les charges de travail.

  2. Remplacer le nœud GPU d'origine.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  3. Vérifiez la mise à niveau du nœud.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie montrant que les deux nœuds sont maintenant sur la version 1.36:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-00000485   10.240.0.68   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-tempgpupool-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  4. Vérifier que les pods de l'opérateur GPU fonctionnent sur le nœud d'origine mis à niveau.

    kubectl get pods -n gpu-operator -o wide
    
  5. Vérifiez que toutes les charges de travail du GPU sont en cours d'exécution.

    kubectl get pods -o wide
    

    Exemple de sortie :

    NAME             READY   STATUS    RESTARTS   AGE    IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          6m8s   172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          44m    172.17.121.28    10.240.0.68   <none>           <none>
    

Étape 6 : Supprimer le nœud temporaire (facultatif)

Une fois que le nœud d'origine est sain et que les charges de travail sont stables, vous pouvez éventuellement supprimer le nœud GPU temporaire.

  1. Supprimer le pool de travailleurs temporaires.

    ibmcloud ks worker-pool rm --cluster <cluster_name> --worker-pool temp-gpu-pool
    
  2. Vérifier que seul le nœud d'origine subsiste.

    ibmcloud ks worker ls -c <cluster_name>
    

Exemple 2 : Plusieurs nœuds GPU dans la grappe

Cet exemple montre la migration d'un cluster avec deux nœuds GPU de la version Kubernetes 1.35 vers 1.36. Avec plusieurs nœuds, vous pouvez mettre à niveau les nœuds un par un tout en conservant la capacité du GPU.

Étape 1 : Obtenir l'état initial de la grappe

  1. Vérifiez la version du plan de contrôle du cluster.

    ibmcloud ks cluster get -c <cluster_name>
    

    Exemple de sortie montrant la version 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Vérifiez les versions des nœuds de travail.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie montrant deux nœuds GPU :

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-0000024b   10.240.0.66   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    

Étape 2 : Installer le GPU Operator NVIDIA

Si vous avez suivi les étapes de la section Préparer la migration avant que la version 1.36 ne soit disponible, vous avez peut-être déjà effectué cette étape.

  1. Étiqueter les nœuds de travail GPU existants afin d'empêcher l'opérateur de déployer des ressources qui entreraient en conflit avec les pilotes préinstallés.

    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.driver=false
    kubectl label node/10.240.0.66 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.66 nvidia.com/gpu.deploy.driver=false
    
  2. Ajoutez le dépôt NVIDIA Helm et installez l'opérateur GPU.

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
    helm repo update
    helm install --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
    
  3. Vérifiez que les pods de l'opérateur GPU sont en cours d'exécution. Notez que l'installateur de pilote, le plugin de périphérique, la boîte à outils de conteneur et l'exportateur DCGM ne doivent PAS être exécutés sur les nœuds étiquetés.

    kubectl get pods -n gpu-operator -o wide
    

    Exemple de sortie :

    NAME                                                              READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-operator-1778819096-node-feature-discovery-gc-84d98bd6nqw2z   1/1     Running   0          2m21s   172.17.64.94    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-master-6b6cpnm9w   1/1     Running   0          2m21s   172.17.64.93    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-hm7ft       1/1     Running   0          2m21s   172.17.64.91    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-xh4qz       1/1     Running   0          2m21s   172.17.121.29   10.240.0.66   <none>           <none>
    gpu-operator-76c686b9df-kn4dw                                     1/1     Running   0          2m21s   172.17.64.92    10.240.0.64   <none>           <none>
    

Étape 3 : Mise à niveau du plan de contrôle de la grappe

  1. Mettre à jour le plan de contrôle du cluster vers la version 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Vérifiez la mise à niveau du plan de contrôle.

    ibmcloud ks cluster get -c <cluster_name>
    

    Exemple de sortie :

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.36.0_1506
    

Étape 4 : Mise à niveau du premier nœud de travail

  1. Remplacer le premier nœud de travail.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  2. Vérifiez la mise à niveau du nœud.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie :

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-0000024b   10.240.0.66   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Vérifiez l'état de la charge de travail du GPU. La charge de travail du GPU programmée sur le nouveau nœud sera dans l'état Pending jusqu'à ce que le pilote soit installé.

    kubectl get pods -o wide
    

    Exemple de sortie :

    NAME             READY   STATUS    RESTARTS   AGE   IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   0/1     Pending   0          18s   <none>          <none>        <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          38m   172.17.121.28   10.240.0.66   <none>           <none>
    
  4. Vérifier que les pods de l'opérateur GPU fonctionnent sur le nouveau nœud.

    kubectl get pods -n gpu-operator -o wide
    

    Exemple de sortie montrant le pilote et le plugin de périphérique fonctionnant sur le nouveau nœud :

    NAME                                                              READY   STATUS      RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-feature-discovery-mw5km                                       1/1     Running     0          4m36s   172.17.116.201   10.240.0.72   <none>           <none>
    nvidia-container-toolkit-daemonset-ns6p8                          1/1     Running     0          4m36s   172.17.116.199   10.240.0.72   <none>           <none>
    nvidia-cuda-validator-vgj45                                       0/1     Completed   0          96s     172.17.116.203   10.240.0.72   <none>           <none>
    nvidia-dcgm-exporter-52cwh                                        1/1     Running     0          4m36s   172.17.116.204   10.240.0.72   <none>           <none>
    nvidia-device-plugin-daemonset-2ql7x                              1/1     Running     0          4m36s   172.17.116.202   10.240.0.72   <none>           <none>
    nvidia-driver-daemonset-zql6m                                     1/1     Running     0          5m29s   172.17.116.197   10.240.0.72   <none>           <none>
    nvidia-operator-validator-44xtz                                   1/1     Running     0          4m36s   172.17.116.200   10.240.0.72   <none>           <none>
    
  5. Vérifiez la charge de travail GPU programmée sur le nouveau nœud.

    kubectl get pods -o wide
    

    Exemple de sortie :

    NAME             READY   STATUS    RESTARTS   AGE    IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          6m8s   172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          44m    172.17.121.28    10.240.0.66   <none>           <none>
    

Étape 5 : Mise à niveau des nœuds restants

  1. Répétez l'étape 4 pour chaque nœud de GPU restant, en mettant à niveau un nœud à la fois.

  2. Après la mise à niveau de tous les nœuds, vérifiez que tous les nœuds de travail utilisent la version 1.36.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemple de sortie :

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-0000048c   10.240.0.73   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Vérifiez que tous les modules d'exploitation GPU sont en cours d'exécution.

    kubectl get pods -n gpu-operator -o wide
    
  4. Vérifiez que toutes les charges de travail du GPU sont en cours d'exécution.

    kubectl get pods -o wide
    

    Exemple de sortie :

    NAME             READY   STATUS    RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          18m     172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-ttcbt   1/1     Running   0          6m46s   172.17.75.77     10.240.0.73   <none>           <none>
    

Etapes suivantes

  • Surveillez vos charges de travail GPU pour vous assurer qu'elles fonctionnent correctement.
  • Consultez la documentation de l'opérateur du GPU NVIDIA pour connaître les options de configuration avancées.
  • Mettre en place une surveillance des métriques GPU à l'aide de l'exportateur DCGM de NVIDIA.