基于Istio的灰度发布改造流程
背景在多人开发的应用团队中，每个人需要基于发布分支（master分支）拉出自己的特性开发分支，那么如何做到发布到测试环境中而互不干扰呢。对于k8s开发环境来说，即使每个版本启动一个pod来隔离，但是也无法做到前端请求精确的分配到指定的pod里面。此时可以引入今天的主角istio，istio是干嘛的这里就不详细的说了，简单来说，今天要用到的是它的路由功能。规范分支名为了对不同分支特性进行灰度，我们需
背景
在多人开发的应用团队中，每个人需要基于发布分支（master分支）拉出自己的特性开发分支，那么如何做到发布到测试环境中而互不干扰呢。
对于k8s开发环境来说，即使每个版本启动一个pod来隔离，但是也无法做到前端请求精确的分配到指定的pod里面。
此时可以引入今天的主角istio，istio是干嘛的这里就不详细的说了，简单来说，今天要用到的是它的路由功能。
规范分支名
为了对不同分支特性进行灰度，我们需要通过分支标识来做istio的路由标识，因此需要规范开发的分支命名，比如feature/xx
更新istio规则
通过更新istio的virtualService和destinationRule配置，对路由进行标签处理
路由策略
我们可以根据需要在不同的端侧增加路由标识；
前端：可以根据特性需要，修改前端的请求体，带上路由标识
网关：在网关处根据需要对到来的请求添加路由标识，（比如根据请求的地域、用户信息等，对不同的地域，不同的用户实施灰度）。
注：apisix或者kong网关都可以自定义插件实现上述功能服务侧：根据需要可以做精确的灰度
一键发布
针对上面的各个环节的处理，可以使用github flow进行代码提交后的一键式集成处理，真正做到devops开发体验。
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献4条内容
所有评论(0)