Kubernetes发布策略
微服务部署方案对比
https://blog.sklinux.com/posts/devops/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E9%83%A8%E7%BD%B2%E6%96%B9%E6%A1%88%E5%AF%B9%E6%AF%94/
总结:
| 发布方式 | 区别 |
| ----------- | ----------- |
| 蓝绿部署 | 不停止老版本,额外搞一套新版本,等测试发现新版本OK后,删除老版本 |
| 滚动发布 | 按批次停止老版本实例,启动新版本实例 |
| 灰度发布&
金丝雀部署 | 不停止老版本,额外搞一套新版本,常常按照用户设置路由权重
例如90%的用户维持使用老版本,10%的用户尝鲜新版 |
- 不同版本应用共存,经常与A/B测试一起使用,用于测试选择多种方案。
Kubernetes发布策略
https://blog.sklinux.com/posts/k8s/%E5%8F%91%E5%B8%83%E7%AD%96%E7%95%A5/
1.重建更新(Recreate)—停止旧版本部署新版本
spec:
replicas: 3
strategy:
type: Recreate
应用状态全部更新。
更新deployment是先全部删除所有pod,然后重建以新的img为标签的deployment。
停机时间取决于应用程序的关闭和启动消耗的时间
2.滚动更新(rolling-update)—一个接一个地以滚动更新方式发布新版本
spec:
replicas: 3 #总共副本数为3
strategy:
type: RollingUpdate #滚动更新为默认更新策略
rollingUpdate:
maxSurge: 2 # 一次可以添加多少个Pod
maxUnavailable: 1 # 滚动更新期间,最多个不可用Pod数。
#maxUnavailable设置为0可以完全确保在滚动更新期间服务不受影响,还可以使用百分比的值来进行设置。
版本在实例之间缓慢替换 每次拉起成功后才能算是添加可用pod
.rollout/rollback 可能需要一定时间
一次性更新完所有老版本
无法控制流量
3.蓝绿更新—新版本与旧版本一起存在,然后切换流量
实时部署/回滚
避免版本问题,因为一次更改是整个应用的改变
可用根据副本数进行一定的比例进行流量控制
需要两倍的资源
在发布到生产之前,应该对整个应用进行适当的测试
多版本共存
流量控制具体实现:新deployment写其他名字,然后根据副本数量来进行切换
整体实现: 新deployment标签不同,直接改svc的标签选择器
4.灰度更新—将新版本面向一部分用户发布,然后继续全量发布
部分用户获取新版本
方便错误和性能监控
快速回滚
发布较慢
流量精准控制,但资源很浪费(99%A / 1%B = 99 Pod A,1 Pod B)