场景一:在链路中透传trace ID

您可以使用宽松模式的流量泳道实现应用版本隔离,基于链路透传请求头和引流请求头,将流量路由到不同泳道。泳道中服务相互调用时,若目标服务不存在当前泳道则转发至基线泳道,保障链路完整性,简化流量管理。

重要

开始阅读前,请确保您已经阅读并理解了使用宽松模式流量泳道实现全链路流量管理及其相关的内容。

场景概述

本示例使用mocka、mockb、mockc三个服务创建代表服务调用链三个版本的三条泳道:s1、s2、s3。其中s1为基线泳道,包含完整的三个服务,s2仅包含mocka和mockc两个服务,s3仅包含mockb一个服务。

步骤一:创建泳道组和对应泳道

  1. 创建泳道组。

    1. 登录ASM控制台,在左侧导航栏,选择服务网格 > 网格管理

    2. 网格管理页面,单击目标实例名称,然后在左侧导航栏,选择流量管理中心 > 流量泳道

    3. 流量泳道页面,单击创建泳道组,在创建泳道组面板,配置相关信息,然后单击确定

      配置项

      说明

      泳道组名称

      本示例配置为test

      入口网关

      选择ingressgateway

      泳道模式

      选择宽松模式

      调用链路上下文透传方式

      选择透传trace id

      trace id请求头

      由于示例应用在调用链路中透传了请求头my-trace-id,因此本示例配置为my-trace-id。

      引流请求头

      用于网关根据请求头内容向不同泳道引流及泳道上下文保持,可任意指定。本示例配置为x-asm-prefer-tag

      泳道服务

      选择目标Kubernetes集群和default命名空间,在下方列表中选中mockamockbmockc服务,单击移动图标,添加目标服务到已选择区域。

      配置完成后,会自动生成对应的流量标签TrafficLabel。您可以在控制台左侧导航栏,单击流量标签进行查看。例如,针对mocka服务会生成如下的TrafficLabel。

      展开查看TrafficLabel YAML示例

      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-trace-id)'
        workloadSelector:
          labels:
            app: mocka
      
  2. 创建s1、s2、s3泳道,并分别绑定v1、v2、v3版本。

    1. 流量泳道页面的流量规则定义区域,单击创建泳道

    2. 创建泳道对话框,配置相关信息,然后单击确定

      配置项

      说明

      泳道名称

      三条泳道分别配置为s1s2s3

      配置服务标签

      标签名称:选择ASM_TRAFFIC_TAG

      标签值:三条泳道分别选择v1v2v3

      添加服务

      s1泳道:选择mocka(default)mockb(default)mockc(default)

      s2泳道:选择mocka(default)mockc(default)

      s3泳道:选择mockb(default)。

      创建s1泳道的示例图如下:

      image.png

      三条泳道创建完成后,示例效果如下:image.png

      说明

      默认情况下,您在泳道组中创建的第一条泳道将被设定为基线泳道。您可以修改基线泳道,当流量发往其他泳道中不存在的服务时,通过回退机制将请求转发至基线泳道。具体操作,请参见在宽松模式中修改基线泳道

      三条泳道创建完成后,针对泳道组中的每个服务都将生成泳道规则对应的目标规则DestinationRule和虚拟服务VirtualService。您可以在控制台左侧导航栏,选择流量管理中心 > 目标规则虚拟服务进行查看。例如,针对mocka服务会自动创建如下DestinationRule和VirtualService。

      展开查看DestinationRule YAML示例

      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 YAML示例

      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
      
  3. 创建三条泳道对应的引流规则。

    1. 流量泳道页面的流量规则定义区域,单击目标泳道右侧操作列下的引流规则

    2. 添加引流规则对话框,配置相关信息,然后单击确定

      本文以泳道服务对应入口API均为/mock为例,为每条泳道配置相同的引流规则。

      配置项

      说明

      入口服务

      选择mocka.default.svc.cluster.local

      引流规则

      配置三条泳道引流规则的名称分别为r1r2r3域名*

      匹配请求的URI

      配置匹配方式精确匹配内容/mock

      为s1泳道添加引流规则的示例图如下:

      image.png

      三条泳道的引流规则创建成功后,示例效果如下:image.png

      创建成功后,会自动生成每条泳道的引流规则,即虚拟服务VirtualService。例如,针对泳道s2会生成如下的虚拟服务VirtualService。

      展开查看VirtualService YAML示例

      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

步骤二:验证全链路灰度功能是否生效

  1. 获取ASM网关的公网IP。具体操作,请参见获取ASM网关地址

  2. 执行以下命令,设置环境变量。

    xxx.xxx.xxx.xxx为上一步获取的IP。

    export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
  3. 验证全链路灰度功能是否生效。

    1. 执行以下命令,查看s1泳道的访问效果。

      x-asm-prefer-tag对应的值s1步骤一.2创建s1泳道时配置的泳道名称。

      for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s1' -H'my-trace-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泳道下的相关服务,符合预期。

    2. 执行以下命令,查看s2泳道的访问效果。

      x-asm-prefer-tag对应的值s2步骤一.2创建s2泳道时配置的泳道名称。

      for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s2' -H'my-trace-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服务,符合预期。

    3. 执行以下命令,查看s3泳道的访问效果。

      x-asm-prefer-tag对应的值s3步骤一.2创建s3泳道时配置的泳道名称。

      for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s3' -H'my-trace-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中不存在的服务mocka、mockc时,流量通过回退机制发往基线泳道s1中的mocka、mockc服务,符合预期。

在宽松模式中修改基线泳道

说明

修改基线泳道的前提是已创建宽松模式的泳道组,并在泳道组中创建至少两条泳道。

  1. 登录ASM控制台,在左侧导航栏,选择服务网格 > 网格管理

  2. 网格管理页面,单击目标实例名称,然后在左侧导航栏,选择流量管理中心 > 流量泳道

  3. 流量泳道页面的目标泳道组页签,在流量规则定义区域,单击基线泳道右侧的238D682D-C76F-4c7c-974E-501245431A86.png图标。

  4. 选择要修改的基线泳道名称,然后单击确定修改