Do I have to explicitly create Persistent Volume when I am using Persistent Volume Claim?

2.6k views Asked by At

I am new to Kubernetes, and I struggle to understand whol idea behind Persistent Storage in Kubernetes.

So is this enough or I have to create Persistent Volume and what will happen if I deploy only these two object without creating PV?

Storage should be on local machine.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  name: nginx-logs
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
status: {}
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: app-web
  name: app-web
spec:
  selector:
    matchLabels:
      app: app-web
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: app-web
    spec:
      containers:
        image: nginx:1.14.2
        imagePullPolicy: Always
        name: app-web
        volumeMounts:
        - mountPath: /var/log/nginx
          name: nginx-logs
      restartPolicy: Always
      volumes:
      - name: nginx-logs
        persistentVolumeClaim:
          claimName: nginx-logs
3

There are 3 answers

1
Howard_Roark On BEST ANSWER

You can see in the doc that it mentions a Dynamic way of provisioning persistent volumes.

When none of the static PVs the administrator created match a user's PersistentVolumeClaim, the cluster may try to dynamically provision a volume specially for the PVC. This provisioning is based on StorageClasses: the PVC must request a storage class and the administrator must have created and configured that class for dynamic provisioning to occur. Claims that request the class "" effectively disable dynamic provisioning for themselves.

When I apply your pvc, it creates a gp2 volume because that is my default storage class.

$kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nginx-logs   Bound    pvc-b95a9d0c-ef46-4ff0-a034-d2dde1ac1f96   1Gi        RWO            gp2            6s

You can see your default storage class like this

$kubectl get storageclass
NAME            PROVISIONER                                           AGE
gp2 (default)   kubernetes.io/aws-ebs                                 355d

You can also include a specific storage class. You can read more about that here.

Users request dynamically provisioned storage by including a storage class in their PersistentVolumeClaim

In short, your current pvc file will use your default storage class to create a Persistent Volume and then you are mounting that volume into your pod via your Persistent Volume Claim in your Deployment.

2
Arghya Sadhu On

A PV which matches with the PVC in terms of capacity(100Mi) and accessModes(ReadWriteOnce)is needed.If you don't have a PV you get error pod has unbound immediate PersistentVolumeClaims. So either you create the PV manually(called static provisioning) or rely on storage class and volume driver to do it automatically(called dynamic provisioning).

A PV is a kubernetes representation of volume. The actual volume still need to be provisioned.If you use dynamic volume provisioning and your cloud provider has a volume driver the provisioning is automated internally by the driver without needing to create a PV manually.

In a local non cloud system you can use local path provisioner to use dynamic provisioning. Configure a default storage class and you can avoid manual PV creation.

2
Jonas On

I struggle to understand whole idea behind Persistent Storage in Kubernetes

The idea is to separate the storage request that the app needs, and the physical storage - such that an app can be moved to e.g. other cloud provider that has a different storage system - but without needing any changes in the app. It also separates the responsibility for "requesting storage" and managing the underlying storage e.g. developers vs operations.

So is this enough or I have to create Persistent Volume and what will happen if I deploy only these two object without creating PV?

This depends on you environment. Most environments typically have Dynamic Volume Provisioning, e.g. the big cloud providers and now also Minikube has support for this.

When using dynamic volume provisioning, the developer only has to create a PersistentVolumeClaim - and no PersistentVolume, its instead dynamically provsioned.