Kubernetes 中 API 的不同版本， Alpha, Beta, Stable 都是什么？

在 Kubernetes 开发中，我们经常可以看到不同的版本如：alpha, beta, stable 。那么这些不同的版本有什么区别呢？

我在 https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions 这里找到了答案，以下是此部分翻译内容：

新功能的开发经历了以下一系列的状态，不断发展成熟：

Development Level 开发级别

• 对象版本：没有规定

• 可用性：不会提交到主要的 kubernetes 仓库，因此在官方的正式发布版本中并不可用

• 用户：其他在此功能和概念上有紧密合作的开发者（比如 client 的开发者）

• 可升级性，可靠性，完整性，和支持：没有要求和保证

Alpha Level

• 对象版本：包含alpha 的 API 版本命名（比如：v1alpha1）

• 可用性：提交到了主要 kubernetest 仓库； 出现在正式的发布版本中； 功能是默认出于非启用状态，但是可以通过 flag 启用

• 用户：开发者以及一些希望对早期功能给出反馈的专家用户

• 完整性：一部分 API 操作，CLI 命令，以及 UI 支持也许还未实现； API 还未经过 API 审查（即，在一般的代码审查的基础上，对 API 进行深入的，有针对性的审查）

• 可升级性：

• API 对象模式和语义可能在未来的版本中变更，无需在现有的集群中保留该对象；

• 移除可升级性的担忧可以方便开发者快速的进行开发；特别的，API 版本可以比 miner release（次要发布）更快节奏的增加，并且开发者不需要维护多个版本；

• 当 API 对象的模式和语义以不兼容的方式变更时，开发人员需要增加 API 版本

• 集群可靠性：由于功能相对较新，所以可能缺乏完全的 e2e 测试，通过 flag 的方式启用功能可能会暴露一些集群不稳定的 bug（比如，一个在控制循环（control loop）的中的 bug 可能造成迅速创建过多的对象，导致 API 存储资源耗尽）

• 支持：并不保证一定会完成改功能，该功能可能会在未来的版本中完全被弃用

• 建议的使用场景：因为其可升级性问题，以及缺乏长期支持的问题，该版本 API 只建议临时的测试集群使用

Beta Level

• 对象版本：包含 beta 的 API 版本命名(比如：v1beta1)

• 可用性：官方发布版本中存在，默认开启

• 用户：对于提供反馈感兴趣的用户

• 完整性：所有的 API 操作，CLI 命令以及 UI 支持都应该实现了；具有完整的 e2e 测试；API 已经过 API 审查并通过，虽然 beta 期间使用经常会冒出 API 审查没有考虑到的问题

• 可升级性：

• 对象的结构和语义可能会在未来的版本中变更；变更发生时，升级路线将会被记录；

• 在一些情况下，对象会被自动的转化为新的版本；而在另一些情况下，可能需要人工升级；

• 人工升级可能要求依赖新功能的部分下线，并要求手动将对象转为新版本；

• 人工转化时，需要提供文档记录转化过程；

• 集群可靠性：因为该功能目前具有 e2e 测试，所以通过 flag 启用功能，并不会造成其他不想关功能的 bug；但是由于是一个新功能，所以可能会有一些次级 bug

• 支持：项目承诺会完成这个功能，一般在接下来的一个稳定版本中；一般会在 3 个月之内完成，有时可能会更久；发布的版本应该至少在一个次级发布周期中，同时支持两个练习的版本（比如 v1beta1和v1bata2, 或 v1beta2和v1），这样用户可以有足够的时间来升级

• 建议的使用场景：临时的测试环境；也可以短暂的部署在生产环境以获取用户反馈

Stable Level

• 对象版本：格式为 vX, 其中X是整数（比如：v1） 的 API 版本命名

• 可用性：官方发布版本中存在，默认开启

• 用户：所有用

• 完整性：必须在释放的一致性配置文件中，进行 SIG 架构批准的一致性测试（比如：不可移植或 可选功能，可能不再默认的配置中）

• 可升级性：只有具有严格兼容性的变更才允许在接下来的发布版本中加入

• 集群可靠性：高

• 支持：该 API 版本竟在接下来的很多发布版本中存在

• 建议的使用场景：任何场景