How to Add Persistent Storage to Kubernetes Pods – CloudSavvy IT

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 kubectl apply

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 Bound

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

Within the 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 volumes and volumeMountsThe volume is placed in your pod in the location indicated by mountPath

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.

Storage classes

The 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.

Access modes

There are three supported values ​​for the accessModes field:

• 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 ReadOnlyManyReadWriteMany 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.

Conclusion

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.