Kubernetes Storage and Volumes

Kubernetes Storage and Volumes is the set of abstractions through which containers gain access to filesystem storage that survives beyond a single container's lifetime, is shared among containers within a Pod, or persists independently of any particular Pod's existence. Because containers are inherently ephemeral, with their writable layer discarded when they exit, Kubernetes introduces a distinct volume model layered on top of the underlying container runtime's storage to provide durability and sharing where an application requires it.

The Volume Abstraction

Volumes Are Pod-Scoped

A Kubernetes volume is defined at the Pod level and mounted into one or more of its containers at specified paths. Its lifetime is tied to the Pod that defines it by default: an ephemeral volume is created when the Pod starts and destroyed when the Pod is removed, unlike a container's own filesystem, which is discarded and recreated on every container restart within the same Pod.

apiVersion: v1
kind: Pod
metadata:
  name: codartium-cache-demo
spec:
  containers:
    - name: writer
      image: busybox:1.36
      command: ["sh", "-c", "echo data > /cache/output.txt && sleep 3600"]
      volumeMounts:
        - name: shared-cache
          mountPath: /cache
    - name: reader
      image: busybox:1.36
      command: ["sh", "-c", "sleep 5 && cat /cache/output.txt"]
      volumeMounts:
        - name: shared-cache
          mountPath: /cache
  volumes:
    - name: shared-cache
      emptyDir: {}

Ephemeral Volume Types

emptyDir creates an initially empty directory shared across the containers in a Pod, useful for scratch space or inter-container data exchange, which is deleted permanently when the Pod is removed. configMap and secret volumes project configuration data or sensitive values directly into a Pod's filesystem as files, sourced from those respective API objects rather than external storage systems.

Persistent Storage

PersistentVolume

A PersistentVolume (PV) represents a piece of storage in the cluster that has been provisioned, either in advance by an administrator or dynamically on demand, independent of any individual Pod that might use it. A PV has its own lifecycle, distinct from any Pod, and encapsulates the details of the actual storage backend.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: codartium-data-pv
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: codartium.io/csi-driver
    volumeHandle: vol-0a1b2c3d

PersistentVolumeClaim

A PersistentVolumeClaim (PVC) is a request for storage made by a user, specifying a required size, access mode, and optionally a StorageClass, which the cluster binds to a matching PersistentVolume. Pods reference storage indirectly through a PVC, keeping application manifests independent of the specific underlying storage implementation.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: codartium-data-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd

spec:
  containers:
    - name: db
      image: codartium/db:9.4
      volumeMounts:
        - name: data
          mountPath: /var/lib/data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: codartium-data-claim

StorageClass and Dynamic Provisioning

Provisioning on Demand

A StorageClass defines a category of storage, backed by a specific provisioner, and a set of parameters describing how volumes of that class should be created. When a PVC specifies a StorageClass and no matching PersistentVolume exists, the associated provisioner dynamically creates one, eliminating the need for administrators to pre-provision volumes manually.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: codartium.io/csi-driver
parameters:
  type: ssd
  iopsPerGB: "50"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Volume Binding Mode

WaitForFirstConsumer delays volume binding and provisioning until a Pod using the claim is actually scheduled, allowing the scheduler to take storage topology, such as availability zone, into account when choosing a node, rather than binding a volume before the Pod's eventual placement is known.

Access Modes and Reclaim Policy

Access Modes

ReadWriteOnce permits mounting by a single node at a time; ReadOnlyMany permits mounting read-only by multiple nodes simultaneously; and ReadWriteMany permits mounting read-write by multiple nodes simultaneously, a capability that depends on the underlying storage backend and is not universally available.

Reclaim Policy

The reclaimPolicy of a PersistentVolume determines its fate once its bound claim is deleted: Delete removes the underlying storage resource along with the PV, while Retain preserves both, requiring manual intervention to reuse or clean up the storage, a choice with direct consequences for accidental data loss risk.

Container Storage Interface (CSI)

Standardizing Storage Integration

The Container Storage Interface (CSI) is a standardized API through which external storage systems integrate with Kubernetes, allowing storage vendors to implement drivers independently of the core Kubernetes codebase, and allowing Kubernetes to support a wide range of storage backends through a uniform PersistentVolume and PersistentVolumeClaim interface.

kubectl get storageclass
kubectl get pv
kubectl get pvc -n codartium-team
kubectl describe pvc codartium-data-claim -n codartium-team

Volume Snapshots

CSI drivers that support it enable VolumeSnapshot objects, allowing point-in-time snapshots of a PersistentVolume to be created and later used to provision new volumes pre-populated with that snapshot's data, supporting backup and restore workflows for stateful applications running on the cluster.