Phase 02 · Core WorkloadsChapter 11 of 33

Phase 02Read time ~12 minDifficulty intermediate

Volumes & Persistent Storage

Warrior, this is one of the most important Kubernetes chapters.

In this chapter (57 sections)

So far, you've learned:

Deployment → Pods → Containers

But containers are generally ephemeral.

That creates a serious problem:

What happens to my data when a Pod is deleted or recreated?

For stateless applications, losing local container data may be fine.

For databases like PostgreSQL, MySQL, MongoDB, it can be disastrous.

Let's understand how Kubernetes handles storage.

1. The Problem: Container Storage Is Temporary#

Imagine a Node.js container:

┌────────────────────────────┐
│       Node.js Container    │
│                            │
│  /app                      │
│  /app/uploads              │
│  /app/data                 │
│                            │
└────────────────────────────┘

Suppose your application writes:

/app/data/user.json

Then the container crashes.

Kubernetes creates a replacement:

Old container
     ❌
     ↓
New container

The new container has its own writable filesystem.

So:

Old Container
/app/data/user.json
       ❌
 
New Container
/app/data/
       empty

That's the problem.

2. Why Kubernetes Needs Volumes#

Kubernetes provides Volumes so data can live outside the container's writable layer.

Instead of:

Container
   ↓
Container filesystem

we can have:

Container
   ↓
Volume
   ↓
Storage

Then:

Container dies
      ↓
New container
      ↓
Same volume
      ↓
Data remains

3. Basic Mental Model#

Think of a volume as:

A storage location that can be mounted inside a Pod.

For example:

                     Pod
                      │
             ┌────────┴────────┐
             │                 │
        Container           Volume
             │                 │
             └───────┬─────────┘
                     │
                 /data

The container sees:

/data

but the actual storage can live somewhere outside the container filesystem.

4. `emptyDir`#

The simplest Kubernetes volume is:

emptyDir

When a Pod is created:

Pod created
    ↓
emptyDir created

Containers inside the Pod can use it.

Example:

apiVersion: v1
kind: Pod
 
metadata:
  name: volume-demo
 
spec:
  containers:
    - name: app
      image: nginx
 
      volumeMounts:
        - name: shared-data
          mountPath: /data
 
  volumes:
    - name: shared-data
      emptyDir: {}

Now the container gets:

/data

5. What Does `emptyDir` Mean?#

emptyDir starts empty.

Pod starts
   ↓
emptyDir = empty

Application writes:

/data/file.txt

Now:

/data
└── file.txt

If the container restarts inside the same Pod, the emptyDir data normally remains.

But:

If the Pod itself is deleted, the emptyDir is deleted.

This distinction is extremely important.

6. Pod vs Container Failure#

Suppose:

Pod
│
└── Container
      ❌ crashes

Kubernetes restarts the container.

The Pod still exists.

Therefore:

emptyDir
   ↓
usually survives container restart

But:

Pod
❌ deleted

then:

emptyDir
❌ deleted

7. Why `emptyDir` Is Useful#

It's useful for temporary data.

Examples:

Temporary processing#

Upload
   ↓
Temporary file
   ↓
Process
   ↓
Delete

Pod
│
├── Main application
│
├── Sidecar
│
└── emptyDir
       ↑
       │
Both containers access it

8. Multi-Container Pod Example#

Suppose:

Pod
│
├── Application
│
└── Logger

Both need access to:

/logs

You can use:

volumes:
  - name: shared-logs
    emptyDir: {}

Mount it into both containers:

containers:
 
  - name: app
    image: my-app
 
    volumeMounts:
      - name: shared-logs
        mountPath: /logs
 
  - name: logger
    image: log-collector
 
    volumeMounts:
      - name: shared-logs
        mountPath: /logs

Now:

              Pod
               │
       ┌───────┴────────┐
       │                │
      App             Logger
       │                │
       └───────┬────────┘
               │
          shared volume
             /logs

9. But `emptyDir` Is NOT Persistent Storage#

This is the key point.

If you need:

Database
User uploads
Documents
Permanent application data

don't use emptyDir as your primary persistent storage.

You need Kubernetes persistent storage mechanisms.

That brings us to:

PersistentVolume
PersistentVolumeClaim
StorageClass

10. PersistentVolume — PV#

A PersistentVolume (PV) represents storage available to the Kubernetes cluster.

Think:

PV = actual storage resource

Conceptually:

Kubernetes Cluster
       │
       ▼
