Traffic Distribution

At the end of this chapter you will be able to :

Providing custom name to deployment
Understanding advanced deployment techniques
Apply blue-green deployment pattern
Apply Canary Release Deployment pattern
Reduce the service visibility

As you learnt from previous chapter, Knative always routes traffic to the latest revision of the service. It is possible to split the traffic amongst the available revisions.

Deploy colors service

To explore the goals of this chapter, we will be using a colors service called blue-green-canary.

blue

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: blue-green-canary
spec:
  template:
    spec:
      containers:
        - image: quay.io/rhdevelopers/blue-green-canary
          env:
            - name: BLUE_GREEN_CANARY_COLOR
              value: "#6bbded"
            - name: BLUE_GREEN_CANARY_MESSAGE
              value: "Hello"

kn
kubectl

kn service create blue-green-canary \
   --image=quay.io/rhdevelopers/blue-green-canary \
   --env BLUE_GREEN_CANARY_COLOR="#6bbded" \
   --env BLUE_GREEN_CANARY_MESSAGE="Hello"

kubectl apply -f $TUTORIAL_HOME/serving/colors-service-blue.yaml

Invoke the Service

Get the service URL,

kn service describe blue-green-canary -o url

Use the URL to open the service in a browser window.If the service was deployed correctly you should see blue background browser page, with greeting as Hello.

Figure 1. Blue Green Canary::Blue

Deploy a New Revision of a Service

Twelve-factor app

12factor.net defines the twelve-factor app as a methodology for building software-as-a-service apps that:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
And can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

In line with 12-Factor principle, Knative rolls out new deployment whenever the Service Configuration changes, and creates immutable version of code and configuration called revision. An example of configuration change could for e.g. an update of Service image, a change to environment variables or add liveness/readiness probes.

Let us now change the configuration of the service by updating the service environment variable BLUE_GREEN_CANARY_COLOR to make the browser display green color with greeting text as Namaste.

green

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: blue-green-canary
spec:
  template:
    spec:
      containers:
        - image: quay.io/rhdevelopers/blue-green-canary
          env:
            - name: BLUE_GREEN_CANARY_COLOR
              value: "#5bbf45"
            - name: BLUE_GREEN_CANARY_MESSAGE
              value: "Namaste"

kn
kubectl

kn service update blue-green-canary \
   --image=quay.io/rhdevelopers/blue-green-canary \
   --env BLUE_GREEN_CANARY_COLOR="#5bbf45" \
   --env BLUE_GREEN_CANARY_MESSAGE="Namaste"

kubectl apply -f $TUTORIAL_HOME/serving/colors-service-green.yaml

Now invoking the service again using the service URL, will show a green color browser page with greeting Namaste.

Figure 2. Blue Green Canary::Green

revisions

Check to ensure you have two revisions of the blue-green-canary service:

kn
kubectl

kn revision list

NAME                        SERVICE             TRAFFIC   TAGS   GENERATION   AGE     CONDITIONS   READY   REASON
blue-green-canary-00002   blue-green-canary   100%             2            2m33s   3 OK / 4     True
blue-green-canary-00001   blue-green-canary                    1            30m     3 OK / 4     True

kubectl get rev \
  --selector=serving.knative.dev/service=blue-green-canary \
  --sort-by="{.metadata.creationTimestamp}"

NAME                        CONFIG NAME         K8S SERVICE NAME            GENERATION   READY   REASON
blue-green-canary-00001   blue-green-canary   blue-green-canary-00001   1            True
blue-green-canary-00002   blue-green-canary   blue-green-canary-00002   2            True

Tag Revisions

As you had observed that the Knative service blue-green-canary now has two revisions namely blue-green-canary-00001 and blue-green-canary-00002. As the Revision names are autogenerated it is hard to comprehend to which code/configuration set it corresponds to. To overcome this problem Knative provides tagging of revision names that allows one to tag a revision name to a logical human understanable names called tags.

As our colors service shows different colors on the browser let us tag the revisions with color,

List the existing revisions,

kn revision list -s blue-green-canary

NAME                        SERVICE             TRAFFIC   TAGS   GENERATION   AGE   CONDITIONS   READY   REASON
blue-green-canary-00002   blue-green-canary   100%             2            23m   3 OK / 4     True
blue-green-canary-00001   blue-green-canary                    1            51m   3 OK / 4     True

When Knative rolls out a new revision, it increments the GENERATION by 1 and then routes 100% of the TRAFFIC to it, hence we can use the GENERATION or TRAFFIC to identify the latest reivsion.

Tag Blue

Let us tag blue-green-canary-00001 which shows blue browser page with tag name blue.

kn service update blue-green-canary --tag=blue-green-canary-00001=blue

Updating Service 'blue-green-canary' in namespace 'knativetutorial':

  0.037s The Route is still working to reflect the latest desired specification.
  0.126s Ingress has not yet been reconciled.
  0.162s Waiting for load balancer to be ready
  0.303s Ready to serve.

Service 'blue-green-canary' with latest revision 'blue-green-canary-00002' (unchanged) is available at URL:
http://blue-green-canary.knativetutorial.192.168.64.13.nip.io

Tag Green

Let us tag blue-green-canary-00002 which shows green browser page with tag name green.

kn service update blue-green-canary --tag=blue-green-canary-00002=green

Updating Service 'blue-green-canary' in namespace 'knativetutorial':

  0.037s The Route is still working to reflect the latest desired specification.
  0.126s Ingress has not yet been reconciled.
  0.162s Waiting for load balancer to be ready
  0.303s Ready to serve.

