10.5 Kubernetes Deployment Controller

Kubernetes Deployment Controller is the workload controller responsible for managing stateless, replicated applications through declarative updates, coordinating the creation and lifecycle of underlying ReplicaSets to achieve rolling updates, version rollbacks, and scaling without requiring users to manually manage the transition between different versions of an application's Pod template.

Relationship to ReplicaSets

Deployments Do Not Manage Pods Directly

A Deployment never creates or manages Pods directly; instead, it creates and manages one or more ReplicaSets, delegating the actual Pod-level reconciliation to those ReplicaSets, while the Deployment itself focuses on orchestrating transitions between different ReplicaSet versions as the Pod template changes over time.

One Active ReplicaSet at Steady State

At any point when no update is in progress, a Deployment typically has exactly one ReplicaSet scaled to its full desired replica count, representing the currently active version of the application, with any previous ReplicaSets retained but scaled down to zero replicas for potential rollback purposes.

Rolling Update Mechanics

Creating a New ReplicaSet on Template Change

When a Deployment's Pod template is modified, the Deployment controller creates a new ReplicaSet reflecting the updated template and begins gradually increasing its replica count while simultaneously decreasing the replica count of the ReplicaSet representing the previous version, according to the configured update strategy.

maxSurge and maxUnavailable

The maxSurge field controls how many Pods above the desired replica count can exist temporarily during an update, while maxUnavailable controls how many Pods below the desired count are tolerated, together shaping whether the rollout prioritizes maintaining full capacity, minimizing resource overhead, or some balance between the two.

Rollback Capability

Revision History Retention

The Deployment controller retains a configurable number of previous ReplicaSets as revision history, each corresponding to a prior version of the Pod template, allowing a rollback operation to scale a previous ReplicaSet back up and the current one back down, effectively reversing an unwanted or problematic update.

Rollback as a Reapplication of a Prior Template

A rollback is not a special separate mechanism but rather the same rolling update process applied in reverse, treating the target revision's template as the new desired template and letting the ordinary rolling update logic transition the Deployment back to that previous state.

Scaling Behavior

Direct Replica Count Adjustment

Scaling a Deployment by changing its replicas field is propagated directly to its currently active ReplicaSet, which then handles the actual creation or deletion of Pods to match the new count, without triggering the creation of any new ReplicaSet, since the Pod template itself remains unchanged during a pure scaling operation.

Interaction With Ongoing Rollouts

If a scaling operation occurs while a rollout is already in progress, the Deployment controller adjusts the replica counts of both the old and new ReplicaSets proportionally, ensuring the rollout continues to progress correctly toward the updated template while still respecting the newly requested total replica count.

Pause and Resume Functionality

Halting Rollout Progression

A Deployment can be paused, which halts any further reconciliation of its rollout progress, allowing multiple changes to the Pod template to be batched together before resuming, at which point a single rollout incorporating all the accumulated changes proceeds rather than triggering a separate rollout for each individual change.

Status Reporting

Conditions Reflecting Rollout Progress

The Deployment controller reports status through conditions such as Progressing, Available, and ReplicaFailure, giving visibility into whether a rollout is actively advancing, whether the Deployment currently has the minimum available replicas required, or whether Pod creation is failing for some underlying reason, all without requiring direct inspection of the individual ReplicaSets involved.