Deployment, ReplicaSet & Replication Controller

The three generations of Kubernetes workload controllers that transform fragile standalone Pods into resilient, scalable, and continuously deployable production services. Synthesized from CKA Day 8 — Deployment, ReplicaSet & Replication Controller Explained.

The Problem: Bare Pods Are Fragile

A standalone Pod is a single point of failure. If the node crashes, the container exits, or the application panics, traffic hits a dead endpoint until someone manually intervenes. In production, you need:

Requirement	Bare Pod	With Controllers
Self-healing	❌ Stays down	✅ Auto-replaced
High availability	❌ Single instance	✅ Multiple replicas
Load distribution	❌ No balancing	✅ Traffic spread across replicas
Zero-downtime updates	❌ Stop-start downtime	✅ Rolling updates
Rollback	❌ Manual redeploy	✅ One-command undo
Health-aware rollout	❌ No readiness checks	✅ Rolling updates wait for readiness probes

Key Insight: You almost never create bare Pods in production. You create Deployments that manage ReplicaSets that manage Pods. Source: CKA Day 8

---

1. ReplicationController (Legacy)

The original Kubernetes replication mechanism. Still functional but superseded by ReplicaSet.

Attribute	Value
apiVersion	v1
kind	ReplicationController
Core Purpose	Ensure N identical Pod replicas are always running
Limitation	Cannot adopt existing Pods that it did not create

YAML Structure

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-rc
  labels:
    env: demo
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

How It Works

1. You define a template describing the Pod to create
2. You set replicas: 3 (desired state)
3. The kube-controller-manager (ReplicationController controller) watches the cluster
4. If a Pod dies → controller creates a replacement from the template
5. If you scale to replicas: 5 → controller launches 2 new Pods

---

2. ReplicaSet (Modern Replacement)

ReplicaSet is the evolution of ReplicationController. It adds selectors, enabling it to manage Pods created outside its own template.

Attribute	Value
apiVersion	apps/v1
kind	ReplicaSet
Key Improvement	selector.matchLabels can adopt existing Pods by label
Used By	Deployments (indirectly — you rarely create ReplicaSets manually)

YAML Structure

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
  labels:
    env: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Critical Difference: The selector.matchLabels block tells the ReplicaSet: “Manage every Pod that has the label app: nginx, regardless of who created it.” This is what allows Deployments to seamlessly take over Pods during rolling updates. Source: CKA Day 8

Scaling a ReplicaSet

Three approaches, ordered by exam speed:

1. Imperative (fastest)

   kubectl scale --replicas=10 rs/nginx-rs

2. Edit live object

   kubectl edit rs nginx-rs
   # modify replicas field in vi, save and exit

3. Declarative (YAML)

   # edit rc.yaml, change replicas: 10
   kubectl apply -f rc.yaml

CKA Tip: Prefer imperative commands to save time. The exam is 2 hours with 16–20 tasks — seconds matter.

---

3. Deployment (Production Standard)

The highest-level and most commonly used workload controller. You interact with Deployments; Kubernetes handles the ReplicaSets and Pods automatically.

Attribute	Value
apiVersion	apps/v1
kind	Deployment
Manages	ReplicaSets (which manage Pods)
Superpowers	Rolling updates, rollback, revision history, pause/resume

YAML Structure

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    env: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Object Hierarchy

Deployment (nginx-deploy)
    └── ReplicaSet (nginx-deploy-<hash>)
            ├── Pod (nginx-deploy-<hash>-abc1)
            ├── Pod (nginx-deploy-<hash>-def2)
            └── Pod (nginx-deploy-<hash>-ghi3)

When you update the Deployment (e.g., change the image), Kubernetes creates a new ReplicaSet with the new specification and scales it up while scaling the old ReplicaSet down — all without user intervention. Source: CKA Day 8

Rolling Updates

The defining feature of Deployments. Instead of deleting all old Pods at once (downtime), Kubernetes:

1. Creates a new ReplicaSet with the updated spec
2. Adds one new Pod (new version)
3. Removes one old Pod (old version)
4. Repeats until only new Pods remain
5. Old ReplicaSet is retained for rollback

This means users never experience an outage — traffic is continuously served by the remaining healthy Pods.

Exposing Deployments with Services

A Deployment manages Pod replicas, but Pods are ephemeral and their IPs change on restart. To provide stable access, you expose the Deployment via a Service:

# Imperative — fastest for the exam
kubectl expose deployment nginx-deploy --type=NodePort --port=80 --target-port=80 --node-port=30001
 
# Declarative — create a Service YAML with selector matching Deployment labels

The Service’s selector must match the Deployment’s Pod labels. The Service then load balances traffic across all healthy Pods managed by the Deployment. Source: CKA Day 9

Rollback

# View revision history
kubectl rollout history deployment/nginx-deploy
 
# Revert to the previous revision
kubectl rollout undo deployment/nginx-deploy
 
# Roll back to a specific revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2

Each change creates a new revision. If a deployment breaks production, rollout undo restores the previous known-good state in seconds. Source: CKA Day 8

Image Updates

# Update the container image on the live object
kubectl set image deployment/nginx-deploy nginx=nginx:1.9.1

Note: This updates the live object in the cluster, not your local YAML file. Keep manifests in version control (GitOps) to avoid drift.

Generating Deployment YAML (Dry-Run)

kubectl create deploy nginx-new --image=nginx \
  --dry-run=client -o yaml > deploy.yaml

This generates a complete Deployment manifest with defaults (1 replica, selectors, labels) that you can customize and apply. Source: CKA Day 8

---