PersistentVolume
       │
       ▼
Actual Storage

The actual storage could be backed by cloud storage such as:

AWS EBS
Google Persistent Disk
Azure Disk
NFS
Ceph
other storage systems

11. PersistentVolumeClaim — PVC#

A developer usually doesn't want to manually select a physical disk.

Instead, the application says:

"I need 20 GB of persistent storage."

That's a:

PersistentVolumeClaim

or:

PVC

Think:

PV
 ↓
Storage available
 
PVC
 ↓
Application's request for storage

12. Easy Analogy#

Imagine a rental system.

PV = Apartment
PVC = Rental application
Pod = Tenant

The tenant says:

I need an apartment with 2 bedrooms.

That's the PVC.

Kubernetes finds suitable storage.

13. PV + PVC Architecture#

                Kubernetes
                     │
             ┌───────┴────────┐
             │                │
            Pod              PVC
             │                │
             │                │
             └───────┬────────┘
                     │
                     ▼
                    PV
                     │
                     ▼
              Physical/Cloud
                  Storage

14. Creating a PVC#

Example:

apiVersion: v1
kind: PersistentVolumeClaim
 
metadata:
  name: app-storage
 
spec:
  accessModes:
    - ReadWriteOnce
 
  resources:
    requests:
      storage: 10Gi

This means:

I want 10 GiB of persistent storage.

Apply:

kubectl apply -f pvc.yaml

Check:

kubectl get pvc

You may see:

NAME           STATUS   VOLUME      CAPACITY
app-storage    Bound    pvc-abc     10Gi

15. What Does `Bound` Mean?#

You might see:

STATUS
Bound

This means:

PVC
 ↓
Successfully connected to storage

Conceptually:

PVC
 │
 │ Bound
 ▼
PV

16. Mounting PVC into a Pod#

Now the Pod can use it:

apiVersion: v1
kind: Pod
 
metadata:
  name: storage-demo
 
spec:
  containers:
    - name: app
      image: nginx
 
      volumeMounts:
        - name: app-storage
          mountPath: /data
 
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: app-storage

Now:

Container
   │
   ▼
/data
   │
   ▼
PVC
   │
   ▼
PV
   │
   ▼
Persistent Storage

17. Why This Is Better#

Suppose the Pod gets deleted:

Pod
 ❌

Kubernetes creates another Pod:

New Pod

The new Pod can mount the same PVC:

New Pod
   │
   ▼
same PVC
   │
   ▼
same storage

So:

Pod 1
  ↓
PVC
  ↓
Data
 
Pod 1 deleted
  ↓
Pod 2
  ↓
same PVC
  ↓
Data still exists

That's the whole point of persistent storage.

18. StorageClass#

Now we reach an important production concept.

Imagine you have:

100 applications

and manually create PVs for every application.

That's inconvenient.

Kubernetes supports:

StorageClass

A StorageClass defines how storage should be dynamically provisioned.

Think:

PVC
 ↓
StorageClass
 ↓
Dynamic provisioning
 ↓
PV
 ↓
Cloud storage

19. Dynamic Provisioning#

Without dynamic provisioning:

Admin
 ↓
Create PV manually
 ↓
Developer creates PVC

With dynamic provisioning:

Developer
 ↓
Creates PVC
 ↓
StorageClass
 ↓
Kubernetes provisions storage
 ↓
PV created
 ↓
PVC becomes Bound

This is much more convenient.

20. Real Cloud Example#

Suppose you're running Kubernetes on AWS EKS.

You might have:

PVC
 ↓
StorageClass
 ↓
AWS EBS

On GKE:

PVC
 ↓
StorageClass
 ↓
Google Persistent Disk

On AKS:

PVC
 ↓
StorageClass
 ↓
Azure Disk

The application doesn't need to know the physical storage details.

21. Access Modes#

PVCs commonly use these access modes:

ReadWriteOnce
ReadOnlyMany
ReadWriteMany

Let's understand them.

ReadWriteOnce — RWO#

Read + Write

The volume can generally be mounted read-write by Pods on a single node at a time.

Common example:

PostgreSQL

ReadOnlyMany — ROX#

Many Pods
     ↓
Read only

Multiple nodes can mount the volume read-only, depending on the storage backend.

ReadWriteMany — RWX#

Pod A ─┐
Pod B ─┼──> Same volume
Pod C ─┘

Multiple nodes can mount it read-write, if the underlying storage supports it.

