Skip to content

Kubernetes Storage Management

Kubernetes Storage Management is the process of provisioning, attaching, and managing persistent storage for containerized applications. Unlike compute resources, storage requires special handling to ensure data persists beyond the lifecycle of a specific Pod^[kubernetes-storage.md].

Because containers are typically ephemeral, Kubernetes provides a robust API to abstract underlying storage hardware (NFS, Cloud Disks, etc.) into consumable resources^[kubernetes-storage.md]. This abstraction decouples the storage logic from the application logic, allowing developers to request storage without needing to know the specific infrastructure details^[kubernetes-storage.md].

Core Concepts

Kubernetes storage management relies on a layered architecture involving three primary API resources^[kubernetes-storage.md]:

  1. PersistentVolume (PV): Represents a piece of storage in the cluster (e.g., a GCE Persistent Disk, an NFS share, or a local directory). PVs are cluster resources, independent of Pods^[kubernetes-storage.md].
  2. PersistentVolumeClaim (PVC): A request for storage by a user. It is similar to a Pod "consuming" node resources; a PVC "consumes" PV resources^[kubernetes-storage.md]. PVCs request specific sizes and access modes (e.g., ReadWriteOnce).
  3. StorageClass: An administrator-defined policy that describes different "classes" of storage (e.g., "fast," "slow"). It allows for Dynamic Provisioning, meaning PVs do not need to be created manually; they are generated automatically when a PVC claims them^[kubernetes-storage.md].

Access Modes

Kubernetes defines specific access modes to control how a volume can be mounted to a node^[kubernetes-storage.md]:

  • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node^[kubernetes-storage.md].
  • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes^[kubernetes-storage.md].
  • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes^[kubernetes-storage.md].

Data Flow and Lifecycle

When an application requires persistent storage, the interaction follows a specific lifecycle^[kubernetes-storage.md]:

  1. Claiming: The developer creates a PersistentVolumeClaim specifying the desired size and access mode^[kubernetes-storage.md].
  2. Provisioning:
    • If a StorageClass is used, the provisioner creates a backend storage instance automatically (Dynamic Provisioning)^[kubernetes-storage.md].
    • Alternatively, an administrator may manually create a PersistentVolume that matches the claim (Static Provisioning)^[kubernetes-storage.md].
  3. Binding: The control plane binds the PVC to a matching PV. Once bound, that PVC is exclusively bound to that PV^[kubernetes-storage.md].
  4. Usage: A Pod references the PVC. The kubelet on the node mounts the volume and makes it available to the container's filesystem^[kubernetes-storage.md].
  5. Reclaiming: When the PVC is deleted, the PV becomes "Released." The data can be retained (manually reclaimed) or deleted based on the persistentVolumeReclaimPolicy (e.g., Delete or Recycle)^[kubernetes-storage.md].

Common Storage Types

Kubernetes supports various storage backends through plugins^[kubernetes-storage.md]:

  • Networked Storage: NFS, Ceph RBD, AWS EBS, Azure Disk, GCE PD.
  • Local Storage: local storage types allow Pods to access local node disks (useful for high-performance needs), but require manual scheduling to ensure the Pod lands on the correct node^[kubernetes-storage.md].

Sources

  • kubernetes-storage.md