Migrazione ai driver GPU NVIDIA autogestiti per Kubernetes 1.36

A partire dalla versione Kubernetes 1.36, IBM Cloud Kubernetes Service non installa più automaticamente i driver GPU NVIDIA sui nodi worker GPU. Per eseguire i carichi di lavoro GPU è necessario installare e gestire autonomamente i driver della GPU.

Cosa sta cambiando?

Versione 1.36 e successive
I driver delle GPU non sono preinstallati sui nodi worker GPU nuovi o sostituiti. È necessario installare e mantenere i seguenti componenti:
  • NVIDIA driver del kernel
  • Componenti di runtime del contenitore (come nvidia-container-toolkit)
  • Kubernetes plugin per dispositivi
Versioni 1.35 e precedenti
I driver delle GPU vengono installati e gestiti automaticamente da IBM su tutti i nodi worker GPU.

Qual è l'impatto?

I pod che richiedono risorse GPU rimangono nello stato Pending finché non si installano i driver GPU necessari sul nodo worker. Dopo l'installazione dei driver, i pod in attesa passano automaticamente allo stato Running.

Comprendere il processo di migrazione

La migrazione ai driver GPU autogestiti segue una sequenza specifica per garantire che i carichi di lavoro della GPU continuino a funzionare durante l'aggiornamento:

  1. Fase di pre-installazione: Si installa il GPU Operator di NVIDIA sul cluster quando è ancora in esecuzione la versione 1.35 o precedente. Durante l'installazione, si etichettano i nodi GPU esistenti per impedire all'operatore di distribuire risorse driver che entrerebbero in conflitto con i driver preinstallati.

  2. Aggiornamento del piano di controllo: si aggiorna il piano di controllo del cluster alla versione 1.36.

  3. Aggiornamento dei nodi worker: Sostituire ogni nodo worker per aggiornare la versione 1.36. In questo modo, le etichette che impedivano la distribuzione del driver vengono automaticamente rimosse. Ciò consente al GPU Operator di NVIDIA di distribuire il proprio stack di driver sui nuovi nodi.

  4. Recupero automatico del carico di lavoro: Una volta che l'operatore installa i driver su un nodo sostituito, qualsiasi carico di lavoro GPU in sospeso passa automaticamente allo stato Running.

Preparazione alla migrazione prima che sia disponibile la versione 1.36

È possibile completare le fasi di preinstallazione prima del rilascio della versione 1.36 per preparare il cluster a una migrazione più agevole:

  1. Etichettare i nodi worker GPU esistenti per evitare che l'operatore distribuisca risorse in conflitto con i driver preinstallati.

    kubectl label node/<node_name> nvidia.com/gpu.deploy.operands=false
kubectl label node/<node_name> nvidia.com/gpu.deploy.driver=false

  2. Installare il GPU Operator NVIDIA seguendo la guida all'installazione del GPU Operator NVIDIA.

  3. Verificare che l'operatore sia installato ma non stia distribuendo le risorse del driver sui nodi etichettati.

    kubectl get pods -n gpu-operator -o wide

Completando queste fasi di preparazione in anticipo, si riduce il lavoro necessario durante l'aggiornamento effettivo alla versione 1.36. Quando sarà disponibile la versione 1.36, sarà sufficiente aggiornare il piano di controllo e sostituire i nodi worker.

Prima di iniziare

  • Rivedere il sito NVIDIA Documentazione dell'operatore GPU.
  • Assicurarsi di avere l'accesso come amministratore del cluster.
  • Pianificate la vostra strategia di aggiornamento in base alla configurazione del cluster (nodo a GPU singola o nodi a GPU multipla).

Esempi di migrazione

I seguenti esempi dimostrano come migrare il cluster in base al numero di nodi GPU.

Esempio 1: Singolo nodo GPU nel cluster

Questo esempio dimostra la migrazione di un cluster con un singolo nodo GPU. Poiché l'unico nodo GPU non sarà disponibile durante l'aggiornamento, si aggiunge un secondo worker GPU temporaneo per mantenere la capacità.

Passo 1: Ottenere lo stato iniziale del cluster

  1. Controllare la versione del piano di controllo del cluster.

    ibmcloud ks cluster get -c <cluster_name>

    Esempio di output che mostra la versione 1.35:

    Master
Status:     Ready
State:      deployed
Health:     normal
Version:    1.35.4_1528

  2. Controllare la versione del nodo worker.

    ibmcloud ks worker ls -c <cluster_name>

    Esempio di output che mostra un singolo nodo 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

Passo 2: Installare l'Operatore GPU NVIDIA

Se si è seguita la procedura descritta in Preparazione alla migrazione prima che sia disponibile la versione 1.36, questo passaggio potrebbe essere già stato completato.

  1. Etichettare il nodo worker GPU esistente per evitare che l'operatore distribuisca risorse in conflitto con i driver preinstallati.

    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. Aggiungere il repository NVIDIA Helm e installare l'operatore 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. Verificare che i pod dell'operatore GPU siano in esecuzione. Si noti che l'installatore di driver, il plugin del dispositivo, il toolkit del contenitore e l'esportatore DCGM NON devono essere in esecuzione sul nodo etichettato.

    kubectl get pods -n gpu-operator -o wide

    Output di esempio:

    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>

Fase 3: aggiornamento del piano di controllo del cluster

  1. Aggiornare il piano di controllo del cluster alla versione 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0

  2. Verificare l'aggiornamento del piano di controllo.

    ibmcloud ks cluster get -c <cluster_name>

    Output di esempio:

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

