Routing and managing traffic with blue/green deployment

This sample demonstrates updating an application to a new version using a
blue/green traffic routing pattern. With Knative, you can safely reroute traffic
from a live version of an application to a new version by changing the routing
configuration.

Deploying Revision 1 (Blue)

We’ll be deploying an image of a sample application that displays the text “App
v1” on a blue background.

First, create a new file called blue-green-demo.yaml and copy this into
it:

apiVersion:serving.knative.dev/v1alpha1kind:Servicemetadata:name:demonamespace:defaultspec:template:metadata:name:demo-bluespec:containers:-image:gcr.io/knative-samples/knative-route-demo:blue# The URL to the sample app docker imageenv:-name:T_VERSIONvalue:"blue"

Note: If you don’t have a custom domain configured for use with Knative, you
can interact with your app using cURL requests if you have the host URL and IP
address:
curl -H "Host: demo.default.example.com" http://IP_ADDRESS
Knative creates the host URL by combining the name of your Route object, the
namespace, and example.com, if you haven’t configured a custom domain. For
example, [route-name].[namespace].example.com. You can get the IP address by
entering kubectl get svc istio-ingressgateway --namespace istio-system (or
kubectl get svc istio-ingressgateway --namespace istio-system if using
Knative 0.2.x or prior versions) and copying the EXTERNAL-IP returned by
that command. See
Interacting with your app
for more information.

Deploying Revision 2 (Green)

Revision 2 of the sample application will display the text “App v2” on a green
background. To create the new revision, we’ll edit our existing service in
blue-green-demo.yaml with an updated image, environment variable and a traffic section:

apiVersion:serving.knative.dev/v1alpha1kind:Servicemetadata:name:demonamespace:defaultspec:template:metadata:name:demo-greenspec:containers:-image:gcr.io/knative-samples/knative-route-demo:green# The URL to the sample app docker imageenv:-name:T_VERSIONvalue:"green"traffic:-tag:currentrevisionName:demo-bluepercent:100-tag:candidaterevisionName:demo-greenpercent:0-tag:latestlatestRevision:truepercent:0

This allows you to validate that the new version of the app is behaving as
expected before switching any traffic over to it.

Migrating traffic to the new revision

We’ll once again update our existing service to begin shifting traffic away from
the first revision and toward the second. Edit blue-green-demo.yaml:

apiVersion:serving.knative.dev/v1alpha1kind:Servicemetadata:name:demonamespace:defaultspec:template:metadata:name:demo-greenspec:containers:-image:gcr.io/knative-samples/knative-route-demo:green# The URL to the sample app docker imageenv:-name:T_VERSIONvalue:"green"traffic:-tag:currentrevisionName:demo-bluepercent:50-tag:candidaterevisionName:demo-greenpercent:50-tag:latestlatestRevision:truepercent:0

Note: This sample shows a 50⁄50 split to assure you don’t have to refresh too
much, but it’s recommended to start with 1-2% of traffic in a production
environment

Rerouting all traffic to the new version

Lastly, we’ll update our existing service to finally shift all traffic to the
second revision. Edit blue-green-demo.yaml:

apiVersion:serving.knative.dev/v1alpha1kind:Servicemetadata:name:demonamespace:defaultspec:template:metadata:name:demo-greenspec:containers:-image:gcr.io/knative-samples/knative-route-demo:green# The URL to the sample app docker imageenv:-name:T_VERSIONvalue:"green"traffic:-tag:previousrevisionName:demo-bluepercent:0-tag:currentrevisionName:demo-greenpercent:100-tag:latestlatestRevision:truepercent:0

With all inbound traffic being directed to the second revision of the
application, Knative will soon scale the first revision down to 0 running pods
and the blue/green deployment can be considered complete. Using the named previous
route (http://previous-demo.default.YOUR_CUSTOM_DOMAIN.com) will reactivate a pod
to serve any occasional requests intended specifically for the initial revision.