Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för: ✔️ AKS Automatic ✔️ AKS Standard
Att köra GPU-arbetsbelastningar på AKS kräver korrekt konfiguration och kontinuerlig validering för att säkerställa att beräkningsresurserna är tillgängliga, säkra och optimalt använda. Den här artikeln beskriver metodtips för att hantera GPU-aktiverade noder, validera konfigurationer och minska avbrott i arbetsbelastningen.
För de flesta AKS-arbetsbelastningar i produktion är AKS Automatic den rekommenderade standardinställningen. AKS Automatic tillhandahåller en produktionsklar baslinje med förkonfigurerade åtgärder, säkerhetsskydd och SLA-stödd poddberedskap, vilket hjälper team att minska plattformskostnaderna dag-2.
Välj AKS Automatic eller AKS Standard för GPU-arbetsbelastningar
Använd följande vägledning som utgångspunkt:
| Scenario | Rekommenderad sökväg | Varför |
|---|---|---|
| De flesta GPU-arbetsbelastningar för produktion | AKS Automatisk | Produktionsklara standardinställningar, inbyggda skyddsfunktioner och minskad administrativ overhead för klusterdrift. |
| Snabbare väg från distribution till stabil produktion | AKS Automatisk | Förkonfigurerade klusteråtgärder och förutsägbart startbeteende via SLA för pod-beredskap. |
| Avancerad plattformsanpassning och explicit driftkontroll | AKS Standard | Större flexibilitet för livscykelhantering av anpassade nodpooler och plattformsanpassning. |
| Specialiserade krav på plattformsarkitektur som inte är standard | AKS Standard | Mer manuell kontroll över infrastrukturbeteende och konfiguration. |
Mer information finns i Introduktion till Azure Kubernetes Service (AKS) Automatisk.
Vad AKS Automatic tillhandahåller för GPU-produktionsarbetsbelastningar
AKS Automatic hjälper till att upprätta en stark baslinje för GPU-produktionsarbetsbelastningar genom att tillhandahålla:
- Produktionsklara standardvärden för klusterkonfiguration.
- Inbyggda beprövade metoder och skyddsmekanismer.
- SLA-backad poddberedskap för förutsägbart startbeteende.
- Hanterade klusteråtgärder som minskar manuella dag-2-uppgifter.
Dessa standardinställningar för plattformen ersätter inte bästa praxis på arbetsbelastningsnivå, till exempel placeringskontroller, valideringskontroller och isoleringspolicyer som beskrivs i den här artikeln.
GPU-arbetsbelastningar, till exempel AI-modellträning, slutsatsdragning i realtid, simuleringar och videobearbetning, beror ofta på:
- Korrigera GPU-drivrutinen och körningskompatibiliteten.
- Korrekt schemaläggning av GPU-resurser.
- Åtkomst till GPU-maskinvaruenheter i containrar.
Felkonfigurationer kan leda till höga kostnader, oväntade jobbfel eller GPU-underutnyttjande.
Framtvinga GPU-arbetsbelastningsplacering
Som standard placerar AKS-schemaläggaren poddar på alla tillgängliga noder med tillräckligt med CPU och minne. Utan arbetsbelastningsplaceringskontroller kan två problem uppstå:
- Schemaläggaren kan placera GPU-arbetsbelastningar på noder utan GPU:er, vilket gör att arbetsbelastningarna inte startar.
- Allmänna arbetsbelastningar kan uppta GPU-noder, vilket slösar bort kostsamma resurser.
Så här framtvingar du rätt placering:
Taint dina GPU-noder med hjälp av en nyckel som
[gpu-vendor].com/gpu: NoSchedule(till exempelnvidia.com/gpu: NoSchedule). Den här tainten blockerar icke-GPU-arbetsbelastningar från att schemaläggas på dessa noder.Lägg till en matchande tolerans i specifikationen för GPU-arbetsbelastningspodden så att den kan schemaläggas på de fördärvade GPU-noderna.
Definiera GPU-resursbegäranden och gränser i podden för att säkerställa att schemaläggaren reserverar GPU-kapacitet. Ett exempel:
resources: limits: [gpu-vendor].com/gpu: 1Använd valideringsprinciper eller antagningskontrollanter för att framtvinga att GPU-arbetsbelastningar innehåller nödvändiga toleranser och resursgränser.
Den här metoden garanterar att endast GPU-klara arbetsbelastningar hamnar på GPU-noder och har åtkomst till de specialiserade beräkningsresurser som krävs.
I AKS Automatic är plattformsskydd förkonfigurerade som standard. Du tillämpar fortfarande placeringskontroller på arbetsbelastningsnivå för att tillämpa strikt GPU-schemaläggningsbeteende.
Verifiera GPU-drivrutinsinstallation och körningsberedskap
Innan du distribuerar GPU-produktionsarbetsbelastningar kontrollerar du alltid att dina GPU-nodpooler är:
- Utrustad med kompatibla GPU-drivrutiner.
- Drifta en välfungerande Kubernetes Device Plugin DaemonSet.
- Exponera
[gpu-vendor].com/gpusom en schemaläggningsbar resurs.
Du kan bekräfta den aktuella drivrutinsversionen som körs på dina GPU-nodpooler med systemhanteringsgränssnittet (SMI) som är associerat med GPU-leverantören.
Följande kommando körs inifrån din GPU-enhets-plugin-distributionspodd nvidia-smi för att verifiera drivrutinsinstallation och körningsberedskap i en NVIDIA GPU-aktiverad nodpool:
kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi
Dina utdata bör likna följande exempelutdata:
+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx Driver Version: 570.xx.xx CUDA Version: 12.x|
...
...
kubectl exec Upprepa kommandot för varje GPU-nodpool för att bekräfta drivrutinsversionen som är installerad på noderna.
I dina AMD GPU-aktiverade nodpooler kan du alternativt distribuera AMD GPU-komponenterna och köra amd-smi kommandot i plugin-podden för ROCm-enheten för att bekräfta drivrutinsversionen som är installerad.
Håll GPU-aktiverade noder uppdaterade till den senaste nod-OS-avbildningen
För att säkerställa prestanda, säkerhet och kompatibilitet för dina GPU-arbetsbelastningar i AKS är det viktigt att hålla dina GPU-nodpooler uppdaterade med de senaste rekommenderade nodoperativsystemavbildningarna. Dessa uppdateringar är viktiga eftersom de:
- Inkludera de senaste GPU-drivrutinerna i produktionsklass och ersätt eventuella inaktuella versioner eller EOL-versioner (end-of-life).
- Testas fullständigt för kompatibilitet med din aktuella Kubernetes-version.
- Åtgärda kända sårbarheter som identifierats av GPU-leverantörer.
- Införliva de senaste förbättringarna av operativsystemet och containerkörningen för förbättrad stabilitet och effektivitet.
Uppgradera GPU-nodpoolerna till den senaste rekommenderade nodoperativsystemavbildningen som AKS har släppt, antingen genom att ställa in autoupgrade-kanalen eller genom en manuell uppgradering. Du kan övervaka och spåra de senaste nodbildversionerna med hjälp av AKS-versionsspåraren.
För de flesta produktionsscenarier börjar du med AKS Automatic som standardbaslinje. Om du använder AKS Standard konfigurerar du uttryckligen uppgraderingskanaler och underhållsfönster.
Separera GPU-arbetsbelastningar när du använder delade kluster
Om ett enda AKS-kluster med GPU-nodpooler kör flera typer av GPU-arbetsbelastningar, till exempel modellträning, slutsatsdragning i realtid eller batchbearbetning, är det viktigt att separera dessa arbetsbelastningar till:
- Undvik oavsiktlig interferens eller resurskonkurrering mellan olika arbetsbelastningstyper.
- Förbättra säkerheten och upprätthålla efterlevnadsgränser.
- Förenkla hanteringen och övervakningen av GPU-resursanvändning per arbetsbelastningskategori.
Du kan isolera GPU-arbetsbelastningar i ett enda AKS-kluster med hjälp av namnområden och nätverksprinciper. Detta möjliggör tydligare styrning via arbetsbelastningsspecifika kvoter, gränser och loggningskonfigurationer.
Exempelscenario
Överväg ett AKS-kluster som är värd för två olika GPU-arbetsbelastningstyper som inte behöver kommunicera med varandra:
- Träningsarbetslaster: Resursintensiva jobb för träning av AI-modeller.
- Slutsatsdragningsarbetsbelastningar: Svarstidskänsliga realtidsinferenstjänster.
Du kan använda följande steg för att separera de två arbetsbelastningarna:
Skapa dedikerade namnområden per arbetsbelastningstyp med kommandot
kubectl create namespace.kubectl create namespace gpu-training kubectl create namespace gpu-inferenceMärka GPU-arbetsbelastningspoddar efter typ, som du ser i följande exempel:
metadata: namespace: gpu-training labels: workload: trainingAnvänd nätverksprinciper för att isolera trafik mellan arbetsbelastningstyper. Följande manifest blockerar alla ingresser och utgående objekt för
gpu-trainingnamnområdet (såvida det inte uttryckligen tillåts):apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-cross-namespace namespace: gpu-training spec: podSelector: {} policyTypes: - Ingress - Egress ingress: [] egress: []
Den här principen:
- Gäller för alla poddar i
gpu-trainingnamnområdet. - Nekar all inkommande och utgående trafik som standard, vilket stöder stark isolering.
Den här modellen förbättrar tydligheten, kontrollen och säkerheten i delade GPU-miljöer, särskilt när arbetsbelastningstyper har olika körningsprofiler, risknivåer eller driftkrav.
Optimera resursanvändningen på GPU-noder med hjälp av GPU för flera instanser (MIG)
Olika GPU-arbetsbelastningar har olika minneskrav. Mindre distributioner, till exempel NVIDIA A100 40GB, kanske inte behöver en hel GPU. Men en enskild arbetsbelastning monopoliserar GPU-resursen som standard även när den är underutnyttad.
AKS stöder resursoptimering på GPU-noder genom att dela upp dem i mindre sektorer med hjälp av GPU för flera instanser (MIG), så att teamen kan schemalägga mindre jobb mer effektivt. Läs mer om GPU-storlekar som stöds och hur du kommer igång med GPU:er för flera instanser i AKS.
Använda tillfälliga NVMe-datadiskar som cache med höga prestanda
För AI-arbetsbelastningar som körs på virtuella GPU-datorer i AKS är snabb och tillförlitlig åtkomst till tillfällig lagring avgörande för att maximera tränings- och slutsatsdragningsprestanda. Tillfälliga NVMe-datadiskar ger lagring med högt dataflöde och låg latens som är direkt kopplad till den virtuella datorns värd, vilket gör dem idealiska för scenarier som cachelagring av datauppsättningar, lagring av mellanliggande kontrollpunkter och modellvikter eller tillhandahålla utrymme för förbearbetning och analys av data.
När du distribuerar GPU-aktiverade nodpooler för AI-arbetsbelastningar, konfigurerar du tillfälliga NVMe-datadiskar för att fungera som högpresterande cacheminne eller tillfälligt utrymme. Den här metoden hjälper till att eliminera I/O-flaskhalsar, påskyndar dataintensiva åtgärder och säkerställer att dina GPU-resurser inte går på tomgång i väntan på data.
Azure stöder tillfälliga NVMe-datadiskar i en mängd olika Azure virtuella GPU-familjer. Beroende på storleken på den virtuella GPU-datorn har den virtuella datorn upp till åtta tillfälliga NVMe-datadiskar med en kombinerad kapacitet på upp till 28 TiB. Detaljerade konfigurationer av VM-storlekar finns i dokumentationen i ND H100 v5-serien eller dokumentationen om VM-storlek för din valda GPU-familj.
För att förenkla etablering och hantering använder du Azure Container Storage, som automatiskt kan identifiera och orkestrera tillfälliga NVMe-diskar för dina Kubernetes-arbetsbelastningar.
Rekommenderade scenarier är:
- Cachelagring av stora datamängder och modellkontrollpunkter för AI-träning och införande.
- Cachelagring av modellvikter för AI-slutsatsdragning. Till exempel KAITO-hostingmodell som OCI-artefakter på lokal NVMe.
- Ger snabbt temporärt utrymme för batchjobb och datapipelines.
Viktigt!
Data på tillfälliga NVMe-diskar är tillfälliga och går förlorade om den virtuella datorn frigörs eller distribueras om. Använd endast dessa diskar för icke-kritiska, tillfälliga data och lagra viktig information om beständiga Azure Storage-lösningar.
Mer information om tillfälliga NVMe-datadiskar finns i Metodtips för tillfälliga NVMe-datadiskar i AKS.
Relaterat innehåll
Mer information om AKS- och GPU-arbetsbelastningar finns i följande artiklar:
- Introduktion till Azure Kubernetes Service (AKS) Automatisk
- Skapa ett AKS-automatiskt kluster
- Skapa en GPU-aktiverad nodpool i ditt AKS-kluster .
- Övervaka GPU-arbetsbelastningar med självhanterad NVIDIA DCGM-exportör.
- Skala dina GPU-arbetsbelastningar automatiskt baserat på vanliga GPU-mått med KEDA och DCGM-exportör.