当您需要对整条调用链路进行灰度发布或版本隔离时，可以使用严格模式的流量泳道，将应用的相关版本（或其他特征）隔离成独立的运行环境，确保只有符合特定条件的流量被路由到新的服务版本，提高发布过程的稳定性和可控性。
前提条件
已创建ASM企业版或旗舰版实例，且版本为1.18.2.111及以上。具体操作，请参见创建ASM实例或升级ASM实例。
说明若您的实例版本为1.17.2.22及以上，1.18.2.111以下，请参见使用泳道模式下的流量管理功能。
已添加集群到ASM实例。具体操作，请参见添加集群到ASM实例。
已创建名称为ingressgateway的ASM入口网关。具体操作，请参见创建入口网关服务。
已创建名称为ingressgateway且命名空间为istio-system的网关规则。具体操作，请参见管理网关规则。
示例说明
本示例使用mocka、mockb、mockc三个服务创建代表服务调用链三个版本的三条泳道：s1、s2、s3。
步骤一：部署示例服务
为default命名空间启用Sidecar网格代理自动注入。具体操作，请参见启用自动注入。
关于自动注入的更多信息，请参见配置Sidecar注入策略。
在ACK集群中执行以下命令，部署示例服务。
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
步骤二：创建泳道组和对应泳道
创建泳道组。
登录ASM控制台，在左侧导航栏，选择。
在网格管理页面，单击目标实例名称，然后在左侧导航栏，选择。
在流量泳道页面，单击创建泳道组，在创建泳道组面板，配置相关信息，然后单击确定。
配置项
说明
泳道组名称
本示例配置为test。
入口网关
选择ingressgateway。
泳道模式
选择严格模式。
泳道服务
选择目标Kubernetes集群和default命名空间，在下方列表中选中mocka、mockb和mockc服务，单击
图标，添加目标服务到已选择区域。
创建s1、s2、s3泳道，并分别绑定v1、v2、v3版本。
在流量泳道页面的流量规则定义区域，单击创建泳道。
在创建泳道对话框，配置相关信息，然后单击确定。
配置项
说明
泳道名称
三条泳道分别配置为s1、s2、s3。
配置服务标签
标签名称：选择ASM_TRAFFIC_TAG。
标签值：三条泳道分别选择v1、v2、v3。
创建s1泳道的示例图如下：
三条泳道创建完成后，示例效果如下：
三条泳道创建完成后，针对泳道组中的每个服务都将生成泳道规则对应的目标规则和虚拟服务。您可以在控制台左侧导航栏，选择或虚拟服务进行查看。例如，针对mocka服务会自动创建如下目标规则和虚拟服务。
分别创建三条泳道对应的引流规则。
在流量泳道页面的流量规则定义区域，单击目标泳道右侧操作列下的引流规则。
在添加引流规则对话框，配置相关信息，然后单击确定。
本文以泳道服务对应入口API均为
/mock为例，为每条泳道配置相同的引流规则。配置项
说明
入口服务
选择mocka.default.svc.cluster.local。
引流规则
配置名称为r1，域名为*。
匹配请求的URI
配置匹配方式为精确，匹配内容为/mock。
添加Header匹配规则
单击添加Header匹配规则，配置名称为x-asm-prefer-tag，匹配方式为精确，三条泳道的匹配内容分别配置为s1、s2、s3。
为s1泳道添加引流规则的示例图如下：
三条泳道的引流规则创建成功后，示例效果如下：
创建成功后，会自动生成每条泳道的引流规则，即虚拟服务。例如，针对s1泳道会生成如下的虚拟服务。
步骤三：验证全链路灰度功能是否生效
获取ASM网关的公网IP。具体操作，请参见获取ASM网关地址。
执行以下命令，设置环境变量。
xxx.xxx.xxx.xxx为上一步获取的IP。export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx验证全链路灰度功能是否生效。
执行以下命令，查看s1泳道的访问效果。
x-asm-prefer-tag对应的值s1为步骤二中第2步创建s1泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: 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标头
x-asm-prefer-tag: s1声明的流量流向s1泳道下的相关服务，符合预期。执行以下命令，查看s2泳道的访问效果。
x-asm-prefer-tag对应的值s2为步骤二中第2步创建s2泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;预期输出：
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)由预期输出得到，通过设置HTTP标头
x-asm-prefer-tag: s2声明的流量流向s2泳道下的相关服务，符合预期。执行以下命令，查看s3泳道的访问效果。
x-asm-prefer-tag对应的值s3为步骤二中第2步创建s3泳道时配置的泳道名称。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;预期输出：
-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)由预期输出得到，通过设置HTTP标头
x-asm-prefer-tag: s3声明的流量流向s3泳道下的相关服务，符合预期。
通过自定义虚拟服务为严格模式的泳道引流
流量泳道预置了配置引流规则的功能。通过为泳道创建引流规则，可以在流量泳道对应的网关上创建虚拟服务，从而实现通过ASM入口网关向不同泳道引流（即转发请求）的效果。
流量泳道的引流规则包含针对请求头以及请求路径的匹配规则，您可以通过自定义虚拟服务的方式来实现更复杂的匹配规则或者自定义请求路由的需求。
在使用自定义虚拟服务为泳道引流时，不建议创建泳道的引流规则，因为自定义虚拟服务和泳道内置的引流规则可能会发生冲突，从而导致流量分发过程出现异常或不可预期的情况。
基于ASM网关创建自定义虚拟服务
以文中场景为例，在步骤二的第3步：分别创建三个泳道对应的引流规则，将创建引流规则的步骤，改为使用以下内容创建虚拟服务。具体操作，请参见管理虚拟服务。
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: swimlane-ingress-vs-custom namespace: istio-system spec: gateways: - istio-system/ingressgateway hosts: - '*' http: - match: # 这条匹配规则表示精准匹配形如 env: dev 的请求头 - headers: env: exact: dev name: dev-route route: - destination: host: mocka.default.svc.cluster.local # 流量转发的目标服务 subset: s2 # subset 填写泳道的名称 weight: 50 - destination: host: mocka.default.svc.cluster.local # 流量转发的目标服务 subset: s3 # subset 填写泳道的名称 weight: 50 - name: base-route route: - destination: host: mocka.default.svc.cluster.local # 流量转发的目标服务 subset: s1 # subset 填写泳道的名称执行步骤三：验证全链路灰度功能是否生效中的命令，访问s1、s2、s3三条泳道的预期输出如下：
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)执行以下命令，验证在访问s1泳道时带有header
env: dev的效果。for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H 'env: dev' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;预期输出：
可以看到带有header
env: dev时访问泳道s1返回的是v2和v3的链路，比例大约50:50左右。即对于带有env: dev请求头的请求，请求将会以50:50的比例转发到s2和s3泳道，其余请求将会被转发到s1泳道。
上述的虚拟服务在ASM网关上指定了一个自定义的路由规则，从而将流量转发到不同的流量泳道。当通过自定义虚拟服务为严格模式的泳道引流时，想要将请求发往某条泳道，只需要在虚拟服务的路由目标subset字段中填写泳道名称即可。当请求发往一条流量泳道后，后续的流量调用将保持在该泳道内部。
基于Sidecar创建自定义虚拟服务
除了在ASM网关上指定自定义路由规则外，您也可以通过生效在所有Sidecar上的虚拟服务来指定集群内部服务访问流量泳道内服务的引流规则。与ASM网关自定义路由规则不同，Sidecar虚拟服务不再需要gateway字段，且hosts中填写的是mocka服务的集群本地服务域名。示例YAML如下：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: swimlane-ingress-vs-custom
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- match: # 这条匹配规则表示精准匹配形如 env: dev 的请求头
- headers:
env:
exact: dev
name: dev-route
route:
- destination:
host: mocka.default.svc.cluster.local # 流量转发的目标服务
subset: s2 # subset 填写泳道的名称
weight: 50
- destination:
host: mocka.default.svc.cluster.local # 流量转发的目标服务
subset: s3 # subset 填写泳道的名称
weight: 50
- name: base-route
route:
- destination:
host: mocka.default.svc.cluster.local # 流量转发的目标服务
subset: s1 # subset 填写泳道的名称执行以下命令，验证Sidecar模式下不带
env: dev请求头时访问mocka服务。kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl http://mocka:8000; echo ""; sleep 1; done;'预期输出：
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)可以看到，不带
env: dev请求头时访问所有泳道返回的都是v1链路，说明流量全部进入了s1泳道。执行以下命令，验证Sidecar模式下带有
env: dev请求头时访问mocka服务。kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;'预期输出：
可以看到，以上预期输出与基于ASM网关创建自定义虚拟服务中的预期输出一致，带有
env: dev请求头时访问mocka服务，流量会以50:50的比例进入s2和s3泳道。
与基于ASM网关创建自定义虚拟服务原理相同，当集群内其它服务调用泳道内的mocka服务时，后续的请求调用链将一直保持在泳道内部。
相关文档
流量泳道分为严格与宽松两种模式。关于两种模式的说明和差异，请参见流量泳道概述。
当您的应用程序在调用链路中存在透传请求头的行为时，宽松模式可以实现更为灵活的泳道使用场景，例如只发布了调用链路中的部分服务的新版本，基于这些新版本服务构建测试环境。具体操作，请参见使用宽松模式流量泳道实现全链路流量管理。
您可以基于VirtualService和DestinationRule等流量规则实现流量泳道，同时通过配置流量降级，在某个版本（或者其他特征）的应用不可用时，将流量发往一个指定的降级版本（或其他特征）的应用。具体操作，请参见基于流量规则配置实现流量泳道和流量降级。
关于虚拟服务的详细CRD定义，请参见虚拟服务（Virtual Service）CRD说明。