Passo 4: aggiungere un nodo worker GPU temporaneo

  1. Aggiungere un secondo GPU worker temporaneo al cluster con la versione Kubernetes 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. Verificare che il nodo temporaneo sia pronto.

    ibmcloud ks worker ls -c <cluster_name>

    Esempio di output che mostra i nodi originali e quelli temporanei:

    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. Verificare che i pod dell'operatore GPU siano in esecuzione sul nuovo nodo temporaneo.

    kubectl get pods -n gpu-operator -o wide

    Esempio di output che mostra il plugin del driver e del dispositivo in esecuzione sul nodo temporaneo:

    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. Verificare la disponibilità della GPU sul nodo temporaneo.

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

Fase 5: Migrazione dei carichi di lavoro e aggiornamento del nodo originale

  1. Migrare i carichi di lavoro delle GPU sul nodo worker temporaneo 1.36. Per spostare i carichi di lavoro si possono usare i selettori di nodo, i taint o l'eliminazione manuale dei pod.

  2. Sostituire il nodo GPU originale.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update

  3. Verificare l'aggiornamento del nodo.

    ibmcloud ks worker ls -c <cluster_name>

    Esempio di output che mostra entrambi i nodi ora nella versione 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. Verificare che i pod dell'operatore GPU siano in esecuzione sul nodo originale aggiornato.

    kubectl get pods -n gpu-operator -o wide

  5. Verificare che tutti i carichi di lavoro della GPU siano in esecuzione.

    kubectl get pods -o wide

    Output di esempio:

    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>

Passo 6: rimuovere il nodo temporaneo (facoltativo)

Dopo che il nodo originale è sano e i carichi di lavoro sono stabili, è possibile rimuovere il nodo GPU temporaneo.

  1. Eliminare il pool temporaneo di lavoratori.

    ibmcloud ks worker-pool rm --cluster <cluster_name> --worker-pool temp-gpu-pool

  2. Verificare che rimanga solo il nodo originale.

    ibmcloud ks worker ls -c <cluster_name>

Esempio 2: Più nodi GPU nel cluster

Questo esempio dimostra la migrazione di un cluster con due nodi GPU dalla versione Kubernetes 1.35 a 1.36. Con i nodi multipli, è possibile aggiornare i nodi uno alla volta mantenendo la capacità della GPU.

Passo 1: Ottenere lo stato iniziale del cluster

  1. Controllare la versione del piano di controllo del cluster.

    ibmcloud ks cluster get -c <cluster_name>

    Esempio di output che mostra la versione 1.35:

    Master
Status:     Ready
State:      deployed
Health:     normal
Version:    1.35.4_1528

  2. Controllare le versioni dei nodi worker.

    ibmcloud ks worker ls -c <cluster_name>

    Esempio di output che mostra due nodi 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

Passo 2: Installare l'Operatore GPU NVIDIA

Se si è seguita la procedura descritta in Preparazione alla migrazione prima che sia disponibile la versione 1.36, questo passaggio potrebbe essere già stato completato.

  1. Etichettare i nodi worker GPU esistenti per evitare che l'operatore distribuisca risorse in conflitto con i driver preinstallati.

    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. Aggiungere il repository NVIDIA Helm e installare l'operatore 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. Verificare che i pod dell'operatore GPU siano in esecuzione. Si noti che l'installatore di driver, il plugin del dispositivo, il toolkit del contenitore e l'esportatore DCGM NON devono essere in esecuzione sui nodi etichettati.

    kubectl get pods -n gpu-operator -o wide

    Output di esempio:

    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>

Fase 3: aggiornamento del piano di controllo del cluster

  1. Aggiornare il piano di controllo del cluster alla versione 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0

  2. Verificare l'aggiornamento del piano di controllo.

    ibmcloud ks cluster get -c <cluster_name>

    Output di esempio:

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

Passo 4: Aggiornamento del primo nodo worker

  1. Sostituire il primo nodo worker.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update

  2. Verificare l'aggiornamento del nodo.

    ibmcloud ks worker ls -c <cluster_name>

    Output di esempio:

    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. Controllare lo stato del carico di lavoro della GPU. Il carico di lavoro della GPU pianificato sul nuovo nodo sarà nello stato Pending fino all'installazione del driver.

    kubectl get pods -o wide

    Output di esempio:

    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. Verificare che i pod dell'operatore GPU siano in esecuzione sul nuovo nodo.

    kubectl get pods -n gpu-operator -o wide

    Esempio di output che mostra il plugin del driver e del dispositivo in esecuzione sul nuovo nodo:

    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. Verificare il carico di lavoro della GPU pianificato sul nuovo nodo.

    kubectl get pods -o wide

    Output di esempio:

    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>

Fase 5: Aggiornamento dei nodi rimanenti

  1. Ripetete il passo 4 per ogni nodo GPU rimanente, aggiornando un nodo alla volta.

  2. Dopo che tutti i nodi sono stati aggiornati, verificare che tutti i nodi worker eseguano la versione 1.36.

    ibmcloud ks worker ls -c <cluster_name>

    Output di esempio:

    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. Verificare che tutti i pod dell'operatore GPU siano in esecuzione.

    kubectl get pods -n gpu-operator -o wide

  4. Verificare che tutti i carichi di lavoro della GPU siano in esecuzione.

    kubectl get pods -o wide

    Output di esempio:

    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>

Passi successivi

  • Monitorare i carichi di lavoro delle GPU per assicurarsi che vengano eseguiti correttamente.
  • Consultate il sito NVIDIA Documentazione dell'operatore GPU per le opzioni di configurazione avanzate.
  • Impostare il monitoraggio delle metriche della GPU usando l'esportatore DCGM di NVIDIA.