Migração para drivers de GPU NVIDIA autogerenciados para Kubernetes 1.36

A partir da versão Kubernetes 1.36, o IBM Cloud Kubernetes Service não instala mais automaticamente os drivers da GPU NVIDIA nos nós de trabalho da GPU. Você mesmo deve instalar e gerenciar os drivers de GPU para executar cargas de trabalho de GPU.

O que está mudando?

Versão 1.36 e e posteriores
Os drivers de GPU não são pré-instalados em nós de trabalho de GPU novos ou substituídos. Você deve instalar e manter os seguintes componentes:
  • NVIDIA driver do kernel
  • Componentes de tempo de execução do contêiner (como nvidia-container-toolkit)
  • Kubernetes plug-in de dispositivo
Versões 1.35 e anteriores
Os drivers da GPU são instalados e gerenciados automaticamente pelo site IBM em todos os nós de trabalho da GPU.

Qual é o impacto?

Os pods que solicitam recursos de GPU permanecem no estado Pending até que você instale os drivers de GPU necessários no nó de trabalho. Depois que os drivers são instalados, os pods pendentes passam automaticamente para o estado Running.

Entendendo o processo de migração

A migração para drivers de GPU autogerenciados segue uma sequência específica para garantir que as cargas de trabalho da GPU continuem em execução durante a atualização:

  1. Fase de pré-instalação: Você instala o NVIDIA GPU Operator em seu cluster enquanto ele ainda estiver executando a versão 1.35 ou anterior. Durante a instalação, você rotula os nós de GPU existentes para evitar que o operador implemente recursos de driver, que entrariam em conflito com os drivers pré-instalados.

  2. Atualização do plano de controle: você atualizará o plano de controle do cluster para a versão 1.36.

  3. Atualização do nó de trabalho: Substitua cada nó de trabalho para atualizá-lo para a versão 1.36. Quando você faz isso, as etiquetas que impediam a implantação do driver são removidas automaticamente. Isso permite que o operador da GPU NVIDIA implemente sua pilha de drivers nos novos nós.

  4. Recuperação automática da carga de trabalho: Quando o operador instala os drivers em um nó substituído, todas as cargas de trabalho de GPU pendentes passam automaticamente para o estado Running.

Preparando-se para a migração antes que a versão 1.36 esteja disponível

Você pode concluir as etapas de pré-instalação antes do lançamento da versão 1.36 para preparar seu cluster para uma migração mais tranquila:

  1. Rotule os nós de trabalho de GPU existentes para evitar que o operador implante recursos que entrem em conflito com os drivers pré-instalados.

    kubectl label node/<node_name> nvidia.com/gpu.deploy.operands=false
    kubectl label node/<node_name> nvidia.com/gpu.deploy.driver=false
    
  2. Instale o NVIDIA GPU Operator seguindo o guia de instalação do NVIDIA GPU Operator.

  3. Verifique se o operador está instalado, mas não está implantando recursos de driver em seus nós rotulados.

    kubectl get pods -n gpu-operator -o wide
    

Ao concluir essas etapas de preparação com antecedência, você reduz o trabalho necessário durante a atualização real para a versão 1.36. Quando a versão 1.36 estiver disponível, você só precisará atualizar o plano de controle e substituir os nós de trabalho.

Antes de Iniciar

  • Consulte a documentação do Operador de GPU do site NVIDIA.
  • Certifique-se de que você tenha acesso de administrador do cluster.
  • Planeje sua estratégia de upgrade com base na configuração do cluster (um único nó de GPU vs. vários nós de GPU).

Exemplos de migração

Os exemplos a seguir demonstram como migrar seu cluster com base no número de nós de GPU.

Exemplo 1: nó de GPU único no cluster

Este exemplo demonstra a migração de um cluster com um único nó de GPU. Como o único nó de GPU não estará disponível durante o upgrade, você adiciona um segundo trabalhador temporário de GPU para manter a capacidade.

Etapa 1: Obter o estado inicial do cluster

  1. Verifique a versão do plano de controle do cluster.

    ibmcloud ks cluster get -c CLUSTER_NAME
    

    Exemplo de saída mostrando a versão 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Verifique a versão do nó de trabalho.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemplo de saída mostrando um único nó de 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
    

Etapa 2: Instale o operador de GPU NVIDIA

Se você seguiu as etapas em Preparando-se para a migração antes de a versão 1.36 estar disponível, talvez já tenha concluído essa etapa.

  1. Rotular o nó de trabalho da GPU existente para evitar que o operador implante recursos que entrem em conflito com os drivers pré-instalados.

    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. Adicione o repositório NVIDIA Helm e instale o operador de 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. Verifique se os pods do operador da GPU estão em execução. Observe que o instalador de driver, o plug-in de dispositivo, o kit de ferramentas de contêiner e o exportador DCGM NÃO devem ser executados no nó rotulado.

    kubectl get pods -n gpu-operator -o wide
    

    Saída de exemplo:

    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>
    

Etapa 3: Faça upgrade do plano de controle do cluster

  1. Atualize o plano de controle do cluster para a versão 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Verifique a atualização do plano de controle.

    ibmcloud ks cluster get -c <cluster_name>
    

    Saída de exemplo:

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

