So far you've learned:

Container
   ↓
Pod

But we discovered a problem:

What happens if the Pod crashes?

And another:

What if I need 5 copies of my application?

And another:

How do I safely deploy version 2 of my application?

The answer is primarily:

Deployment#

1. What is a Deployment?#

A Kubernetes Deployment manages a set of identical application Pods.

Instead of saying:

"Run this Pod."

you say:

"I want 3 replicas of this application running."

For example:

Deployment
    │
    ↓
  3 replicas
    │
    ├── Pod 1
    ├── Pod 2
    └── Pod 3

If one Pod disappears:

Pod 1 ✅
Pod 2 ❌
Pod 3 ✅

The Deployment's controllers work to get back to:

Pod 1 ✅
Pod 3 ✅
Pod 4 ✅

2. Why not create Pods directly?#

You learned in Chapter 5 that we can create:

kubectl run nginx --image=nginx

That creates a standalone Pod.

But if it dies:

Pod ❌

there's no Deployment saying:

"I require one replica."

So it stays gone.

A Deployment changes the situation:

Deployment
Desired replicas = 3
 
Current:
Pod 1
Pod 2
Pod 3

If Pod 2 disappears:

Current:
Pod 1
Pod 3
 
Desired:
3

Kubernetes works toward:

Pod 1
Pod 3
Pod 4

3. Deployment Architecture#

This hierarchy is extremely important:

Deployment
     ↓
ReplicaSet
     ↓
Pods
     ↓
Containers

For example:

                 Deployment
                     │
                     ↓
                ReplicaSet
                     │
            ┌────────┼────────┐
            ↓        ↓        ↓
          Pod 1    Pod 2    Pod 3
            │        │        │
         Container Container Container

You generally create the Deployment.

Kubernetes creates/manages the ReplicaSet and Pods.

4. What is a ReplicaSet?#

A ReplicaSet maintains a specified number of Pod replicas.

Suppose:

replicas: 3

The ReplicaSet's responsibility is essentially:

"Keep 3 matching Pods running."

So:

Desired = 3
Current = 3

Everything is fine.

If:

Desired = 3
Current = 2

it works toward creating another Pod.

5. Why do we need both Deployment and ReplicaSet?#

Good question.

You could technically use a ReplicaSet directly.

But Deployment gives you higher-level application management.

Deployment provides things such as:

• Replica management
• Rolling updates
• Rollbacks
• Version history
• Deployment strategies

So the normal hierarchy is:

Deployment
    ↓
ReplicaSet
    ↓
Pods

Think:

Deployment = application release manager

ReplicaSet = replica manager

6. Your First Deployment#

Let's create an Nginx Deployment.

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

Don't worry about every line yet.

Focus on:

kind: Deployment

and:

replicas: 3

7. Apply the Deployment#

Save it as:

deployment.yaml

Then:

kubectl apply -f deployment.yaml

You'll get something similar to:

deployment.apps/nginx-deployment created

8. Check the Deployment#

kubectl get deployments

You may see:

NAME               READY   UP-TO-DATE   AVAILABLE
nginx-deployment   3/3     3            3

Meaning:

Desired replicas = 3
Ready replicas   = 3
Available        = 3

9. Check the Pods#

kubectl get pods

You might see:

NAME                                READY   STATUS
nginx-deployment-7d8f9c7f5b-abc12   1/1     Running
nginx-deployment-7d8f9c7f5b-def34   1/1     Running
nginx-deployment-7d8f9c7f5b-ghi56   1/1     Running

Notice something interesting:

You didn't create these Pods manually.

The Deployment caused Kubernetes to create them.

10. Check the ReplicaSet#

Run:

kubectl get replicasets

or:

kubectl get rs

You'll see something like:

NAME                          DESIRED   CURRENT   READY
nginx-deployment-7d8f9c7f5b   3         3         3

So:

Deployment
    ↓
nginx-deployment-7d8f9c7f5b
    ↓
3 Pods