NFS and certain distributed filesystems can support RWX.

22. Stateful Applications#

Now you can understand the difference between:

Stateless

and:

Stateful

Stateless#

Example:

Next.js
Node.js API

Usually:

Request
   ↓
Pod
   ↓
Response

The Pod doesn't need to permanently store user data locally.

Stateful#

Example:

PostgreSQL
MongoDB
MySQL

They maintain important data:

Users
Orders
Payments
Transactions

Therefore persistent storage is required.

23. Stateless Architecture#

A typical Kubernetes architecture:

                 Service
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Pod A       Pod B       Pod C
        │           │           │
      Node.js     Node.js     Node.js

If Pod A dies:

Pod A ❌

No important application state should be lost.

Deployment creates:

Pod D

24. Stateful Architecture#

For PostgreSQL:

If the PostgreSQL Pod restarts:

Pod dies
   ↓
New Pod
   ↓
Same storage
   ↓
Database data remains

25. StatefulSet#

Kubernetes provides another workload type:

StatefulSet

It is designed for applications that need stable identity and/or persistent storage.

For example:

postgres-0
postgres-1
postgres-2

Unlike a typical Deployment where Pods may have generated names:

node-api-7d89f6...
node-api-7d89f6...

StatefulSet gives stable identities.

We'll study StatefulSets in more detail later when discussing production workloads.

26. Deployment vs StatefulSet#

Feature	Deployment	StatefulSet
Typical use	Stateless apps	Stateful apps
Stable Pod identity	❌	✅
Persistent storage	Possible	Common
Typical example	Node.js API	PostgreSQL
Scaling	Easy	More ordered
Pod names	Generated	Stable ordinal names

Don't interpret this as "StatefulSet automatically makes a database production-ready." Database operation still requires backups, replication, failover, upgrades, etc.

27. Volume Architecture#

Here's the hierarchy you should remember:

                    Application
                         │
                         ▼
                        Pod
                         │
                    volumeMount
                         │
                         ▼
                       Volume
                         │
                         ▼
                        PVC
                         │
                         ▼
                        PV
                         │
                         ▼
                 Storage Provider

With dynamic provisioning:

Pod
 │
 ▼
PVC
 │
 ▼
StorageClass
 │
 ▼
Dynamic Provisioning
 │
 ▼
PV
 │
 ▼
Cloud Storage

28. Important Difference: Volume vs PVC vs PV#

This confuses beginners.

Volume#

A volume is something a Pod mounts.

Pod → Volume

PVC#

A request for persistent storage.

Application → PVC

PV#

The persistent storage resource.

PVC → PV

StorageClass#

Defines how storage can be dynamically provisioned.

PVC → StorageClass → PV

29. Real Example: PostgreSQL#

Imagine your application:

Next.js
   ↓
Node.js API
   ↓
PostgreSQL

Kubernetes:

                   Internet
                       │
                       ▼
                   Ingress
                       │
                       ▼
                  Node API
                       │
                       ▼
                PostgreSQL Service
                       │
                       ▼
                 PostgreSQL Pod
                       │
                       ▼
                      PVC
                       │
                       ▼
               Persistent Storage

If the PostgreSQL Pod dies:

PostgreSQL Pod
      ❌
      ↓
New PostgreSQL Pod
      ↓
Same PVC
      ↓
Same data

30. One Huge Warning ⚠️#

Persistent storage does not mean backup.

Suppose:

Database
   ↓
Persistent Disk

The disk survives Pod deletion.

But if:

Disk gets corrupted

or:

Someone deletes the storage

your data can still be lost.

Therefore production databases need:

Persistent storage
        +
Backups
        +
Replication/HA where appropriate
        +
Monitoring
        +
Disaster recovery

This distinction is extremely important.

31. Common Kubernetes Storage Mistakes#

Mistake 1#

Using:

emptyDir

for database data.

❌ Dangerous.

Mistake 2#

Thinking:

PVC = backup

❌ No.

PVC provides persistent storage access, not backup.

Mistake 3#

Assuming every storage system supports:

ReadWriteMany

❌ Not necessarily.

Access modes depend on the storage implementation.

Mistake 4#

Putting user uploads inside a random Pod filesystem.

For example:

/app/uploads

If your application has:

Pod A
Pod B
Pod C

each Pod can have its own local filesystem.

Instead consider:

Object Storage

such as:

Amazon S3
Google Cloud Storage
Azure Blob Storage

