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

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

Executar cargas de trabalho de GPU no AKS requer uma configuração adequada e validação contínua para garantir que os recursos de computação são acessíveis, seguros e utilizados de forma ótima. Este artigo apresenta as melhores práticas para gerir nós com GPU, validar configurações e reduzir interrupções de carga de trabalho.

Para a maioria das cargas de trabalho de produção do AKS, o AKS Automatic é a opção predefinida recomendada. O AKS Automatic fornece uma base pronta para produção com operações pré-configuradas, salvaguardas de segurança e prontidão para pods apoiados por SLA, ajudando as equipas a reduzir a sobrecarga da plataforma do segundo dia.

Escolha AKS Automático ou AKS Standard para cargas de trabalho da GPU

Use as seguintes orientações como ponto de partida:

Para mais informações, consulte Introdução ao Azure Kubernetes Service (AKS) Automatic.

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

O AKS Automatic ajuda a estabelecer uma base operacional sólida para cargas de trabalho de GPUs de produção, fornecendo:

• Predefinições prontas para produção para a configuração de cluster.
• Melhores práticas e salvaguardas incorporadas.
• Prontidão dos pods apoiados por SLA para um comportamento previsível de arranque.
• Operações de cluster geridas que reduzem tarefas manuais do segundo dia.

Estes padrões de plataforma não substituem as melhores práticas ao nível da carga de trabalho, como controlos de posicionamento, verificações de validação e políticas de isolamento descritas neste artigo.

As cargas de trabalho da GPU, como treino de modelos de IA, inferência em tempo real, simulações e processamento de vídeo, dependem frequentemente de:

• Corrija a compatibilidade do controlador da GPU e do ambiente de execução.
• Agendamento preciso dos recursos da GPU.
• Acesso a dispositivos de hardware GPU dentro de contêineres.

Erros de configuração podem levar a altos custos, falhas inesperadas de trabalho ou subutilização da GPU.

Forçar a alocação da carga de trabalho da GPU

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

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

Para garantir a colocação correta:

• Contamine os nós da sua GPU usando uma chave como [gpu-vendor].com/gpu: NoSchedule (por exemplo, nvidia.com/gpu: NoSchedule). Esta restrição impede que cargas de trabalho que não utilizam GPU sejam agendadas nestes nós.

• Adicione uma tolerância correspondente na especificação do pod de carga de trabalho da GPU para que ela possa ser agendada nos nós da GPU contaminados.

• Defina pedidos de recursos e limites de GPU no seu pod para garantir que o agendador reserva a capacidade da GPU. Por exemplo:

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

• Use políticas de validação ou controladores de admissão para impor que as cargas de trabalho da GPU incluam as tolerâncias necessárias e os limites de recursos.

Essa abordagem garante que apenas cargas de trabalho prontas para GPU aterrissem em nós de GPU e tenham acesso aos recursos de computação especializados necessários.

No AKS Automatic, os corrimãos de proteção das plataformas são pré-configurados por defeito. Continuas a aplicar controlos de colocação ao nível da carga de trabalho para impor um comportamento rigoroso de agendamento da GPU.

Validar a instalação do controlador da GPU e a prontidão do ambiente de execução

Antes de implantar cargas de trabalho de GPU de produção, sempre valide se seus pools de nós de GPU são:

• Equipado com drivers GPU compatíveis.
• Hospedando um plugin de dispositivo Kubernetes saudável DaemonSet.
• Expondo [gpu-vendor].com/gpu como um recurso escalonável.

Pode confirmar a versão atual do controlador em execução nos conjuntos de nós de GPU com a interface de gestão do sistema (SMI) associada ao fabricante da GPU.

O comando seguinte executa nvidia-smi a partir do interior do pod de implantação do plug-in de dispositivo da GPU, para verificar a instalação do controlador e a prontidão do ambiente de execução num conjunto de nós com suporte para GPU NVIDIA:

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

Sua saída deve ser semelhante à saída de exemplo a seguir:

+-----------------------------------------------------------------------------+
|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 da GPU para confirmar a versão do driver instalada nos seus nós.

Nos seus agrupamentos de nós com GPU AMD ativada, em alternativa, implemente os componentes da GPU AMD e execute o comando amd-smi no pod do plug-in de dispositivo ROCm para confirmar a versão do controlador instalada.

