Orchestrer des GPU sur GKE : Kueue, DWS, CCC et Ray pour les charges d'IA

Chez Symbol Retail, l'équipe de data science reçoit le feu vert pour entraîner un modèle de recommandation qui boostera le rush de Noël. Plusieurs ingénieurs ML envoient des travaux de training et de fine-tuning en même temps, et l'infrastructure descend dans le chaos : GKE par défaut attribue les ressources en first-come-first-served, les premiers travaux consomment tous les GPU disponibles et laissent d'autres projets critiques sans ressources, et l'autoscaler aggrave la situation.

Ce scénario, qui apparaît dans toute entreprise avec plusieurs équipes partageant des GPU, est ce qui ouvre « AI Infrastructure: Orchestration and Automation », de Google Skills. Le parcours qui suit couvre la couche qui transforme ce chaos en une file ordonnée : les constructos Kubernetes pour l'IA, l'infrastructure as code, Kueue, le Dynamic Workload Scheduler, les Custom Compute Classes et Ray sur Kubernetes.

GKE et les constructos qu'il utilise pour l'IA

GKE est l'implémentation Kubernetes gérée de Google et le hub central d'orchestration pour les charges ML et deep learning, comme l'illustre le cas QuickScan, une entreprise d'imagerie médicale qui entraîne un modèle pour détecter des signes précoces de cancer sur des radiographies sans avoir besoin d'experts Kubernetes.

Les objets Kubernetes qui soutiennent ce travail ont des destinations différentes. Le Pod est la plus petite unité déployable (conteneur, stockage et IP réseau) et en inférence il contient le modèle entraîné. Les Deployments gèrent des ensembles de Pods identiques avec un nombre spécifié toujours actif : l'inférence se gère avec des Deployments et se scale avec des Horizontal Pod Autoscalers. Les Jobs couvrent l'exécution batch simple. Et les JobSets sont le standard recommandé pour l'entraînement distribué complexe. Pour l'inférence, GKE ajoute le GKE Inference Gateway, le load balancing conscient du modèle qui apparaît déjà dans un autre texte de cette série.

Infrastructure as code : trois voies

Créer des clusters à la main ne monte pas en charge, et les trois voies qu'ordonne le matériel ont des profils différents. Terraform gère et provisionne l'infrastructure via des fichiers de définition lisibles par machine en HCL, en utilisant les ressources du fournisseur Google Cloud pour créer des clusters GKE. Cluster Toolkit est open-source et blueprint-driven : il combine Terraform et Ansible pour déployer des environnements HPC et d'IA cohérents. Cluster Director est un service géré enterprise dans le stack AI Hypercomputer de Google qui automatise le déploiement d'environnements d'entraînement massifs et optimisés.

Kueue : la porte d'admission avant le scheduler

C'est ici que commence le cœur de l'orchestration. Kueue est un système cloud-native de job queuing et quota management pour Kubernetes, et sa position est ce qui le définit : il fonctionne comme admission gate, positionné avant le scheduler standard de Kubernetes.

Quand un travail haute performance ou batch est soumis, Kueue gère la file, la multi-tenancy et les quotas de ressources pour décider exactement quand admettre le travail ou le retenir en cas de pénurie. Ses composants structurels sont les ResourceFlavors, des profils qui catégorisent les variations de matériel (GPU A100, plus de RAM, stockage plus rapide) mappés à des serveurs réels avec labels, taints et tolerations ; les ClusterQueues ; les cohorts, qui permettent le fair sharing ; et les LocalQueues. Sa configuration vit en YAML et est observable avec kubectl.

Le cycle de vie, en huit étapes : soumission du job, suspension du job, notification à Kueue, génération du Workload, admission check de la LocalQueue, décision de placement des ressources et des nœuds, admission et création des Pods, et planification finale des Pods.

flowchart TD
    J[Travail soumis] --> K[Kueue : file, quotas et admission gate]
    K --> D[DWS : queued provisioning et placement]
    D --> A[Autoscaling avec ComputeClass de CCC]
    A --> S[Scheduler avec TAS sur la topologie]

La démonstration installe Kueue v0.10.0 sur un cluster GKE avec image streaming et un nœud, et crée deux node pools aux buts opposés : reserved, avec deux nœuds de calcul garantis, et ondemand, avec un autoscaler jusqu'à trois nœuds qui scale à zéro pour économiser. Ensuite elle installe Kueue avec kubectl apply --server-side contre le manifest du release, attend que les pods du control plane soient Running, et crée les ResourceFlavors qui reflètent les caractéristiques de chaque node pool.

DWS : la file au niveau cloud

Avec Kueue qui gère l'admission, le problème suivant est d'obtenir les accélérateurs. Le Dynamic Workload Scheduler (DWS) agit comme courtier entre Kueue et la capacité de Google Cloud.

Sans DWS, l'autoscaler demande aveuglément « huit H100 maintenant » et, si la zone n'a pas de stock, la requête échoue. DWS introduit le queued provisioning : la requête entre dans une file au niveau cloud, et le scheduler s'assure que tous les accélérateurs dont le travail a besoin sont provisionnés en même temps et physiquement placés près les uns des autres dans le data center, pour que la vitesse réseau entre nœuds ne dégrade pas l'entraînement.

Les deux modes couvrent des profils temporels différents. Flex start mode pour les travaux batch à temps flexible, avec coût optimisé. Calendar mode pour les sprints de pre-training critiques et prévisibles, avec fenêtres de réservation futures.

TAS : la topologie est aussi de la performance

