Procedure consigliate per GPU per il servizio Azure Kubernetes

Si applica a: ✔️ AKS Automatic ✔️ AKS Standard

L'esecuzione di carichi di lavoro GPU nel servizio Azure Kubernetes richiede la corretta configurazione e la convalida continua per garantire che le risorse di calcolo siano accessibili, sicure e usate in modo ottimale. Questo articolo illustra le procedure consigliate per la gestione dei nodi abilitati per GPU, la convalida delle configurazioni e la riduzione delle interruzioni del carico di lavoro.

Per la maggior parte dei carichi di lavoro del servizio Azure Kubernetes di produzione, il servizio Azure Kubernetes automatico è l'impostazione predefinita consigliata. AKS Automatic offre una configurazione di base pronta per la produzione con operazioni preconfigurate, protezioni di sicurezza e prontezza dei pod garantita da SLA, aiutando i team a ridurre l'overhead operativo continuativo della piattaforma.

Scegli AKS Automatic o AKS Standard per i carichi di lavoro GPU

Usare le indicazioni seguenti come punto di partenza:

Scenario Percorso consigliato Perché
La maggior parte dei carichi di lavoro di produzione su GPU AKS Automatico Impostazioni predefinite pronte per l’ambiente di produzione, protezioni integrate e overhead operativo del cluster ridotto.
Percorso più rapido dalla distribuzione alla produzione stabile AKS Automatico Operazioni del cluster preconfigurate e comportamento di avvio prevedibile tramite il contratto di servizio di conformità dei pod.
Personalizzazione avanzata della piattaforma e controllo operativo esplicito Servizio Azure Kubernetes Standard Maggiore flessibilità per il ciclo di vita del pool di nodi personalizzato e l'ottimizzazione della piattaforma.
Requisiti speciali di architettura della piattaforma non standard Servizio Azure Kubernetes Standard Maggiore controllo manuale sul comportamento e sulla configurazione dell'infrastruttura.

Per altre informazioni, vedi Introduzione ad Servizio Azure Kubernetes (AKS) Automatic.

Cosa offre AKS Automatic per i carichi di lavoro GPU di produzione

AKS Automatic aiuta a stabilire una solida baseline operativa per i carichi di lavoro GPU di produzione, fornendo:

  • Impostazioni predefinite adatte all’uso in produzione per la configurazione del cluster.
  • Procedure consigliate e misure di sicurezza predefinite.
  • Prontezza dei pod garantita da SLA per un comportamento di avvio prevedibile.
  • Operazioni di cluster gestito che riducono le attività manuali del day-2.

Queste impostazioni predefinite della piattaforma non sostituiscono le procedure consigliate a livello di carico di lavoro, ad esempio controlli di posizionamento, controlli di convalida e criteri di isolamento descritti in questo articolo.

I carichi di lavoro GPU, ad esempio il training del modello di intelligenza artificiale, l'inferenza in tempo reale, le simulazioni e l'elaborazione video, spesso dipendono da:

  • Correggere la compatibilità del driver GPU e del runtime.
  • Pianificazione accurata delle risorse GPU.
  • Accesso ai dispositivi hardware GPU all'interno dei contenitori.

Le configurazioni errate possono causare costi elevati, errori imprevisti dei processi o sottoutilizzo della GPU.

Imponi posizionamento del carico di lavoro GPU

Per impostazione predefinita, l'utilità di pianificazione di AKS colloca i pod su qualsiasi nodo disponibile con CPU e memoria sufficienti. Senza controlli di posizionamento del carico di lavoro, possono verificarsi due problemi:

  • L'utilità di pianificazione potrebbe assegnare i carichi di lavoro GPU a nodi privi di GPU, causando il mancato avvio dei carichi di lavoro.
  • I carichi di lavoro per utilizzo generico potrebbero occupare nodi GPU, sprecare risorse costose.

Per applicare il posizionamento corretto:

  • Applica un taint ai nodi con GPU utilizzando una chiave come [gpu-vendor].com/gpu: NoSchedule (ad esempio, nvidia.com/gpu: NoSchedule). Questo taint impedisce la pianificazione dei carichi di lavoro non GPU in questi nodi.

  • Aggiungere una tolleranza corrispondente nella specifica del pod del carico di lavoro GPU in modo che possa essere pianificata nei nodi GPU contaminati.

  • Definisci le richieste e i limiti delle risorse GPU nel tuo pod per garantire che lo scheduler riservi la capacità GPU. Per esempio:

    resources:
      limits:
        [gpu-vendor].com/gpu: 1
    
  • Usare i criteri di convalida o i controller di ammissione per imporre che i carichi di lavoro GPU includano le tolleranze necessarie e i limiti delle risorse.

