Alibaba Cloud Service Mesh (ASM) provides scope configurations that you can use to specify the pods to which routing rules apply. If you apply routing rules to an increasing number of pods, you can expand the scope for canary releases. This topic describes how to use a scope configuration to specify the pods to which a virtual service applies. This allows you to implement a canary release for an application.

Prerequisites

Background information

When you upgrade the version of an application, you must deploy an earlier version and a new version in an environment at the same time. Then, you can adjust the proportion of the traffic that is distributed to the earlier version and new version to ensure a smooth transition between the versions. Virtual services can be used to distribute traffic. In the Bookinfo application, the Productpage microservice calls the Reviews microservice. After the Reviews microservice is upgraded to version v2, you can use a virtual service to route the traffic that is sent to the Productpage microservice to version v2 of the Reviews microservice. review
A smooth canary release requires you to control the risks that are brought by changes in routing rules. You can use a scope configuration to specify that the virtual service applies to only pod 1 of the Productpage microservice. This way, the traffic to pod 1 is routed to version v2 of the Reviews microservice, and the traffic to pod 2 is routed to version v1 of the Reviews microservice. Canary release
The Istio community provides workload selectors that can be used to specify the effective scope for specific routing rules. However, workload selectors have the following limits:
  • You can use only key-value pairs to set tags. A field with multiple values, such as idc: shanghai01,shanghai02, is not supported.
  • Original routing rules cannot coexist with routing rules that are configured for a canary release.
ASM provides scope configurations that can be used to specify the pods to which routing rules apply. You can use a scope configuration to configure a canary release in two modes.
Note You cannot enable the rollingUpdate and selector modes at the same time.
  • Selector mode: To enable this mode, you must tag one or more pods. For example, you can tag a pod with the information about data centers, units, or canary releases. Envoy passes the tags of the pods to Istio. You can set the matchLabels or matchExpressions parameter for tag matching. This way, routing rules apply only to the scope that is specified by the tags. You can use this method to implement a canary release.
  • RollingUpdate mode: In this mode, you do not need to tag pods. Instead, you can apply routing rules to pods in batches. After you enable this mode, Istio separates pods into batches as specified and then applies routing rules to pods by batch.
apiVersion: istio.alibabacloud.com/v1beta1
kind: ScopeConfig
metadata:
  name: reviews-route-canary
spec:
  scope:
    selector: // Specify the pods to which routing rules apply to implement a canary release.
        matchLabels:
            app: ratings
        matchExpressions:
        - {key: idc, operator: In, values: [shanghai01,shanghai02]}
        - {key: environment, operator: NotIn, values: [dev]}
    rollingUpdate:  // Configure a rolling release. You cannot set the selector and rollingUpdate parameters at the same time. 
        batchNum: 5    // The total number of batches in the rolling release. 
        batchOrder: 1  // The sequence number of the current batch in the rolling release. 
Scope configurations only specify the pods to which routing rules apply. To implement a canary release, you must associate scope configurations with virtual services. You can use annotations to associate scope configurations with virtual services.
annotations:
  istio.canary.scopeconfig: default/reviews-route-canary  // Identify the scope configuration that is associated with the virtual service. Describe the scope configuration in the format of namespace/name. 
  istio.canary.prod-config: reviews // Identify the pods to which the virtual service applies. 

Step 1: Increase the number of pods for the Productpage microservice

By default, the Productpage microservice runs in one pod. To verify the effect of a canary release that is implemented by applying routing rules to an increasing number of pods, you can create another pod for the Productpage microservice.

  1. Connect to a Kubernetes cluster by using kubectl. For more information see Connect to Kubernetes clusters by using kubectl.
  2. Run the following command to change the number of pods for the Productpage-v1 microservice:
    kubectl edit deployment  productpage-v1
  3. Change the value of the replicas parameter to 2 and save the change.

Step 2: Route all traffic to version v1 of the Reviews microservice

  1. Define an Istio gateway by creating a file that contains the following code. For more information, see Manage Istio gateways.
    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: bookinfo-gateway
    spec:
      selector:
        istio: ingressgateway # use istio default controller
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - "*"
  2. Define a virtual service by creating a file that contains the following code. For more information, see Manage virtual services.

    The virtual service defines that requests that contain productpage, static, login, logout, or api/v1/products can access the Productpage microservice.

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: bookinfo
    spec:
      hosts:
      - "*"
      gateways:
      - bookinfo-gateway
      http:
      - match:
        - uri:
            exact: /productpage
        - uri:
            prefix: /static
        - uri:
            exact: /login
        - uri:
            exact: /logout
        - uri:
            prefix: /api/v1/products
        route:
        - destination:
            host: productpage
            port:
              number: 9080
  3. Define a destination rule by creating a file that contains the following code. For more information, see Manage destination rules.
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: productpage
    spec:
      host: productpage
      subsets:
      - name: v1
        labels:
          version: v1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: reviews
    spec:
      host: reviews
      subsets:
      - name: v1
        labels:
          version: v1
      - name: v2
        labels:
          version: v2
      - name: v3
        labels:
          version: v3
  4. Define another virtual service by creating a file that contains the following code. For more information, see Manage virtual services.
    The virtual service defines that all traffic is routed to version v1 of the Reviews microservice.
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: productpage
    spec:
      hosts:
      - productpage
      http:
      - route:
        - destination:
            host: productpage
            subset: v1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - route:
        - destination:
            host: reviews
            subset: v1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: ratings
    spec:
      hosts:
      - ratings
      http:
      - route:
        - destination:
            host: ratings
            subset: v1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: details
    spec:
      hosts:
      - details
      http:
      - route:
        - destination:
            host: details
            subset: v1