Service 'blue-green-canary' with latest revision 'blue-green-canary-00002' (unchanged) is available at URL:
http://blue-green-canary.knativetutorial.192.168.64.13.nip.io

Tag Latest

Lets tag whatever revision that is latest to be tagged as latest.

kn service update blue-green-canary --tag=@latest=latest

Updating Service 'blue-green-canary' in namespace 'knativetutorial':

  0.037s The Route is still working to reflect the latest desired specification.
  0.126s Ingress has not yet been reconciled.
  0.162s Waiting for load balancer to be ready
  0.303s Ready to serve.

Service 'blue-green-canary' with latest revision 'blue-green-canary-00002' (unchanged) is available at URL:
http://blue-green-canary.knativetutorial.192.168.64.13.nip.io

Let us query the Service Revisions again,

kn revision list -s blue-green-canary

NAME                        SERVICE             TRAFFIC   TAGS    GENERATION   AGE   CONDITIONS   READY   REASON
blue-green-canary-00002   blue-green-canary   100%      latest,green   2            29m   3 OK / 4     True
blue-green-canary-00001   blue-green-canary             blue    1            57m   3 OK / 4     True

As green happend to be latest revision it has been tagged with name lastest in addition to green.

Let us use the tag names for easier identification of the revision and perform traffic distribution amongst them.

Applying Blue-Green Deployment Pattern

Knative offers a simple way of switching 100% of the traffic from one Knative service revision (blue) to another newly rolled out revision (green). If the new revision (e.g. green) has erroneous behavior then it is easy to rollback the change.

In this exercise you will applying the Blue/Green deployment pattern with the Knative Service called greeter. You have already deployed two revisions of blue-green-canary identified using the tags blue and green.

With the deployment of green revison you noticed that Knative automatically started to routing 100% of the traffic to blue-green-canary-00002.

Now let us assume, due to a critical bug we need to roll back green to blue.

The following Knative Service YAML is identical to the previously deployed green except that we have added the traffic section to indicate that 100% of the traffic should be routed to blue.

Before you rollback the revision, refresh the browser window where you have opened the blue-green-canary service, to make sure it is still showing green browser page with greeting Namaste.

Now apply the update Knative service configuration using the command as shown in following listing:

Rollback to blue

Route all the traffic of service blue-green-canary to blue revision of the service:

kn service update blue-green-canary --traffic blue=100,green=0,latest=0

We use the tag names to identify the revisions

Let us list all revisions with tags:

kn revision list

Based on the revision tags that we created earlier, the output should be like:

NAME                        SERVICE             TRAFFIC   TAGS           GENERATION   AGE   CONDITIONS   READY   REASON
blue-green-canary-00002   blue-green-canary             latest,green   2            56m   4 OK / 4     True
blue-green-canary-00001   blue-green-canary   100%      blue           1            83m   4 OK / 4     True

Let us list the available sub-routes:

kubectl -n knativetutorial get ksvc blue-green-canary -oyaml \
 | yq r - 'status.traffic[].url'

The above command should return you three sub-routes for the main greeter route:

http://latest-blue-green-canary.knativetutorial.192.168.64.13.nip.io (1)
http://blue-blue-green-canary.knativetutorial.192.168.64.13.nip.io (2)
http://green-blue-green-canary.knativetutorial.192.168.64.13.nip.io  (3)

1	the sub route for the traffic tag `latest`
2	the sub route for the traffic tag `blue`
3	the sub route for the traffic tag `green`

You will notice that the command does not create any new configuration/revision/deployment as there was no application update (e.g. image tag, env var, etc), but when you call the service, Knative scales up the blue that shows blue browser page with greeting Hello.

Figure 3. Blue Green Canary::Blue

kubectl get pods

NAME                                     READY   STATUS        RESTARTS   AGE
blue-green-canary-00001-deployment-54597d94b9-25x4r   2/2     Running       0          12s
blue-green-canary-00002-deployment-6cb545df65-ktqc2   0/2     Terminating   0          2m

Since blue is the active revision now, the existing green pod is getting terminated as no future requests will be served by it.

As an exercise, flip all the traffic back to green using kn command.

Applying Canary Release Pattern

A Canary release is more effective when you want to reduce the risk of introducing new feature. It allows you a more effective feature-feedback loop before rolling out the change to your entire user base.

Knative allows you to split the traffic between revisions in increments as small as 1%.

To see this in action, apply the following Knative service definition that will split the traffic 80% to 20% between blue and green.

To roll out the greeter canary deployment use the following command:

Create greeter canary Deployment

kn service update blue-green-canary \
  --traffic="blue=80" \
  --traffic="green=20"

As in the previous section on Applying Blue-Green Deployment Pattern deployments, the command will not create any new configuration/revision/deployment. To observe the traffic distribution, open the Service Route URL in your browser window.

You will notice the browser alternating betwee green and blue color, with majority of the time staying with blue.

You should also notice that two pods are running representing both blue and green:

watch "kubectl get pods -n knativetutorial"

NAME                                                    READY   STATUS    RESTARTS   AGE
blue-green-canary-00001-deployment-54597d94b9-q8c57   2/2     Running   0          79s
blue-green-canary-00002-deployment-8564bf5b5b-gtvh4   2/2     Running   0          14s

As a challenge:

Deploy a new revision called "yellow" which will show Yellow Color browser page (Hex for yellow is #f2f25e) and a greeting text Bonjour.
Create the tag called yellow, mapping to yellow revision of the service.
Update the traffic distribution to be 70% to blue, 20% to green and 10% to yellow.

Cleanup

kn service delete blue-green-canary