从 Beta 版本迈进
在 Kubernetes 中，功能遵循一个定义的生命周期。首先，它可能只是一个感兴趣的开发者心中的灵光一现。然后，也许会在在线讨论中勾勒出来，就像在咖啡馆的餐巾纸上画草图一样。这种粗略的工作通常会演变成一个Kubernetes 增强提案 (KEP)，然后通常会转化为代码。
对于 Kubernetes v1.20 及更高版本，我们正致力于帮助这些代码成熟为稳定功能。
我提到的那个生命周期如下所示
通常，alpha 功能默认是不启用的。你需要通过设置 feature gate 来开启它们；通常是通过在使用该功能的每个组件上设置命令行标志。
（如果您通过托管服务使用 Kubernetes，例如 AKS、EKS、GKE 等，则运行该服务的供应商可能已经为您决定了哪些 feature gate 是启用的）。
有一个明确的流程用于将现有的 alpha 功能升级到 beta 阶段。这很重要，因为beta 功能默认是启用的，feature flag 仍然存在，以便集群操作员如果需要可以禁用。
类似但更全面的升级标准管理着向通用可用 (GA) 的过渡，GA 也称为“稳定”。GA 功能是 Kubernetes 的一部分，并承诺在当前主版本中保持不变。
默认启用 beta 功能可以让 Kubernetes 及其贡献者获得宝贵的实际反馈。然而，这存在激励不匹配的问题。一旦功能默认启用，人们就会开始使用它。即使可能还有一些细节需要完善，Kubernetes 的 REST API 和惯例的工作方式意味着任何未来的稳定 API 都将与最新的 beta API 兼容：当一个 beta 功能升级到 GA 时，您的 API 对象不会停止工作。
特别是对于 API 及其资源，将功能从 beta 推进到 GA 的动力远不如从 alpha 推进到 beta 强。想要某个特定功能的供应商有充分理由帮助代码达到默认启用功能的程度，但在此之后，这个旅程就变得不那么明朗了。
KEPs 跟踪的不仅仅是代码改进。从本质上讲，任何需要向更广泛社区传达的内容都值得成为一个 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 版本。在发布窗口期结束后的第一个 Kubernetes 发布周期之后，REST API 没有选项停留在同一个 beta 版本。
这对您意味着什么
如果您正在使用 Kubernetes，您很有可能正在使用某个 beta 功能。就像我说过的，有很多这样的功能。除了 Ingress，您可能还在使用 CronJob 或 PodSecurityPolicy 等功能。更大概率是，您的控制平面上至少启用了一个 beta 功能。
如果您正在使用或生成使用像 Ingress 这样的 beta API 的 Kubernetes manifest 文件，您将需要计划修改它们。当前的 API 将按照时间表（我之前提到的 9 个月）被弃用，再过 9 个月，这些被弃用的 API 将被移除。届时，为了与 Kubernetes 保持同步，您应该已经完成了迁移。
这对 Kubernetes 贡献者意味着什么
这里的动机似乎很明确：让功能变得稳定。保证 beta 功能将被弃用增加了一个很大的动力，这样想要该功能的人就会持续努力，直到代码、文档和测试都准备好，使该功能可以升级到稳定阶段，并有多个 Kubernetes 发布周期的实际使用证据支持。
这对生态系统意味着什么
在我看来，这些看起来严厉的措施非常有意义，并且对 Kubernetes 有益。通过一个适用于所有不同特别兴趣小组 (SIG) 的规则来弃用现有 API，有助于避免停滞并鼓励修复。
假设一个 API 进入了 beta 阶段，然后实际使用经验表明它并不合适——从根本上说，这个 API 存在缺陷。随着 9 个月的倒计时滴答作响，相关人员有了方法和理由来修订并发布一个能处理这些问题情况的 API。任何想要继续使用被弃用 API 的人都可以这样做——Kubernetes 是开源的——但他们的需求不应阻碍该功能的进展。