Mantenha os nós com GPU atualizados com a imagem mais recente do sistema operativo do nó

Para garantir o desempenho, a segurança e a compatibilidade de suas cargas de trabalho de GPU no AKS, é essencial manter seus pools de nós de GPU atualizados com as últimas imagens recomendadas do sistema operacional de nós. Essas atualizações são essenciais porque:

• Inclua os drivers de GPU de nível de produção mais recentes, substituindo quaisquer versões obsoletas ou de fim de vida útil (EOL).
• São totalmente testados quanto à compatibilidade com sua versão atual do Kubernetes.
• Resolva vulnerabilidades conhecidas identificadas por fornecedores de GPU.
• Incorpore as mais recentes melhorias de tempo de execução do SO e do contentor para melhorar a estabilidade e a eficiência.

Atualize os pools de nós da sua GPU para a imagem mais recente recomendada do sistema operativo lançada pela AKS, seja definindo o canal de atualização automática ou através de atualização manual. Você pode monitorar e acompanhar as últimas liberações de imagens de nó usando o rastreador de liberação do AKS.

Para a maioria dos cenários de produção, comece com o AKS Automático como base padrão. Se usares o AKS Standard, configura explicitamente os canais de atualização e as janelas de manutenção.

Separe cargas de trabalho de GPU ao usar clusters compartilhados

Se um único cluster 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 lote, é importante separar essas cargas de trabalho para:

• Evite interferências acidentais ou contenção de recursos entre diferentes tipos de carga de trabalho.
• Melhore a segurança e mantenha os limites de conformidade.
• Simplifique o gerenciamento e o monitoramento do uso de recursos da GPU por categoria de carga de trabalho.

Você pode isolar cargas de trabalho de GPU em um único cluster AKS usando namespaces e políticas de rede. Isso permite uma governança mais clara por meio de cotas, limites e configurações de log específicos da carga de trabalho.

Cenário de exemplo

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

• Cargas de trabalho de formação: Tarefas de treino de modelos de IA com utilização intensiva de recursos.
• Cargas de trabalho de inferência: Serviços de inferência em tempo real sensíveis à latência.

Você pode usar as seguintes etapas para separar as duas cargas de trabalho:

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

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

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

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

3. Aplique políticas de rede para isolar o tráfego entre tipos de carga de trabalho. O manifesto seguinte bloqueia todo o tráfego de entrada e de saída do 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 espaço de nomes gpu-training.
• Nega todo o tráfego de entrada e saída por padrão, suportando um forte isolamento.

Esse modelo aumenta a clareza, o controle e a segurança em ambientes de GPU compartilhados, especialmente quando os tipos de carga de trabalho têm diferentes perfis de tempo de execução, níveis de risco ou requisitos operacionais.

Otimize o uso de recursos em nós de GPU usando GPU de várias instâncias (MIG)

Diferentes cargas de trabalho de GPU têm requisitos de memória distintos. Implementações mais pequenas, como a NVIDIA A100 40GB, podem não precisar de uma GPU inteira. No entanto, uma única carga de trabalho por padrão monopoliza o recurso da GPU, mesmo quando subutilizado.

O AKS suporta a otimização de recursos em nós de GPU dividindo-os em fatias menores usando GPU de várias instâncias (MIG), para que as equipes possam agendar trabalhos menores de forma mais eficiente. Saiba mais sobre os tamanhos de GPU suportados e como começar a usar GPUs de várias instâncias no AKS.

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

Para cargas de trabalho de IA executadas em VMs 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 fornecem armazenamento de alta taxa de transferência e baixa latência diretamente conectado ao host da VM, tornando-os ideais para cenários como armazenamento em cache de conjuntos de dados, armazenamento de pontos de verificação intermediários e pesos de modelo ou fornecimento de espaço de trabalho para pré-processamento e análise de dados.

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

O Azure suporta discos de dados NVMe efémeros numa vasta gama de famílias de VMs GPU Azure. Dependendo do tamanho da VM da 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 de VM para a família de GPUs escolhida.

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

Os cenários recomendados incluem:

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

Para obter mais orientações sobre discos de dados NVMe efêmeros, consulte Práticas recomendadas para discos de dados NVMe efêmeros no AKS.

Conteúdo relacionado

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

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