Aanbevolen GPU-procedures voor Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Voor het uitvoeren van GPU-workloads op AKS is een juiste installatie en continue validatie vereist om ervoor te zorgen dat rekenresources toegankelijk, veilig en optimaal worden gebruikt. In dit artikel vindt u een overzicht van aanbevolen procedures voor het beheren van gpu-knooppunten, het valideren van configuraties en het verminderen van werkbelastingonderbrekingen.

Voor de meeste AKS-workloads in productie is AKS Automatic de aanbevolen standaardinstelling. AKS Automatic biedt een productierijpe basis met vooraf geconfigureerde operationele mogelijkheden, beveiligingsmaatregelen en SLA-ondersteunde podgereedheid, waarmee teams de platformoverhead op dag 2 kunnen verminderen.

Kies AKS Automatisch of AKS Standard voor GPU-workloads

Gebruik de volgende richtlijnen als uitgangspunt:

Zie Inleiding tot Azure Kubernetes Service (AKS) Automatisch voor meer informatie.

Wat AKS Automatic biedt voor GPU-productieworkloads

AKS Automatic helpt bij het vaststellen van een sterke operationele basislijn voor gpu-workloads voor productie door het volgende te bieden:

• Standaardinstellingen die gereed zijn voor productie voor clusterconfiguratie.
• Ingebouwde beproefde methoden en beveiligingsmaatregelen.
• Gereedheid voor pods met SLA-ondersteuning voor voorspelbaar opstartgedrag.
• Beheerde clusteractiviteiten die handmatige day-2-beheertaken verminderen.

Deze standaardinstellingen van het platform vervangen niet de best practices op het niveau van workloads, zoals plaatsingscontroles, validatiecontroles en isolatiebeleid, zoals beschreven in dit artikel.

GPU-workloads, zoals training van AI-modellen, realtime deductie, simulaties en videoverwerking, zijn vaak afhankelijk van:

• Corrigeer het GPU-stuurprogramma en de runtimecompatibiliteit.
• Nauwkeurige planning van GPU-resources.
• Toegang tot GPU-hardwareapparaten in containers.

Onjuiste configuraties kunnen leiden tot hoge kosten, onverwachte taakfouten of GPU-ondergebruik.

Plaatsing van GPU-workloads afdwingen

Standaard plaatst de AKS-scheduler pods op elk beschikbaar knooppunt met voldoende CPU en geheugen. Zonder besturingselementen voor de plaatsing van werkbelastingen kunnen er twee problemen optreden:

• De scheduler kan GPU-workloads plaatsen op knooppunten zonder GPU's, waardoor de workloads niet kunnen worden gestart.
• Workloads voor algemeen gebruik kunnen GPU-knooppunten in beslag nemen en kostbare resources verspillen.

De juiste plaatsing afdwingen:

• Taint uw GPU-knooppunten met behulp van een sleutel zoals [gpu-vendor].com/gpu: NoSchedule (bijvoorbeeld nvidia.com/gpu: NoSchedule). Deze taint voorkomt dat workloads zonder GPU op deze knooppunten worden ingepland.

• Voeg een bijbehorende toleratie toe aan de podspecificatie van je GPU-workload, zodat deze kan worden ingepland op de van een taint voorziene GPU-knooppunten.

• Definieer GPU-resourceaanvragen en -limieten in uw pod om ervoor te zorgen dat de scheduler GPU-capaciteit reserveert. Voorbeeld:

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

• Gebruik validatiebeleid of toegangscontrollers om af te dwingen dat GPU-workloads de vereiste toleranties en resourcelimieten bevatten.

Deze aanpak garandeert dat alleen GPU-workloads terechtkomen op GPU-knooppunten en toegang hebben tot de gespecialiseerde rekenresources die ze nodig hebben.

In AKS Automatic worden platformbeveiligingen standaard vooraf geconfigureerd. Je past nog steeds plaatsingsinstellingen op workloadniveau toe om strikte GPU-planning af te dwingen.

Installatie van GPU-stuurprogramma's en runtimegereedheid valideren

Voordat u GPU-workloads voor productie implementeert, moet u altijd controleren of uw GPU-knooppuntgroepen het volgende zijn:

