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版本竟在接下来的很多发布版本中存在
• 建议的使用场景：任何场景