Questo approccio garantisce che solo i carichi di lavoro pronti per GPU approdano su nodi GPU e abbiano accesso alle risorse di calcolo specialistico necessarie.

In AKS Automatic, le barriere di protezione della piattaforma sono preconfigurate per impostazione predefinita. Si applicano ancora controlli di posizionamento a livello di carico di lavoro per applicare un comportamento di pianificazione GPU rigoroso.

Verificare l'installazione del driver GPU e la prontezza dell'ambiente di runtime

Prima di distribuire carichi di lavoro GPU di produzione, verificare sempre che i pool di nodi GPU siano:

  • Dotato di driver GPU compatibili.
  • Hosting di un DaemonSet del plug-in del dispositivo Kubernetes integro.
  • Esposizione [gpu-vendor].com/gpu come risorsa pianificabile.

È possibile confermare la versione corrente del driver in esecuzione nei pool di nodi GPU con l'interfaccia di gestione del sistema (SMI) associata al fornitore della GPU.

Il comando seguente viene eseguito nvidia-smi dall'interno del pod di distribuzione del plug-in del dispositivo GPU per verificare l'installazione del driver e l'idoneità del runtime in un pool di nodi abilitato per GPU NVIDIA:

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

L'output dovrebbe essere simile all'output di esempio seguente:

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

Ripetere il kubectl exec comando per ogni pool di nodi GPU per confermare la versione del driver installata nei nodi.

Nei pool di nodi abilitati per GPU AMD distribuire in alternativa i componenti GPU AMD ed eseguire il amd-smi comando nel pod del plug-in del dispositivo ROCm per confermare la versione del driver installata.

Mantenere i nodi abilitati per la GPU aggiornati all'immagine del sistema operativo del nodo più recente

Per garantire prestazioni, sicurezza e compatibilità dei carichi di lavoro GPU nel servizio Azure Kubernetes, è essenziale mantenere aggiornati i pool di nodi GPU con le immagini del sistema operativo del nodo consigliate più recenti. Questi aggiornamenti sono fondamentali perché:

  • Includono i driver GPU di livello di produzione più recenti, sostituendo eventuali versioni deprecate o fine del servizio (EOL).
  • Vengono testati completamente per la compatibilità con la versione corrente di Kubernetes.
  • Risolvono le vulnerabilità note identificate dai fornitori di GPU.
  • Incorporano i miglioramenti più recenti del sistema operativo e del runtime dei contenitori per migliorare la stabilità e l'efficienza.

Aggiorna i pool di nodi GPU all'immagine del sistema operativo dei nodi più recente consigliata rilasciata da AKS, impostando il canale di aggiornamento automatico o mediante aggiornamento manuale. È possibile monitorare e tenere traccia delle versioni più recenti dell'immagine del nodo usando lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.

Per la maggior parte degli scenari di produzione, iniziare con AKS Automatic come baseline predefinita. Se si utilizza AKS Standard, configurare esplicitamente i canali di aggiornamento e le finestre di manutenzione.

Separare i carichi di lavoro GPU quando si usano cluster condivisi

Se un singolo cluster del servizio Azure Kubernetes con pool di nodi GPU esegue più tipi di carichi di lavoro GPU, ad esempio il training del modello, l'inferenza in tempo reale o l'elaborazione batch, è importante separare questi carichi di lavoro per:

  • Evitare interferenze accidentali o conflitti di risorse tra diversi tipi di carico di lavoro.
  • Migliorare la sicurezza e mantenere i limiti di conformità.
  • Semplificare la gestione e il monitoraggio dell'utilizzo delle risorse GPU per categoria di carico di lavoro.

È possibile isolare i carichi di lavoro GPU all'interno di un singolo cluster del servizio Azure Kubernetes usando spazi dei nomi e criteri di rete. Ciò consente una governance più chiara tramite quote, limiti e configurazioni di registrazione specifiche del carico di lavoro.

Scenario di esempio

Si consideri un cluster del servizio Azure Kubernetes che ospita due diversi tipi di carico di lavoro GPU che non devono comunicare tra loro:

  • Carichi di lavoro di addestramento: processi di addestramento di modelli di intelligenza artificiale ad alta intensità di risorse.
  • Carichi di lavoro di inferenza: servizi di inferenza in tempo reale sensibili alla latenza.