• Uitgerust met compatibele GPU-stuurprogramma's.
• Een goed functionerende Kubernetes Device Plugin DaemonSet hosten.
• [gpu-vendor].com/gpu blootstellen als een planbare resource.

U kunt de huidige stuurprogrammaversie die wordt uitgevoerd op uw GPU-knooppuntgroepen bevestigen met de systeembeheerinterface (SMI) die is gekoppeld aan de GPU-leverancier.

Met de volgende opdracht voert u nvidia-smi uit vanuit uw deployment-pod voor de GPU-deviceplugin, om te verifiëren of de driver is geïnstalleerd en de runtime gereed is op een voor NVIDIA GPU's ingeschakelde nodepool:

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

De uitvoer moet lijken op het volgende voorbeeld:

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

Herhaal de kubectl exec opdracht voor elke GPU-knooppuntgroep om te bevestigen dat de versie van het stuurprogramma op uw knooppunten is geïnstalleerd.

Op uw nodegroepen met AMD GPU-ondersteuning kunt u als alternatief de AMD GPU-componenten implementeren en de opdracht amd-smi uitvoeren in de pod van de ROCm device plugin om te controleren welke stuurprogrammaversie is geïnstalleerd.

Knooppunten met GPU bijgewerkt houden naar de meest recente installatiekopieën van het knooppuntbesturingssysteem

Om de prestaties, beveiliging en compatibiliteit van uw GPU-workloads op AKS te garanderen, is het essentieel om uw GPU-knooppuntgroepen up-to-date te houden met de meest recente aanbevolen installatiekopieën van knooppuntbesturingssystemen. Deze updates zijn essentieel omdat ze:

• Neem de nieuwste GPU-stuurprogramma's op productieniveau op, waarbij alle afgeschafte of end-of-life-versies (EOL) worden vervangen.
• Zijn volledig getest op compatibiliteit met uw huidige Kubernetes-versie.
• Los bekende beveiligingsproblemen op die zijn geïdentificeerd door GPU-leveranciers.
• Neem de nieuwste verbeteringen in het besturingssysteem en de containerruntime op voor verbeterde stabiliteit en efficiëntie.

Werk uw GPU-knooppuntgroepen bij naar de meest recente aanbevolen installatiekopieën van het knooppuntbesturingssysteem die door AKS zijn uitgebracht, door het autoupgrade-kanaal of via handmatige upgrade in te stellen. U kunt de meest recente releases van knooppuntimages monitoren en volgen via de AKS-release-tracker.

Voor de meeste productiescenario's begint u met AKS Automatic als standaardbasislijn. Als u AKS Standard gebruikt, configureert u expliciet upgradekanalen en onderhoudsvensters.

Scheid GPU-workloads wanneer u gedeelde clusters gebruikt

Als in één AKS-cluster met GPU-knooppuntgroepen meerdere typen GPU-workloads worden uitgevoerd, zoals modeltraining, realtime deductie of batchverwerking, is het belangrijk om deze workloads te scheiden van:

• Vermijd onbedoelde verstoring of conflicten om resources tussen verschillende typen workloads.
• Verbeter de beveiliging en behoud de nalevingsgrenzen.
• Vereenvoudig het beheer en de bewaking van GPU-resourcegebruik per workloadcategorie.

U kunt GPU-workloads binnen één AKS-cluster isoleren met behulp van naamruimten en netwerkbeleid. Dit maakt duidelijker beheer mogelijk via workloadspecifieke quota, limieten en logboekregistratieconfiguraties.

Voorbeeldscenario

Overweeg een AKS-cluster dat als host fungeert voor twee verschillende GPU-workloadtypen die niet met elkaar hoeven te communiceren:

• Trainingsworkloads: Trainingstaken voor resource-intensieve AI-modellen.
• Inferentie-workloads: Latentiegevoelige real-time inferentieservices.

U kunt de volgende stappen gebruiken om de twee werkbelastingen te scheiden:

1. Maak toegewezen naamruimten per workloadtype met behulp van de kubectl create namespace opdracht.

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

2. Label GPU-workloadpods per type, zoals wordt weergegeven in het volgende voorbeeld:

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

3. Pas netwerkbeleid toe om verkeer tussen workloadtypen te isoleren. Het volgende manifest blokkeert alle toegangs- en uitgaand verkeer voor de gpu-training naamruimte (tenzij expliciet toegestaan):

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

