Lorsqu’un ingénieur de données soumet une tâche Spark sur un cluster OpenShift équipé de Kueue, celle-ci ne s’exécute pas immédiatement ; elle est d’abord mise en attente. Cette mécanique de « gardien » est cruciale, car elle déplace la problématique du « quel pod rentre où » (le rôle du planificateur Kubernetes) vers le « quelle application mérite la ressource maintenant », selon les systèmes de gestion de quotas de Kueue.

L’intégration de Kueue avec l’opérateur Spark permet d’appliquer des règles strictes de partage des ressources, assurant que le cluster ne soit pas monopolisé par une seule équipe ou un seul projet. Selon github.com, le système intercepte la création de chaque SparkApplication via un webhook mutateur, la suspendant en attendant la validation des quotas.

Ce mécanisme repose sur une hiérarchie de ressources en trois niveaux : ResourceFlavor (qui définit le type de ressource, comme les nœuds GPU), ClusterQueue (qui constitue le pool de quotas et définit les limites CPU/mémoire) et LocalQueue (qui sert de point d’entrée au niveau du namespace pour les utilisateurs).

Pour l’utilisateur final, le changement est étonnamment minime. Il suffit d’ajouter une étiquette spécifique, kueue.x-k8s.io/queue-name, à sa SparkApplication, référençant la LocalQueue définie par l’administrateur. Sans cette étiquette, la tâche contourne Kueue et est soumise directement par l’opérateur Spark.

Le cycle de vie est bien balisé. Une fois soumise, la tâche passe de l’état « Submitted » à « Suspended ». Kueue évalue ensuite si le quota est disponible. Si oui, il met à jour l’application en désactivant la suspension, permettant à l’opérateur Spark de la faire passer à l’état « Resuming » avant qu’elle n’atteigne « Running ». Si le quota est plein, la tâche attend en file d’attente.

Les administrateurs ont le contrôle fin sur cette attente. Ils peuvent configurer des stratégies de préemption, comme LessThanOrEqualToFinalShare, qui permettent de réclamer des ressources à des travaux de moindre priorité si un travail plus important arrive. Ceci est géré par des ressources spécifiques WorkloadPriorityClass, distinctes des PriorityClasses standard de Kubernetes.

La préemption n’est pas une pause gracieuse. Lorsqu’un travail est évincé par une tâche prioritaire, Kueue suspend l’application, l’opérateur Spark détruit tous les pods associés, et le travail repart de zéro lorsque la ressource est redevenue disponible. Toutes les données en mémoire sont perdues.

Pour ceux qui gèrent l’infrastructure, la mise en place des queues doit être explicite. Privilégier les ClusterQueue gérées en interne plutôt que les fonctionnalités auto-créées offre aux équipes de contrôle des limites plus claires et facilite les revues de code via GitOps. L’ensemble de ces mécanismes, bien que fonctionnel, est actuellement marqué comme « Alpha », ce qui signifie que les API et le comportement peuvent évoluer dans les futures versions de Kueue.

Sources

• spark-operator/examples/openshift/docs/kueue-spark-admin-guide.md at main · opendatahub-io/spark-operator, github.com
• spark-operator/examples/openshift/docs/kueue-spark-user-guide.md at main · opendatahub-io/spark-operator, github.com
• How Kueue schedules Spark jobs fairly on Red Hat OpenShift AI, Red Hat Developer, 4 novembre 2026