for many user-upload scenarios.

32. Interview Questions#

Q1. Why do we need Kubernetes Volumes?#

Containers have ephemeral writable storage. Volumes provide storage that can be shared between containers or have a lifecycle independent of an individual container.

Q2. What is `emptyDir`?#

A temporary volume created when a Pod is assigned to a node. It survives container restarts within that Pod but is deleted when the Pod is removed.

Q3. What is a PersistentVolume?#

A cluster-level storage resource representing persistent storage available to Kubernetes workloads.

Q4. What is a PersistentVolumeClaim?#

A request from a workload for a certain amount and type of persistent storage.

Q5. What is StorageClass?#

A Kubernetes object that describes classes of storage and enables dynamic provisioning of persistent volumes.

Q6. What happens when a Pod using a PVC is deleted?#

Typically:

Pod deleted
   ↓
PVC remains
   ↓
Persistent storage remains
   ↓
New Pod mounts PVC

The exact behavior depends on the storage and reclaim policy.

Q7. Is PVC a backup?#

No.

PVC provides persistent storage; it doesn't replace backups.

🧠 Chapter 10 Cheat Sheet#

emptyDir
   ↓
Temporary Pod storage
 
Volume
   ↓
Storage mounted into Pod
 
PVC
   ↓
Application requests storage
 
PV
   ↓
Persistent storage resource
 
StorageClass
   ↓
Dynamic storage provisioning

And remember this:

Pod deleted
   ↓
emptyDir → gone
 
Pod deleted
   ↓
PVC → normally remains
   ↓
Persistent data → remains

Kubernetes Mental Model After Chapter 10#

You now have:

                         Kubernetes Cluster
                                │
                    ┌───────────┴───────────┐
                    │                       │
                   DEV                     PROD
                    │                       │
              Deployment               Deployment
                    │                       │
                ReplicaSet              ReplicaSet
                    │                       │
                   Pods                    Pods
                    │                       │
               Containers              Containers
                    │                       │
              ┌─────┴─────┐           ┌─────┴─────┐
              │           │           │           │
         ConfigMap      Secret    ConfigMap     Secret
                    │
                    ▼
                  Volume
                    │
                    ▼
                   PVC
                    │
                    ▼
                   PV
                    │
                    ▼
              Persistent Storage

The key idea:#

Containers run your application; Volumes preserve or share data; PVCs request persistent storage; PVs represent that storage.

Next → Chapter 11: Kubernetes Networking#

This is a big chapter.

We'll build the complete networking picture:

Pod IP
   ↓
Container communication
   ↓
Pod-to-Pod communication
   ↓
Service
   ↓
ClusterIP
   ↓
NodePort
   ↓
LoadBalancer
   ↓
DNS
   ↓
Ingress
   ↓
Internet

And you'll finally understand how a request travels through a Kubernetes cluster from browser → Ingress → Service → Pod → container.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 9 — ConfigMaps & Secrets Next ChapterChapter 11 — Kubernetes Networking

Prev Next

So far, you've learned:

Deployment → Pods → Containers

But containers are generally ephemeral.

That creates a serious problem:

What happens to my data when a Pod is deleted or recreated?

For stateless applications, losing local container data may be fine.

For databases like PostgreSQL, MySQL, MongoDB, it can be disastrous.

Let's understand how Kubernetes handles storage.

1. The Problem: Container Storage Is Temporary#

Imagine a Node.js container:

┌────────────────────────────┐
│       Node.js Container    │
│                            │
│  /app                      │
│  /app/uploads              │
│  /app/data                 │
│                            │
└────────────────────────────┘

Suppose your application writes:

/app/data/user.json

Then the container crashes.

Kubernetes creates a replacement:

Old container
     ❌
     ↓
New container

The new container has its own writable filesystem.

So:

Old Container
/app/data/user.json
       ❌
 
New Container
/app/data/
       empty

That's the problem.

2. Why Kubernetes Needs Volumes#

Kubernetes provides Volumes so data can live outside the container's writable layer.

Instead of:

Container
   ↓
Container filesystem

we can have:

Container
   ↓
Volume
   ↓
Storage

Then:

Container dies
      ↓
New container
      ↓
Same volume
      ↓
Data remains

3. Basic Mental Model#

Think of a volume as:

A storage location that can be mounted inside a Pod.

For example:

                     Pod
                      │
             ┌────────┴────────┐
             │                 │
        Container           Volume
             │                 │
             └───────┬─────────┘
                     │
                 /data

