What Are Kubernetes Persistent Volumes? Ordinarily, containers in a Kubernetes cluster are immutable. This means that when you shut down a container, any information stored within it is lost. This is suitable for stateless applications, but in order to run stateful applications like databases in Kubernetes, you will need persistent storage. To enable persistent storage that survives the shutdown of a container or pod, Kubernetes provides a persistent volumes subsystem. It provides API objects to let you allocate and manage storage resources persistently. You can set up persistent storage using the following API resources: —each PV represents a storage resource available within the cluster. Unlike ephemeral volumes, the lifecycle of a PV is independent of any pod using it. This ensures that the storage remains persistent. Administrators can provision PVs manually. Kubernetes can also dynamically provision PVs using storage classes. PersistentVolume (PVs) —each PVC represents a request for storage. A PVC can consume only a PV resource that meets its size and access modes requirements. If a relevant PV is available, it is bound to the PVC. Otherwise, Kubernetes dynamically provisions a PV or the request fails. PersistentVolumeClaims (PVCs) For more background see this . blog about Kubernetes Persistent Volumes Kubernetes Storage Concepts Kubernetes Storage Class Kubernetes lets administrators define that are abstracted from the storage implementation. It enables users to request the specific StorageClass relevant to each PVC without specifying all storage requirements. StorageClasses Administrators can create various types of StorageClasses, each defined differently for the provisioner, parameters, and reclaimPolicy. It lets you set up StorageClasses that provide different performance, such as HDD or SSD, costs, and applications. The provisioner lets you tie a StorageClass to specific backends, such as AWS EBS or Azure Files, and a storage endpoint. Additional parameters are available according to the chosen provisioner to help you describe the volumes for each StorageClass using parameters like , , , or . type zone server path Kubernetes StatefulSet A is a workload API object for managing stateful applications. It lets you define a set of pods with unique network identifiers to be deployed and scaled in a specific order. StatefulSets help manage persistent storage across a Kubernetes cluster. Kubernetes StatefulSet Pods associated with a StatefulSet are assigned a unique identity comprised of stable storage, an ordinal, and a stable network identity. This identifier sticks to the pods and the StatefulSet maintains it across scheduling and rescheduling. Learn more in this . blog about Kubernetes networking Kubernetes CSI Plugins Container Storage Interface (CSI) plugins help make third-party storage available for your Kubernetes cluster. It helps introduce persistent storage to containerized applications. CSI plugins receive PVC requests that specify the third-party vendor as a provisioner and then create and mount the requested volume. Lifecycle of PVs and PVCs A PVC is a request for a PV that exists as a storage resource within a Kubernetes cluster. A PVC is tied to a matching PV to ensure storage remains persistent. As a result, the lifecycle of PVs and PVCs is usually tightly connected. Provisioning Kubernetes provides the following types of provisioning for persistent storage: —this type of provisioning is available for cluster administrators. It enables admins to manually create PV resources and make them available to all cluster users. Once the PV exists within the Kubernetes API, users can create a PVC request for a pod to consume a PV resource. Static —this type of provisioning is available for a Kubernetes cluster. It enables the cluster to automatically provision a PV to match a PVC according to predefined StorageClasses. Dynamic provisioning typically occurs when non of the PVs statically provisioned match a PVC. Dynamic Binding A control loop monitors new PVCs. Once a user creates a new PVC, the control loop searches for a marching PV that meets the PVC requirements. It looks to satisfy the requested amount of storage and may do so using a PV that exceeds the request. Here is how this process works: If the control loop finds a matching PV, it binds it to the PVC. Binding ensures that the PV and PVC remain exclusive. If the control loop cannot find a PV that meets the PVC requirements for access mode and storage size, it dynamically provisions a new PV according to the StorageClass and binds it to the PVC. If no PV is available for a PVC—static or dynamic—the PVC remains unbound indefinitely. Using Kubernetes pods use PVCs as volumes. Users can specify an access mode for the PVC, and the cluster mounts the bound PV to the pod. When using volumes that support multiple access modes, the user must specify the desired mode. Once a user gets a bound PVC, the bound PV also belongs to that user. Reclaiming Once a user no longer needs to use a volume, it can be deleted or retained. Users can delete a PVC object directly from the API that enables them to reclaim this resource. Otherwise, the PV’s reclaim policy defines what the cluster should do with a volume that was released of its claim. Quick Tutorial: Working with Persistent Volumes This tutorial is adapted from the full persistent storage tutorial in the . Kubernetes documentation Before starting this tutorial, set up a Kubernetes cluster on your local machine with only one node. Ensure that kubectl is installed on your machine and communicating successfully with the cluster. You can easily create a one-node cluster with . Minikube Step 1: Create a File On the Node Because we are working with persistent storage, we need to create a static file and demonstrate that this file persists even after we shut down a node. Open a shell to your node, create a directory named , and inside it create an file with the text “Hello World Persistent Volume”. /mnt/data index.html Step 2: Create a Persistent Volume To create a persistent volume, open a text editor and copy-paste the YAML code below. apiVersion: v1 kind: PersistentVolume metadata: name: my-pv-volume labels: type: local spec: storageClassName: manual capacity: storage: 6Gi accessModes: —ReadWriteOnce hostPath: path: "/mnt/data" Save the YAML file as in your local directory. Deploy the persistent volume by running this command: my-pv-volume.yaml kubectl create -f my-pv-volume.yaml Step 3: Create a Persistent Volume Claim Create a PVC specification by opening your text editor and copying the YAML code below: apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pv-claim spec: storageClassName: manual accessModes: —ReadWriteOnce resources: requests: storage: 2Gi Save the file in your local directory as . Deploy it using this command:** my-pv-claim.yaml kubectl apply -f my-pv-claim.yaml Step 4: Create a Pod and Mount the PVC as a Volume Now it gets interesting—let’s create a pod that mounts this PVC so it can make use of our persistent volume. Copy the following code to your text editor: apiVersion: v1 kind: Pod metadata: name: my-pv-pod spec: volumes: —name: my-pv-storage persistentVolumeClaim: claimName: my-pv-claim containers: —name: my-pv-container image: nginx ports: —containerPort: 80 name: "http-server" volumeMounts: —mountPath: "/usr/share/nginx/html" name: my-pv-storage Notice that the pod specifies the PVC, it does not directly reference the PV. Kubernetes is responsible for matching this pod with a PV that meets its requirements, based on the information in the PVC. In our case it is simple because there is only one PV. Save the pod spec in your local directory as . Deploy the pod by running this command: my-pv-pod.yaml kubectl apply -f my-pv-pod.yaml Ensure the pod is running: kubectl get pod my-pv-pod Step 5: Verify that the Pod Has Access to Persistent Storage Let’s see if our pod can access the file we saved in persistent storage at the beginning of the tutorial. The important thing here is that pod you create using this specification will have access to the same storage—even after you shut down or delete the pod, the file will persist. any Run this command to bash into the container: kubectl exec -it my-pv-pod -- /bin/bash Once you are running in the root shell of your container, run these commands: apt update apt install curl curl http://localhost/ You should see the content of your index.html files: Hello World Persistent Volume Congrats! You just created a pod that has access to a Persistent Volume via a Persistent Volume Claim. Conclusion In this article, I explained the basics of Kubernetes persistent storage, explained the concepts of Persistent Volumes and Persistent Volume Claims, and showed how to set up a quick demo of a pod that mounts a PVC: 1. Create a one-node cluster using Minikube. 2. Create an HTML file on the node. 3. Create a Persistent Volume YAML file and deploy it using . kubectl 4. Create a Persistent Volume Claim YAML file and deploy it using . kubectl 5. Create a Pod YAML which mounts the PVC as a volume, and deploy it using . kubectl 6. Bash into the container and use curl to view the HTML file from step 2—this proves that your container has access to a persistent volume. I hope this will be useful as you take your first steps in Kubernetes storage management.
