关于kubernetes:Kubernetes中API的不同版本-Alpha-Beta-Stable-都是什么

33次阅读

共计 1668 个字符，预计需要花费 5 分钟才能阅读完成。

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

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

新性能的开发经验了以下一系列的状态，一直倒退成熟：

对象版本：没有规定
可用性：不会提交到次要的 kubernetes 仓库，因而在官网的正式公布版本中并不可用
用户：其余在此性能和概念上有严密单干的开发者（比方 client 的开发者）
可降级性，可靠性，完整性，和反对：没有要求和保障

对象版本：蕴含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 的 API 版本命名(比方：v1beta1)
可用性：官网公布版本中存在，默认开启
用户：对于提供反馈感兴趣的用户
完整性：所有的 API 操作，CLI 命令以及 UI 反对都应该实现了；具备残缺的 e2e 测试；API 曾经过 API 审查并通过，尽管 beta 期间应用常常会冒出 API 审查没有思考到的问题
可降级性：
- 对象的构造和语义可能会在将来的版本中变更；变更产生时，降级路线将会被记录；
- 在一些状况下，对象会被主动的转化为新的版本；而在另一些状况下，可能须要人工降级；
- 人工降级可能要求依赖新性能的局部下线，并要求手动将对象转为新版本；
- 人工转化时，须要提供文档记录转化过程；
集群可靠性：因为该性能目前具备 e2e 测试，所以通过 flag 启用性能，并不会造成其余不想关性能的 bug；然而因为是一个新性能，所以可能会有一些次级 bug
反对：我的项目承诺会实现这个性能，个别在接下来的一个稳固版本中；个别会在 3 个月之内实现，有时可能会更久；公布的版本应该至多在一个次级公布周期中，同时反对两个练习的版本（比方 v1beta1和 v1bata2, 或 v1beta2 和v1），这样用户能够有足够的工夫来降级
倡议的应用场景：长期的测试环境；也能够短暂的部署在生产环境以获取用户反馈