The container sees:

/data

but the actual storage can live somewhere outside the container filesystem.

4. `emptyDir`#

The simplest Kubernetes volume is:

emptyDir

When a Pod is created:

Pod created
    ↓
emptyDir created

Containers inside the Pod can use it.

Example:

apiVersion: v1
kind: Pod
 
metadata:
  name: volume-demo
 
spec:
  containers:
    - name: app
      image: nginx
 
      volumeMounts:
        - name: shared-data
          mountPath: /data
 
  volumes:
    - name: shared-data
      emptyDir: {}

Now the container gets:

/data

5. What Does `emptyDir` Mean?#

emptyDir starts empty.

Pod starts
   ↓
emptyDir = empty

Application writes:

/data/file.txt

Now:

/data
└── file.txt

If the container restarts inside the same Pod, the emptyDir data normally remains.

But:

If the Pod itself is deleted, the emptyDir is deleted.

This distinction is extremely important.

6. Pod vs Container Failure#

Suppose:

Pod
│
└── Container
      ❌ crashes

Kubernetes restarts the container.

The Pod still exists.

Therefore:

emptyDir
   ↓
usually survives container restart

But:

Pod
❌ deleted

then:

emptyDir
❌ deleted

7. Why `emptyDir` Is Useful#

It's useful for temporary data.

Examples:

Temporary processing#

Upload
   ↓
Temporary file
   ↓
Process
   ↓
Delete

Pod
│
├── Main application
│
├── Sidecar
│
└── emptyDir
       ↑
       │
Both containers access it

8. Multi-Container Pod Example#

Suppose:

Pod
│
├── Application
│
└── Logger

Both need access to:

/logs

You can use:

volumes:
  - name: shared-logs
    emptyDir: {}

Mount it into both containers:

containers:
 
  - name: app
    image: my-app
 
    volumeMounts:
      - name: shared-logs
        mountPath: /logs
 
  - name: logger
    image: log-collector
 
    volumeMounts:
      - name: shared-logs
        mountPath: /logs

Now:

              Pod
               │
       ┌───────┴────────┐
       │                │
      App             Logger
       │                │
       └───────┬────────┘
               │
          shared volume
             /logs

9. But `emptyDir` Is NOT Persistent Storage#

This is the key point.

If you need:

Database
User uploads
Documents
Permanent application data

don't use emptyDir as your primary persistent storage.

You need Kubernetes persistent storage mechanisms.

That brings us to:

PersistentVolume
PersistentVolumeClaim
StorageClass

10. PersistentVolume — PV#

A PersistentVolume (PV) represents storage available to the Kubernetes cluster.

Think:

PV = actual storage resource

Conceptually:

Kubernetes Cluster
       │
       ▼
PersistentVolume
       │
       ▼
Actual Storage

The actual storage could be backed by cloud storage such as:

AWS EBS
Google Persistent Disk
Azure Disk
NFS
Ceph
other storage systems

11. PersistentVolumeClaim — PVC#

A developer usually doesn't want to manually select a physical disk.

Instead, the application says:

"I need 20 GB of persistent storage."

That's a:

PersistentVolumeClaim

or:

PVC

Think:

PV
 ↓
Storage available
 
PVC
 ↓
Application's request for storage

12. Easy Analogy#

Imagine a rental system.

PV = Apartment
PVC = Rental application
Pod = Tenant

The tenant says:

I need an apartment with 2 bedrooms.

That's the PVC.

Kubernetes finds suitable storage.

13. PV + PVC Architecture#

                Kubernetes
                     │
             ┌───────┴────────┐
             │                │
            Pod              PVC
             │                │
             │                │
             └───────┬────────┘
                     │
                     ▼
                    PV
                     │
                     ▼
              Physical/Cloud
                  Storage

14. Creating a PVC#

Example:

apiVersion: v1
kind: PersistentVolumeClaim
 
metadata:
  name: app-storage
 
spec:
  accessModes:
    - ReadWriteOnce
 
  resources:
    requests:
      storage: 10Gi

This means:

I want 10 GiB of persistent storage.

Apply:

kubectl apply -f pvc.yaml

Check:

kubectl get pvc

You may see:

NAME           STATUS   VOLUME      CAPACITY
app-storage    Bound    pvc-abc     10Gi

15. What Does `Bound` Mean?#

You might see:

STATUS
Bound

This means:

PVC
 ↓
