Kubernetes Persistent volumes
When dealing with persistent storage in Kubernetes, 3 key objects are important:
StorageClass provides a way for administrators to describe the “classes” of storage they offer. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators. This concept is sometimes called “profiles” in other storage systems.
A user would first create a bunch of StorageClass’s in the cluster and then create volumes (PVCs) that reference the StorageClass.
Let’s take an example.
In above StorageClass,
- provisioner: kubernetes.io/portworx-volume indicates that volumes should be provisioned by the Portworx driver
- parameters provide driver specific parameters. The Kubernetes controller simply passes these parameters as-is to the underlying driver (Portworx in this example).
- repl: “3” indicates that the Portworx volume needs to have 3 replicas
- io_profile: “db” indicates that the Portworx volume needs to have IO profile optimized for DB workloads.
This table lists all parameters that are supported by the Portworx driver.
allowVolumeExpansion cannot be added after the storage class has been created.
Let’s take a look at an example.
To resize a Portworx PVC, you can simply edit the PVC spec and update the size. Let’s take an example of resizing a MySQL PVC.
- Download the MySQL StorageClass spec and apply it. Note that the StorageClass has
- Download the MySQL PVC spec and apply it. We will start with a 5GB volume.
- Download the MySQL Deployment spec and apply it. Wail till the pod becomes 1⁄1 and then proceed to next step.
kubectl edit pvc mssql-dataand change the size in the “spec” to 10Gi.
After you save the spec,
kubectl describe pvc mssql-data should have an entry like below that confirms the volume resize.
Normal VolumeResizeSuccessful 5s volume_expand ExpandVolume succeeded for volume default/mssql-data
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
Let’s take an example.
In above PVC,
- name: postgres-db gives the name of the PVC.
- storageClassName: portworx-sc-db indicates that this PVC should be creating using the provisioner and parameters specified in the portworx-sc-db StorageClass.
- ReadWriteOnce indicates that only one pod is allowed to read and write to the volume.
- storage: 10Gi indicates this is a 10GiB PVC.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator.
When you create a PVC, behind the scenes, either a new PV is created (dynamic provisioning) or an existing PV is bound to the PVC. In other words, there is a one-one mapping between a PVC and a PV.
To find the PV that is being used by a PVC, you can do
kubectl get pvc <pvc-name>
An end user needs to interact with a PV only when using pre-provisioned volumes. For dynamically provisioned volumes, end users only create PVCs and the backing storage provider creates the PV.
ReadWriteMany and ReadWriteOnce
A PVC can be
- ReadWriteMany: In the mode, multiple pods can mount and volume and access it at the same time.
- This should be used by applications like web servers (nginx, wordpress etc) that can handle multiple instances writing to the same volume. It is not recommended to use for databases.
- ReadWriteOnce: In the mode, only a single pod can access the volume at a given time
shared: true in the StorageClass for the PVC.
- Interactive tutorial - Resize Kubernetes volumes using kubectl
- Interactive tutorial - Persistent volumes on Kubernetes using Portworx
- Interactive tutorial - Using Portworx Shared Volumes
- Interactive tutorial - Encrypting volumes on Kubernetes
- Kubernetes Storage documentation