云效发布策略指南|滚动、分批、灰度怎么选()
文章图片
无论从开发运维还是产品运营的角度来看,任何一次上线都是有风险的。从最基本的应用停止导致流量丢失、服务不可用、服务QPS水位下降,到步骤的遗漏、流程的不规范、开发过程中引入的bug,以及新产品/新功能上线导致用户体验的变化,都会导致线上风险。在日常和用户交流过程中,我们也经常会被用户问到关于发布的问题,比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊常见应用发布方式的选择,以及每种发布模式适合什么样的场景。
平滑升级:滚动发布
分批发布通常指取出一例或多例应用实例,将其停止服务、升级到新版本;周而复始地重复这一过程,直到所有实例都升级到新版本。使用滚动发布,可以最大程度地避免因发布导致的流量丢失和服务不可用问题;这一模式也是Kubernetes应用部署使用的缺省模式。
针对部署规模较小、领域边界较清晰,同时面临业务快速发展变化的微服务应用,滚动发布流程简易且可靠性较高。不过由于通常情况下缺乏强干预手段,发布的可逆程度较差;一旦在发布过程中觉察到问题,往往需要进行全量回滚。
一般来说,滚动发布适用于符合如下条件的场景:
- 应用部署规模较小、启动和回滚的速度较快;
- 应用所关注的业务领域范围相对小、边界较清晰,且易于进行线上回归验证;
- 发布人员充分理解、掌握平台所提供的滚动发布策略;
- 新版本引入的变更,具有向下兼容性。
面向ECS的滚动发布
在云效中,我们可以使用主机部署任务进行滚动发布。如图所示,假设需要对以下由2台ECS构成的主机组进行滚动发布,每次滚动更新1台主机:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/70224bbf0bda44f4b87710e9b9ed6d24.jpg)
文章图片
在流水线中,配置主机部署任务:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/a6e079ac3909435ead0f2a34a1350a1d.jpg)
文章图片
设置“暂停方式”为“不暂停”、“分批数量”为2,即可实现滚动发布。
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/f81e667c50ec4dc987b9dcdc824ca41c.jpg)
文章图片
在进行ECS滚动发布时需要注意一点:通常情况下,滚动发布中的主机无法对外提供服务,这意味着集群整体服务水位(如可承接的QPS)会降低——例如在上面2台主机分2批发布的过程中,集群始终只有1台主机可以响应请求,整体QPS水位下降了50%。发布人员需要仔细评估“由于发布而导致服务主机不可用”对服务水位的影响,并选择合适的时间(如业务低峰期)进行发布。
原生支持:Kubernetes YAML滚动发布
YAML发布是我们在使用Kubernetes时最直接的应用部署方式。在持续交付流水线中,我们一般将这些用于描述Kubernetes资源的YAML文件通过Git进行统一版本管理,通过云效CI/CD平台监听代码库的变更事件,并通过流水线将这些YAML变更同步到集群当中。
例如下面的app.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: ${IMAGE}
ports:
- containerPort: 80
由于没有声明发布策略,Kubernetes会缺省指定RollingUpdate策略,也即滚动发布。
YAML文件中的占位符${IMAGE}是为云效流水线专门留出的替换变量,发布时会被替换成具体的镜像。
如下图所示,我们可以通过“Kubernetes发布”任务实现上述Deployment的滚动发布:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/d679a6dc0a5d4151b130c0fc475efd4b.jpg)
文章图片
具体的发布进度,可以参考发布单中的展示:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/107ec8a91d7c409cad218111e751c0fe.jpg)
文章图片
极简体验:Kubernetes镜像升级
在一些开发团队与运维团队分工较为明确的场景中,开发团队可能希望够尽可能少地理解Kubernetes相关概念,由专职的运维团队负责完成应用环境的部署和初始化;开发团队只负责完成代码开发,并通过流水线自动化完成应用镜像构建,并使用该镜像对集群中已有的应用进行升级。
如下图所示,在云效流水线中,我们监听应用代码库的变化,并构建出相应的Docker镜像;发布阶段只需要指定对集群中实例并关联前序任务产生的镜像,即可完成应用的升级发布。与YAML发布相同,缺省情况下,镜像升级也使用了滚动发布模式:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/f9929b0d9e0b4ce594868dd4b914955c.jpg)
文章图片
如上所述,该场景适用于:
- 开发和运维分离:运维团队充分理解Kubernetes的原生发布策略,开发团队只负责产出代码以及应用镜像,由运维团队负责集群中应用的实际运维管理
分批发布的基本模式与滚动发布相似,主要差异则在于允许人工控制新版本上线、老版本下线的过程。由于新版本的部署比例可控,发布人员可以预先制定批次部署计划,在少量部署的新版本上,基于生产环境流量进行小规模线上验证;若应用自身规模较大或逻辑较复杂,维持一段时间的小规模验证也能起到线上回归测试的作用。另一方面,人工控制部署批次使得发布整体具有较好的可逆性:一旦在小规模验证中发现问题,可以快速回滚已经发布的新版本。
分批发布通常适合:
- 应用在业务链路中较为关键,部署规模较大,业务逻辑较复杂;
- 进行线上验证时,难以圈定灰度流量,需要使用较少比例的新版本部署进行验证,以期控制风险影响面;
- 新版本引入的变更,具有向下兼容性。
在云效中,主机部署任务也可以被配置为分批发布模式,如下图所示:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/65624db4377c43b3b9c98ea24018b7ce.jpg)
文章图片
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/fa338fdd9a424751a4dd6af0b8a181e7.jpg)
文章图片
我们可以通过指定“第一批暂停”或“每批暂停”,实现分批控制:
- 若指定“每批暂停”,则每一批发布完成后,都需要人工确认后方可发布下一批。这种模式适合需要全程控制发布节奏的场景,通过逐步观察线上指标,逐步确认新版本的正确性;或是有明确的发布计划,如“先部署1批(占比10%)、夜间业务低峰期+次日9-11点业务高峰期观察无问题后,按30%、50%、80%、100%实例数递进部署,每批停顿不少于30分钟,期间观察线上指标,若出现问题则回滚”。
- 若指定“第一批暂停”,则只有第一批发布结束后,会等待发布人员确认;一经确认,此后的各批次将自动部署,与滚动发布类似。这种模式结合了滚动发布的简便性,以及分批发布的小规模验证、快速回滚能力,通常适用于“先进行一批小规模线上验证,验证通过后即可全量发布”的场景。
面向Kubernetes的分批发布
云效的分批发布中,我们以Service为最小发布单元,在发布开始阶段我们将基于新版镜像创建出应用的版本V2,并根据当前应用的副本总数以及分批数量,对新旧两个版本的应用实例分别进行缩容和扩容,来控制实际进入到新版应用的流量比例,从而可以实现小规模的发布验证,在对发布进行充分验证后,再逐步完全下线老版应用。
与ECS部署类似,批次之间支持暂停和手动恢复,用以对发布过程进行控制。
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/7786f301e75b45198fbc464c84b83ace.jpg)
文章图片
该模式适用于:采用Kubernetes原生的服务发现机制,并希望获得相比于原生Kubernetes发布更好过程控制性以及安全性的用户。
流量可控:灰度发布 较之滚动/分批发布,灰度发布加强了对线上验证影响范围的控制:通常需要以同样的实例数,部署新/老版本两套服务;再通过流量分发控制手段,将特定的线上流量导入新版本、其余流量仍然流入老版本;线上验证通过后,所有流量都将导入新版本实例,而老版本实例则可用作下一次发布的模板。
常见的流量分发控制手段如:
- 支持流量在新/老版本之间按比例分配;
- 支持匹配特定URL/cookie/header/业务字段(如用户ID)的流量,流入新版本。
灰度发布一般适用于:
- 能够定义流量分发规则(如header、cookie、用户ID等);
- 变更具有较高的技术风险,或对业务有较大改动,需要将受影响的流量控制在较为精确的范围内(如先让内部员工试用)进行线上验证;
- 产品运营团队希望使用线上的自然流量,对新/老设计进行比较。
Kubernetes外部流量:Ingress灰度发布
一种典型的对外接收流量的场景,是使用Ingress暴露服务。在云效流水线的Ingress灰度发布中,我们以Ingress作为发布单元,当触发部署后,将会根据当前Ingress以及其关联的Service/Deployment资源,基于新版镜像创建出V2版本的Service/Deployment,并通过Nginx Ingress的Annoation完成对流量规则声明,从而确保只有满足特定特征的流量才能进入到V2版本中。
例如在下图的流水线中,我们根据cookie匹配流量,进行灰度发布:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/7da790e8143047ddb62b0c3e4faf0085.jpg)
文章图片
当处于灰度状态时,流水线将会等待人工验证,以触发发布或者或者回滚操作。
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/88a51886cad0447ea442a7d11b560116.jpg)
文章图片
Kubernetes内部流量:Istio/ASM蓝绿发布
当采用微服务架构时,大部分的后端服务只在集群内部开放,微服务之间通过Kubernetes Service进行相互访问。在这种情况下,如果希望采用灰度发布模式,则需要在Service级别进行流量控制,以确保指定的流量进入到灰度的链路,而不对正常用户产生影响。
不过由于Kubernetes原生Service级别并不支持任何的流量控制规则,因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。
如下图所示,当使用Kubernetes蓝绿发布模式时,可以设置灰度流量规则,从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中:
![云效发布策略指南|滚动、分批、灰度怎么选()](https://img.it610.com/image/info9/ec60c21a091a459aa88b393d699bd534.jpg)
文章图片
该模式适用于:采用Istio或者阿里云ServiceMesh的Kubernetes用户,并且希望能够通过灰度的方式对发布进行验证。
点击下方链接即可前往云效帮助中心查看详细操作文档。
https://help.aliyun.com/document_detail/224586.html
关于我们
了解更多关于云效DevOps的最新动态,可微信搜索关注【云效】公众号;
彩蛋:公众号后台回复【指南】,可获得《阿里巴巴DevOps实践指南》&《10倍研发效能提升案例集》;
【云效发布策略指南|滚动、分批、灰度怎么选()】看完觉得对您有所帮助别忘记点赞、收藏和关注呦;
推荐阅读
- 赠己诗
- jhipster|jhipster 升级无效问题
- 【译】20个更有效地使用谷歌搜索的技巧
- 八、「料理风云」
- 西湖游
- 怎样用黑谜速冻膜去黑头,|怎样用黑谜速冻膜去黑头, 最有效的去黑头的方法看这!
- SpringBoot调用公共模块的自定义注解失效的解决
- 两短篇
- 9531
- NeuVector 会是下一个爆款云原生安全神器吗()