K8s 部署策略

服务全部停止，然后重新创建。也就是说服务是中断的。

逐步更新，起一个服务（启动成功，并且可以正常对外提供服务 - ready 状态 - 健康检测），然后停止一个，以此类推，所以称之为滚动更新。

思路是这样的，但实际上为了增快发布时间，还可以：

• 并行发布：设置每次启停的个数，比如 10 个实例，以 3 个为单位发布；
• 最大实例个数：除了当前的实例个数，最多还可以添加多少个实例（同时存在的）；
• 最大不可用：滚动更新过程中最多的不可用实例个数；

控制层面在实例，无法控制实际流量。

新服务全部起来之后，把流量切过去，然后再停止旧服务。

很显然，蓝绿发布比较费资源。

新版本先给一部分用户用，稳定之后再全部部署。一般用于平台测试功能稳定性。

跟滚动更新很类似，但是控制的更细腻一些，而且目的也不同：个人理解，滚动更新主要是为了旧服务到新服务迁移更加平滑，让用户无感知； 而金丝雀是为了测试产品功能。

但是细粒度的流量控制，成本可能比较高。

在特定情况下将一部分用户路由到新功能，这种控制一般在上层控制的，控制力度更加的小，平台层比较难做。 但是个人觉得对于产品是非常有用的功能，比如按照城市地区发布功能等。

成本比较高。

新版本和旧版本共存，并且不会互相影响。把生产版本的流量同时打到测试版本，对生产无影响，有点像我们说的预发。