Reroute traffic using blue-green strategy - Serving | Serverless

Routing and managing traffic by using a blue-green deployment strategy

You can safely reroute traffic from a production version of an app to a new version, by using a blue-green deployment strategy.

Routing and managing traffic by using a blue-green deployment strategy

Prerequisites

The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
Install the OpenShift CLI (oc).

Procedure

Create and deploy an app as a Knative service.

Find the name of the first revision that was created when you deployed the service, by viewing the output from the following command:

$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

Example command

$ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

Example output

$ example-service-00001

Add the following YAML to the service spec to send inbound traffic to the revision:

...
spec:
  traffic:
    - revisionName: <first_revision_name>
      percent: 100 # All traffic goes to this revision
...

Verify that you can view your app at the URL output you get from running the following command:
```
$ oc get ksvc <service_name>
```
Deploy a second revision of your app by modifying at least one field in the template spec of the service and redeploying it. For example, you can modify the image of the service, or an env environment variable. You can redeploy the service by applying the service YAML file, or by using the kn service update command if you have installed the Knative (kn) CLI.
Find the name of the second, latest revision that was created when you redeployed the service, by running the command:
```
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
```
At this point, both the first and second revisions of the service are deployed and running.
Update your existing service to create a new, test endpoint for the second revision, while still sending all other traffic to the first revision:
Example of updated service spec with test endpoint
```
...
spec:
  traffic:
    - revisionName: <first_revision_name>
      percent: 100 # All traffic is still being routed to the first revision
    - revisionName: <second_revision_name>
      percent: 0 # No traffic is routed to the second revision
      tag: v2 # A named route
...
```
After you redeploy this service by reapplying the YAML resource, the second revision of the app is now staged. No traffic is routed to the second revision at the main URL, and Knative creates a new service named v2 for testing the newly deployed revision.
Get the URL of the new service for the second revision, by running the following command:
```
$ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"
```
You can use this URL to validate that the new version of the app is behaving as expected before you route any traffic to it.

Update your existing service again, so that 50% of traffic is sent to the first revision, and 50% is sent to the second revision:

Example of updated service spec splitting traffic 50/50 between revisions

...
spec:
  traffic:
    - revisionName: <first_revision_name>
      percent: 50
    - revisionName: <second_revision_name>
      percent: 50
      tag: v2
...

When you are ready to route all traffic to the new version of the app, update the service again to send 100% of traffic to the second revision:
Example of updated service spec sending all traffic to the second revision
```
...
spec:
  traffic:
    - revisionName: <first_revision_name>
      percent: 0
    - revisionName: <second_revision_name>
      percent: 100
      tag: v2
...
```
You can remove the first revision instead of setting it to 0% of traffic if you do not plan to roll back the revision. Non-routeable revision objects are then garbage-collected.
Visit the URL of the first revision to verify that no more traffic is being sent to the old version of the app.

Rerouting traffic using blue-green strategy

Routing and managing traffic by using a blue-green deployment strategy