Introduction to Kubernetes Volumes

 

Persist and share data in Kubernetes

Containers are ephemeral by nature. Any data written to a container’s filesystem is lost when the container restarts or the Pod is rescheduled. Kubernetes volumes solve this problem by providing directories that are mounted into containers and backed by different storage media.

---

What Is a Volume?

From a container’s perspective, a volume is just a directory.
What changes between volume types is:

• How the directory is created
• Which storage backend is used
• How long the data lives

As the Kubernetes documentation summarizes it: volumes are directories, possibly with data, that are accessible to containers in a Pod.

---

How Volumes Are Defined

Using volumes is always a two-step process:

1. Declare volumes at the Pod level

   spec:
     volumes:
       - name: my-volume
         emptyDir: {}
   

2. Mount volumes inside containers

   spec:
     containers:
       - name: app
         volumeMounts:
           - name: my-volume
             mountPath: /data
   

The volume name must match between volumes and volumeMounts.

Volumes such as PersistentVolumes, ConfigMaps, and Secrets must already exist before the Pod is created.

---

Volume Lifecycle Overview

• Volumes live outside the container
• Some volumes follow the Pod lifecycle
• Others outlive Pods and even container restarts
• Storage backends can be local, cloud-based, or network-attached

---

Common Kubernetes Volume Types

Volume Type	When to Use
emptyDir	Temporary storage inside a Pod. Data is deleted when the Pod is terminated.
local	Persistent storage tied to a specific node. Requires node affinity. Preferred over hostPath.
PersistentVolume	Durable storage backed by cloud or on‑prem storage. Can be statically or dynamically provisioned.
ConfigMap	Inject configuration data into Pods without hard‑coding values.
Secret	Inject sensitive data (tokens, passwords, keys) securely into Pods.

---

emptyDir

• Created when the Pod starts
• Deleted when the Pod stops
• Shared between containers in the same Pod
• Useful for:
  • Scratch space
  • Temporary files
  • Inter-container data sharing

---

local Volumes

• Stored on a specific node
• Data survives Pod restarts
• Data does not survive node failure
• Requires:
  • PersistentVolume
  • PersistentVolumeClaim
  • Node affinity

hostPath is discouraged due to security risks. local volumes are the recommended alternative.

---

Persistent Volumes (PV & PVC)

Persistent Volumes abstract storage from Pods.

Static provisioning

• Admin creates the PV first
• Pod claims it using a PVC

Dynamic provisioning

• Pod creates a PVC
• Kubernetes provisions the PV automatically

Supported by many backends:

• AWS EBS / EFS
• GCP Persistent Disks
• Azure Disks
• NFS
• CSI drivers

---

ConfigMaps and Secrets as Volumes

Both can be mounted as files:

• Each key becomes a file
• File content equals the value
• Ideal for configuration and credentials

Advantages:

• No hard-coded values
• Easy updates
• Environment-specific configuration

---

Storage Backends and CSI

Kubernetes supports many storage backends and allows custom ones via CSI (Container Storage Interface).

CSI enables:

• Custom storage drivers
• Vendor-neutral integrations
• Dynamic provisioning support

If you need a custom storage solution, CSI is the correct starting point.

---

Key Takeaways

• Containers are ephemeral; volumes provide persistence
• Volumes are directories from the container’s view
• Storage lifecycle depends on volume type
• Use:
  • emptyDir for temporary data
  • local for node-bound persistence
  • PersistentVolume for durable storage
  • ConfigMap and Secret for configuration

---