Successfully connected to storage

Conceptually:

PVC
 │
 │ Bound
 ▼
PV

16. Mounting PVC into a Pod#

Now the Pod can use it:

apiVersion: v1
kind: Pod
 
metadata:
  name: storage-demo
 
spec:
  containers:
    - name: app
      image: nginx
 
      volumeMounts:
        - name: app-storage
          mountPath: /data
 
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: app-storage

Now:

Container
   │
   ▼
/data
   │
   ▼
PVC
   │
   ▼
PV
   │
   ▼
Persistent Storage

17. Why This Is Better#

Suppose the Pod gets deleted:

Pod
 ❌

Kubernetes creates another Pod:

New Pod

The new Pod can mount the same PVC:

New Pod
   │
   ▼
same PVC
   │
   ▼
same storage

So:

Pod 1
  ↓
PVC
  ↓
Data
 
Pod 1 deleted
  ↓
Pod 2
  ↓
same PVC
  ↓
Data still exists

That's the whole point of persistent storage.

18. StorageClass#

Now we reach an important production concept.

Imagine you have:

100 applications

and manually create PVs for every application.

That's inconvenient.

Kubernetes supports:

StorageClass

A StorageClass defines how storage should be dynamically provisioned.

Think:

PVC
 ↓
StorageClass
 ↓
Dynamic provisioning
 ↓
PV
 ↓
Cloud storage

19. Dynamic Provisioning#

Without dynamic provisioning:

Admin
 ↓
Create PV manually
 ↓
Developer creates PVC

With dynamic provisioning:

Developer
 ↓
Creates PVC
 ↓
StorageClass
 ↓
Kubernetes provisions storage
 ↓
PV created
 ↓
PVC becomes Bound

This is much more convenient.

20. Real Cloud Example#

Suppose you're running Kubernetes on AWS EKS.

You might have:

PVC
 ↓
StorageClass
 ↓
AWS EBS

On GKE:

PVC
 ↓
StorageClass
 ↓
Google Persistent Disk

On AKS:

PVC
 ↓
StorageClass
 ↓
Azure Disk

The application doesn't need to know the physical storage details.

21. Access Modes#

PVCs commonly use these access modes:

ReadWriteOnce
ReadOnlyMany
ReadWriteMany

Let's understand them.

ReadWriteOnce — RWO#

Read + Write

The volume can generally be mounted read-write by Pods on a single node at a time.

Common example:

PostgreSQL

ReadOnlyMany — ROX#

Many Pods
     ↓
Read only

Multiple nodes can mount the volume read-only, depending on the storage backend.

ReadWriteMany — RWX#

Pod A ─┐
Pod B ─┼──> Same volume
Pod C ─┘

Multiple nodes can mount it read-write, if the underlying storage supports it.

NFS and certain distributed filesystems can support RWX.

22. Stateful Applications#

Now you can understand the difference between:

Stateless

and:

Stateful

Stateless#

Example:

Next.js
Node.js API

Usually:

Request
   ↓
Pod
   ↓
Response

The Pod doesn't need to permanently store user data locally.

Stateful#

Example:

PostgreSQL
MongoDB
MySQL

They maintain important data:

Users
Orders
Payments
Transactions

Therefore persistent storage is required.

23. Stateless Architecture#

A typical Kubernetes architecture:

                 Service
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Pod A       Pod B       Pod C
        │           │           │
      Node.js     Node.js     Node.js

If Pod A dies:

Pod A ❌

No important application state should be lost.

Deployment creates:

Pod D

24. Stateful Architecture#

For PostgreSQL:

If the PostgreSQL Pod restarts:

Pod dies
   ↓
New Pod
   ↓
Same storage
   ↓
Database data remains

25. StatefulSet#

Kubernetes provides another workload type:

StatefulSet

It is designed for applications that need stable identity and/or persistent storage.

For example:

postgres-0
postgres-1
postgres-2

Unlike a typical Deployment where Pods may have generated names:

node-api-7d89f6...
node-api-7d89f6...

StatefulSet gives stable identities.

We'll study StatefulSets in more detail later when discussing production workloads.

26. Deployment vs StatefulSet#

Feature	Deployment	StatefulSet
Typical use	Stateless apps	Stateful apps
Stable Pod identity	❌	✅
Persistent storage	Possible	Common
Typical example	Node.js API	PostgreSQL
Scaling	Easy	More ordered
Pod names	Generated	Stable ordinal names

