depending on the team and project, can span from minutes to several months), this is another effort-saving automation by Kubernetes. In Chapter 2, we have seen that, to do its job effectively, the scheduler requires suffi‐ cient resources on the host system, appropriate placement policies, and containers with adequately defined resource profiles. Similarly, for a Deployment to do its job correctly, it expects the containers to be good cloud-native citizens. At the very core of a Deployment is the ability to start and stop a set of Pods predictably. For this to work as expected, the containers themselves usually listen and honor lifecycle events (such as SIGTERM; see Chapter 5,  Managed Lifecycle ) and also provide health-check endpoints as described in Chapter 4,  Health Probe , which indicate whether they started successfully. If a container covers these two areas accurately, the platform can cleanly shut down old containers and replace them by starting updated instances. Then all the remain‐ ing aspects of an update process can be defined in a declarative way and executed as one atomic action with predefined steps and an expected outcome. Let’s see the options for a container update behavior. Kubernetes has supported rolling updates since its very beginning. The first imple‐ mentation was  imperative  in nature; the client  kubectl  tells the server what to do for each update step. Although the  kubectl rolling-update  command is still present, it’s highly depre‐ cated because of the following drawbacks of such an imperative approach: 26  |  Chapter 3: Declarative Deployment • The only way to find out what we have deployed is by checking the condition of the system. Sometimes the state of the current system might not be the desired state, in which case we have to correlate it with the deployment documentation. • The update process has to be documented and kept up-to-date while the service evolves. • Somebody else may override your changes with time. • You may need more than one command to get the system into the desired state. These commands must be automated and repeatable in different environments. • The whole orchestration logic for replacing the containers and the Replication‐ Controllers is performed by  kubectl , which monitors and interacts with the API Server behind the scenes while the update process happens, moving an inherent server-side responsibility to the client. • Rather than describing the desired end state,  kubectl rolling-update  issues commands to get the system into the desired state. Imperative Rolling Updates with kubectl Are Deprecated