Kubernetes Storage Definition

Kubernetes Storage Definition is the precise characterization of the layered abstractions, Volume, PersistentVolume, PersistentVolumeClaim, and StorageClass, through which Kubernetes formally represents filesystem storage, ranging from ephemeral, Pod-scoped scratch space to durable, independently provisioned storage backed by external systems, and binds that storage to the containers that consume it. Each layer is formally defined by a distinct scope of lifetime and a distinct party responsible for declaring it, together forming a chain from raw storage capacity to a mounted directory inside a running container.

Volume: The Pod-Scoped Abstraction

Formal Lifetime Binding

A Volume is formally defined at the Pod level, in spec.volumes, and its lifetime is bound to that of the Pod that declares it, for ephemeral volume types, meaning it is created when the Pod starts and irrevocably destroyed when the Pod is removed, independent of any individual container's own restarts within that Pod.

Mount as a Container-Level Reference

A Volume declared at the Pod level becomes visible inside a specific container only through that container's volumeMounts, formally a separate reference naming the volume and the filesystem path at which it should appear, meaning a single Pod-level volume can be mounted into multiple containers within the same Pod simultaneously.

spec:
  volumes:
    - name: shared-cache
      emptyDir: {}
  containers:
    - name: writer
      volumeMounts:
        - name: shared-cache
          mountPath: /cache

PersistentVolume: Storage Independent of Any Pod

Formal Independence from Pod Lifecycle

A PersistentVolume (PV) is formally an object in its own right, with a lifecycle entirely independent of any Pod, or even any PersistentVolumeClaim, that might reference it. It represents a specific piece of provisioned storage, existing whether or not anything is currently consuming it.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: codartium-data-pv
spec:
  capacity:
    storage: 20Gi
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Retain

Cluster-Scoped by Definition

A PersistentVolume is formally cluster-scoped, not namespaced, reflecting that it represents a resource of the cluster's infrastructure rather than an artifact belonging to any one application or team.

PersistentVolumeClaim: The Binding Request

Formal Role as an Indirection Layer

A PersistentVolumeClaim (PVC) is formally a namespaced request for storage meeting specified criteria, size, access mode, and optionally a StorageClass, which the control plane binds to a satisfying PersistentVolume. A Pod references storage only through a PVC, never a PersistentVolume directly, formally decoupling application manifests from any specific underlying storage implementation.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: codartium-data-claim
  namespace: codartium-team
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi

One-to-One Binding

A bound PersistentVolumeClaim and PersistentVolume are formally locked into a one-to-one relationship for the duration of that binding; a PersistentVolume, once bound, is not available to satisfy any other claim until the existing binding is released.

StorageClass: Provisioning Policy

Formal Definition as a Provisioning Template

A StorageClass is formally a named category of storage, associated with a specific provisioner and a set of parameters, that governs how a PersistentVolume should be dynamically created when a PVC references that class and no existing PersistentVolume already satisfies it.

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

Dynamic vs. Static Provisioning

Static provisioning is formally defined as an administrator creating a PersistentVolume in advance, for a PVC to later bind to; dynamic provisioning is formally defined as a PersistentVolume being created automatically, on demand, by a StorageClass's provisioner in response to an otherwise unsatisfiable PVC.

Access Modes as a Formal Constraint

The Three Defined Modes

ReadWriteOnce formally permits mounting by a single node at a time; ReadOnlyMany formally permits simultaneous read-only mounting by multiple nodes; ReadWriteMany formally permits simultaneous read-write mounting by multiple nodes, with support for each mode determined by the underlying storage backend rather than by Kubernetes itself.

kubectl get pv,pvc -n codartium-team
kubectl describe storageclass fast-ssd

Why Storage Is Layered This Way

The formal separation between Volume, PersistentVolume, PersistentVolumeClaim, and StorageClass exists to isolate three independently varying concerns, a Pod's need for storage, the cluster's available storage capacity, and the policy governing how that capacity is provisioned, so that application manifests remain portable across clusters with entirely different underlying storage infrastructure.