Kubernetes：从Beta前进，避免永久Beta

作者：Tim Bannister，The Scale Factory

在Kubernetes中，特性遵循一个已定义的生命周期。首先，作为一个感兴趣的开发人员的一瞬。也许，在网上的讨论中，在相当于咖啡餐巾的网上画上草图。这种粗糙的工作通常会变成KEP（Kubernetes增强建议，Kubernetes Enhancement Proposal），然后通常会转换成代码。

对于Kubernetes v1.20及以后版本，我们的重点是帮助这些代码过渡到稳定的特性。

我提到的生命周期运行如下：

Alpha→Beta→GA

通常，alpha特性在默认情况下是不启用的。你通过设置功能门（feature gate）来打开它们；通常，通过在使用该特性的每个组件上设置一个命令行标志。

（如果你通过托管服务 - 如AKS、EKS、GKE等 - 使用Kubernetes，那么运行该服务的供应商可能已经决定为你启用哪些特性了）。

将一个现有的、alpha的特性转化为beta阶段是一个明确的过程。这一点很重要，因为测试版（beta）特性是默认启用的，特性标志仍然存在，所以集群操作人员可以选择不启用。

一套类似但更彻底的分级标准控制着向GA（general availability）的过渡，也被称为“稳定（stable）”。GA特性是Kubernetes的一部分，并承诺在当前主要版本中保留它们。

默认测试版功能可以让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）有一个新的方法。

避免永久测试版

对于Kubernetes REST API来说，当一个新特性的API达到beta时，就开始倒计时了。测试版API现在有九个月的时间：

• 达到GA，并弃用beta，或
• 拥有一个新的测试版（并弃用之前的测试版）。

需要明确的是，此时只有REST API会受到影响。例如，APIListChunking是一个beta特性，但它本身不是REST API。目前还没有计划自动弃用APIListChunking，或任何其他非REST API的特性。

如果REST API达到了9个月的倒计时，那么下一个Kubernetes版本将会弃用该API版本。在Kubernetes 9个月后发布的第一个测试版之后，REST API不能选择继续保持测试版。

这对你意味着什么

如果你正在使用Kubernetes，那么你很有可能正在使用beta特性。就像我说的，有很多。和Ingress一样，你可能正在使用CronJob，或PodSecurityPolicy，或其他。更大的可能性是，你运行在一个至少启用了一个测试版特性的控制平面上。

如果你正在使用或生成使用像Ingress这样的beta API的Kubernetes清单，则需要计划修改它们。当前的API将按照计划（我前面提到的9个月）被弃用，9个月后那些弃用的API将被删除。此时，为了与Kubernetes保持同步，你应该已经进行了迁移。

这对Kubernetes的贡献者意味着什么

这里的动机似乎很清楚：让特性稳定。保证beta特性将会被废弃，这是一个很大的激励，因此想要该特性的人们会继续努力，直到该特性的代码、文档和测试已经准备好达到稳定，并得到Kubernetes在实际使用中发布的证据的支持。

这对生态系统意味着什么

在我看来，这些看似严厉的措施是很有意义的，而且对Kubernetes也有好处。通过一种适用于所有不同特殊兴趣组（SIG）的规则来弃用现有API，有助于避免停滞并鼓励修复。

假设一个API达到了beta，然后实际经验表明它是不正确的——从根本上说，这个API有缺陷。随着9个月的倒计时，相关人员有了方法和理由来修改和发布处理问题案例的API。欢迎任何希望使用这个已被弃用的API的人使用它 - Kubernetes是开源的 - 但是他们的需求不必阻碍这个特性的发展。

点击阅读网站原文。

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。