Kubernetes 渐进式发布
通常渐进式发布包括：蓝绿发布、金丝雀发布。这篇文章对此做了详细介绍：
常规方案
蓝绿发布
蓝绿部署中，一共有两套系统：一套是正在提供的服务系统，标记为”绿色”；另一套是准备发布的系统，标记为”蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。 开发新版本，要用新版本替换线上的旧版本，在线上的系统之后，搭建了一个使用新版本代码的全新系统，这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
k8s 默认不支持蓝绿发布，如果要在 k8s 中实现蓝绿发布， 需要部署 两个 deployment 分别作为 蓝方和绿方，然后更新应用程序的service以指向新的deployment部署的应用。
金丝雀发布
金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。 金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。 简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
在 k8s 中可使用滚动更新策略和 rollout 机制来实现 金丝雀发布, 实例如下：
将应用 myapp-v1 升级到 v2，之后立即 暂停。
1
2
[root@k8s-master1 blue-green]# kubectl set image deployment myapp-v1 myapp=hebye/myapp:v2 -n blue-green && kubectl rollout pause deployment myapp-v1 -n blue-green
deployment.apps/myapp-v1 image updated
观察一段时间，如果没问题则继续 resume 执行。
1
[root@k8s-master1 blue-green]# kubectl rollout resume deployment myapp-v1 -n blue-green
如果发现问题，则 把版本更新至先前版本，再 resume。
1
2
[root@k8s-master1 blue-green]# kubectl set image deployment myapp-v1 myapp=hebye/myapp:v1 -n blue-green
[root@k8s-master1 blue-green]# kubectl rollout resume deployment myapp-v1 -n blue-green
注意：在 Pause 状态不能调用 rollout undo 回滚，会报错。
1
[root@master1 ~]# kubectl rollout undo deployment myapp-v1 -n blue-green
第三方基于 k8s 的实现方案
这篇文章有对这三种方案进行对比：openkruise/rollouts Introduction