11. The selector and labels#

This is one of the most important concepts in Kubernetes.

You have:

selector:
  matchLabels:
    app: nginx

And the Pod template has:

labels:
  app: nginx

These need to match appropriately.

Think:

Deployment
     ↓
"I'm responsible for Pods labeled app=nginx"
     ↓
Pod
labels:
  app=nginx

Labels are how Kubernetes identifies and groups resources.

12. What are Labels?#

Labels are key-value metadata.

For example:

labels:
  app: nginx
  environment: production
  team: backend

A Pod might therefore have:

app=nginx
environment=production
team=backend

Labels are used heavily by:

• Deployments
• Services
• Scheduling
• Monitoring
• Organization

13. Scaling a Deployment#

This is where things get interesting.

Suppose you have:

3 Pods

and traffic increases.

You can manually scale:

kubectl scale deployment nginx-deployment --replicas=5

Now:

Before:
 
Pod 1
Pod 2
Pod 3
 
After:
 
Pod 1
Pod 2
Pod 3
Pod 4
Pod 5

Check:

kubectl get pods

14. Scaling Down#

You can also reduce replicas:

kubectl scale deployment nginx-deployment --replicas=2

Now Kubernetes works toward:

Pod 1
Pod 2

The extra Pods are terminated.

15. Declarative Scaling#

Instead of:

kubectl scale deployment nginx-deployment --replicas=5

you can modify:

spec:
  replicas: 5

Then:

kubectl apply -f deployment.yaml

This is the declarative model:

YAML
 ↓
Desired state = 5
 ↓
Kubernetes
 ↓
5 Pods

16. What Happens If a Pod Dies?#

Suppose:

Deployment
replicas = 3
 
Pod A ✅
Pod B ✅
Pod C ✅

Now you manually delete Pod B:

kubectl delete pod <pod-name>

For a moment:

Pod A
Pod C

But Kubernetes sees:

Desired = 3
Current = 2

So a new Pod appears:

Pod A
Pod C
Pod D

This is the self-healing behavior you learned earlier.

17. This is Reconciliation#

Remember:

Desired State
     vs
Current State

The Deployment/ReplicaSet controllers continuously work toward:

Current State = Desired State

For example:

Desired = 3
Current = 2
 
       ↓
 
Create Pod
 
       ↓
 
Current = 3

This reconciliation model is one of the core ideas behind Kubernetes.

18. Rolling Updates#

Now we get to one of the biggest reasons Deployments are useful.

Suppose your application currently runs:

nginx:1.27

You want:

nginx:1.28

You don't necessarily want:

Stop everything
      ↓
Start new version

because that could cause downtime.

Instead, Kubernetes can perform a rolling update.

Conceptually:

OLD VERSION
 
Pod 1 → v1
Pod 2 → v1
Pod 3 → v1

Gradually:

Pod 1 → v2
Pod 2 → v1
Pod 3 → v1

Then:

Pod 1 → v2
Pod 2 → v2
Pod 3 → v1

Finally:

Pod 1 → v2
Pod 2 → v2
Pod 3 → v2

19. Updating the Image#

Change:

image: nginx:1.27

to:

image: nginx:1.28

Then:

kubectl apply -f deployment.yaml

Kubernetes detects that the Pod template changed.

It creates a new ReplicaSet for the new version and gradually transitions from the old ReplicaSet to the new one.

Conceptually:

Deployment
   │
   ├── Old ReplicaSet
   │      └── v1 Pods
   │
   └── New ReplicaSet
          └── v2 Pods

This is a crucial detail:

A Deployment manages ReplicaSets, and during a rolling update it can use multiple ReplicaSets.

20. Check Rollout Status#

Run:

kubectl rollout status deployment/nginx-deployment

You'll see progress such as:

Waiting for deployment to finish...
deployment successfully rolled out

21. Rollout History#

You can see Deployment revisions:

kubectl rollout history deployment/nginx-deployment

This helps track changes to the Deployment.