Step 3: Route the traffic to pod 1 to version v2 of the Reviews microservice

  1. View the IP addresses of the pods where the Productpage-v1 microservice resides.
    1. Log on to the ACK console.
    2. In the left-side navigation pane of the ACK console, click Clusters.
    3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
    4. In the left-side navigation pane of the details page, choose Workloads > Deployments.
    5. On the Deployments page, click the name of the Productpage-v1 microservice.
    6. On the Pods tab, view the IP addresses of the pods where the Productpage-v1 microservice resides.
  2. Define a scope configuration by creating a file that contains the following code. For more information, see Manage scope configurations.
    The scope configuration defines that a virtual service applies only to pod 1.
    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ScopeConfig
    metadata:
      name: reviews-route-canary
    spec:
      scope:
        selector:
            matchExpressions:
            - {key: ip, operator: In, values: [<Pod IP1>]}
  3. Define a virtual service by creating a file that contains the following code. For more information, see Manage virtual services.
    The virtual service is associated with the scope configuration by using annotations. This enables the virtual service to apply only to pod 1.
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews-canary
      annotations:
        istio.canary.scopeconfig: default/reviews-route-canary // Identify the scope configuration that is associated with the virtual service. Describe the scope configuration in the format of namespace/name.
        istio.canary.prod-config: reviews // Identify the pods to which the virtual service applies.
    spec:
      hosts:
        - reviews
      http:
      - route:
        - destination:
            host: reviews
            subset: v2
  4. Verify whether the traffic to pod 1 is routed to version v2 of the Reviews microservice and whether the traffic to pod 2 is still routed to version v1 of the reviews microservice.
    1. Log on to the ACK console.
    2. In the left-side navigation pane of the ACK console, click Clusters.
    3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
    4. In the left-side navigation pane of the details page, choose Network > Services.
    5. At the top of the Services page, select istio-system from the Namespace drop-down list. Find the ingress gateway that is named istio-ingressgateway and view the IP address for port 80 in the External Endpoint column.
    6. In the address bar of a browser, enter http://<The IP address of the istio-ingressgateway ingress gateway>/productpage. Refresh the web page multiple times. No stars and black stars appear in turns in the Reviewer1 and Reviewer2 sections.

      If version v1 of the Reviews microservice is called, no stars appear. If version v2 of the Reviews microservice is called, black stars appear. No stars and black stars appear in turns, which indicates the traffic to pod 1 is routed to version v2 of the Reviews microservice, and the traffic to pod 2 is routed to version v1 of the reviews microservice.

      V2v1

Step 4: Route the traffic to pod 1 and pod 2 to version v2 of the Reviews microservice

  1. View the IP addresses of the pods where the Productpage-v1 microservice resides.
    1. Log on to the ACK console.
    2. In the left-side navigation pane of the ACK console, click Clusters.
    3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
    4. In the left-side navigation pane of the details page, choose Workloads > Deployments.
    5. On the Deployments page, click the name of the Productpage-v1 microservice.
    6. On the Pods tab, view the IP addresses of the pods where the Productpage-v1 microservice resides.
  2. Modify the scope configuration by replacing the content of its configuration file with the following code. For more information, see Manage scope configurations.
    The modified scope configuration defines that the virtual service applies to both pod 1 and pod 2.
    Note In Step 3, the virtual service has been associated with the scope configuration. Therefore, you do not need to modify the virtual service.
    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ScopeConfig
    metadata:
      name: reviews-route-canary
    spec:
      scope:
        selector:
            matchExpressions:
            - {key: ip, operator: In, values: [<Pod IP1>,<PodIp2>]}
  3. Verify whether the traffic to pod 1 and pod 2 is routed to version v2 of the Reviews microservice.
    1. Log on to the ACK console.
    2. In the left-side navigation pane of the ACK console, click Clusters.
    3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
    4. In the left-side navigation pane of the details page, choose Network > Services.
    5. At the top of the Services page, select istio-system from the Namespace drop-down list. Find the ingress gateway that is named istio-ingressgateway and view the IP address for port 80 in the External Endpoint column.
    6. In the address bar of a browser, enter http://<The IP address of the istio-ingressgateway ingress gateway>/productpage. Refresh the web page multiple times. Black stars appear in the Reviewer1 and Reviewer2 sections all the time.
      If version v1 of the Reviews microservice is called, no stars appear. If version v2 of the Reviews microservice is called, black stars appear. Black stars appear all the time, which indicates that both the traffic to pod 1 and pod 2 is routed to version v2 of the Reviews microservice. V2
  4. Optional:After you complete a canary release, we recommend you perform the following operations to prevent custom resources from being accumulated.
    1. Modify the virtual service by replacing the content of its configuration file with the following code. For more information, see Manage virtual services.
      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: reviews
      spec:
        hosts:
          - reviews
        http:
        - route:
          - destination:
              host: reviews
              subset: v2
    2. Delete the scope configuration that is named reviews-route-canary and the virtual service that is named reviews-canary. For more information, see Manage scope configurations and Manage virtual services.