Kueue sépare l’admission du scheduling et rend le Job en attente enfin lisible
Le 14 octobre 2026, les mainteneurs de Kueue publient un guide Headlamp-first pour tracer l’admission d’un Job Kubernetes, désormais lisible dans l’UI via un plugin alpha. Avant de chercher pourquoi vos Pods sont en attente, la première question devient : Kueue a-t-il admis le Workload ?
14 octobre 2026. Utkarsh Raj (mentoré LFX, CNCF), René Dudfield (Microsoft) et Kevin Hannon (Red Hat) publient sur le blog officiel de Kubernetes un guide pour tracer l’admission d’un Job avec le plugin Kueue de Headlamp. 0.1.0-alpha. C’est la version du plugin, en lecture seule, qui apporte la réponse dans l’interface au lieu de la reconstruire à coups de kubectl. Pourquoi c’est important : sur un cluster géré par Kueue, un Job qui reste en attente n’est pas un problème de scheduler — c’est d’abord une question d’admission, et la plupart des équipes regardent au mauvais endroit. Le guide publié cette semaine corrige précisément ce réflexe.
Kueue ajoute une couche d’admission au-dessus du scheduler
La confusion vient d’un découpage que Kueue rend explicite. Kueue et le kube-scheduler répondent à deux questions différentes. L’admission Kueue demande : ce Workload doit-il démarrer maintenant, compte tenu de la politique de file, des quotas, des ResourceFlavors, des admission checks et des autres Workloads en attente ? Le scheduling des Pods demande, lui : une fois le Workload admis et le Job relancé, quels nœuds peuvent héberger ses Pods ?
Cette frontière change toute l’investigation. Si le Workload n’est pas admis, il faut rester dans la section Kueue de Headlamp. S’il est admis mais que ses Pods sont toujours en attente, on bascule vers les vues Job et Pod classiques pour inspecter les événements du scheduler. L’article résume la bonne question : non pas « pourquoi le Pod est-il en attente ? », mais d’abord « Kueue a-t-il admis le Workload ? ».
Kueue matérialise cette étape dans un objet Workload, qui représente la demande de ressources et l’état d’admission d’un Job. Sans lui, un Job suspendu n’a ni logs applicatifs, ni parfois même de Pod à inspecter — d’où l’impression d’un trou noir.
Le chemin Headlamp-first en cinq étapes
Le guide recommande de commencer par le Workload, pas par un shell. Le plugin affiche en lecture seule les ressources v1beta2 : Cohorts, ClusterQueues, LocalQueues, ResourceFlavors et Workloads.
Première étape, la liste des Workloads : la vue donne déjà une première lecture utile — priorité de la LocalQueue, état actif, état admis, état terminé, et un statut lisible comme Admitted, Finished ou Inadmissible. Deuxième étape, les conditions : les deux qui comptent pour l’admission sont QuotaReserved et Admitted. Un Admitted=True signifie que Kueue a admis le Workload — le Job peut reprendre, et tout Pod encore en attente relève du scheduling. Un QuotaReserved=False avec la raison Pending signifie que le quota n’a pas été réservé, et le message de condition explique pourquoi.
Troisième étape, comparer la demande du Workload à son affectation. Le piège classique : un Job avec parallelism: 3 et un CPU par Pod demande en réalité trois CPU au total à Kueue — regarder le gabarit d’un seul Pod sous-estime la demande. Quatrième étape, suivre la LocalQueue liée : c’est elle qui relie le Workload à une ClusterQueue au niveau du cluster, et elle répond à deux questions — le Job est-il entré dans la bonne file, et est-il le seul à y attendre ?
Cinquième étape, inspecter la capacité de la ClusterQueue. L’exemple de l’article est limpide : la ClusterQueue offre un quota nominal de deux CPU et deux emplacements de Pod, et le Workload en demande trois de chaque. Le message de condition et la page ClusterQueue racontent alors la même histoire : le Workload ne tient pas, donc Kueue laisse le Job suspendu. C’est un problème de capacité d’admission — pas une preuve que le kube-scheduler échoue.
Pourquoi le batch et l’IA rendent cette couche nécessaire
Kueue n’est pas un projet marginal : c’est un projet CNCF dédié à l’ordonnancement de travaux par lots, et il répond à un problème que le kube-scheduler n’a jamais été conçu pour traiter. Le scheduler place des Pods sur des nœuds ; il ne décide pas si un travail a le droit de démarrer, ni dans quel ordre les files doivent se vider quand la demande dépasse la capacité. C’est toute la différence entre « où » et « si », et elle devient critique dès qu’on mutualise un cluster entre équipes.
Le contexte IA rend le sujet brûlant. L’entraînement et le fine-tuning de modèles sont des charges batch par excellence : des centaines de GPU, des files d’attente longues, du fair-sharing entre équipes, des admission checks de conformité. Sans couche d’admission, un cluster partagé distribue les ressources au premier arrivé, et une seule équipe peut monopoliser la capacité pendant des heures. Kueue transforme cette négociation implicite en politique explicite — et, avec le plugin Headlamp, en un chemin observable.
Le plugin s’inscrit d’ailleurs dans un écosystème Headlamp déjà fourni : des plugins existent pour Kubeflow, Volcano, Knative ou encore Cluster API. Chacun applique la même recette — sortir l’état d’un contrôleur de ses YAML pour le rendre lisible dans l’interface. La liste des auteurs du guide est un dernier signal : un mentoré LFX de la CNCF, un ingénieur Microsoft et un ingénieur Red Hat. Kueue n’est pas le projet d’un seul éditeur, et cette diversité de gouvernance protège une couche devenue, de fait, aussi stratégique que le scheduler lui-même.
Ce que le plugin 0.1.0-alpha ne fait pas encore
La version alpha est volontairement bornée : lecture seule, pas d’actions de création, d’édition, d’arrêt ou de reprise. Les liens de owner references s’affichent en texte Kind/nom mais ne sont pas encore cliquables. Headlamp fournit toujours ses actions YAML et de ressources standard quand vos permissions le permettent, mais la promesse du plugin est ailleurs : rendre visible le chemin d’admission, pas remplacer kubectl.
La commande reste utile pour reproduire l’exemple ou automatiser un diagnostic. Le guide ne la présente d’ailleurs qu’en section optionnelle — signe que l’article assume pleinement sa posture UI d’abord.
# Lire l’état d’admission d’un Workload sans passer par l’UI
kubectl get workloads -n equipe-data
kubectl get workload train-octobre -n equipe-data \
-o jsonpath='{range .status.conditions[*]}{.type}={.status} ({.reason}) {.message}{"\n"}{end}'Pour les équipes qui ont déjà Kueue en production, l’apport est immédiat mais mesuré : le plugin ne remplace pas encore les réflexes kubectl du diagnostic avancé, et la v0.1.0-alpha reste une vitrine de ce que devient l’admission quand elle est visible. Le chemin recommandé par le guide vaut néanmoins pour tout le monde — commencer par le Workload, lire la condition Admitted, puis remonter la chaîne LocalQueue → ClusterQueue → ResourceFlavor. C’est un ordre d’investigation, et il s’apprend en cinq minutes, même sans l’interface.
Verdict
Le verdict dépend de votre usage du cluster. Si vous exploitez un cluster multi-équipes avec quotas, fair-sharing ou files d’attente batch, installez Kueue et son plugin Headlamp : le coût est faible — la version alpha est en lecture seule, donc sans risque d’action malencontreuse — et le gain est immédiat, car l’admission devient un chemin lisible plutôt qu’un état à reconstruire dans des YAML. Si vous êtes sur un cluster mono-équipe sans quotas ni files, Kueue ajoute une couche que vous n’avez pas besoin de gérer, et le guide reste une lecture utile pour comprendre où finira votre cluster quand il grossira. Dans tous les cas, retenez la bascule de réflexe : un Job en attente sous Kueue est d’abord une question d’admission, ensuite seulement une question de scheduler.