22. Rollback#

Suppose you deploy version 2:

v1 → v2

But v2 has a bug.

You can roll back:

kubectl rollout undo deployment/nginx-deployment

Conceptually:

v1
 ↓
v2 ❌
 ↓
rollback
 ↓
v1

That's one of the major advantages of using Deployments.

23. Deployment Status#

Useful command:

kubectl describe deployment nginx-deployment

You can see:

• Desired replicas
• Current replicas
• Available replicas
• Conditions
• Events
• ReplicaSets

24. Deployment YAML — Deep Dive#

Let's revisit the YAML:

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

Let's break it down.

apiVersion#

apiVersion: apps/v1

The Deployment resource belongs to the apps/v1 API group/version.

kind#

kind: Deployment

You're creating a Deployment.

metadata#

metadata:
  name: nginx-deployment

The Deployment's name.

replicas#

replicas: 3

Desired number of Pods.

selector#

selector:
  matchLabels:
    app: nginx

The Deployment identifies its Pods using labels.

template#

template:

This defines the template from which Pods are created.

Inside it:

metadata:
  labels:
    app: nginx

gives the Pods their label.

Then:

spec:
  containers:

defines the containers inside those Pods.

25. Very Important Distinction#

This YAML contains two metadata sections conceptually:

Deployment metadata
        ↓
Deployment name
 
Pod template metadata
        ↓
Pod labels

Don't confuse them.

26. Deployment vs Pod#

27. Deployment vs ReplicaSet#

Think:

Deployment
"I want this version of my application."
 
        ↓
 
ReplicaSet
"I need 3 Pods for this version."
 
        ↓
 
Pods
"Run the containers."

28. Rolling Update Strategy#

Deployments use a rolling update strategy by default.

Two useful parameters are:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

maxUnavailable#

How many Pods can be unavailable during the update.

maxSurge#

How many extra Pods can temporarily exist above the desired count.

For example:

Desired replicas = 3
maxSurge = 1

Kubernetes may temporarily have:

4 Pods

during the update.

29. Why This Matters#

Suppose:

replicas = 3

You don't necessarily want:

3 old Pods
      ↓
0 Pods
      ↓
3 new Pods

Instead, you want a controlled transition:

3 old
 ↓
2 old + 1 new
 ↓
1 old + 2 new
 ↓
0 old + 3 new

This is the basic idea behind rolling updates.

30. What About Zero Downtime?#

A rolling update can reduce downtime, but a Deployment alone doesn't guarantee that users will never see failures.

For robust production deployments, you also need things like:

• Readiness probes
• Proper application startup
• Service routing
• Appropriate rollout settings
• Enough replicas
• Correct application compatibility

We'll connect these concepts later.

31. Real Node.js Example#

Imagine:

Node.js API

Docker image:

mycompany/node-api:v1

Deployment:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: mycompany/node-api:v1
          ports:
            - containerPort: 3000

Kubernetes produces:

Deployment
     ↓
ReplicaSet
     ↓
┌──────────┬──────────┬──────────┐
Pod 1      Pod 2      Pod 3
│          │          │
Node.js    Node.js    Node.js

Then we'll eventually add:

Service
     ↓
Pods

so users can access the application.

32. Deployment Scaling + HPA#

Earlier you asked:

Can Kubernetes increase Pods when traffic increases by 80%?

Now you can see where that fits.

Manual:

Deployment
   ↓
replicas = 3

Automatic:

Deployment
   ↑
   │
HPA
   ↑
Metrics

For example:

Traffic increases
       ↓
CPU increases
       ↓
HPA
       ↓
Deployment replicas
3 → 5
       ↓
More Pods

We'll study HPA much later.

33. Practical Exercise#

Let's create a Deployment.

deployment.yaml#

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

Apply:

kubectl apply -f deployment.yaml

Check:

kubectl get deployment

Then:

kubectl get replicasets

Then:

kubectl get pods

You should see:

Deployment
    ↓
