目的:平滑升级项目,做到用户无感知。
重要点:要有回滚
1.蓝绿发布 比如有bug升级
比如有bug升级,分为蓝绿组2组,交替升级。1组下线升级,完成后然后上线。然后2组下线,完成后上线。
优点:策略简单,自己可以在lb上线下线就可以了,切换速度非常快如果有问题。
缺点:剩下的1半服务器要能够支撑住服务,可能需要两倍以上的服务器资源。
2.灰度发布
第一次升级25%的机器,25%的用户使用新版本,75%的用户使用老版本。然后没有坏的反馈的话,就逐渐增加机器新版本覆盖范围。直到升级到100%的机器。
过程中也是lb调度,可能会调度到老机器和旧机器。
缺点:实现会比较复杂一点,实现有些技术含量,涉及到%比。需要在ci/cd这块有一定控制的开关(第三方平台可以拉一下,升级多少台机器,但是升级哪些机器要记录,涉及到回滚啥的)。
优点:1.即使有位问题,覆盖范围会比较小。如果时蓝绿发布,升级后的上线,有问题的话就是100%的风险。如果用灰度发布,就只是部分的人影响到。
2.
3.滚动发布(k8s默认升级策略)
4个web服务,第一次升级一个,再自动升级下一个。与灰度发布不同的是,他是一个持续的过程,不受控制。
滚动不动(服务没起来,挡着你滚了)就不会网下滚动。
优点:服务启动没问题,就会自动升级,不需要人工干预
区点: 部署周期长(4个web,第一次1个,第二次第2个,周期就很长,有默认规则来高)
发布策率复杂
不容易回滚。滚动更新不确定下一个升级哪个的,所以一回滚他不确定哪个升级,哪个没有升级。要用滚动更新要考虑到这个层面。
4.k8s中的滚动更新
deployment默认规则就是滚动更新。
流程和3一样。类似灰度发布的滚动更新。
利用replicaset的控制对象来实现的,滚动更新的时候会有两个replicaset来进行新旧替换。
滚动更新第一步会生成1个新的rs,新副本为1,然后开始将老的rs副本减掉1(打比方,具体和最大超过预期上限百分比设置,和不能用数量的百分比来的),然后重复,直到新的副本是你预期的副本数量

发表评论

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