作者：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微信公众号。