Rolling updates individually replace each container with the new version of an application. It  can achieve zero downtime because Kubernetes automatically load balances users only to  running replicas of the application.  Depending on the application requirements, it is also possible to instruct Kubernetes to probe  the application and ensure it is fully started before routing users to the new version. Such a  scenario can easily be achieved with Kubernetes readiness probes that allow developers to  specify sanity checks with which the cluster can identify when an application is ready for  servicing. Finally, after the new version is successfully rolled-out, Kubernetes stops and  remove the previous containers. The drawback of rolling updates is that it requires more computing resources during the  roll-out period. Because Kubernetes spins up the new version side by side with the older  running version, rolling updates can present a problem for resource-intensive containers. The benefits of such approach are zero downtime, reduced impact, and easy rollback  mechanisms if a need arises to return to the previous version. As with updating, the rollback  can also be done without any downtime. Blue/green  refers to the deployment of a new version of an application (green) that is run  simultaneously alongside its previous version (blue), in such a way that both versions coexist  within the cluster. The biggest difference from rolling updates is that no traffic is routed to the  new version.  The green deployment is then tested and, if the result is satisfactory, the traffic is routed to it  and no longer to the blue (old) application. If the deployment is unsuccessful or presents  problems, the new version of the application is shut down and the older application continues  to operate. If problems are discovered later, the switch to the green (new) version occurred,  and the rollback can be done by routing the traffic back to the blue (old) version. The drawback of such approach is that it causes a resource overhead because two  duplicated environments are running simultaneously. The main benefits of this approach include zero downtime and the possibility to perform tests  before routing users to the new updated version. By having two environments running  simultaneously, the rollback to the older version is quick and greatly simplified. Canaries are similar to blue/green deployments in nature. However, instead of routing all  users directly to the new version, the shift occurs gradually.  The basic idea behind canary deployments is to prevent a major business impact if the new  updates are not well-accepted or start presenting problems. Another benefit of canaries is the  possibility to extract metrics that are based on user feedback in such a way that developers  can monitor the interaction with the application from a small set of users to determine whether  the update was well-accepted. After the update is ready to be rolled-out to all users, all traffic  is routed to the new version. In Kubernetes, the roll-out of canary deployments is done in a controlled way. First, one  replica that includes the new application is deployed. After the developers are comfortable  with the change, these replicas are scaled up to match the same number of replicas as exist  on the old version. Finally, the old version is removed from the environment. Blue/green deployments Canary deployments Chapter 7. Securing IBM Cloud Private and Microservices on LinuxONE  215