Dit beleid:

• Is van toepassing op alle pods in de gpu-training naamruimte.
• Weigert standaard al het binnenkomende en uitgaande verkeer, dat sterke isolatie ondersteunt.

Dit model verbetert de duidelijkheid, controle en veiligheid in gedeelde GPU-omgevingen, met name wanneer workloadtypen verschillende runtimeprofielen, risiconiveaus of operationele vereisten hebben.

Resourcegebruik op GPU-knooppunten optimaliseren met GPU (MIG) met meerdere exemplaren

Verschillende GPU-workloads hebben verschillende geheugenvereisten. Kleinere implementaties, zoals NVIDIA A100 40 GB, hebben mogelijk geen volledige GPU nodig. Eén enkele workload monopoliseert standaard de GPU-resources, zelfs wanneer die onderbenut worden.

AKS ondersteunt resourceoptimalisatie op GPU-knooppunten door ze op te splitsen in kleinere segmenten met behulp van GPU (MIG) voor meerdere exemplaren, zodat teams efficiënter kleinere taken kunnen plannen. Meer informatie over de ondersteunde GPU-grootten en hoe u aan de slag kunt met GPU's met meerdere exemplaren op AKS.

Tijdelijke NVMe-gegevensschijven gebruiken als cache met hoge prestaties

Voor AI-workloads die worden uitgevoerd op GPU-VM's in AKS, is snelle en betrouwbare toegang tot tijdelijke opslag essentieel voor het maximaliseren van training en deductieprestaties. Tijdelijke NVMe-gegevensschijven bieden opslag met hoge doorvoer, lage latentie die rechtstreeks is gekoppeld aan de VM-host, waardoor ze ideaal zijn voor scenario's zoals het opslaan van gegevenssets in de cache, het opslaan van tussenliggende controlepunten en modelgewichten, of het bieden van scratchruimte voor gegevensvoorverwerking en analyse.

Bij het implementeren van GPU-ondersteunde knooppuntgroepen voor AI-workloads configureert u tijdelijke NVMe-gegevensdisks om te fungeren als cache met hoge prestaties of tijdelijke ruimte. Deze aanpak helpt bij het elimineren van I/O-knelpunten, versnelt gegevensintensieve bewerkingen en zorgt ervoor dat uw GPU-resources niet inactief zijn tijdens het wachten op gegevens.

Azure ondersteunt kortstondige NVMe-gegevensschijven voor een breed scala aan Azure GPU-VM-families. Afhankelijk van de GROOTTE van de GPU-VM heeft de VM maximaal acht kortstondige NVMe-gegevensschijven met een gecombineerde capaciteit van maximaal 28 TiB. Raadpleeg de documentatie van de ND H100 v5-serie of de VM-groottedocumentatie voor de gekozen GPU-serie voor gedetailleerde configuraties voor VM-grootten.

Gebruik Azure Container Storage, waarmee tijdelijke NVMe-schijven automatisch kunnen worden gedetecteerd en ingedeeld voor uw Kubernetes-workloads om het inrichten en beheren te vereenvoudigen.

Aanbevolen scenario's zijn:

• Grote gegevenssets en modelcontrolepunten opslaan in de cache voor AI-training en deductie.
• Gewichten van het cachemodel voor AI-inferentie. Bijvoorbeeld, KAITO-hostingmodel als OCI-artefacten op lokale NVMe.
• Snelle scratchruimte bieden voor batchtaken en gegevenspijplijnen.

Zie De aanbevolen procedures voor kortstondige NVMe-gegevensschijven in AKS voor meer informatie over tijdelijke NVMe-gegevensschijven.

Verwante inhoud

Zie de volgende artikelen voor meer informatie over AKS- en GPU-workloads:

• Inleiding tot Azure Kubernetes Service (AKS) Automatic
• Een automatisch AKS-cluster maken
• Maak een gpu-knooppuntgroep in uw AKS-cluster .
• Bewaak GPU-workloads met behulp van zelfbeheerde NVIDIA DCGM-exporteur.
• Uw GPU-workloads automatisch schalen op basis van algemene GPU-metrische gegevens met KEDA en DCGM-exporteur.