Progressive Rollout with Istio

    The application deployment model in KubeVela is designed and implemented with extreme level of extensibility at heart. Hence, KubeVela can be easily integrated with any existing tools to superpower your application delivery with modern technologies such as Service Mesh immediately, without writing dirty glue code/scripts.

    This guide will introduce how to use KubeVela and Istio to do an advanced canary release process. In this process, KubeVela will help you to:

    • ship Istio capabilities to end users without asking them to become an Istio expert (i.e. KubeVela will provide you a rollout trait as abstraction);
    • design canary release steps and do rollout/rollback in a declarative workflow, instead managing the whole process manually or with ugly scripts.

    We will use the well-known application as the sample.

    If your cluster haven’t installed Istio. Install the Istio cluster plugin.

    Otherwise, you just need apply these 4 YAML files under this path

    The default namespace needs to be labeled so that Istio will auto-inject sidecar.

    Deploy the Application of bookinfo:

    1. kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/first-deploy.yaml

    The component architecture and relationship of the application are as follows:

    This Application has four Components, productpage, ratings, details components configured with anexpose Trait to expose cluster-level service.

    The productpage component is also configured with an istio-gateway Trait, allowing the Component to receive traffic coming from outside the cluster. The example below show that it sets gateway:ingressgateway to use Istio’s default gateway, and hosts: "*" to specify that any request can enter the gateway.

    You can port-forward to the gateway as follows:

    1. kubectl port-forward service/istio-ingressgateway -n istio-system 19082:80

    Visit through the browser and you will see the following page.

    pic-v2

    Next, we take the reviews Component as an example to simulate the complete process of a canary release, and first upgrade a part of the component instances, and adjust the traffic at the same time, so as to achieve the purpose of progressive canary release.

    Execute the following command to update the application.

    1. kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/rollout-v2.yaml

    This operation updates the mirror of the reviews Component from the previous v2 to v3. At the same time, the Rollout Trait of the reviews Component specifies that the number of target instances to be upgraded is two, which are upgraded in two batches, with one instance in each batch.

    In addition, a canary-traffic Trait has been added to the Component.

    This update also adds an upgraded execution Workflow to the Application, which contains three steps.

    The first step is to upgrade only the first batch of instances by specifying batchPartition equal to 0. And use to switch 10% of the traffic to the new version of the instance.

    The third step of the Workflow is to complete the upgrade of the remaining instances and switch all traffic to the new component version.

    1. ...
    2.   workflow:
    3.     steps:
    4.       - name: rollout-1st-batch
    5.         properties:
    6.           # just upgrade first batch of component
    7.           batchPartition: 0
    8.           traffic:
    9.             weightedTargets:
    10.               - revision: reviews-v1
    11.                 weight: 90 # 90% shift to new version
    12.               - revision: reviews-v2
    13.                 weight: 10 # 10% shift to new version
    16.       # give user time to verify part of traffic shifting to newRevision
    18.         type: suspend
    21.         type: canary-rollout
    22.         properties:
    23.           # upgrade all batches of component
    24.           batchPartition: 1
    25.           traffic:
    26.             weightedTargets:
    27.               - revision: reviews-v2
    28.                 weight: 100 # 100% shift to new version
    29. ...

    After the update is complete, visit the previous URL multiple times in the browser. There is about 10% probability that you will see the new page below,

    It can be seen that the new version of the page has changed from the previous black five-pointed star to a red five-pointed star.

    If the service is found to meet expectations during manual verification, the Workflow needs to be continued to complete the full release. You can do that by executing the following command.

    1. vela workflow resume book-info

    If you continue to verify the webpage several times on the browser, you will find that the five-pointed star will always be red.

    Rollback to The Old Version

    During the manual verification, if the service does not meet the expectations, you can terminate the pre-defined release workflow and rollback the instances and the traffic to the previous version.

    This is basically updates the workflow to rollback step:

    1.   ...
    2.   workflow:
    3.     steps:
    5.         type: canary-rollback

    Under the hood, it changes:

    • the Rollout spec to target to the old version, which rolls replicas of new versions to the old version and keeps replicas of old version as is.
    • the DestinationRule spec to update the subsets to only the old version.

    You see?! All the complexity of the work is kept away from users and provided in a simple step!