CHAPTER 3 Declarative Deployment Problem Solution The heart of the  Declarative Deployment  pattern is Kubernetes’ Deployment resource. This abstraction encapsulates the upgrade and rollback processes of a group of con‐ tainers and makes its execution a repeatable and automated activity. We can provision isolated environments as namespaces in a self-service manner and have the services placed in these environments with minimal human intervention through the scheduler. But with a growing number of microservices, continually updating and replacing them with newer versions becomes an increasing burden too. Upgrading a service to a next version involves activities such as starting the new ver‐ sion of the Pod, stopping the old version of a Pod gracefully, waiting and verifying that it has launched successfully, and sometimes rolling it all back to the previous ver‐ sion in the case of failure. These activities are performed either by allowing some downtime but no running concurrent service versions, or with no downtime, but increased resource usage due to both versions of the service running during the update process. Performing these steps manually can lead to human errors, and scripting properly can require a significant amount of effort, both of which quickly turn the release process into a bottleneck. Luckily, Kubernetes has automated this activity as well. Using the concept of  Deploy‐ ment , we can describe how our application should be updated, using different strate‐ gies, and tuning the various aspects of the update process. If you consider that you do multiple Deployments for every microservice instance per release cycle (which, 25