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