5fca3ce544d09933.jpg_e680.jpg

微服务部署方案对比

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)

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

Captcha Code