Práticas recomendadas de GPU para o Serviço de Kubernetes do Azure (AKS)

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

A execução de cargas de trabalho de GPU no AKS requer a configuração adequada e a validação contínua para garantir que os recursos de computação sejam acessíveis, seguros e idealmente utilizados. Este artigo descreve as práticas recomendadas para gerenciar nós habilitados para GPU, validar configurações e reduzir interrupções de carga de trabalho.

Para a maioria das cargas de trabalho de produção no AKS, o AKS Automatic é a opção padrão recomendada. O AKS Automático fornece uma base pronta para produção, com operações pré-configuradas, salvaguardas de segurança e prontidão de pods respaldada por SLA, ajudando as equipes a reduzir a sobrecarga operacional da plataforma no dia 2.

Escolher AKS Automático ou AKS Standard para cargas de trabalho de GPU

Use as seguintes diretrizes como ponto de partida:

Para obter mais informações, consulte Introdução ao AKS (Serviço de Kubernetes do Azure) Automático.

O que o AKS Automatic fornece para cargas de trabalho de GPU de produção

O AKS Automatic ajuda a estabelecer uma linha de base operacional forte para cargas de trabalho de GPU de produção fornecendo:

• Configurações padrão prontas para produção para a configuração do cluster.
• Melhores práticas e salvaguardas integradas.
• Preparação de pod apoiada por SLA para comportamento de inicialização previsível.
• Operações de cluster gerenciadas que reduzem tarefas manuais do dia 2.

Esses padrões de plataforma não substituem as práticas recomendadas no nível da carga de trabalho, como controles de posicionamento, verificações de validação e políticas de isolamento descritas neste artigo.

Cargas de trabalho de GPU, como treinamento de modelo de IA, inferência em tempo real, simulações e processamento de vídeo, geralmente dependem de:

• Compatibilidade correta entre driver de GPU e runtime.
• Agendamento preciso dos recursos de GPU.
• Acesso aos dispositivos de hardware de GPU dentro dos contêineres.

Configurações incorretas podem gerar altos custos, falhas inesperadas de trabalho ou subutilização da GPU.

Impor colocação de carga de trabalho de GPU

Por padrão, o agendador do AKS agenda pods em qualquer nó disponível com CPU e memória suficientes. Sem controles de posicionamento de carga de trabalho, dois problemas podem ocorrer:

• O agendador pode colocar cargas de trabalho de GPU em nós sem GPUs, fazendo com que as cargas de trabalho não sejam iniciadas.
• Cargas de trabalho de uso geral podem ocupar nós de GPU, desperdiçando recursos caros.

Para impor a colocação correta:

• Aplique um taint aos seus nós de GPU com uma chave como [gpu-vendor].com/gpu: NoSchedule (por exemplo, nvidia.com/gpu: NoSchedule). Isso impede que cargas de trabalho não GPU sejam agendadas nesses nós.

• Adicionar uma tolerância correspondente na especificação do pod da carga de trabalho de GPU para que ele possa ser agendado nos nós de GPU com taint.

• Defina solicitações de recursos de GPU e limites em seu pod para garantir que o agendador reserve a capacidade de GPU. Por exemplo:

  resources:
    limits:
      [gpu-vendor].com/gpu: 1
  

• Usar políticas de validação ou controladores de admissão para impor que as cargas de trabalho de GPU incluam as tolerâncias e os limites de recurso exigidos.

Essa abordagem garante que apenas cargas de trabalho preparadas para GPU sejam executadas em nós de GPU e tenham acesso aos recursos de computação especializados de que precisam.

No AKS Automatic, os guardrails de plataforma são pré-configurados por padrão. Você ainda aplica controles de posicionamento no nível da carga de trabalho para impor um comportamento estrito de agendamento de GPU.

Validar a instalação do driver de GPU e a preparação para o runtime

Antes de implantar cargas de trabalho de GPU em produção, sempre validar se os pools de nós de GPU estão:

