摘要

  • implementable 记录的是受影响 SIG 的 approver 对“可进入实施”的决定；它不是代码已合入、特定版本已包含或任何集群已启用的收据。
  • 里程碑、Production Readiness Review、测试、feature gate、编号发布和运营方支持分别归属不同的决定者，不能被一句“已获批”替代。
  • 一份从提案到运营的简短凭据可把这些交接保留下来，避免上游设计决定被写成下游服务承诺。

“可实施”回答的是谁可以开始做，而不是谁已经承担结果

Kubernetes 的 KEP 机制不是把想法贴上标签的地方。它把跨 SIG 的动机、设计、审阅、稳定性目标和长期追踪放进可回看的记录中。公开流程说明，approver 来自受影响的 SIG，并由他们决定 KEP 何时进入 implementable；同一流程还区分 provisional、implemented、deferred、rejected、withdrawn 和 replaced。 Kubernetes KEP 流程

因此，implementable 不是空洞的状态。它表明有权就该设计范围作判断的技术角色已经同意进入实施。但这个范围有边界：它没有说明某一提交已经合入，没有指明某一 release 已经接纳，也没有披露某个 administrator 在其 apiserver、kubelet 或其他组件上选择了什么值。更不会代替承担客户可用性和事故处置成本的 operator 作出支持决定。

把这个边界说清，并不是贬低 SIG 的工作。恰恰相反，它让 SIG 的判断不会被夸大为它从未作出的保证。设计 approver 面对的是架构、接口和跨 SIG 依赖；集群经营者面对的则是容量、扩展组件、版本偏差、监控、回滚和服务合同。同一句“获批”若把两类损失合并，真正承担后一类损失的人就从记录里消失了。

目标 release 有自己的反复核验

KEP 模板把第二条边界写得很直白。要让变更进入目标 release，关联 KEP 的 enhancement issue 必须在 Enhancement Freeze 前指向相应 milestone。模板列出的 release signoff 并不止 implementable：它还包括设计细节、测试计划、graduation criteria、已完成并获批的 Production Readiness Review、实施历史、面向用户的文档和支持材料。模板特别要求，每次为 milestone 考虑该 enhancement 时都重新审阅这份清单。 Kubernetes KEP 模板

这种反复不是手续堆叠。一份设计足以启动实现，不意味着它已经拥有该 release 所需的所有当前证据。测试可能需要补充，文档可能已过时，或上一周期的运营问题需要重新回答。反过来，一条 issue 出现在 milestone 上，也不表示 checklist 的每一项已关闭。把“目标”写成“已发布”，和把“可实施”写成“已合入”，是同一种证据越界。

Production Readiness Review 又增加了第三个责任面。Kubernetes 将其交给不同于 SIG lead 的团队，关注可观测性、可扩展性、可支持性、安全运行，以及必要时禁用或回滚的能力。公开流程称，自 Kubernetes 1.21 起，PRR 获批是 enhancement 成为 release 一部分的必要条件。 Production Readiness Review 流程

这是一条重要的 upstream 准入线，却不是对所有环境的担保。PRR 无法替某个机构判断其 CNI、CSI、admission policy、节点组合、成本模型或客户风险。它证明一个独立审查面完成了其职责；不能据此推导另一个机构已经同意承担运营后果。

feature gate 是组件配置，不是全网采用

官方 feature-gate 参考将 gate 定义为 Kubernetes 组件通过 --feature-gates 设置的 key=value 对；每个组件只支持与自身功能有关的 gate。页面还分别记录 Alpha、Beta、stable、引入版本和移除版本。 Kubernetes Feature Gates

这回答的是“怎样配置”，不是“谁已配置”。文档中存在一项 gate，不会显示它在某一集群是否为真；一个能力可能要求多个组件协同设置；发行版也可能附加限制。operator 可以基于版本偏差、存储语义、监控信号或撤销路径，合理地决定暂不启用。上游公开了旋钮，不等于替任何人旋转了它。

模板中的 graduation 例子同样分层：Alpha 有受 feature flag 保护的实现和初步 e2e 测试；Beta 要求功能、安全、监控和测试要求完成，并处理已知缺口；GA 看重真实使用、反馈时间和 Beta 反馈的解决。非可选功能走向 GA 还需要 conformance tests。 Kubernetes KEP 模板 这是项目生命周期的证据要求，并不是某一家运营商的启用授权。

编号发布也不会替运营方发言

Kubernetes 的发布页独立列出 release branch、x.y.z 版本、补丁和 EOL 时间。它是比提案状态更强的公开收据：读者可以定位项目发布的制品及其项目级支持窗口。 Kubernetes 发布记录 但项目级窗口不能说明某家托管平台打包了什么、某个集群是否兼容、或者某个服务是否承诺处理事故。

enhancements 仓库有助于观察 issue、KEP 和周期跟踪，却不是采用证明。 Kubernetes enhancements 跟踪 把 KEP 直接推演为 release、再把 release 推演为配置、最后把配置推演为支持，实质是每一步都抹去唯一能确认下一步的主体。

较好的报道方式是保存一张“提案到运营”凭据：KEP 标识和不可变修订；拥有和受影响的 SIG；approver 和状态；milestone 与 freeze；PRR 请求和结果；代码与测试修订；gate、组件及默认值；编号 release 和 release note；发行版边界；operator 对启用、支持、version skew 与 rollback 的明确声明。它不设立新权力，只让每一个判断保留其作者。

这也呼应 Lu Heng 的基本区分：参与和专长可以构成证据，却不会自动生成对缺席主体的授权；运行后果应由真正承担它的人清楚地认领。 The Multi-Stakeholder Mirage Running-Code Primacy

这份记录不能证明什么

这些资料不证明任何具名 KEP 的状态、任何改动已进入特定 release、任何 gate 已在特定集群开启，或任何发行版和 operator 已作出兼容性与支持承诺。它们也不评估厂商、客户、集群或事故。这里的凭据只是 Daniel Kade 的编辑建议，并非 Kubernetes 规则。

来源