Etapa 4: adicionar um nó de trabalho temporário da GPU

  1. Adicione um segundo trabalhador temporário de GPU ao cluster com a versão 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. Verifique se o nó temporário está pronto.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemplo de saída mostrando os nós originais e temporários:

    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. Verifique se os pods do operador de GPU estão sendo executados no novo nó temporário.

    kubectl get pods -n gpu-operator -o wide
    

    Exemplo de saída que mostra o driver e o plug-in de dispositivo em execução no nó temporário:

    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. Verifique a prontidão da GPU no nó temporário.

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

Etapa 5: migrar as cargas de trabalho e atualizar o nó original

  1. Migre suas cargas de trabalho de GPU para o nó de trabalho temporário 1.36. Você pode usar seletores de nós, taints ou exclusão manual de pods para mover cargas de trabalho.

  2. Substitua o nó original da GPU.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  3. Verifique a atualização do nó.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemplo de saída mostrando os dois nós agora na versão 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. Verifique se os pods do operador de GPU estão sendo executados no nó original atualizado.

    kubectl get pods -n gpu-operator -o wide
    
  5. Verifique se todas as cargas de trabalho da GPU estão sendo executadas.

    kubectl get pods -o wide
    

    Saída de exemplo:

    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>
    

Etapa 6: remover o nó temporário (opcional)

Depois que o nó original estiver íntegro e as cargas de trabalho estiverem estáveis, você poderá, opcionalmente, remover o nó temporário da GPU.

  1. Excluir o pool de trabalhadores temporários.

    ibmcloud ks worker-pool rm --cluster <cluster_name> --worker-pool temp-gpu-pool
    
  2. Verifique se apenas o nó original permanece.

    ibmcloud ks worker ls -c <cluster_name>
    

Exemplo 2: Vários nós de GPU no cluster

Este exemplo demonstra a migração de um cluster com dois nós de GPU da versão Kubernetes 1.35 para 1.36. Com vários nós, você pode fazer upgrade de um nó de cada vez, mantendo a capacidade da GPU.

Etapa 1: Obter o estado inicial do cluster

  1. Verifique a versão do plano de controle do cluster.

    ibmcloud ks cluster get -c <cluster_name>
    

    Exemplo de saída mostrando a versão 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Verifique as versões do nó de trabalho.

    ibmcloud ks worker ls -c <cluster_name>
    

    Exemplo de saída mostrando dois nós de 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
    

Etapa 2: Instale o operador de GPU NVIDIA

Se você seguiu as etapas em Preparando-se para a migração antes de a versão 1.36 estar disponível, talvez já tenha concluído essa etapa.

  1. Rotular os nós de trabalho de GPU existentes para evitar que o operador implante recursos que entrem em conflito com os drivers pré-instalados.

    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. Adicione o repositório NVIDIA Helm e instale o operador de 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. Verifique se os pods do operador da GPU estão em execução. Observe que o instalador de driver, o plug-in de dispositivo, o kit de ferramentas de contêiner e o exportador DCGM NÃO devem ser executados nos nós rotulados.

    kubectl get pods -n gpu-operator -o wide
    

    Saída de exemplo:

    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>
    

Etapa 3: Faça upgrade do plano de controle do cluster

  1. Atualize o plano de controle do cluster para a versão 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Verifique a atualização do plano de controle.

    ibmcloud ks cluster get -c <cluster_name>
    

    Saída de exemplo:

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

Etapa 4: Atualizar o primeiro nó de trabalho

  1. Substitua o primeiro nó de trabalho.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  2. Verifique a atualização do nó.

    ibmcloud ks worker ls -c <cluster_name>
    

    Saída de exemplo:

    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. Verifique o status da carga de trabalho da GPU. A carga de trabalho da GPU programada no novo nó estará no estado Pending até que o driver seja instalado.

    kubectl get pods -o wide
    

    Saída de exemplo:

    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. Verifique se os pods do operador de GPU estão sendo executados no novo nó.

    kubectl get pods -n gpu-operator -o wide
    

    Exemplo de saída que mostra o driver e o plug-in de dispositivo em execução no novo nó:

    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. Verifique a carga de trabalho da GPU programada no novo nó.

    kubectl get pods -o wide
    

    Saída de exemplo:

    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>
    

Etapa 5: Atualizar os nós restantes

  1. Repita a Etapa 4 para cada nó de GPU restante, atualizando um nó de cada vez.

  2. Depois que todos os nós forem atualizados, verifique se todos os nós de trabalho estão executando a versão 1.36.

    ibmcloud ks worker ls -c <cluster_name>
    

    Saída de exemplo:

    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. Verifique se todos os pods de operador de GPU estão em execução.

    kubectl get pods -n gpu-operator -o wide
    
  4. Verifique se todas as cargas de trabalho da GPU estão sendo executadas.

    kubectl get pods -o wide
    

    Saída de exemplo:

    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>
    

Próximas etapas

  • Monitore as cargas de trabalho da GPU para garantir que estejam sendo executadas corretamente.
  • Consulte a documentação do Operador de GPU do site NVIDIA para obter opções avançadas de configuração.
  • Configure o monitoramento das métricas de GPU usando o exportador NVIDIA DCGM.