作者:尹航
在前文基于阿里云服务网格流量泳道的全链路流量管理(一):严格模式流量泳道中,我们介绍了使用服务网格 ASM 的严格模式流量泳道进行全链路灰度管理的使用场景。该模式对于应用程序无任何要求,只需配置流量泳道即可实现。本文继续介绍流量泳道的第二种模式:宽松模式。
宽松模式流量泳道概述
与严格模式流量泳道相对的就是宽松模式流量泳道。在宽松模式下,您只需要确保创建一条包含调用链路中所有服务的泳道:基线泳道。其它泳道可以不包含调用链路上的全部服务。当一个泳道中的服务进行相互调用时,若目标服务在当前泳道中不存在,则请求将被转发到基线泳道中的相同服务,并在请求目标在当前泳道中存在时将请求重新转发回当前泳道。
使用宽松模式的流量泳道时,您的应用程序必须包含一个能够在整条调用链路中透传的请求头(链路透传请求头),且链路透传请求头的值对于每条请求都各不相同。同时,您需要指定一个引流请求头,ASM 网关将会根据引流请求头的内容将流量发往不同的流量泳道。本文介绍如何在 ASM 中使用宽松模式的流量泳道实现全链路流量管理。
宽松模式演练场景 1:在链路中未透传引流请求头
本文首先介绍宽松模式流量泳道最常用的使用场景,即调用链路中透传的请求头并非引流请求头的情况。
在这个宽松模式示例场景下,将使用如图所示的三个服务 mocka、mockb、mockc 创建代表服务调用链三个版本的三个泳道:s1、s2、s3。其中 s1 为基线泳道,包含完整的三个服务,而 s2 仅包含 mocka、mockc 两个服务,s3 仅包含 mockb 一个服务。
前提条件
- 已创建 ASM 企业版或旗舰版实例,且版本为 1.18.2.111 及以上。具体操作,请参见创建 ASM 实例[1]。
- 已添加集群到 ASM 实例。具体操作,请参见添加集群到 ASM 实例[2]。
- 已创建名称为 ingressgateway 的 ASM 网关。具体操作,请参见创建入口网关服务[3]。
- 已创建名称为 ingressgateway 且命名空间为 istio-system 的网关规则。具体操作,请参见管理网关规则[4]。
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: ingressgateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- '*'
步骤一:部署示例服务
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml
步骤二:创建泳道组和对应泳道
a. 登录 ASM 控制台[7],在左侧导航栏,选择服务网格 > 网格管理。
b. 在网格管理页面,单击目标实例名称,然后在左侧导航栏,选择流量管理中心 > 流量泳道。
c. 在流量泳道页面,单击创建泳道组,在创建泳道组面板,配置相关信息,然后单击确定。
配置项 | 说明 |
---|---|
泳道组名称 | 本示例配置为test。 |
入口网关 | 选择ingressgateway。 |
泳道模式 | 选择宽松模式 |
请求头设定 | 由于示例应用在调用链路中透传了请求头my-request-id,链路透传请求头填写my-request-id。引流请求头用于网关根据请求头内容向不同泳道引流及泳道上下文保持,可任意指定,这里引流请求头填写x-asm-prefer-tag。 |
泳道服务 | 选择目标Kubernetes集群和default命名空间,在下方列表中选中mocka、mockb和mockc服务,单击图标,添加目标服务到已选择区域。 |
配置完成后,会自动生成对应的流量标签 TrafficLabel。例如,针对 mocka 服务,会生成如下的流量标签 TrafficLabel。
apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: asm-swimlane-test-mocka
namespace: default
spec:
rules:
- labels:
- name: asm-label
valueFrom:
- '$getExternalInboundRequestHeader(x-asm-prefer-tag, my-request-id)'
workloadSelector:
labels:
app: mocka
a. 在流量泳道页面的流量规则定义区域,单击创建泳道。
b. 在创建泳道对话框,配置相关信息,然后单击确定。
配置项 | 说明 |
---|---|
泳道名称 | 对于不同泳道,分别填写s1、s2和s3。 |
配置服务标签 | 本示例中标签名称配置为ASM_TRAFFIC_TAG,针对s1、s2、s3泳道,标签值分别配置为v1、v2和v3。 |
添加服务 | 对于s1泳道,选择mocka(default)、mockb(default)和mockc(default)。对于s2泳道,选择mocka(default)、mockc(default)。对于s3泳道,选择mockb(default)。 |
下图给出了创建 s1 泳道时的界面示例:
默认情况下,您在泳道组中创建的第一个泳道将被设定为基线泳道,您可以修改基线泳道,当流量发往其它泳道中不存在的服务时,通过回退机制将请求转发至基线泳道。三个泳道创建完成后,示例效果如下:
每创建一个泳道,会自动创建对应的目标规则 DestinationRule。例如,所有泳道创建完成后,会针对 s1 服务自动创建如下的目标规则 DestinationRule。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: trafficlabel-dr-test-default-mocka
namespace: istio-system
spec:
host: mocka.default.svc.cluster.local
subsets:
- labels:
ASM_TRAFFIC_TAG: v1
name: s1
- labels:
ASM_TRAFFIC_TAG: v2
name: s2
三个泳道创建完成后,针对泳道组中的每个服务都将生成泳道规则对应的虚拟服务 VirtualService。例如,针对 mocka 服务会自动创建如下虚拟服务 VirtualService。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: trafficlabel-vs-test-default-mocka
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- name: default
route:
- destination:
host: mocka.default.svc.cluster.local
subset: $asm-label
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
a. 在流量泳道页面的流量规则定义区域,单击目标泳道右侧操作列下的引流规则。
b. 在添加引流规则对话框,配置相关信息,然后单击确定。本文以泳道服务对应入口 API 均为 /mock 为例,为每个泳道配置相同的引流规则。
配置项 | 说明 |
---|---|
入口服务 | 选择mocka.default.svc.cluster.local。 |
引流规则 | 配置名称为r1,域名为*。 |
匹配请求的URI | 配置匹配方式为精确,匹配内容为/mock。 |
三个泳道的引流规则创建成功后,示例效果如下:
创建成功后,会自动生成每条泳道的引流规则,即虚拟服务 VirtualService。例如,针对泳道 s2 会生成如下的虚拟服务 VirtualService:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: swimlane-ingress-vs-test-s2
namespace: istio-system
spec:
gateways:
- istio-system/ingressgateway
hosts:
- '*'
http:
- match:
- headers:
x-asm-prefer-tag:
exact: s2
uri:
exact: /mock
name: r2
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s2
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
步骤三:验证全链路灰度功能是否生效
获取 ASM 网关的公网 IP。具体操作,请参见获取 ASM 网关地址[8]。
执行以下命令,设置环境变量。xxx.xxx.xxx.xxx 为上一步获取的 IP。
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
a. 执行以下命令,查看 s1 泳道的访问效果。x-asm-prefer-tag 对应的值 s1 为步骤二创建 s1 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
由预期输出得到,通过设置 HTTP 标头 x-asm-prefer-tag: s1 声明的流量流向 s1 泳道下的相关服务,符合预期。
b. 执行以下命令,查看 s2 泳道的访问效果。x-asm-prefer-tag 对应的值 s2 为步骤二创建 s2 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v2, ip: 172.17.0.128)
由预期输出得到,通过设置 HTTP 标头 x-asm-prefer-tag: s2 声明的流量流向 s2 泳道下的相关服务,当流量发往泳道 s2 中不存在的服务 mockb 时,流量通过回退机制发往基线泳道 s1 中的 mockb 服务,后续流量发往 mockc 服务时,目标重新设定为 s2 泳道中的 mockc 服务,符合预期。
c. 执行以下命令,查看 s3 泳道的访问效果。x-asm-prefer-tag 对应的值 s3 为步骤二创建 s3 泳道时配置的泳道名称。
for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3 -H'my-request-id: x000'$i' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
由预期输出得到,通过设置 HTTP 标头 x-asm-prefer-tag: s3 声明的流量流向 s3 泳道下的相关服务,当流量发往泳道 s3 中不存在的服务 mockb、mockc 时,流量通过回退机制发往基线泳道 s1 中的 mockb、mockc 服务,符合预期。
宽松模式演练场景 2:在链路中已透传引流请求头
在宽松模式演练场景 1 中,引流请求头与链路透传请求头并不相同(分别为 my-request-id 和 x-asm-prefer-tag)。在这种情况下,需要链路透传请求头中的内容针对每次请求都不相同(即每次调用链路都有唯一的链路 id)。而如果同时将链路透传请求头也指定为引流请求头,则针对链路透传请求头不再需要上述的限制,只需用链路透传请求头的内容向不同泳道引流即可。
在第二个宽松模式示例场景下,将使用如图所示的三个服务 mocka、mockb、mockc 创建代表服务调用链三个版本的三个泳道:s1、s2、s3。其中 s1 为基线泳道,包含完整的三个服务,而 s2 仅包含 mocka、mockc两个服务,s3 仅包含 mockb 一个服务。同时,链路透传请求头与引流请求头都指定为 my-request-id。
前提条件
- 已创建 ASM 企业版或旗舰版实例,且版本为 1.18.2.111 及以上。具体操作,请参见创建 ASM 实例[1]。
- 已添加集群到 ASM 实例。具体操作,请参见添加集群到 ASM 实例[2]。
- 已创建名称为 ingressgateway 的 ASM 网关。具体操作,请参见创建入口网关服务[3]。
- 已创建名称为 ingressgateway 且命名空间为 istio-system 的网关规则。具体操作,请参见管理网关规则[4]。
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: ingressgateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- '*'
步骤一:部署示例服务
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml
步骤二:创建泳道组和对应泳道
a. 登录 ASM 控制台[7],在左侧导航栏,选择服务网格 > 网格管理。
b. 在网格管理页面,单击目标实例名称,然后在左侧导航栏,选择流量管理中心 > 流量泳道。
c. 在流量泳道页面,单击创建泳道组,在创建泳道组面板,配置相关信息,然后单击确定。
配置项 | 说明 |
---|---|
泳道组名称 | 本示例配置为test。 |
入口网关 | 选择ingressgateway。 |
泳道模式 | 选择宽松模式 |
请求头设定 | 在本例中,引流请求头与链路透传请求头都为my-request-id。 |
泳道服务 | 选择目标Kubernetes集群和default命名空间,在下方列表中选中mocka、mockb和mockc服务,单击图标,添加目标服务到已选择区域。 |
a. 在流量泳道页面的流量规则定义区域,单击创建泳道。
b. 在创建泳道对话框,配置相关信息,然后单击确定。
配置项 | 说明 |
---|---|
泳道名称 | 对于三条泳道,泳道名称分别填写s1、s2和s3。 |
配置服务标签 | 本示例中标签名称配置为ASM_TRAFFIC_TAG,针对s1、s2、s3泳道,标签值分别配置为v1、v2和v3。 |
添加服务 | 对于s1泳道,选择mocka(default)、mockb(default)和mockc(default)。对于s2泳道,选择mocka(default)、mockc(default)。对于s3泳道,选择mockb(default)。 |
下图给出了创建 s1 泳道时的界面示例:
默认情况下,您在泳道组中创建的第一个泳道将被设定为基线泳道,您可以修改基线泳道,当流量发往其它泳道中不存在的服务时,通过回退机制将请求转发至基线泳道。
三个泳道创建完成后,示例效果如下:
每创建一个泳道,会自动创建对应的目标规则 DestinationRule。例如,所有泳道创建完成后,会针对 s1 服务自动创建如下的目标规则 DestinationRule。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: trafficlabel-dr-test-default-mocka
namespace: istio-system
spec:
host: mocka.default.svc.cluster.local
subsets:
- labels:
ASM_TRAFFIC_TAG: v1
name: s1
- labels:
ASM_TRAFFIC_TAG: v2
name: s2
三个泳道创建完成后,针对泳道组中的每个服务都将生成泳道规则对应的虚拟服务 VirtualService。例如,针对 mocka 服务会自动创建如下虚拟服务 VirtualService。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: trafficlabel-vs-test-default-mocka
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- match:
- headers:
my-request-id:
exact: s1
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s1
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
- match:
- headers:
my-request-id:
exact: s2
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s2
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
- match:
- headers:
my-request-id:
exact: s3
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s3
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
a. 在流量泳道页面的流量规则定义区域,单击目标泳道右侧操作列下的引流规则。
b. 在添加引流规则对话框,配置相关信息,然后单击确定。本文以泳道服务对应入口 API 均为 /mock 为例,为每个泳道配置相同的引流规则。
配置项 | 说明 |
---|---|
入口服务 | 选择mocka.default.svc.cluster.local。 |
引流规则 | 配置名称为r1,域名为*。 |
匹配请求的URI | 配置匹配方式为精确,匹配内容为/mock。 |
三个泳道的引流规则创建成功后,示例效果如下:
创建成功后,会自动生成每条泳道的引流规则,即虚拟服务 VirtualService。例如,针对泳道 s2 会生成如下的虚拟服务 VirtualService:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
labels:
asm-system: 'true'
provider: asm
swimlane-group: test
name: swimlane-ingress-vs-test-s2
namespace: istio-system
spec:
gateways:
- istio-system/ingressgateway
hosts:
- '*'
http:
- match:
- headers:
my-request-id:
exact: s2
uri:
exact: /mock
name: r2
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s2
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
步骤三:验证全链路灰度功能是否生效
获取 ASM 网关的公网 IP。具体操作,请参见获取 ASM 网关地址[8]。
执行以下命令,设置环境变量。xxx.xxx.xxx.xxx为上一步获取的 IP。
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
a. 执行以下命令,查看 s1 泳道的访问效果。my-request-id 对应的值 s1 为步骤二创建 s1 泳道时配置的泳道名称。
for i in {1..100}; do curl -H'my-request-id: s1' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
由预期输出得到,通过设置 HTTP 标头 my-request-id: s1 声明的流量流向 s1 泳道下的相关服务,符合预期。
b. 执行以下命令,查看 s2 泳道的访问效果。my-request-id 对应的值 s2 为步骤二创建 s2 泳道时配置的泳道名称。
for i in {1..100}; do curl -H'my-request-id: s2' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
由预期输出得到,通过设置 HTTP 标头 my-request-id: s2 声明的流量流向 s2 泳道下的相关服务,当流量发往泳道 s2 中不存在的服务 mockb 时,流量通过回退机制发往基线泳道 s1 中的 mockb 服务,后续流量发往 mockc 服务时,目标重新设定为 s2 泳道中的 mockc 服务,符合预期。
c. 执行以下命令,查看 s3 泳道的访问效果。my-request-id 对应的值 s3 为步骤二创建 s3 泳道时配置的泳道名称。
for i in {1..100}; do curl -H'my-request-id: s3' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;
预期输出:
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
由预期输出得到,通过设置 HTTP 标头 my-request-id: s3 声明的流量流向 s3 泳道下的相关服务,当流量发往泳道 s3 中不存在的服务 mockb、mockc 时,流量通过回退机制发往基线泳道 s1 中的 mockb、mockc 服务,符合预期。
相关链接:
[1] 创建 ASM 实例
help.aliyun.com/document_de…
[2] 添加集群到 ASM 实例
help.aliyun.com/document_de…
[3] 创建入口网关服务
help.aliyun.com/document_de…
[4] 管理网关规则
help.aliyun.com/document_de…
[5] 启用自动注入
help.aliyun.com/document_de…
[6] 开启 Sidecar 自动注入
help.aliyun.com/document_de…
[7] ASM 控制台
servicemesh.console.aliyun.com/
[8] 获取 ASM 网关地址
help.aliyun.com/document_de…