Skip to content

Kubernetes PV PVC Storage Management

Kubernetes PV PVC Storage Management refers to the system within Kubernetes used to manage storage resources, decoupling storage from the lifecycle of Pods^[400-devops__06-Kubernetes__k8s-mysql__README.md]. It addresses the challenge of data persistence in an environment where containers are ephemeral, ensuring that data remains available even if the underlying compute resources are restarted or rescheduled^[400-devops__06-Kubernetes__k8s-mysql__README.md].

This management system relies on the interaction between two core API resources: Persistent Volumes (PV) and Persistent Volume Claims (PVC)^[400-devops__06-Kubernetes__k8s-mysql__README.md].

Core Concepts

PersistentVolume (PV)

A PersistentVolume represents a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes^[400-devops__06-Kubernetes__k8s-mysql__README.md]. It is a resource in the cluster, independent of any individual Pod, with a specific lifecycle of its own^[400-devops__06-Kubernetes__k8s-mysql__README.md].

PersistentVolumeClaim (PVC)

A PersistentVolumeClaim is a request for storage by a user^[400-devops__06-Kubernetes__k8s-mysql__README.md]. It acts similarly to a Pod: Pods consume node resources (CPU and RAM), while PVCs consume PV resources^[400-devops__06-Kubernetes__k8s-mysql__README.md].

The Binding Relationship

The system operates on a provisioning and binding model: * Provisioning: Storage can be provisioned statically (by an admin creating PVs) or dynamically (by the cluster creating PVs based on StorageClasses when a PVC is created)^[400-devops__06-Kubernetes__k8s-mysql__README.md]. * Binding: A PVC acts as a claim for a specific resource. The control plane looks for a PV that satisfies the claim's requirements (size, access mode) and binds the two together^[400-devops__06-Kubernetes__k8s-mysql__README.md]. Once bound, the PVC is the "ticket" allowing a Pod to access that specific storage^[400-devops__06-Kubernetes__k8s-mysql__README.md].

Management Workflow

In a practical scenario, such as deploying a database like [[MySQL]], the workflow typically follows these steps^[400-devops__06-Kubernetes__k8s-mysql__README.md]:

  1. Define Requirements: The user creates a PVC specifying the desired storage size and access mode (e.g., ReadWriteOnce).
  2. Provisioning:
    • If Dynamic Provisioning is enabled, Kubernetes automatically creates a matching PV (e.g., an AWS EBS volume, GCE PD, or Ceph RBD volume).
    • If static provisioning is used, an administrator must have already created a PV that matches the claim.
  3. Binding: The PVC binds to the available PV.
  4. Mounting: The Pod definition is updated to reference the PVC. Kubernetes then mounts the volume into the container's filesystem at a specific directory.

Access Modes

Kubernetes supports specific access modes for PVs, which determine how the storage can be mounted:

  • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node^[400-devops__06-Kubernetes__k8s-mysql__README.md].
  • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes^[400-devops__06-Kubernetes__k8s-mysql__README.md].
  • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes^[400-devops__06-Kubernetes__k8s-mysql__README.md].
  • ReadWriteOncePod (RWXOP): The volume can be mounted as read-write by a single Pod (preventing multiple Pods on the same node from accessing it).

Data Persistence Strategies

To ensure data integrity for stateful applications like databases, Pods managing critical data should not be treated as disposable. If a Pod managing a database dies, the new Pod must reconnect to the same data volume to function correctly^[400-devops__06-Kubernetes__k8s-mysql__README.md].

By using PVCs, the storage lifecycle is separated from the Pod lifecycle^[400-devops__06-Kubernetes__k8s-mysql__README.md]. This ensures that: * Data survives Pod crashes or deletions^[400-devops__06-Kubernetes__k8s-mysql__README.md]. * Data can be migrated between nodes (depending on the underlying storage driver). * Databases like MySQL do not lose their transaction logs or user data during updates to the deployment^[400-devops__06-Kubernetes__k8s-mysql__README.md].

Sources

^[400-devops__06-Kubernetes__k8s-mysql__README.md]