基于 GitOps 在托管网格下的工作集群中进行灰度发布¶
场景:基于 GitOps 的方式客户如何在托管网格下的工作集群中进行灰度发布?
前提条件¶
参考文档基于 GitOps 在托管网格下的工作集群中部署 istio 相关资源 完成 创建托管网格并纳管工作集群
之前的所有步骤
基于 GitOps 实现基于权重的灰度发布¶
-
前往应用工作台,在
GitOps
,创建 gitops 应用, 其中仓库地址:https://github.com/amamba-io/rollout-examples
,路径设置为rollouts/v1
,集群/命名空间选择工作集群下的命名空间即可。 -
创建成功后,手动 同步 应用资源
-
前往服务网格,在托管网格查看工作集群中同步的 vs、dr、gateway 资源,如果未查找到,请检测章节 创建托管网格并纳管工作集群 中的注意事项是否配置正确
-
默认情况下工作集群的负载均衡暴露的是
80
端口,所需要在工作集群中修改服务的 gatway 端口为 80 以便能访问到服务 -
在浏览器访问
http://<工作集群节点IP>/hello?name=test-v1
-
前往应用工作台,在 灰度发布 列表,选择
dubbo3-provider
进行 yaml 编辑,修改version: v1
为version: v2
-
修改成功后,
dubbo3-provider
开始进入灰度过程如上图:可以根据 workload 的标签 rollouts-pod-template-hash 和 version 来进行区分
Note
- v1 Pod: dubbo3-provider-5d96bf8bbd-v9c28
- v2 Pod: dubbo3-provider-f44c7c68f-95pfb
-
灰度规则说明,这部分在 git 仓库
rollouts-legacy/v1/rollout-provider.yaml
目录下可以看到... strategy: canary: trafficRouting: istio: virtualService: name: provider routes: - test-v1 destinationRule: name: dubbo-provider stableSubsetName: stable canarySubsetName: canary # 进入灰度发布时,会将新版本的流量全中权重设置为 5%,等待 10 分钟后会将权重设置为 50% steps: - setWeight: 5 - pause: duration: 10m - setWeight: 50 - pause: duration: 10m
-
终端模拟访问结果如下:
-
新版本权重为 5% ,v1 Pod 和 v2 Pod 的流量分配如下:
-
新版本权重为 50% ,v1 Pod 和 v2 Pod 的流量分配如下:
-
发布成功后,全是 v2 Pod 的流量
-
基于 GitOps 实现基于请求特征的灰度发布¶
介绍¶
本演示示例仓库地址:https://github.com/amamba-io/rollout-examples
其中 dubbo3-consumer
和 dubbo3-provider
两个服务有关联关系,访问 dubbo3-consumer 的 /hello 接口,
dubbo3-consumer 会将请求转发给 dubbo3-provider,发布过程会对 dubbo3-provider 服务进行更新,并根据预设的 header 信息来进行路由。
操作步骤¶
-
前往应用工作台,在
GitOps
,创建 gitops 应用, 其中仓库地址:https://github.com/amamba-io/rollout-examples
,路径设置为rollouts-legacy/v1
,集群/命名空间选择工作集群下的命名空间即可。 -
创建成功后,手动 同步 应用资源
-
前往服务网格,在托管网格查看工作集群中同步的 vs、dr、gateway 资源,如果未查找到,请检测章节 创建托管网格并纳管工作集群 中的注意事项是否配置正确
-
默认情况下工作集群的负载均衡暴露的是
80
端口,所需要在工作集群中修改服务的 gatway 端口为 80 以便能访问到服务 -
在浏览器访问
http://<工作集群节点IP>/hello?name=test-v1
-
前往应用工作台,在 灰度发布 列表,选择
dubbo3-provider
进行 yaml 编辑,修改version: v1
为version: v2
-
修改成功后,
dubbo3-provider
开始进入灰度过程如上图:可以根据 workload 的标签 rollouts-pod-template-hash 和 version 来进行区分
Note
- v1 Pod: dubbo3-provider-5d96bf8bbd-v9c28
- v2 Pod: dubbo3-provider-f44c7c68f-95pfb
-
灰度规则说明,这部分在 git 仓库
rollouts-legacy/v1/rollout-provider.yaml
目录下可以看到... strategy: canary: canaryService: dubbo3-provider-canary stableService: dubbo3-provider trafficRouting: managedRoutes: - name: test-v2 istio: virtualService: name: provider routes: - test-v1 # 进行灰度发布时,会将 vs 中 header 设置为 test-v2,即请求时如果请求头中带有`lane: test-v2`,将会路由到新版本 steps: - setCanaryScale: weight: 100 - setHeaderRoute: name: test-v2 match: - headerName: lane headerValue: exact: test-v2 - pause: {}
-
终端模拟访问结果如下:
FAQ¶
上述步骤是否支持多集群的灰度?¶
支持的,需要做以下动作:
-
首先需要将多个集群都放在同一个托管网格下
-
需要创建同名的命名空间,并且基于每个集群的命名空间都要部署相同的 GitOps 应用
-
灰度发布时需要在两个集群中对对应的服务分别进行操作。