Configurare le code Kueue per i carichi di lavoro Ray in AKS

In questo articolo viene configurato il controllo di ammissione Kueue per i carichi di lavoro Ray in Servizio Azure Kubernetes (AKS). Kueue regola gli invii dei RayJob: i processo vengono creati con suspend: true e un'etichetta di coda. Kueue li ammette quando la quota è disponibile impostando suspend: false, che attiva l'operatore KubeRay per creare il cluster Ray.

Vengono fornite due configurazioni di coda. Scegliere quello più adatto al caso d'uso:

Configurazione Cosa dimostra
Coda singola Una ClusterQueue con backpressure: un carico di lavoro viene eseguito, quello successivo attende
Code del team Due ClusterQueue in una coorte condivisa con quote per team, prestito e precedenza

Importante

Il software open source è citato nella documentazione e negli esempi di AKS. Il software che distribuisci è escluso dagli accordi sul livello di servizio di AKS, dalla garanzia limitata e dal supporto Azure. Quando si utilizza una tecnologia open source insieme ad AKS, consulta le opzioni di supporto offerte dalle rispettive community e dai responsabili dei progetti per definire un piano.

Microsoft si assume la responsabilità di creare i pacchetti open source che distribuiamo su AKS. Tale responsabilità comprende la piena responsabilità del processo di compilazione, scansione, firma, convalida e applicazione degli hotfix, oltre al controllo dei file binari nelle immagini container. Per altre informazioni, vedere Gestione delle vulnerabilità per il servizio Azure Kubernetes (AKS) e Copertura del supporto del servizio Azure Kubernetes (AKS).

Prerequisiti

Crea il namespace e l'account di servizio

Passa al modulo di configurazione della coda nel repository clonato:

cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/2-kueue-queues
kubectl apply -f manifests/00-namespace.yaml
kubectl apply -f <(terraform -chdir=../1-infrastructure/terraform output -raw ray_workload_sa_yaml)

Verificare che l'account del servizio abbia annotazioni di identità del carico di lavoro:

kubectl -n ray get serviceaccount ray-workload -o yaml

L'output deve includere azure.workload.identity/client-id e azure.workload.identity/tenant-id annotazioni che consentono ai pod Ray di accedere Archiviazione BLOB di Azure senza credenziali.

Creare ResourceFlavors

ResourceFlavors descrive i tipi di nodi disponibili nel cluster. Creare due versioni: default (qualsiasi nodo) e gpu (nodi dell'acceleratore NVIDIA):

kubectl apply -f manifests/10-resource-flavors.yaml

Verificare:

kubectl get resourceflavors

Output previsto:

NAME      AGE
default   1m
gpu       1m

La configurazione gpu si rivolge ai nodi con etichetta accelerator=nvidia, che AKS applica automaticamente ai pool di nodi GPU.

Opzione A: Configurare una singola coda

La configurazione a coda singola crea un clusterQueue con quote ridimensionate per un carico di lavoro alla volta. Quando la quota è completamente esaurita, la richiesta successiva rimane in stato Pending finché la prima non viene completata.

kubectl apply -f manifests/20-single-queue.yaml

Verificare la ClusterQueue e la LocalQueue:

kubectl get clusterqueue cluster-queue
kubectl -n ray get localqueue default

Output previsto:

NAME            COHORT   PENDING WORKLOADS
cluster-queue            0

NAME      CLUSTERQUEUE    PENDING WORKLOADS   ADMITTED WORKLOADS
default   cluster-queue   0                   0

Controllare le quote configurate:

kubectl get clusterqueue cluster-queue -o jsonpath='{.spec.resourceGroups}' | python3 -m json.tool

Le quote predefinite vengono ridimensionate per ammettere un carico di lavoro da questa soluzione alla volta: 96 CPU, 768 Gi di memoria, 8 GPU.

Opzione B: configura le code del team con funzionalità di prestito

La configurazione della coda di team suddivide il nodo GPU tra due team, ciascuno con la propria ClusterQueue, collegati tramite una coorte condivisa:

kubectl apply -f manifests/30-team-queues.yaml

Importante

Scegliere Opzione A o Opzione B, non entrambe. Per passare da una configurazione all'altra, eliminare prima di tutto la configurazione attiva:

kubectl delete -f manifests/20-single-queue.yaml

Verificare:

kubectl get clusterqueues
kubectl -n ray get localqueues

Output previsto:

NAME        COHORT          PENDING WORKLOADS
team-a-cq   shared-cohort   0
team-b-cq   shared-cohort   0

NAME     CLUSTERQUEUE    PENDING WORKLOADS   ADMITTED WORKLOADS
team-a   team-a-cq       0                   0
team-b   team-b-cq       0                   0

Nota

Per impostazione predefinita, gli esempi di workload sono impostati su QUEUE_NAME=default, che corrisponde all'opzione A. Se hai scelto l'opzione B, imposta export QUEUE_NAME=team-a o export QUEUE_NAME=team-bprima di eseguire source env.example in ogni directory del workload.

Ogni team ottiene 4 GPU garantite con un borrowingLimit valore pari a 4, quindi un team può usare fino a 8 GPU totali quando l'altro team è inattiva. Comportamenti principali:

Scenario Che succede
Il team A invia, il team B è inattivo Il team A ottiene tutte e 8 le GPU (4 proprietari + 4 prese in prestito)
Il team B invia mentre il team A usa 8 Kueue sottrae le GPU prese in prestito da Team A, Team B ottiene le 4 GPU garantite
Entrambi i team impegnati Ogni team usa 4 GPU garantite

Risoluzione dei problemi

Sintomo Cause Correzione
Il carico di lavoro rimane in sospeso Quota esaurita Attendere il completamento del carico di lavoro in esecuzione o aumentare nominalQuota nel ClusterQueue
LocalQueue not found Etichetta del nome della coda errata Verificare che l'etichetta kueue.x-k8s.io/queue-name corrisponda a un nome LocalQueue esistente
ResourceFlavor non corrisponde ai nodi Etichetta del nodo mancante Controllare che i nodi GPU abbiano l'etichetta accelerator=nvidia con kubectl get nodes --show-labels
Il controller Kueue non è in esecuzione Problema della release Helm Verificare con kubectl -n kueue-system logs deploy/kueue-controller-manager

Per tutti i dettagli del file manifest, consulta la directory 2-kueue-queues nel repository.

Pulire le risorse

Per rimuovere la configurazione della coda Kueue (mantenendo il cluster e gli operatori):

kubectl delete -f manifests/20-single-queue.yaml   # or 30-team-queues.yaml
kubectl delete -f manifests/10-resource-flavors.yaml
kubectl delete -f manifests/00-namespace.yaml

Nota

L'eliminazione dello ray spazio dei nomi rimuove tutti i carichi di lavoro, LocalQueues e ServiceAccount in tale spazio dei nomi. ClusterQueues e ResourceFlavors sono con ambito cluster e devono essere eliminati separatamente. Per smantellare l'intera infrastruttura, vedi Distribuire l'infrastruttura per Ray e Kueue in AKS.

Passaggi successivi

Eseguire gli esempi del carico di lavoro nelle code configurate. I passaggi da 1 a 2 e passaggi da 3 a 4 sono coppie indipendenti:

  1. Ottimizzare il modello meteo Aurora
  2. Servire il modello Aurora ottimizzato con Ray Serve (richiede il passaggio 1)
  3. Eseguire il training di un LLM con Ray
  4. Eseguire l'inferenza batch con Ray (richiede il passaggio 3)
  • Last updated on