How to configure traffic lanes and fallbacks - Alibaba Cloud Service Mesh

Prerequisites

An ASM Enterprise Edition or Ultimate Edition instance is created, and the instance version is 1.17 or later. For more information, see Create an ASM instance or Upgrade an ASM instance.
A Kubernetes cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
An ASM gateway named ingressgateway is created. For more information, see Create an ingress gateway.

Step 1: Deploy the sample services

Enable automatic sidecar injection for the default namespace. For more information, see Enable automatic sidecar proxy injection.

For more information about automatic sidecar injection, see Configure sidecar injection policies.
Use the kubeconfig file of the data plane cluster and run the following commands to deploy the sample services.

The sample services include mocka, mockb, and mockc. Each service has three versions: v1, v2, and v3.

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml

Step 2: Create traffic rules to implement a traffic lane

Complete the following sub-tasks to create the DestinationRule, VirtualService, and gateway routing rules that define the traffic lane.

Create DestinationRule traffic rules

Create a DestinationRule for each service to define version subsets.

Use the following content to create the dr-mock.yaml file.

The following file divides each of the mocka, mockb, and mockc services into three subsets: v1, v2, and v3.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mockb
  namespace: istio-system
spec:
  host: mockb.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mockc
  namespace: istio-system
spec:
  host: mockc.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3

Use the kubeconfig file of the ASM instance and run the following command to apply the DestinationRule traffic rules.

kubectl apply -f dr-mock.yaml

Create VirtualService traffic rules

Create a VirtualService for each internal service to define version-based routing within the traffic lane.

Use the following content to create the vs-mock.yaml file.

The following file creates a traffic lane for the mocka→mockb→mockc service invocation chain. After the traffic lane is created, a request sent by a service of one version can be sent only to a service of the same version.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockb
  namespace: istio-system
spec:
  hosts:
    - mockb.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v2
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockc
  namespace: istio-system
spec:
  hosts:
    - mockc.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v2
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v3

Use the kubeconfig file of the ASM instance and run the following command to apply the VirtualService traffic rules.

kubectl apply -f vs-mock.yaml

Create gateway traffic routing rules

Create gateway routing rules to route external requests into the traffic lane based on the x-asm-prefer-tag header.

Use the following content to create the gw-mock.yaml file.

The following file creates gateway traffic routing rules for the mocka→mockb→mockc service invocation chain. The rules match the x-asm-prefer-tag header of requests sent to the gateway and route the requests to the v1, v2, or v3 version of the mocka service based on the header value.

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:
        - '*'
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v1
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v1
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v2
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v2
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v3
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v3

Use the kubeconfig file of the ASM instance and run the following command to apply the gateway traffic routing rules.

kubectl apply -f gw-mock.yaml

Step 3: Verify that the traffic lane takes effect

Obtain the public IP address of the ASM gateway. For more information, see Obtain the address of an ASM gateway.
Run the following command to set the environment variable.

xxx.xxx.xxx.xxx is the IP address obtained in the previous step.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

Verify that the traffic lane takes effect.
Run the following command to check the responses of the v1 traffic lane.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Expected output:

-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

The expected output indicates that traffic with the x-asm-prefer-tag: v1 HTTP header flows to the services of the v1 version.

Run the following command to check the responses of the v2 traffic lane.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Expected output:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

The expected output indicates that traffic with the x-asm-prefer-tag: v2 HTTP header flows to the services of the v2 version.

Run the following command to check the responses of the v3 traffic lane.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Expected output:

-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

The expected output indicates that traffic with the x-asm-prefer-tag: v3 HTTP header flows to the services of the v3 version.

(Optional) Step 4: Configure traffic degradation within the traffic lane

Use the following content to modify the vs-mock.yaml file.

The following file creates a traffic lane for the mocka→mockb→mockc service invocation chain. In addition, when the v2 or v3 version of mockb or mockc is unavailable, requests are sent to the v1 version invocation chain of the service.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockb
  namespace: istio-system
spec:
  hosts:
    - mockb.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v2
      fallback:
        target:
          host: mockb.default.svc.cluster.local
          subset: v1
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v3
      fallback:
        target:
          host: mockb.default.svc.cluster.local
          subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockc
  namespace: istio-system
spec:
  hosts:
    - mockc.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v2
      fallback:
        target:
          host: mockc.default.svc.cluster.local
          subset: v1
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v3
      fallback:
        target:
          host: mockc.default.svc.cluster.local
          subset: v1

Use the kubeconfig file of the ASM instance and run the following command to modify the existing VirtualService traffic rules and apply the traffic degradation configuration.

kubectl apply -f vs-mock.yaml

(Optional) Step 5: Verify that traffic degradation takes effect

Log on to the ACK console. In the left navigation pane, click Clusters.

On the Clusters page, click the name of your cluster. In the left navigation pane, click Workloads > Deployments.

On the Deployments page, find the mockb-v2 workload and click Scale in the Actions column. In the Scale dialog box, set Desired Pod Count to 1 and click OK. In the Confirm dialog box, click OK to simulate a failure of the mockb service of the v2 version.

Run the following command to check the responses of the v2 traffic lane.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Expected output:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)

The expected output indicates that traffic with the x-asm-prefer-tag: v2 HTTP header flows to the services of the v2 version. When the traffic passes through the mockb service of the v2 version, the request is then sent to the v1 version invocation chain of the service because the mockb service of the v2 version has failed. This implements traffic degradation.