ReplicaSet
    ↓
3 Pods

34. Test Self-Healing#

Run:

kubectl get pods

Pick one Pod and delete it:

kubectl delete pod <pod-name>

Immediately run:

kubectl get pods

You'll see something like:

Pod A    Running
Pod B    Terminating
Pod C    Running
Pod D    ContainerCreating

Then eventually:

Pod A    Running
Pod C    Running
Pod D    Running

You just witnessed Kubernetes reconciliation.

35. Test Scaling#

Run:

kubectl scale deployment nginx-deployment --replicas=5

Then:

kubectl get pods

You should eventually have:

5 Pods

Scale back:

kubectl scale deployment nginx-deployment --replicas=3

36. Test a Rolling Update#

Change:

image: nginx:1.28

to another valid Nginx version.

Then:

kubectl apply -f deployment.yaml

Watch:

kubectl rollout status deployment/nginx-deployment

You can also watch Pods:

kubectl get pods -w

-w means watch.

You'll see Pods being replaced.

Press:

Ctrl + C

to stop watching.

37. Test Rollback#

Check history:

kubectl rollout history deployment/nginx-deployment

Then:

kubectl rollout undo deployment/nginx-deployment

Check:

kubectl rollout status deployment/nginx-deployment

You've now performed:

v1
 ↓
v2
 ↓
rollback
 ↓
v1

🧠 Chapter 6 Mental Model#

This is the diagram I want you to remember:

                    Deployment
                         │
                         │
                         ↓
                    ReplicaSet
                         │
              ┌──────────┼──────────┐
              ↓          ↓          ↓
            Pod 1      Pod 2      Pod 3
              │          │          │
              ↓          ↓          ↓
          Container   Container   Container

When updating:

                    Deployment
                         │
                ┌────────┴────────┐
                ↓                 ↓
          Old ReplicaSet     New ReplicaSet
                ↓                 ↓
             v1 Pods            v2 Pods
                │                 │
                └──── gradually ──┘
                         ↓
                       v2

🎯 Interview Questions#

Q1. Why use Deployment instead of a Pod?#

A Deployment manages the lifecycle and desired number of Pods and supports features such as rolling updates and rollbacks.

Q2. What is a ReplicaSet?#

A controller that maintains the desired number of matching Pod replicas.

Q3. What happens if a Pod managed by a Deployment is deleted?#

The ReplicaSet/Deployment controllers work to create a replacement Pod.

Q4. What is a rolling update?#

Gradually replacing old application Pods with new-version Pods instead of replacing everything simultaneously.

Q5. How do you scale a Deployment?#

kubectl scale deployment <name> --replicas=5

or declaratively:

replicas: 5

followed by:

kubectl apply -f deployment.yaml

Q6. How do you check rollout status?#

kubectl rollout status deployment/<name>

Q7. How do you rollback?#

kubectl rollout undo deployment/<name>

Q8. What is the hierarchy?#

Deployment
 ↓
ReplicaSet
 ↓
Pod
 ↓
Container

⭐ The Most Important Takeaway#

If you remember only one thing from this chapter, remember:

You normally don't manage production Pods individually. You define the desired application state in a Deployment, and Kubernetes uses ReplicaSets to maintain the required Pods.

So instead of thinking:

"Create 3 Pods."

think:

"I want 3 replicas of my application."

Kubernetes handles the mechanics.

🚀 Next — Chapter 7: Services#

We now have a problem.

Suppose we have:

Deployment
     ↓
┌────┬────┬────┐
Pod  Pod  Pod

Each Pod has an IP.

But Pods can be destroyed and recreated, so their IPs can change.

How does your frontend reliably communicate with your backend?

How does a user access your application?

The answer is:

Kubernetes Services#

We'll learn:

Pod IP
Service IP
ClusterIP
NodePort
LoadBalancer
Selectors
Service Discovery
DNS
Port vs targetPort
Load balancing across Pods

And we'll expose the Nginx/Node.js application we've been building.