È possibile usare la procedura seguente per separare i due carichi di lavoro:

  1. Creare spazi dei nomi dedicati per tipo di carico di lavoro usando il kubectl create namespace comando.

    kubectl create namespace gpu-training
    kubectl create namespace gpu-inference
    
  2. Etichettare i pod del carico di lavoro GPU per tipo, come illustrato nell'esempio seguente:

    metadata:
      namespace: gpu-training
      labels:
        workload: training
    
  3. Applicare criteri di rete per isolare il traffico tra i tipi di carico di lavoro. Il manifesto seguente blocca tutti i dati in ingresso e in uscita per lo spazio dei gpu-training nomi (a meno che non sia consentito in modo esplicito):

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

Questo criterio:

  • Si applica a tutti i pod nello gpu-training spazio dei nomi .
  • Nega tutto il traffico in ingresso e in uscita per impostazione predefinita, supportando l'isolamento sicuro.

Questo modello migliora chiarezza, controllo e sicurezza negli ambienti GPU condivisi, soprattutto quando i tipi di carico di lavoro hanno profili di runtime, livelli di rischio o requisiti operativi diversi.

Ottimizzare l'utilizzo delle risorse nei nodi GPU usando GPU a istanze multipla (MIG)

I diversi carichi di lavoro GPU hanno requisiti di memoria diversi. Le distribuzioni più piccole, ad esempio NVIDIA A100 40 GB, potrebbero non avere bisogno di un'intera GPU. Tuttavia, un singolo carico di lavoro per impostazione predefinita monopolizza la risorsa GPU anche quando è sottoutilizzata.

Il servizio Azure Kubernetes supporta l'ottimizzazione delle risorse nei nodi GPU suddividendoli in sezioni più piccole usando GPU a istanza multipla (MIG), in modo che i team possano pianificare processi più piccoli in modo più efficiente. Altre informazioni sulle dimensioni della GPU supportate e su come iniziare a usare GPU a più istanze nel servizio Azure Kubernetes.

Usare dischi dati NVMe temporanei come cache ad alte prestazioni

Per i carichi di lavoro di intelligenza artificiale in esecuzione in macchine virtuali GPU nel servizio Azure Kubernetes, l'accesso rapido e affidabile all'archiviazione temporanea è fondamentale per ottimizzare le prestazioni di training e inferenza. I dischi dati NVMe temporanei offrono archiviazione a bassa latenza e velocità effettiva elevata direttamente collegata all'host della macchina virtuale, rendendoli ideali per scenari come la memorizzazione dei set di dati nella cache, l'archiviazione di checkpoint intermedi e i pesi del modello o lo spazio di lavoro per la pre-elaborazione e l'analisi dei dati.

Quando si distribuiscono pool di nodi abilitati GPU per i carichi di lavoro di intelligenza artificiale, configurare dischi dati NVMe temporanei per fungere da cache ad alte prestazioni o spazio di lavoro temporaneo. Questo approccio consente di eliminare i colli di bottiglia di I/O, accelerare le operazioni con uso intensivo di dati e assicura che le risorse GPU non siano inattive durante l'attesa dei dati.

Azure supporta dischi dati NVMe temporanei in un'ampia gamma di famiglie di macchine virtuali GPU Azure. A seconda delle dimensioni della macchina virtuale GPU, la macchina virtuale ha fino a otto dischi dati NVMe temporanei con una capacità combinata fino a 28 TiB. Per configurazioni dettagliate sulle dimensioni delle macchine virtuali, vedere la documentazione della serie ND H100 v5 o la documentazione relativa alle dimensioni della macchina virtuale per la famiglia di GPU scelta.

Per semplificare il provisioning e la gestione, usare Azure Container Storage, che consente di rilevare e orchestrare automaticamente i dischi NVMe effimeri per i carichi di lavoro Kubernetes.

Gli scenari consigliati includono:

  • Memorizzazione nella cache di ampi set di dati e checkpoint del modello per l'addestramento e l'inferenza dell'intelligenza artificiale.
  • Memorizzazione nella cache dei pesi del modello per l'inferenza dell'intelligenza artificiale. Ad esempio, il modello di hosting KAITO come artefatti OCI su NVMe locale.
  • Fornire spazio rapido per processi batch e pipeline di dati.

Importante

I dati nei dischi NVMe temporanei sono temporanei e andranno persi se la macchina virtuale viene deallocata o ridistribuita. Usare questi dischi solo per dati non critici, temporanei e archiviare informazioni importanti sulle soluzioni di archiviazione di Azure persistenti.

Per ulteriori indicazioni sui dischi dati NVMe temporanei, vedere Migliori pratiche per dischi dati NVMe temporanei in AKS.

Per ulteriori informazioni su AKS e i carichi di lavoro GPU, consulta gli articoli seguenti: