Kubernetes Pod file systems are ephemeral by default. This is in line with the stateless nature of containers. Persistent data must be stored outside of the container, even if it appears to be in the container’s file system. Here’s how to provision permanent storage in Kubernetes.
The base unit of Kubernetes persistent storage is a persistent volume. This is an abstraction from the more fundamental Volume.
Permanent volumes exist independently of a specific pod. As with regular Docker volumes, the Kubernetes Persistent Volumes can remain in your cluster even if there are no pods using them.
Pods can access permanent volumes through a Sustained volume claimThis is another resource type that represents a pod̵
A simple example
Let’s take a look at how to create a permanent storage system by manually setting a Persistent Volume and Persistent Volume Claim. Each resource goes to its own manifest file. You can apply these files to your cluster with
Create lasting volume
Start creating your volume:
apiVersion: v1 kind: PersistentVolume metadata: name: my-volume namespace: pvc-demo spec: storageClassName: manual capacity: storage: 2Gi accessModes: - ReadWriteOnce hostPath: path: /mnt/data
This definition creates a volume named
my-volumeIt has a capacity of 2Gi and is stored on
/mnt/data on the host node. Since we are creating this volume manually, it is
storageClassName Gets up
manualStorage classes can be used to require volumes to be bound only to volume claims that request the same class.
Make a permanent volume claim
You can now configure a persistent volume claim:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-volume-claim namespace: pvc-demo spec: storageClassName: manual accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
The claim calls for 1Gi storage of a volume using the
manual class. The volume we created earlier can meet these conditions. When the claim is created, Kubernetes must realize this and bind the claim to the volume.
If you were to inspect the details of the volume and claim, you would see that they both have the status of
kubectl get pv my-volume kubectl get pvc my-volume-claim
Add a pod
The final step is to use your volume claim to add permanent storage to a pod.
apiVersion: v1 kind: Pod metadata: name: my-pod namespace: pvc-demo spec: containers: - name: my-container image: my-image:latest volumeMounts: - mountPath: /path/in/container name: my-pod-volume volumes: - name: my-pod-volume persistentVolumeClaim: claimName: my-volume-claim
volumes section configures a reference to the Persistent Volume Claim. You do not need to provide any other information about the volume. The Pod uses the claim, which provides the volume to which it is bound.
The claim is referenced in
volumeMountsMake sure to use the same name in
volumeMountsThe volume is placed in your pod in the location indicated by
Your pod now has permanent storage space available. Everything that is written to
/path/in/container is stored on the permanent volume. The Persistent Volume Claim will be reused by new Pods referencing it, allowing data to outlive each individual Pod.
manual storage class is used when you create your own volume and volume claim manifests. Different volume plug-in drivers provide their own storage classes. Refer to the storage class that represents the volume type you want to use.
Managed Kubernetes services typically offer their own storage classes tailored for the platform’s block storage implementation. Examples include
gcePersistentDisk with Google Kubernetes Engine, or
do-block-storage with DigitalOcean Managed Kubernetes.
In these scenarios, you don’t have to
PersistentVolume manifest manually. make a
PersistentVolumeClaim with the proper
storageClassName and use the
resources.requests.storage field (shown above) to specify the desired capacity. The storage driver automatically associates the claim with a compatible volume instance.
There are three supported values for the
ReadWriteOnce– The volume can only be mounted on a single Kubernetes node. That node has full read and write access to the volume.
ReadOnlyMany– The volume can be consumed by multiple nodes at the same time. Each node has read-only access (nothing can write to the volume).
ReadWriteMany– The volume can be attached to multiple nodes at the same time. Any node can read and write to the volume.
Only one access mode can be used for a given volume at a time. That means that two volume claims will only bind to the same volume if both claims specify the same access mode.
The access mode of your volumes affects the Kubernetes scheduler’s ability to span replicas of your pods across multiple nodes. The
ReadWriteMany modes should be used if you need pods to share persistent storage and are replicated across multiple nodes.
Note that not all storage drivers support all access modes – you will need to contact your plug-in provider. A non-exhaustive list of volume plugins and compatible access modes can be found in the Kubernetes documentation.
Persistent storage in Kubernetes isn’t as daunting as it might seem at first glance. Make sure pods that need storage access have volumes bound to a persistent volume claim.
When using persistent volume claims, Kubernetes creates persistent volumes that survive individual pods. When your pods are replaced, the claimed volumes are automatically mounted in the new pods. The data will not be destroyed until the claim has been deleted.