Comparative Summary

Feature	ReplicationController	ReplicaSet	Deployment
apiVersion	v1	apps/v1	apps/v1
Self-healing	✅	✅	✅
Selector flexibility	❌	✅ (matchLabels)	✅ (inherited from RS)
Rolling updates	❌	❌	✅
Rollback	❌	❌	✅
Revision history	❌	❌	✅
Production use	❌ Legacy	⚠️ Rarely direct	✅ Standard

---

Essential Commands Cheatsheet

Command	Purpose
kubectl apply -f deploy.yaml	Create/Update from manifest
kubectl get deploy	List Deployments
kubectl get rs	List ReplicaSets
kubectl get pods	List Pods
kubectl get all	List all resources in namespace
kubectl describe deploy <name>	Detailed Deployment info
kubectl scale --replicas=5 deploy/<name>	Scale Deployment
kubectl set image deploy/<name> <container>=<image>:<tag>	Update image
kubectl rollout status deploy/<name>	Watch rollout progress
kubectl rollout history deploy/<name>	Show revisions
kubectl rollout undo deploy/<name>	Rollback to previous
kubectl delete deploy <name>	Delete Deployment (cascades to RS + Pods)

---

CKA Exam Relevance

• Workloads & Scheduling (~15% of exam): Expect tasks to create, scale, and update Deployments.
• Troubleshooting (~30%): Debug why Pods aren’t reaching desired replica count; inspect Deployment events and ReplicaSet status.
• Resource controls: Deployment Pod templates should carry container requests/limits so replicas can be scheduled predictably and memory leaks fail as OOMKilled Pods instead of destabilizing nodes. Source: CKA Day 16
• Speed Patterns:
  • kubectl create deploy ... --dry-run=client -o yaml → redirect → edit → apply
  • kubectl scale deploy/<name> --replicas=N for instant scaling
  • kubectl set image for rapid image swaps

Sources

• CKA Day 8 — Deployment, ReplicaSet & Replication Controller Explained
• CKA Day 7 — Pod Explained

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a Deployment You are asked to create a Deployment named web-deploy with image nginx:1.24 and 4 replicas. Requirements: Use --dry-run=client -o yaml, save to a file, and apply. Verification: kubectl get deploy web-deploy shows 4/4 replicas ready. Solution:

kubectl create deploy web-deploy --image=nginx:1.24 --replicas=4 --dry-run=client -o yaml > web-deploy.yaml
kubectl apply -f web-deploy.yaml

Task 2: Imperative Scale You are asked to scale the existing Deployment web-deploy to 6 replicas without editing any YAML file. Requirements: Use a single imperative command. Verification: kubectl get deploy web-deploy shows 6/6 replicas ready. Solution:

kubectl scale deploy web-deploy --replicas=6

Task 3: Rolling Update with Strategy You are asked to update web-deploy to use image nginx:1.25 with a rolling update strategy of maxSurge: 2 and maxUnavailable: 1. Requirements: Edit the live object or patch the Deployment; verify the rollout completes. Verification: kubectl rollout status deploy/web-deploy Solution:

kubectl set image deploy/web-deploy nginx=nginx:1.25
kubectl patch deploy web-deploy -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":2,"maxUnavailable":1}}}}'
kubectl rollout status deploy/web-deploy

Task 4: Rollback The new image introduced a regression. Roll back web-deploy to the previous revision and verify. Requirements: Use a single rollout command; confirm the previous image is restored. Verification: kubectl get deploy web-deploy -o jsonpath='{.spec.template.spec.containers[0].image}' Solution:

kubectl rollout undo deploy/web-deploy
kubectl rollout history deploy/web-deploy
kubectl get deploy web-deploy -o jsonpath='{.spec.template.spec.containers[0].image}'

Related Pages

• Pod Fundamentals — What these controllers manage
• Multi-Container Pods — Deployments managing Pods with multiple containers
• Kubernetes Services — How to expose Deployments to clients
• Kubernetes Service Types — ClusterIP, NodePort, LoadBalancer, ExternalName
• Kubernetes Architecture — Controller Manager and reconciliation loops
• CKA Certification — Exam structure and domains
• CKA Study Roadmap — 40-day learning plan
• Why Kubernetes? — The problems replication solves
• Kubernetes Namespaces — Namespace-scoped workload isolation
• Kubernetes DaemonSet — Node-level alternative for infrastructure agents
• Kubernetes Jobs — Finite batch workloads (contrast with long-running Deployments)
• Kubernetes CronJobs — Scheduled batch workloads
• Kubernetes Labels and Selectors — matchLabels and Pod adoption mechanics
• Kubernetes Taints and Tolerations — How node taints filter Deployment Pod placement
• Kubernetes Static Pods — Node-local Pods without controller management
• Kubernetes Resource Requests and Limits — resource budgets inside Deployment Pod templates
• Kubernetes Autoscaling — HPA scales Deployments automatically based on load
• Horizontal Pod Autoscaler (HPA) — primary tool for scaling Deployment replicas
• Vertical Pod Autoscaler (VPA) — right-sizes container resources within Deployment templates
• Kubernetes Health Probes — Readiness probes gate rolling updates and replica availability
• Kubernetes ConfigMaps and Secrets — Propagating config across all replicas via Pod templates
• Kubernetes Application Troubleshooting — Day 37: rollout stalls and Deployment failure diagnosis
• Docker Fundamentals — Container basics underlying Pods
• Tech Tutorials with Piyush — Course creator

---

Tags: kubernetes deployment replicaset replicationcontroller workload cka devops high-availability rolling-update self-healing