从 Beta 走向未来
在 Kubernetes 中，功能遵循定义的生命周期。首先，它可能只是一个感兴趣的开发人员的一点点想法。然后，它可能在线上讨论中被勾勒出来，就像在咖啡馆餐巾纸上画草图一样。这种粗略的工作通常会成为一份Kubernetes 增强提案（KEP），然后通常会转化为代码。
对于 Kubernetes v1.20 及更高版本，我们正致力于帮助这些代码升级为稳定功能。
我提到的生命周期运行如下：
通常，alpha 功能默认不启用。您需要通过设置功能门来启用它们；通常，通过在每个使用该功能的组件上设置命令行标志。
（如果您通过 AKS、EKS、GKE 等托管服务产品使用 Kubernetes，那么运行该服务的供应商可能已经为您决定了哪些功能门已启用）。
将现有 alpha 功能升级到 beta 阶段有一个明确的流程。这很重要，因为**beta 功能默认启用**，并且功能标志仍然存在，以便集群操作员可以根据需要选择退出。
一套类似但更彻底的升级标准管理着向通用可用性（GA）的过渡，也称为“稳定版”。GA 功能是 Kubernetes 的一部分，并承诺在当前主要版本中保持不变。
默认启用 beta 功能可以让 Kubernetes 及其贡献者获得宝贵的实际反馈。然而，存在激励机制不匹配的问题。一旦功能默认启用，人们就会使用它。即使可能存在一些细节需要解决，Kubernetes 的 REST API 和约定工作方式意味着任何未来的稳定 API 都将与最新的 beta API 兼容：当 beta 功能升级到 GA 时，您的 API 对象不会停止工作。
特别是对于 API 及其资源，将功能从 beta 迁移到 GA 的激励机制远不如从 alpha 迁移到 beta 那么强烈。希望某个特定功能的供应商有充分理由帮助将代码开发到默认启用功能的程度，而在此之后，其过程就不那么明确了。
KEP 不仅仅追踪代码改进。本质上，任何需要向更广泛社区传达的内容都值得一份 KEP。也就是说，大多数 KEP 都涵盖 Kubernetes 功能（以及实现这些功能的代码）。
您可能知道 Ingress 已经在 Kubernetes 中存在一段时间了，但您是否意识到它实际上是在 2015 年才进入 beta 阶段？为了推动事情向前发展，Kubernetes 架构特别兴趣小组（SIG）有了一个新的方法。
避免永久 Beta
对于 Kubernetes REST API，当新功能的 API 达到 beta 阶段时，计时器就开始了。这个 beta 质量的 API 现在有**三个版本**（大约九个日历月）来决定：
- 达到 GA 并弃用 beta 版本，或者
- 发布一个新的 beta 版本（并弃用之前的 beta 版本）。
需要明确的是，此时**只有 REST API 受影响**。例如，*APIListChunking* 是一个 beta 功能，但它本身不是一个 REST API。目前还没有计划自动弃用 *APIListChunking* 或任何其他非 REST API 的功能。
如果一个 Beta API 在三个 Kubernetes 版本之后仍未升级到 GA，那么下一个 Kubernetes 版本将弃用该 API 版本。REST API 没有选项可以在发布窗口后的第一个 Kubernetes 版本之后继续停留在相同的 Beta 版本。
这对你意味着什么
如果您正在使用 Kubernetes，那么您很有可能正在使用 Beta 功能。正如我所说，这样的功能有很多。除了 Ingress，您可能还在使用 CronJob，或者 PodSecurityPolicy，或者其他功能。更有可能的是，您正在运行的控制平面至少有一个 Beta 功能已启用。
如果您正在使用或生成使用 Beta API（如 Ingress）的 Kubernetes 清单，您需要计划修改这些清单。当前的 API 将按照计划（我前面提到的 9 个月）被弃用，再过 9 个月后，这些弃用的 API 将被移除。届时，为了与 Kubernetes 保持同步，您应该已经完成了迁移。
这对 Kubernetes 贡献者意味着什么
这里的动机似乎很明确：让功能稳定。保证 Beta 功能将被弃用，这提供了一个相当大的激励，让希望该功能的人们继续努力，直到代码、文档和测试都准备好让该功能升级到稳定版，并得到 Kubernetes 多个版本在实际使用中证据的支持。
这对生态系统意味着什么
在我看来，这些看似严厉的措施非常有意义，并且将对 Kubernetes 有益。通过一项适用于所有不同特别兴趣小组（SIG）的规则来弃用现有 API，有助于避免停滞并鼓励修复。
假设一个 API 进入 Beta 阶段，然后实际经验表明它并不正确——也就是说，从根本上讲，该 API 存在缺陷。在 9 个月的倒计时中，相关人员有能力和理由修改并发布一个能够解决这些问题的 API。任何想要继续使用已弃用 API 的人都可以这样做——Kubernetes 是开源的——但他们的需求不应该阻碍该功能的进展。