content_image/814843.jpg
the consumers reach the updated version. When we are happy with the new version of our service and how it performed with a small sample of users, we replace all the old instances with the new version. Figure 3-4 shows a canary release in action. 

<img src='content_image/814843.jpg'>

In Kubernetes, this technique can be implemented by creating a new ReplicaSet for the new container version (preferably using a Deployment) with a small replica count that can be used as the Canary instance. At this stage, the Service should direct some of the consumers to the updated Pod instances. Once we are confident that every‐ thing with new ReplicaSet works as expected, we scale a new ReplicaSet up, and the old ReplicaSet down to zero. In a way, we are performing a controlled and user-tested incremental rollout. 

## Discussion 

The Deployment primitive is an example of where Kubernetes turns the tedious pro‐ cess of manually updating applications into a declarative activity that can be repeated and automated. The out-of-the-box deployment strategies (rolling and recreate) con‐ trol the replacement of old containers by new ones, and the release strategies (blue- green and canary) control how the new version becomes available to service consumers. The latter two release strategies are based on a human decision for the transition trigger and as a consequence are not fully automated but require human interaction. Figure 3-5 shows a summary of the deployment and release strategies, showing instance counts during transitions. 

