Deployments for Application Rollouts

A ReplicaSet in Kubernetes maintains a stable set of running Pods, guaranteeing their availability by ensuring a specified number of identical Pods are always active. Despite this capability, a ReplicaSet has a significant limitation: it lacks a built-in, automated mechanism for updating these Pods. When deploying a new application version, the process requires manual orchestration, such as creating a new ReplicaSet and carefully scaling down the old one. This manual approach is prone to error and introduces the risk of downtime.

To address this, Kubernetes provides a higher-level controller called a Deployment. A Deployment manages the entire lifecycle of your application, including its initial creation, updates, and scaling. It uses ReplicaSets as a building block to provide these advanced capabilities. You interact with the Deployment object, and the Deployment controller, in turn, manages the underlying ReplicaSets for you. This abstraction is the standard and recommended way to run stateless applications in Kubernetes.

The Deployment-ReplicaSet Relationship

The primary function of a Deployment is to provide declarative updates to Pods. Instead of managing ReplicaSets directly, you declare the desired state of your application in a Deployment manifest. This state includes details like the container image, the number of replicas, and the strategy for applying updates.

When you apply a change to your Deployment's Pod template, the Deployment controller initiates a rollout. Here is how it works:

1. The Deployment controller creates a new ReplicaSet with the updated Pod specification.
2. It begins to gradually scale up the new ReplicaSet, creating new Pods with the new application version.
3. Simultaneously, it scales down the old ReplicaSet, terminating the old Pods.
4. This process continues until all old Pods are replaced by new ones, and the application is fully updated.

This controlled process is called a rolling update, and it ensures that your application remains available throughout the update. The Deployment also keeps the old ReplicaSet around (scaled to zero replicas) so you can easily roll back to a previous version if the new version has issues.

This diagram shows a Deployment mid-rollout. The Deployment controller is scaling down the old ReplicaSet (running nginx:1.20.2) while scaling up the new ReplicaSet (nginx:1.21.6) to achieve the desired state of three running replicas of the new version.

Controlling the Rollout Strategy

Deployments offer fine-grained control over the update process. The default strategy is RollingUpdate, which minimizes downtime by updating Pods incrementally. You can tune its behavior using two important parameters in the Deployment specification:

• maxUnavailable: This specifies the maximum number of Pods that can be unavailable during the update process. It can be an absolute number (e.g., 1) or a percentage of desired replicas (e.g., 25%). A lower value ensures higher availability but may slow down the rollout.
• maxSurge: This defines the maximum number of Pods that can be created above the desired number of replicas. Like maxUnavailable, it can be an absolute number or a percentage. This allows the system to create new Pods before terminating old ones, which can speed up the update process.

For example, if you have a Deployment with 10 replicas and set maxUnavailable to 25% and maxSurge to 25%, Kubernetes will ensure that at least 7 Pods (10 - 2.5, rounded down) are always available. It will also ensure that the total number of Pods (old and new combined) does not exceed 12 (10 + 2.5, rounded up) at any point during the rollout.

The Recreate Strategy

Besides RollingUpdate, Deployments also support a simpler strategy called Recreate. When this strategy is used, the Deployment controller terminates all Pods from the old version before creating any Pods for the new version.

This approach will cause application downtime, as there will be a period where no Pods are running. While generally not suitable for production environments, the Recreate strategy can be useful in specific scenarios, such as:

• Development environments where brief downtime is acceptable.
• Applications that cannot tolerate running old and new versions simultaneously due to data schema migrations or other breaking changes.

By managing application lifecycles through declarative updates, Deployments provide the automation, resilience, and control needed for modern software delivery. They are a foundational component for implementing CI/CD pipelines and GitOps workflows on Kubernetes.