Storage in Kubernetes

Kubernetes Fundamentals

Chapter 8 · Storage in Kubernetes

Chapter 7 covered configuration and secrets. This chapter covers persistent data — what happens when a pod needs to store data that survives beyond its own disposable lifecycle (Chapter 3's pets-vs-cattle material).

The Problem — Container Filesystems Are Ephemeral Too

A container's own filesystem is ephemeral by default — when the container stops or is replaced, anything written locally is gone. This is exactly Chapter 3's pod-disposability problem again, but for data rather than the pod's own identity or IP — the same underlying theme, recurring at a different layer.

Volumes — Pod-Level Storage

A basic Volume attaches to a pod, not an individual container — it can be shared between multiple containers in the same pod, echoing Chapter 3's shared-storage point. An emptyDir volume's lifetime is tied to the pod's own lifetime — it survives container restarts within the same pod, but not pod deletion or replacement. Useful for temporary scratch space or inter-container file sharing — not for data that must outlive the pod itself.

emptyDir surviving a restart doesn't mean it's persistent

An emptyDir volume surviving a container restart within the same pod can create a false impression of durability. It does not survive the pod itself being deleted or replaced — a genuinely common point of confusion worth being deliberate about.

PersistentVolumes (PV) — Cluster-Level Storage Resources

A PersistentVolume represents an actual piece of storage in the cluster — backed by cloud block storage (cloud1-4's own EBS/Managed Disks/Persistent Disk material, directly reused here), NFS, or another backend. A PV's lifetime is independent of any specific pod — it exists as a cluster resource on its own, genuinely solving the persistence problem.

PersistentVolumeClaims (PVC) — Requesting Storage

A PVC is how a pod actually requests storage — specifying how much space and what access mode it needs, without needing to know the underlying storage details. Kubernetes matches (or "binds") a PVC to a suitable available PV automatically.

A repeated Kubernetes pattern worth recognizing

This mirrors Chapter 6's own Service abstraction exactly — a stable, decoupled interface (the PVC, like a Service) hiding a dynamic underlying implementation (the PV, like a pod). Recognizing this same "claim/interface vs. dynamic backing resource" pattern recurring across different Kubernetes concepts makes each new one faster to understand.

StorageClasses — Dynamic Provisioning

Rather than a cluster administrator manually pre-creating PVs ahead of time, a StorageClass defines how storage should be dynamically provisioned on demand when a PVC requests it — which cloud storage type or tier to use (directly tying to cloud1-4's own storage-tier material). When a PVC references a StorageClass, Kubernetes automatically creates a matching PV behind the scenes — the common, practical pattern on managed cloud Kubernetes (EKS/AKS/GKE), rather than manual PV pre-provisioning.

Access Modes

Mode	Meaning
ReadWriteOnce (RWO)	Mounted read-write by a single node at a time — the common case for block storage (e.g. a database)
ReadOnlyMany (ROX)	Many nodes can mount read-only simultaneously
ReadWriteMany (RWX)	Many nodes can mount read-write simultaneously — needs a backend that actually supports it (e.g. NFS, not typical block storage)

Genuinely practical to know ahead of Course 2's k8s2-1 StatefulSets chapter, where shared-storage scenarios come up directly.

Putting It Together — A Concrete PVC + Pod Example

# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi

# Referenced in a pod spec (Ch.5's structure, Ch.7's mounting pattern)
volumes:
  - name: app-data
    persistentVolumeClaim:
      claimName: data-pvc
containers:
  - name: app
    volumeMounts:
      - name: app-data
        mountPath: /data

This is genuinely the same mounting mechanism as Chapter 7's Secret volume — just a different volume source underneath.

When to Actually Use Persistent Storage

Matching this course's own honest "when you don't need X" convention from Chapter 1: stateless applications — most web and API servers — generally don't need persistent volumes at all. They should store state in an external database or object store (cloud1-4's object storage material) rather than local pod storage. Persistent volumes are genuinely needed for stateful workloads specifically — databases, message queues with local state — directly foreshadowing Course 2's k8s2-1 StatefulSets chapter.

Hands-On Exercises

Exercise 1

Explain the difference between an emptyDir Volume and a PersistentVolume, specifically regarding what pod-lifecycle events each one survives.

📄 View solution

Exercise 2

Explain the relationship between a PersistentVolumeClaim and a PersistentVolume, and explain the structural parallel to Chapter 6's Service/pod relationship.

📄 View solution

Exercise 3

A team is deploying a stateless REST API that doesn't store any of its own data locally — it reads and writes to an external managed database. Should they configure a PersistentVolume for their pods? Justify your answer using this chapter's "when to actually use persistent storage" material.

📄 View solution

Chapter 8 Quick Reference

Container filesystems are ephemeral — the same disposability problem as Chapter 3, now applied to data
emptyDir Volume — tied to pod lifetime, survives container restarts, NOT pod replacement
PersistentVolume (PV) — a real cluster storage resource, independent of any specific pod
PersistentVolumeClaim (PVC) — a pod's request for storage, matched/bound to a PV — the same decoupled-claim pattern as Chapter 6's Services
StorageClass — defines dynamic provisioning; the practical default on managed Kubernetes
RWO (single node) vs. ROX (many, read-only) vs. RWX (many, read-write, needs a backend like NFS)
Stateless apps generally don't need persistent storage at all — use an external database/object store instead
Next chapter: Ingress & Exposing Services Externally — Ingress controllers, path/host-based routing