Kubernetes lance un groupe sur la conformité des workloads

Le projet Kubernetes a annoncé le 27 octobre 2026 la création d'un groupe de travail consacré à la conformité des workloads, le WG Workload Conformance. Jusqu'ici, les programmes de conformité de l'écosystème testaient les clusters. Ce nouveau groupe veut définir un standard ouvert et vérifiable décrivant comment les applications elles-mêmes doivent se comporter lorsqu'elles tournent sur Kubernetes.

Combler un angle mort

Le constat de départ est posé dans l'annonce publiée sur le blog du projet : le programme Certified Kubernetes vérifie le cluster, et Kubernetes AI Conformance vérifie qu'un cluster sait faire tourner des charges d'IA et de machine learning. Mais « rien de comparable n'existe pour les workloads eux-mêmes ». Résultat, les opérateurs de clusters continuent de contrôler chaque application à la main avant une opération de maintenance ou une montée de version de Kubernetes.

Le groupe s'est fixé trois livrables : une spécification du comportement des workloads pour chaque version mineure de Kubernetes, une méthode pour tester chaque exigence sur un workload en fonctionnement, et un outillage de conformité maintenu en amont, au sein du projet.

Un périmètre large, des tests objectifs

Les domaines visés couvrent la sécurité, la résilience lors des perturbations, la consommation de ressources, le réseau, le stockage, l'usage de l'API et l'observabilité. Les exigences précises ne sont pas encore arrêtées, mais une règle est déjà fixée : chaque exigence devra s'accompagner d'un test objectif exécutable par un binaire. Rien de subjectif n'entrera dans la spécification.

La charte précise aussi ce qui reste hors champ. La logique applicative du workload n'est pas évaluée : la spécification porte sur la façon dont une application s'exécute, pas sur ce qu'elle fait. L'outil ne retestera pas ce que couvre déjà Certified Kubernetes et n'imposera ni format de packaging, ni moteur de politiques, ni scanner de sécurité d'un éditeur. Le groupe ne gère pas non plus de programme de certification : ce rôle reviendrait à la CNCF, et seulement après validation du standard par SIG Architecture.

Organisation et calendrier

Le groupe est parrainé par deux Special Interest Groups. SIG Architecture hébergera la spécification et l'outillage dans un sous-projet, créé lorsque les premiers éléments seront proposés. SIG Apps apporte le point de vue des applications. D'autres SIG, comme Node, Auth, Security, Network ou Storage, seront consultés selon les sujets. Les organisateurs sont Nabarun Pal (Broadcom) et Maciej Szulik (Defense Unicorns).

L'objectif affiché est d'obtenir une première spécification stable et des tests fonctionnels d'ici deux à trois cycles de publication de Kubernetes. Au rythme habituel de trois versions mineures par an, cela représente un horizon de huit mois à un an, quelques versions après la version 1.37.

Comment participer

Le groupe se réunit un mercredi sur deux à 15 h UTC, sur Zoom, et échange sur le canal #wg-workload-conformance du Slack Kubernetes ainsi que sur une liste de diffusion dédiée. Il cherche des relecteurs pour les exigences proposées, des contributeurs pour écrire les tests et l'outillage, et, plus tard, des testeurs prêts à lancer le binaire sur leurs propres workloads pour signaler les résultats qui varient d'un environnement à l'autre.

Pour les équipes plateforme, l'enjeu est concret : disposer à terme d'un moyen standard de vérifier qu'une application est prête pour une mise à jour de cluster, plutôt que de s'appuyer sur des listes de contrôle maison. Les équipes qui préparent la fin de vie de Kubernetes 1.34 en savent quelque chose.