Number of Pods that can be run temporarily in addition to the replicas specified during an update. In this example, it could be a total of four replicas at maxi‐ mum. Number of Pods that can be unavailable during the update. Here it could be that only two Pods are available at a time during the update. Readiness probes are very important for a rolling deployment to provide zero downtime—don’t forget them (see Chapter 4,  Health Probe ). RollingUpdate  strategy behavior ensures there is no downtime during the update process. Behind the scenes, the Deployment implementation performs similar moves by creating new ReplicaSets and replacing old containers with new ones. One enhancement here is that with Deployment, it is possible to control the rate of a new container rollout. The Deployment object allows you to control the range of available and excess Pods through  maxSurge  and  maxUnavailable  fields. Figure 3-1 shows the rolling update process. To trigger a declarative update, you have three options: See also the full example in our example repository, which demonstrates the usage of these commands, and shows you how you can monitor or roll back an upgrade with kubectl rollout . • Replace the whole Deployment with the new version’s Deployment with kubectl replace . • Patch ( kubectl patch ) or interactively edit ( kubectl edit ) the Deployment to set the new container image of the new version. • Use  kubectl set image  to set the new image in the Deployment. Figure 3-1. Rolling deployment 28  |  Chapter 3: Declarative Deployment