Résumé

  • L’état implementable signifie que les approbateurs des SIG concernés ont validé une KEP pour l’implémentation. Il ne constate ni fusion de code, ni présence dans une release, ni activation dans un cluster.
  • Le jalon, la revue Production Readiness, les tests, le cycle de feature gate et le support d’un opérateur constituent des surfaces de preuve distinctes.
  • Un reçu concis reliant ces surfaces empêcherait qu’une décision de conception soit présentée comme une garantie de disponibilité ou de support.

L’approbation d’un SIG est une décision réelle, mais circonscrite

La procédure des KEP n’est pas un simple registre d’idées. Kubernetes l’emploie pour rendre visibles les changements importants, leur motivation, leurs responsabilités, leurs critères de stabilité et leur progression sur plusieurs releases. Les approbateurs proviennent des SIG touchés; ce sont eux qui décident le passage d’une KEP à l’état implementable. La même procédure distingue ensuite implemented, mais aussi deferred, rejected, withdrawn et replaced. Processus KEP

Cette grammaire donne un sens précis au statut. Implementable dit qu’une proposition est approuvée pour être mise en œuvre. Il ne dit pas que sa mise en œuvre est achevée. Il ne désigne pas une version précise. Il n’indique pas quel composant d’un cluster est configuré, ni si une organisation en assume l’astreinte. Le périmètre de l’approbateur est celui du changement et du SIG, pas celui de chaque environnement où Kubernetes pourra être exécuté.

Cette réserve n’affaiblit pas la décision du SIG; elle empêche de lui attribuer une autorité qu’il ne revendique pas. Les concepteurs ont à juger la cohérence technique et les dépendances entre SIG. L’opérateur, lui, doit répondre de la capacité, des extensions, de la sécurité, de la compatibilité de versions, des engagements clients et du retour arrière. Faire passer l’un pour l’autre est une manière de déplacer le risque sans le nommer.

Une cible de release rassemble des preuves supplémentaires

Le modèle de KEP rend la séparation explicite. Pour que du code puisse entrer dans une release ciblée, il prévoit une issue d’amélioration liée à la KEP et au jalon avant l’Enhancement Freeze. Sa liste de signoff demande bien l’état implementable, mais aussi des détails de conception, un plan de test, des critères de graduation, une revue de préparation à la production approuvée, un historique d’implémentation, de la documentation utilisateur et des éléments d’appui. La liste est décrite comme itérative: elle doit être revue à chaque nouvelle considération pour un jalon. Modèle KEP

Un jalon n’est donc pas la conclusion d’une conception. C’est l’ouverture d’une autre question: quelles preuves existent maintenant pour cette release? Une KEP peut être saine et pourtant nécessiter un test, un historique ou une documentation actualisés pour le cycle visé. Inversement, une issue attachée à un jalon ne prouve pas que toutes les entrées de la liste sont closes. La transparence exige de garder ces deux états séparés.

La Production Readiness Review constitue une troisième surface. Kubernetes la confie à une équipe distincte des SIG leads, avec une attention à l’observabilité, la scalabilité, l’exploitabilité sûre, la désactivation et le rollback. La procédure publique indique que son approbation est requise pour qu’une amélioration fasse partie d’une release depuis Kubernetes 1.21. Production Readiness Review

Cette barrière est importante, mais elle ne devient pas une police d’assurance pour toutes les installations. Une PRR ne sait pas quelle distribution un tiers fournit, quelles politiques d’admission un client impose, ni si l’opérateur a validé la topologie, le coût ou le plan de reprise de son propre cluster.

Une feature gate décrit une configuration, pas une adoption

La documentation Kubernetes définit les feature gates comme des paires clé=valeur configurées au moyen de --feature-gates sur les composants concernés. Chaque composant ne reconnaît que les gates qui relèvent de sa fonction; la référence distingue également les stades Alpha, Beta, stable, les introductions et les retraits. Feature Gates

Cette description répond à « comment un administrateur peut-il configurer le mécanisme? ». Elle ne répond pas à « qui l’a configuré? », « dans quelles combinaisons? » ou « qui promet de le maintenir? ». Une gate peut être disponible dans une version publique tout en restant désactivée dans un cluster. Elle peut demander des réglages coordonnés sur plusieurs composants. Une distribution peut poser une condition supplémentaire. Un opérateur peut raisonnablement attendre des métriques, une validation de version skew ou une procédure de rollback avant de l’exposer à ses clients.

Les critères de graduation du modèle KEP suivent la même logique par étapes: Alpha comporte une feature flag et des tests initiaux; Beta demande l’achèvement fonctionnel, de sécurité, de monitoring et de tests; GA s’intéresse à l’usage réel, au retour d’expérience et aux écarts résolus. Modèle KEP Cette progression établit des attentes upstream. Elle ne décide pas à la place du responsable d’un cluster.

La release publique ne contient pas l’engagement commercial ou opérationnel

La page des releases Kubernetes publie des branches, des versions numérotées, des correctifs et des dates de fin de vie. Elle fournit donc une preuve plus solide qu’un statut de proposition: un artefact public et une fenêtre de support du projet. Releases Kubernetes Mais cette fenêtre est celle du projet. Elle ne déclare pas qu’une plate-forme donnée active une feature, qu’un fournisseur gère ses incidents ou qu’un opérateur la recommande à un client.

Le raccourci courant consiste à transformer KEP en release, release en configuration, puis configuration en support. À chaque saut, la personne qui pourrait confirmer le fait disparaît. Le dossier de suivi des améliorations est précieux pour observer les travaux et les jalons; il n’est pas une attestation d’adoption. Suivi des enhancements

Un reçu « proposition-vers-opération » rendrait les sauts vérifiables: identifiant et révision immuable de KEP; SIG propriétaire et SIG affectés; approbateurs et statut; jalon et freeze; demande et décision PRR; révisions de code et de tests; gate, composant et valeur par défaut; version et note de release; frontière de distribution; déclaration explicite d’activation et de support par l’opérateur; version skew et rollback. Il n’ajoute aucune autorité. Il oblige seulement chaque affirmation à conserver son auteur.

Cette retenue rejoint la distinction de Heng Lu entre participation, expertise et mandat, ainsi que son rappel que l’autorité opérationnelle doit rester lisible chez celui qui assume les conséquences. The Multi-Stakeholder Mirage Running-Code Primacy

Ce que le dossier ne permet pas d’affirmer

Les sources ne permettent pas d’établir le statut d’une KEP nommée, l’inclusion d’un changement dans une release, l’activation d’une gate, la compatibilité d’une distribution ni le support d’un opérateur. Elles n’évaluent aucun fournisseur, cluster, client ou incident. Le reçu proposé est une recommandation éditoriale de Daniel Kade, et non une obligation Kubernetes.

Sources