Deployment Theory
Explore how Kubernetes Deployments effectively manage stateless applications by enabling scaling, self-healing, rolling updates, and rollbacks. Understand how Deployments work with Pods and controllers to maintain application resilience and handle updates seamlessly.
We'll cover the following...
Introduction to Deployments
Deployments are the most popular way of running stateless apps on Kubernetes. They add self-healing, scaling, rollouts, and rollbacks.
Consider a quick example.
Assume we have a requirement for a web app that needs to be resilient, scale on demand, and be frequently updated. We write the app, containerize it, and define it in a Pod YAML so it can run on Kubernetes. We then wrap the Pod inside a Deployment and post it to Kubernetes, where the Deployment controller deploys the Pod. At this point, our cluster is running a single Deployment managing a single Pod.
If the Pod fails, the Deployment controller replaces it with a new one. If demand increases, the Deployment controller can deploy more identical Pods. When we update the app, the Deployment controller deletes the old Pods and replaces them with new ones.
Assume the app has another stateless microservice, such as a shopping cart. We’d containerize this, wrap it in its own Pod, wrap the Pod in its own Deployment, and deploy it to the cluster.
At this point, we’d have two Deployments managing two different microservices.
The following figure shows this setup with the Deployment controller watching and managing both Deployments. The web Deployment manages four identical web server Pods, and the cart Deployment manages two identical shopping cart Pods.
Under the hood, Deployments follow standard Kubernetes architecture comprising of:
A resource
A controller
At the highest level, resources define objects and controllers manage them.
The Deployment resource exists in the apps/v1 API and defines all supported attributes and capabilities. The Deployment controller runs on the control plane, watches Deployments, and reconciles the observed state with the desired state.
Deployments and Pods
Every Deployment manages one or more identical Pods.
For example, an application comprising a web service and a shopping cart service will need two Deployments — one for managing the web Pods and the other for managing the shopping cart Pods. Figure 6.1 showed the web Deployment managing four identical web Pods and the cart Deployment managing two identical shopping cart Pods.
The following figure shows a Deployment YAML file requesting four replicas of a single Pod. If we increase the replica count to six, it will deploy and manage two additional identical Pods.
Notice how the Pod spec is defined in a template embedded in the Deployment YAML.