基于kubernetes的应用部署策略有哪些?

基于k8s我们可以轻松实现以下多种应用部署策略:

重建部署

删除旧的服务,然后部署新的服务,版本A下线后版本B上线,中间服务会中断

优点:

便于设置
应用状态完整更新

缺点:

对用户影响很大,预期的宕机时间取决于下线时间和应用启动耗时

滚动部署

按照指定的更新频率缓慢更新到新版本,版本B缓慢更新并替代版本A,频率可以通过并行数、最大峰值、最大不可用数来定义

优点:

便于设置
版本在实例间缓慢发布
对于能够处理数据重平衡的有状态应用非常方便

缺点:

发布/回滚耗时
支持多个API很困难
无法控制流量

蓝绿部署

直接创建一套完整的新版本,版本B(绿)同等数量的被并排部署在版本A(蓝)旁边,当新版本满足上线条件的测试后,然后直接切全部流量到新版本,版本B并行与版本A发布,然后流量切换到版本B

优点:

实时发布、回滚
避免版本冲突问题,整个应用状态统一一次切换

缺点:

比较昂贵因为需要双倍的资源
在释放版本到生产环境之前,整个平台的主流程测试必须执行
处理有状态的应用很棘手

金丝雀部署

部署一个新版本并引流量到新版本,确认新版本没有问题的情况下,再将全部流量切到新版本,版本B向一部分用户发布,然后完全放开,通常流量是按比例分配的。例如90%的请求流向版本A,10%的流向版本B。这个技术大多数用于缺少足够测试,或者缺少可靠测试,或者对新版本的稳定性缺乏信心的情况下。

优点:

版本面向一部分用户发布
方便错误评估和性能监控
快速回滚

缺点:

发布缓慢

A/B部署布

将一部分用户的请求转发到新版本上,版本B只向特定条件的用户发布,用来评估新特性的受欢迎程度,通常用于根据统计来制定商业决策,而不是部署策略,可以在金丝雀部署方式上添加额外功能来实现

下面是可以用于在版本间分散流量的条件:
浏览器cookie
查询参数
地理位置
技术支持:浏览器版本、屏幕尺寸、操作系统等
语言

优点:

多个版本并行运行
完全控制流量分布

缺点:

需要智能负载均衡
对于给定的会话,很难定位问题,分布式跟踪是必须的

影子部署

旧版本在接收真实生产请求的同时,复制出部分请求并发送到新部署的版本上,新版本只接受请求,不返回应答,对生产环境无影响,适用于压测,版本B接受真实的流量请求,但是不产生响应,将版本A进来的请求同时分发到版本B,同时对生产环境流量无影响

优点:

可以使用生产环境流量进行性能测试
对用户无影响
直到应用的稳定性和性能满足要求后才发布

缺点:

双倍资源,成本昂贵
不是真实用户测试,可能出现误导
配置复杂
某种情况下需要模拟服务

总结

部署应用有很多种方法,实际采用哪种方式取决于需求和预算。当发布到开发或者模拟环境时,重建或者滚动部署是一个好选择。当发布到生产环境时,滚动部署或者蓝绿部署通常是一个好选择,但是新平台的主流程测试是必须的。

蓝绿部署和影子部署对预算有更高的要求,因为需要双倍资源。如果应用缺乏测试或者对软件的功能和稳定性影响缺乏信心,那么可以使用金丝雀部署或者AB测试或者影子发布。如果业务需要根据地理位置、语言、操作系统或者浏览器特征等这样参数来给一些特定的用户测试,那么可以采用AB测试技术。

最后但并不是最不重要的,影子发布很复杂,且需要额外工作来模拟响应分支流量请求,当可变操作(邮件、银行等)调用外部依赖时这是必须的,这个技术在升级新数据库是非常有用,使用影子流量来监控负载下的系统性能。

X

发表评论

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