共计 2142 个字符，预计需要花费 6 分钟才能阅读完成。
作者：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 微信公众号。