Don't interpret this as "StatefulSet automatically makes a database production-ready." Database operation still requires backups, replication, failover, upgrades, etc.

27. Volume Architecture#

Here's the hierarchy you should remember:

                    Application
                         │
                         ▼
                        Pod
                         │
                    volumeMount
                         │
                         ▼
                       Volume
                         │
                         ▼
                        PVC
                         │
                         ▼
                        PV
                         │
                         ▼
                 Storage Provider

With dynamic provisioning:

Pod
 │
 ▼
PVC
 │
 ▼
StorageClass
 │
 ▼
Dynamic Provisioning
 │
 ▼
PV
 │
 ▼
Cloud Storage

28. Important Difference: Volume vs PVC vs PV#

This confuses beginners.

Volume#

A volume is something a Pod mounts.

Pod → Volume

PVC#

A request for persistent storage.

Application → PVC

PV#

The persistent storage resource.

PVC → PV

StorageClass#

Defines how storage can be dynamically provisioned.

PVC → StorageClass → PV

29. Real Example: PostgreSQL#

Imagine your application:

Next.js
   ↓
Node.js API
   ↓
PostgreSQL

Kubernetes:

                   Internet
                       │
                       ▼
                   Ingress
                       │
                       ▼
                  Node API
                       │
                       ▼
                PostgreSQL Service
                       │
                       ▼
                 PostgreSQL Pod
                       │
                       ▼
                      PVC
                       │
                       ▼
               Persistent Storage

If the PostgreSQL Pod dies:

PostgreSQL Pod
      ❌
      ↓
New PostgreSQL Pod
      ↓
Same PVC
      ↓
Same data

30. One Huge Warning ⚠️#

Persistent storage does not mean backup.

Suppose:

Database
   ↓
Persistent Disk

The disk survives Pod deletion.

But if:

Disk gets corrupted

or:

Someone deletes the storage

your data can still be lost.

Therefore production databases need:

Persistent storage
        +
Backups
        +
Replication/HA where appropriate
        +
Monitoring
        +
Disaster recovery

This distinction is extremely important.

31. Common Kubernetes Storage Mistakes#

Mistake 1#

Using:

emptyDir

for database data.

❌ Dangerous.

Mistake 2#

Thinking:

PVC = backup

❌ No.

PVC provides persistent storage access, not backup.

Mistake 3#

Assuming every storage system supports:

ReadWriteMany

❌ Not necessarily.

Access modes depend on the storage implementation.

Mistake 4#

Putting user uploads inside a random Pod filesystem.

For example:

/app/uploads

If your application has:

Pod A
Pod B
Pod C

each Pod can have its own local filesystem.

Instead consider:

Object Storage

such as:

Amazon S3
Google Cloud Storage
Azure Blob Storage

for many user-upload scenarios.

32. Interview Questions#

Q1. Why do we need Kubernetes Volumes?#

Containers have ephemeral writable storage. Volumes provide storage that can be shared between containers or have a lifecycle independent of an individual container.

Q2. What is `emptyDir`?#

A temporary volume created when a Pod is assigned to a node. It survives container restarts within that Pod but is deleted when the Pod is removed.

Q3. What is a PersistentVolume?#

A cluster-level storage resource representing persistent storage available to Kubernetes workloads.

Q4. What is a PersistentVolumeClaim?#

A request from a workload for a certain amount and type of persistent storage.

Q5. What is StorageClass?#

A Kubernetes object that describes classes of storage and enables dynamic provisioning of persistent volumes.

Q6. What happens when a Pod using a PVC is deleted?#

Typically:

Pod deleted
   ↓
PVC remains
   ↓
Persistent storage remains
   ↓
New Pod mounts PVC

The exact behavior depends on the storage and reclaim policy.

Q7. Is PVC a backup?#

No.

PVC provides persistent storage; it doesn't replace backups.

🧠 Chapter 10 Cheat Sheet#

emptyDir
   ↓
Temporary Pod storage
 
Volume
   ↓
Storage mounted into Pod
 
PVC
   ↓
Application requests storage
 
PV
   ↓
Persistent storage resource
 
StorageClass
   ↓
Dynamic storage provisioning

And remember this:

Pod deleted
   ↓
emptyDir → gone
 
Pod deleted
   ↓
PVC → normally remains
   ↓
Persistent data → remains

Kubernetes Mental Model After Chapter 10#