• Equipados com drivers de GPU compatíveis.
• Hospedando um DaemonSet de Plugin de Dispositivo do Kubernetes íntegro.
• Expondo [gpu-vendor].com/gpu como um recurso agendável.

É possível confirmar a versão atual do driver em execução nos pools de nós de GPU usando a interface de gerenciamento do sistema (SMI) associada ao fornecedor da GPU.

O comando a seguir executa nvidia-smi de dentro do pod de implantação do plugin de dispositivo de GPU para verificar a instalação do driver e a preparação do runtime em um pool de nós com GPU NVIDIA habilitada:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

Sua saída deve ser parecida com o seguinte exemplo de saída:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Repita o kubectl exec comando para cada pool de nós de GPU para confirmar a versão do driver instalada em seus nós.

Nos pools de nós com GPU AMD habilitada, implantar os componentes de GPU AMD e executar o comando amd-smi no pod do plugin de dispositivo ROCm para confirmar a versão do driver instalada.

Manter nós com GPU habilitada atualizados para a imagem mais recente do SO do nó

Para garantir o desempenho, a segurança e a compatibilidade das cargas de trabalho de GPU no AKS, é essencial manter os pools de nós de GPU atualizados com as imagens de SO mais recentes recomendadas. Essas atualizações são críticas porque:

• Incluem os drivers de GPU mais recentes em nível de produção, substituindo versões preteridas ou de fim de suporte (EOL).
• São totalmente testadas para compatibilidade com a versão atual do Kubernetes.
• Corrigem vulnerabilidades conhecidas identificadas pelos fornecedores de GPU.
• Incorporam as melhorias mais recentes do SO e do runtime de contêiner para maior estabilidade e eficiência.

Atualize os pools de nós de GPU para a imagem de SO de nó mais recente recomendada e lançada pelo AKS, configurando o canal de atualização automática ou por meio da atualização manual. É possível monitorar e acompanhar as versões mais recentes de imagens de nó usando o rastreador de versões do AKS.

Para a maioria dos cenários de produção, comece com o AKS Automatic como a linha de base padrão. Se você usar o AKS Standard, configure explicitamente os canais de atualização e as janelas de manutenção.

Separar cargas de trabalho de GPU ao usar clusters compartilhados

Se um único cluster do AKS com pools de nós de GPU estiver executando vários tipos de cargas de trabalho de GPU, como treinamento de modelo, inferência em tempo real ou processamento em lotes, é importante separar essas cargas de trabalho para:

• Evitar interferências acidentais ou contenção de recursos entre diferentes tipos de carga de trabalho.
• Melhorar a segurança e manter os limites de conformidade.
• Simplificar o gerenciamento e o monitoramento do uso de recursos de GPU por categoria de carga de trabalho.

É possível isolar cargas de trabalho de GPU dentro de um único cluster do AKS usando namespaces e políticas de rede. Isso permite uma governança mais clara por meio de cotas, limites e configurações de registro em log específicas por carga de trabalho.

Cenário de exemplo

Considere um cluster do AKS que hospeda dois tipos diferentes de cargas de trabalho de GPU que não precisam se comunicar entre si:

• Cargas de trabalho de treinamento: tarefas de treinamento de modelos de IA que exigem muitos recursos.
• Cargas de trabalho de inferência: serviços de inferência em tempo real sensíveis à latência.

É possível usar as etapas a seguir para separar as duas cargas de trabalho:

1. Criar namespaces dedicados por tipo de carga de trabalho usando o comando kubectl create namespace.

   kubectl create namespace gpu-training
   kubectl create namespace gpu-inference
   

2. Rotular os pods de carga de trabalho de GPU por tipo, como mostrado no exemplo a seguir:

   metadata:
     namespace: gpu-training
     labels:
       workload: training
   

3. Aplicar políticas de rede para isolar o tráfego entre os tipos de carga de trabalho. O manifesto a seguir bloqueia toda a entrada e saída para o namespace gpu-training (a menos que seja explicitamente permitido):

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: deny-cross-namespace
     namespace: gpu-training
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress
     ingress: []
     egress: []
   

