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

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.
• 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

Related Pages

• Pod Fundamentals — What these controllers manage
• 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
• 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