DEV Community

Madhavam Saxena
Madhavam Saxena

Posted on

Persistent Volumes and Persistent Volumes Claims

Persistent Volumes:
Persistent volumes is the concept that comes into play when disadvantages of hostpath are observed. Persistent volumes, unlike hostpath and emptydir, are simply independent of pods and slave / worker Node, hence, data stored in persistent volumes is available even after a pod or even a slave / worker node crashes.

Persistent Volume Claim:
PVC is present on the slave / worker node which is basically connected to a persistent volume. With the help of this connection, worker / slave nodes and pods are able to write into a persistent volume.
A single claim can be attached to multiple persistent volumes, also, different volume claims on different volumes, attached with different pods on different node, i.e. you’ve full flexibility with the volumes and data remains available.

Defining Persistent Volume:

apiVersion: v1
kind: PersistentVolume
metadata:
    name: host-pv
spec:
    capacity:
        storage: 4Gi
        volumeMode: Filesystem
        accessMode:
            - ReadWriteOnce
            # - ReadOnlyMany
            # - ReadWriteMany
    hostPath:
        path: /data
        type: DirectoryOrCreate
Enter fullscreen mode Exit fullscreen mode

spec.capacty: Defines the capacity of the volumes.
spec.capacity.storage: Here we define the size of persistent volume in Gi format which basically is defining a Gb.
spec.capacity.volumeMode: It is of two types:
Filesystem
Block
spec.capacity.accessMode: As the name suggests, it defines the mode of access. Since I’ve takes example of hostPath, therefore, I only can use ReadWrtiteOnce access mode as hostPath allows different pods within same slave / worker node to write into the volume, therefore only these pods can access it and ReadWriteOnce access mode defines that Different number of pods can access a persistent volume that are part of same salve / worker node.

Persistent Volumes Claims:
Persistent volume claims are used to map the pods with the persistent volumes, hence this claim needs to be defined in the pod that needs to access the persistent volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: host-pvc
spec:
    volumeName: <name_of_the_volume_that_is_to_be_mapped>
                host-pv
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: <counter_part_of_volume_Defined_in_deployment.yml>
                     1Gi
Enter fullscreen mode Exit fullscreen mode

spec.resources: defines the resource
spec.resources.requests: requests the resource
spec.resources.requests.storage: maximum as that is defined in the deployment.yml

Adding this Persistent Volume claim in the pods:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: story_deployment
spec:
    replicas: 1
    selector:
        matchLabels:
            app: story
    spec:
        template:
            metadata:
                labels:
                    app: story
            containers:
                - name: story
                  image: deocker_repo/<image_name>
                  volumeMounts:
                    - mountPath: /app/story
                      name: story-volume
            volumes:
                - name: story-volumes
                  persistentVOlumeClaim:
                    claimName: <name_of_the_persistent_volume_claim>
Enter fullscreen mode Exit fullscreen mode

Top comments (0)