Topology Aware Scheduling attaque un détail que le scheduler standard ignore : il ne comprend pas la disposition physique des nœuds et peut placer des pods qui communiquent à travers tout le data center. TAS, utilisé avec Kueue sur GKE, prend des décisions de placement sur la topologie réseau, en minimisant les sauts et la contention.

Les bénéfices déclarés : latence réduite entre pods, contention réseau minimisée, bande passante optimisée, convergence plus rapide du modèle, entraînements plus courts et usage plus efficace des accélérateurs. La recommandation de capacité est concrète : ça fonctionne mieux avec une capacité dense (node reservations), et peut fonctionner moins bien avec flex start ou Spot VMs, car cette capacité est moins susceptible d'être attribuée ensemble.

CCC : priorités de provisioning

Custom Compute Classes (CCC) traitent les patrons de demande steady et surge : comment provisionner la bonne ressource VM au moment exact. Un ComputeClass est un custom resource au niveau cluster avec une liste ordonnée de priorités que GKE évalue de haut en bas, cherchant à provisionner la première configuration de nœud qui satisfait la spec ; le workload le référence avec un nodeSelector dans son manifest.

La donnée qui évite les confusions : les ComputeClasses pilotent l'autoscaling, pas le kube-scheduler. Le scheduler se focalise sur la disponibilité des nœuds et ne favorise pas nécessairement un ComputeClass haute priorité si un nœud adapté existe déjà ailleurs.

Par défaut, GKE traite les règles dans l'ordre du YAML. Depuis GKE 1.35.2-gke.1842000+, le champ priorityScore donne un contrôle plus granulaire : des entiers entre 1 et 1000, avec la restriction que toutes les regs d'une classe doivent utiliser des scores ou aucune ; jusqu'à trois règles peuvent faire égalité et GKE les traite comme un groupe, en choisissant le meilleur ajustement avec la logique de l'autoscaler. Le compromis est la latence : regrouper les règles ou utiliser des propriétés larges comme machineFamily augmente le temps de simulation d'autoscaling, tandis que des propriétés spécifiques comme machineType montent en charge plus vite mais échouent plus quand le stock est faible.

Trois profils de stratégie documentés sortent de CCC. Obtainability : assurer la capacité de façon fiable. Cost optimization : priorise le prix le plus bas pour le batch, le dev/test ou les travaux tolérants aux interruptions, en cédant la stabilité de runtime et la disponibilité immédiate pour minimiser la dépense, et en favorisant la capacité décomptée et de réserve. Performance : pour les applications côté utilisateur, les bases de données critiques ou les charges intensives en CPU, GKE saute les options ephemeral, décomptées ou en file et ne vise que des machines premium non preemptibles, par exemple c3-highcpu-22 via réservations spécifiques ou on-demand, avec c2d-highcpu-28 comme fallback si nécessaire.

Ray et KubeRay : orchestration distribuée de Python

Le dernier tronçon ferme l'arc avec l'exécution distribuée. Ray est le framework de calcul au niveau application : là où les JobSets gèrent les cycles de vie des Pods et conteneurs, Ray fournit des bibliothèques et APIs Python unifiées (Ray Core, Ray Train et Ray Serve) pour distribuer le runtime de calcul, partager la mémoire et paralléliser l'exécution de Python sur plusieurs nœuds.

KubeRay est l'orchestrateur natif Kubernetes, et son opérateur est la façon recommandée de déployer et gérer des clusters Ray sur GKE. Ses trois custom resources : RayCluster, qui gère un head pod coordinateur et ses worker pods ; RayJob, qui déploie un RayCluster temporaire pour exécuter un script Python et fait le teardown automatique des ressources quand le travail réussit ; et RayService, avec des graphes de déploiement de modèles Ray Serve persistants et des upgrades sans downtime.

flowchart TD
    IR[Infrastructure : manifests Kubernetes] --> KR[KubeRay : RayCluster, RayJob, RayService]
    ML[Équipe ML : Python seulement] --> R[Ray Core, Ray Train, Ray Serve]
    R --> KR

La séparation des responsabilités est l'argument pratique : l'infrastructure gère les ressources avec des manifests Kubernetes, et l'équipe ML n'écrit que du Python. La démonstration déploie un cluster GKE avec l'add-on Ray operator et parcours trois cas : un simple Ray batch job, un modèle résumeur de texte servi avec Ray Serve avec accélération GPU, et des travaux Ray accélérés par Kueue.

Ce que l'arc laisse et ce qui est resté non exécuté

L'arc complet a une logique claire : le chaos du first-come-first-served se traite avec une couche d'admission (Kueue), une couche de capacité (DWS et ses files au niveau cloud), une couche de topologie (TAS), une couche de provisioning (CCC avec ses profils) et une couche d'exécution distribuée (Ray sur KubeRay), avec GKE comme plateforme unifiée et l'infrastructure as code qui standardise la création de clusters.

Ce qui est resté non exécuté dans cette documentation : le quiz n'a ni été ouvert ni soumis, la credential n'a pas été réclamée, plusieurs leçons du bundle ont été extraites comme squelette de gabarit sans corps (donc les tiers complets du mécanisme d'obtainability à cinq niveaux restent dehors), les manifests complets de ResourceFlavor, ClusterQueue et ComputeClass ne sont pas intacts dans le matériel extrait, et l'étape 8 du cycle de vie de Kueue apparaît tronquée dans le PDF. Les démos utilisent Cloud Shell et des commandes gcloud et kubectl décrites dans des transcriptions, pas dans des sessions propres.

---

*Source : « AI Infrastructure: Orchestration and Automation », de Google Skills (cours google.orchestration-automation).*