Esta política:

• Aplica-se a todos os pods no namespace gpu-training.
• Nega todo o tráfego de entrada e saída por padrão, oferecendo isolamento robusto.

Este modelo aprimora o esclarecimento, o controle e a segurança em ambientes de GPU compartilhada, especialmente quando os tipos de carga de trabalho têm perfis de runtime, níveis de risco ou requisitos operacionais diferentes.

Otimizar o uso do recurso em nós de GPU usando GPU de instância múltipla (MIG)

Cargas de trabalho de GPU diferentes têm requisitos de memória diferentes. Implantações menores, como NVIDIA A100 40 GB, podem não precisar de uma GPU inteira. No entanto, uma única carga de trabalho, por padrão, monopoliza o recurso de GPU mesmo quando está subutilizada.

O AKS dá suporte à otimização de recursos em nós de GPU, dividindo-os em partes menores com GPU de instância múltipla (MIG), para que as equipes possam agendar trabalhos menores com mais eficiência. Saiba mais sobre os tamanhos de GPU com suporte e como começar a usar GPUs de instância múltipla no AKS.

Usar discos de dados NVMe efêmeros como cache de alto desempenho

Para cargas de trabalho de IA em execução em VMs de GPU no AKS, o acesso rápido e confiável ao armazenamento temporário é fundamental para maximizar o desempenho de treinamento e inferência. Os discos de dados NVMe efêmeros oferecem armazenamento de alta taxa de transferência e baixa latência, diretamente anexado ao host da VM, tornando-os ideais para cenários como armazenar em cache conjuntos de dados, guardar pontos de verificação e pesos de modelo intermediários ou fornecer espaço temporário para pré-processamento e análise de dados.

Ao implantar pools de nós com GPU para cargas de trabalho de IA, configurar discos de dados NVMe efêmeros para atuar como cache ou espaço temporário de alto desempenho. Essa abordagem ajuda a eliminar gargalos de E/S, acelera operações com uso intensivo de dados e garante que seus recursos de GPU não fiquem ociosos enquanto aguardam dados.

Azure dá suporte a discos de dados NVMe efêmeros em uma ampla gama de famílias de VM de GPU Azure. Dependendo do tamanho da VM de GPU, a VM tem até oito discos de dados NVMe efêmeros com uma capacidade combinada de até 28 TiB. Para obter configurações detalhadas sobre tamanhos de VM, consulte a documentação da série ND H100 v5 ou a documentação de tamanho da VM para sua família de GPU escolhida.

Para simplificar o provisionamento e o gerenciamento, use o Armazenamento de Contêineres do Azure, que pode detectar e orquestrar automaticamente discos NVMe efêmeros para suas cargas de trabalho do Kubernetes.

Os cenários recomendados incluem:

• Armazenando em cache grandes conjuntos de dados e pontos de verificação de modelo para treinamento e inferência de IA.
• Armazenar em cache pesos de modelo para inferência de IA. Por exemplo, modelo de hosting KAITO como artefatos OCI em NVMe local.
• Fornecer espaço temporário rápido para trabalhos em lote e pipelines de dados.

Para obter mais diretrizes sobre discos de dados NVMe efêmeros, consulte as práticas recomendadas para discos de dados NVMe efêmeros no AKS.

Conteúdo relacionado

Para saber mais sobre cargas de trabalho de AKS e GPU, confira os seguintes artigos:

• Introdução ao AKS (Serviço de Kubernetes do Azure) Automatic
• Criar um cluster automático do AKS
• Criar um pool de nós com GPU no cluster do AKS.
• Monitorar cargas de trabalho de GPU usando um exportador NVIDIA DCGM autogerenciado.
• Dimensionar automaticamente suas cargas de trabalho de GPU com base em métricas comuns de GPU usando KEDA e exportador DCGM.