11 Kubernetes Deployment Management

Kubernetes Deployment Management is the practice of using the Deployment object to declaratively control how a stateless application's Pods are created, updated, scaled, and rolled back, without requiring operators to manually orchestrate the underlying ReplicaSets or individual Pods involved in a release.

The Deployment Object

Desired State for Applications

A Deployment specifies a Pod template, a desired replica count, and an update strategy. The Deployment controller continuously reconciles this desired state against the cluster, creating and managing ReplicaSets to bring the actual number and version of running Pods in line with what was declared.

Ownership Chain

A Deployment owns one or more ReplicaSets, and each ReplicaSet owns a set of Pods. This layered ownership is what allows a Deployment to keep multiple ReplicaSets around temporarily during a rollout, and to retain old ones for rollback purposes.

Update Strategies

RollingUpdate

The default update strategy gradually replaces old Pods with new ones, controlled by two parameters: maxUnavailable, the maximum number of Pods that can be unavailable during the update, and maxSurge, the maximum number of extra Pods that can be created above the desired count during the transition.

Recreate

The Recreate strategy terminates all existing Pods before creating replacements, resulting in a period of downtime but guaranteeing that old and new versions never run simultaneously, which is sometimes required for applications that cannot tolerate mixed versions.

Rolling Out a Change

Triggering a Rollout

Any change to a Deployment's Pod template, such as updating the container image, environment variables, or resource limits, triggers a new rollout. Changes to fields outside the Pod template, such as the replica count alone, instead trigger scaling rather than a new rollout.

Monitoring Rollout Progress

A rollout's progress can be observed through the Deployment's status conditions, which report whether the rollout is progressing, has completed, or has stalled due to failing Pods, giving operators visibility into whether a release is succeeding before it fully replaces the previous version.

Rollbacks

Revision History

Deployments retain a history of previous ReplicaSets, each representing a prior revision of the Pod template, up to a configurable limit. This history allows an operator to revert to any retained prior revision.

Automatic Rollback Conditions

Some deployment strategies incorporate automated rollback triggers, reverting to the last known good revision if health checks or external validation signals indicate the new revision is unhealthy, reducing the time a faulty release remains live.

Scaling a Deployment

Manual Scaling

The replica count of a Deployment can be adjusted directly, causing the underlying ReplicaSet to create or terminate Pods to match the new count without triggering a rollout, since the Pod template itself has not changed.

Autoscaling Integration

A Deployment's replica count can also be managed automatically by a Horizontal Pod Autoscaler, which adjusts it based on observed metrics such as CPU utilization, removing the need for manual intervention as load fluctuates.

Deployment Rollout Diagram

This combination of controlled rollout strategies, revision history, and integration with autoscaling makes Deployments the primary mechanism for managing the lifecycle of stateless applications in Kubernetes.