The Deployment resource is Kubernetes’ primary mechanism for managing application releases. It transforms the operational complexity of rolling updates, health monitoring, and rollbacks into a declarative configuration that can be version-controlled and automated.
Core Responsibility
Release Orchestration - While Pods represent running instances and ReplicaSets maintain replica counts, Deployments orchestrate transitions between versions. They create new ReplicaSets for updated configurations while gracefully draining traffic from old versions.
Version History - Deployments maintain a history of ReplicaSet revisions, enabling rollback to previous configurations. Each change to the Pod template (new image, updated environment variables) creates a new ReplicaSet while preserving old ones for potential rollback.
Update Automation - Deployments automate the careful sequencing required for safe releases: creating new instances, waiting for health checks, updating load balancers, and terminating old instances. This operational knowledge is encoded into reusable configuration.
Relationship to Primitives
Deployments compose several distributed primitives:
Pods - Deployments don’t manage Pods directly; they manage ReplicaSets which manage Pods.
ReplicaSets - Ensure a specified number of identical Pods are running. Deployments create a new ReplicaSet for each configuration version, gradually scaling the new one up while scaling the old one down.
Services - Services automatically route traffic to healthy instances based on label selectors, enabling zero-downtime updates.
Deployment Strategies
Kubernetes provides two fundamental strategies for transitioning between versions:
RollingUpdate (default) - Rolling deployment gradually replaces old Pods with new ones, maintaining application availability throughout the update. Control parameters manage the rate of change and temporary resource overhead.
Recreate - Fixed deployment terminates all old Pods before starting new ones. This simpler strategy accepts downtime in exchange for guaranteed version isolation and simpler resource requirements.
The choice between strategies depends on application requirements: can the application tolerate different versions running simultaneously? Is temporary downtime acceptable? Do you have capacity for extra replicas during updates?
Rollout Management
The kubectl rollout command family provides server-side deployment control:
# Monitor deployment progress
kubectl rollout status deployment/myapp
# Pause to apply multiple changes
kubectl rollout pause deployment/myapp
kubectl set image deployment/myapp app=myapp:v2
kubectl set env deployment/myapp DATABASE_URL=newurl
kubectl rollout resume deployment/myapp
# Rollback to previous revision
kubectl rollout undo deployment/myapp
# View revision history
kubectl rollout history deployment/myapp
# Restart with current config
kubectl rollout restart deployment/myappThis server-side management enables declarative deployment workflows where you describe desired state and let Kubernetes handle the transition.
Configuration Parameters
replicas - Desired number of Pod instances. The Deployment ensures this count is maintained, replacing failed Pods automatically.
selector - Label selector identifying which Pods this Deployment manages. Must match the labels in the Pod template.
template - Pod specification defining containers, volumes, resource requirements, and other Pod characteristics. Changes to the template trigger rollouts.
strategy - Either RollingUpdate or Recreate, with strategy-specific parameters:
- RollingUpdate: maxSurge, maxUnavailable, minReadySeconds
- Recreate: no additional parameters
revisionHistoryLimit - Number of old ReplicaSets to retain for rollback. Defaults to 10.
Health Integration
Deployments depend on Pod health checks to make safe rollout decisions:
Readiness Probes - Determine when a new Pod is ready to receive traffic. Deployments wait for readiness before considering a Pod available and continuing the rollout.
Liveness Probes - Detect unhealthy Pods that should be restarted. During rollouts, consistent liveness failures trigger rollback logic.
minReadySeconds - How long a Pod must be ready before being considered available. Prevents premature progression when applications have delayed failures.
These health checks connect to broader cloud native architecture requirements - applications must provide programmatic health endpoints for automated operations.
Advanced Patterns
While Deployments provide solid building blocks, more sophisticated patterns often require external tooling:
Blue-Green Deployment - Maintains two complete environments, switching traffic instantly via Service selector changes.
Canary Deployment - Tests new versions with a subset of traffic before full rollout, reducing risk through gradual exposure.
Tools like Flagger, Argo Rollouts, and Knative build on Deployments to provide progressive delivery, automatic rollback based on metrics, and traffic splitting capabilities.
Resource Context
Deployments exist within Namespaces and are subject to resource quotas. The resource requirements of all Pods (both old and new during rollouts) must fit within namespace limits.
Resource profiles affect deployment behavior - rollouts may stall if insufficient resources are available for new Pods, and aggressive maxSurge settings can exceed cluster capacity.