Kubernetes Deployments and ReplicaSets: Practical Guide

Kubernetes deployments are the standard mechanism for deploying and managing containerized applications in production. A Deployment creates and supervises ReplicaSets, which in turn manage Pods. This hierarchy ensures availability, scaling, and updates without service interruption.

TL;DR: A Deployment defines the desired state of your application (image, replicas, resources). The ReplicaSet maintains the specified number of Pods. Kubernetes automatically reconciles the actual state with the declared state. This guide covers creating, scaling, rolling updates, and rollback of Kubernetes deployments.

To discover these concepts, the Kubernetes Fundamentals training (1 day) gives you the essential basics.

What Is a Kubernetes Deployment?

A Deployment is a Kubernetes object that declares the desired state of an application. It answers three questions: what image to run, how many replicas to maintain, and how to update.

Deployments embody the Kubernetes philosophy by abstracting Pod management complexity.

Essential characteristics:

Remember: never create isolated Pods in production. Always use a Deployment that ensures their availability.

With 82% of container users on Kubernetes, Deployments represent the dominant deployment pattern.

How Do Kubernetes Deployments Manage ReplicaSets?

A ReplicaSet is a controller that maintains a stable number of identical Pods. The Deployment automatically creates and manages ReplicaSets.

Here's the hierarchy:

Deployment
└── ReplicaSet (current version)
├── Pod 1
├── Pod 2
└── Pod 3
└── ReplicaSet (previous version, 0 replicas)

Kubernetes ReplicaSets perform three functions:

1. Creation: start the specified number of Pods
2. Monitoring: watch Pod state
3. Reconciliation: recreate failed Pods

# View a Deployment's ReplicaSets
kubectl get rs -l app=my-app

# Observe the Deployment → ReplicaSet → Pods link
kubectl get deploy,rs,pods -l app=my-app

Remember: always manipulate the Deployment, never the ReplicaSet directly. The Deployment orchestrates transitions between versions.

Check our Kubernetes Training: Complete Guide for a comprehensive overview.

How to Create a Kubernetes Deployment?

Create a Deployment with a structured YAML manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
name: api-backend
labels:
app: api-backend
spec:
replicas: 3
selector:
matchLabels:
app: api-backend
template:
metadata:
labels:
app: api-backend
spec:
containers:
- name: api
image: my-registry/api:v1.2.0
ports:
- containerPort: 8080
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 3

Apply the manifest:

kubectl apply -f deployment.yaml

# Check status
kubectl rollout status deployment/api-backend

# View details
kubectl describe deployment api-backend

IT teams spend 34 working days per year resolving Kubernetes issues. Well-configured Deployments with probes reduce this time.

To expose this Deployment, check our guide on Kubernetes Services.

How to Scale a Deployment?

Scaling adjusts the number of Pods based on load. Two methods exist.

Manual Scaling

# Scale to 5 replicas
kubectl scale deployment/api-backend --replicas=5

# Verify scaling
kubectl get deployment api-backend

Declarative Scaling

Modify the replicas field in the manifest and reapply:

spec:
replicas: 5  # Changed from 3 to 5

kubectl apply -f deployment.yaml

Remember: declarative scaling facilitates versioning and code review. Prefer this approach in production.

For automatic scaling based on CPU/memory metrics, configure a HorizontalPodAutoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api-backend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api-backend
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70

With 80% of organizations using Kubernetes in production, automatic scaling becomes critical.

How to Perform a Rolling Update of Kubernetes Deployments?

Rolling updates allow updating an application without interruption. Kubernetes progressively replaces old Pods with new ones.

Update the Deployment's image:

# Imperative method
kubectl set image deployment/api-backend api=my-registry/api:v1.3.0

# Watch the rollout
kubectl rollout status deployment/api-backend

The default RollingUpdate strategy controls the transition:

spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%  # Max unavailable pods
maxSurge: 25%        # Max extra pods

Remember: configure readinessProbe so Kubernetes waits for the new Pod to be ready before removing the old one.

Master kubectl commands to supervise your rolling updates.

How to Perform a Rollback?

If an update causes problems, restore a previous version instantly.

# View revision history
kubectl rollout history deployment/api-backend

# Details of a specific revision
kubectl rollout history deployment/api-backend --revision=2

# Rollback to previous revision
kubectl rollout undo deployment/api-backend

# Rollback to a specific revision
kubectl rollout undo deployment/api-backend --to-revision=3

Kubernetes keeps old ReplicaSets (with 0 replicas) to enable rollbacks. The revisionHistoryLimit parameter controls this number:

spec:
revisionHistoryLimit: 5  # Keep 5 versions

According to TealHQ: "Don't let your knowledge remain theoretical - set up a real Kubernetes environment to solidify your skills." Practice rollbacks on a test cluster.

Best Practices for Kubernetes Deployments

Consistent Labels and Selectors

metadata:
labels:
app: api-backend
version: v1.2.0
environment: production
spec:
selector:
matchLabels:
app: api-backend

Resource Requests and Limits

Always define resources to prevent node overload:

resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"

Health Probes

Remember: without readinessProbe, Kubernetes sends traffic to unready Pods, causing 5xx errors.

Annotations for Rollouts

# Record the change cause
kubectl annotate deployment/api-backend \
kubernetes.io/change-cause="Upgrade API to v1.3.0"

Discover the basics in Kubernetes fundamentals for beginners.

Summary Table: Deployment Commands

Take Action: SFEIR Kubernetes Trainings

Deployments and ReplicaSets form the core of Kubernetes application management. To go deeper:

• Get started in 1 day with Kubernetes Fundamentals: Pods, Deployments, Services, architecture
• Prepare for CKAD with LFD459 Kubernetes for Developers: 3 days focused on application development
• Administer in production with LFS458 Kubernetes Administration: 4 days for CKA certification

Contact our advisors to build your certification path.