You now have:

                         Kubernetes Cluster
                                │
                    ┌───────────┴───────────┐
                    │                       │
                   DEV                     PROD
                    │                       │
              Deployment               Deployment
                    │                       │
                ReplicaSet              ReplicaSet
                    │                       │
                   Pods                    Pods
                    │                       │
               Containers              Containers
                    │                       │
              ┌─────┴─────┐           ┌─────┴─────┐
              │           │           │           │
         ConfigMap      Secret    ConfigMap     Secret
                    │
                    ▼
                  Volume
                    │
                    ▼
                   PVC
                    │
                    ▼
                   PV
                    │
                    ▼
              Persistent Storage

The key idea:#

Containers run your application; Volumes preserve or share data; PVCs request persistent storage; PVs represent that storage.

Next → Chapter 11: Kubernetes Networking#

This is a big chapter.

We'll build the complete networking picture:

Pod IP
   ↓
Container communication
   ↓
Pod-to-Pod communication
   ↓
Service
   ↓
ClusterIP
   ↓
NodePort
   ↓
LoadBalancer
   ↓
DNS
   ↓
Ingress
   ↓
Internet

And you'll finally understand how a request travels through a Kubernetes cluster from browser → Ingress → Service → Pod → container.

1. The Problem: Container Storage Is Temporary#

2. Why Kubernetes Needs Volumes#

3. Basic Mental Model#

4. emptyDir#

5. What Does emptyDir Mean?#

6. Pod vs Container Failure#

7. Why emptyDir Is Useful#

Temporary processing#

Sharing data between containers#

8. Multi-Container Pod Example#

9. But emptyDir Is NOT Persistent Storage#

10. PersistentVolume — PV#

11. PersistentVolumeClaim — PVC#

12. Easy Analogy#

13. PV + PVC Architecture#

14. Creating a PVC#

15. What Does Bound Mean?#

16. Mounting PVC into a Pod#

17. Why This Is Better#

18. StorageClass#

19. Dynamic Provisioning#

20. Real Cloud Example#

21. Access Modes#

ReadWriteOnce — RWO#

ReadOnlyMany — ROX#

ReadWriteMany — RWX#

22. Stateful Applications#

Stateless#

Stateful#

23. Stateless Architecture#

24. Stateful Architecture#

25. StatefulSet#

26. Deployment vs StatefulSet#

27. Volume Architecture#

28. Important Difference: Volume vs PVC vs PV#

Volume#

PVC#

PV#

StorageClass#

29. Real Example: PostgreSQL#

30. One Huge Warning ⚠️#

31. Common Kubernetes Storage Mistakes#

Mistake 1#

Mistake 2#

Mistake 3#

Mistake 4#

32. Interview Questions#

Q1. Why do we need Kubernetes Volumes?#

Q2. What is emptyDir?#

Q3. What is a PersistentVolume?#

Q4. What is a PersistentVolumeClaim?#

Q5. What is StorageClass?#

Q6. What happens when a Pod using a PVC is deleted?#

Q7. Is PVC a backup?#

🧠 Chapter 10 Cheat Sheet#

Kubernetes Mental Model After Chapter 10#

The key idea:#

Next → Chapter 11: Kubernetes Networking#

Finished this chapter?

1. The Problem: Container Storage Is Temporary#

2. Why Kubernetes Needs Volumes#

3. Basic Mental Model#

4. emptyDir#

5. What Does emptyDir Mean?#

6. Pod vs Container Failure#

7. Why emptyDir Is Useful#

Temporary processing#

Sharing data between containers#

8. Multi-Container Pod Example#

9. But emptyDir Is NOT Persistent Storage#

10. PersistentVolume — PV#

11. PersistentVolumeClaim — PVC#

12. Easy Analogy#

13. PV + PVC Architecture#

14. Creating a PVC#

15. What Does Bound Mean?#

16. Mounting PVC into a Pod#

17. Why This Is Better#

18. StorageClass#

19. Dynamic Provisioning#

4. `emptyDir`#

5. What Does `emptyDir` Mean?#

7. Why `emptyDir` Is Useful#

9. But `emptyDir` Is NOT Persistent Storage#

15. What Does `Bound` Mean?#

Q2. What is `emptyDir`?#

4. `emptyDir`#

5. What Does `emptyDir` Mean?#

7. Why `emptyDir` Is Useful#

9. But `emptyDir` Is NOT Persistent Storage#

15. What Does `Bound` Mean?#

Q2. What is `emptyDir`?#