Can we get Persistent Volume with only PVC (without PV) in k8s?
I just saw a yaml file for Postgres with PersistentVolumeClaim and volumeMounts and volumes with the persistentVolumeClaim in the postgres container. I couldn't find any PersistentVolume defined.
However, when the postgres container pod has been brought up, I can see a PersistentVolume bound to the persistentVolumeClaim defined in the yaml file.
So will k8s create the PersistentVolume if we only define the PersistentVolumeClaim?
Similar Questions
2 Answers
yea that's correct, so when your cluster has dynamic provisioning with storage-classes then you just need to provide the PVC , provisioner will get relevant information from PVC and storageClass, then based on these info it will create the PV.
Provisioning of PV happens dynamically
When none of the static PVs the administrator created matches 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 in order for dynamic provisioning to occur. dynamic-provisining
For example here you provide the following info in PVC
StorageClassName
Requested Storage size
AccessModes
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3GiIn the StorageClass you provide the following information
Provisioner
Other information
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: manual
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Retain
volumeBindingMode: Immediate
- PVC is a namespace scoped kubernetes object but storageclass in a cluster scope k8s object. So there is always a default storageclass in your cluster.so when you do not specify the name of the storgaeclass in your pvc, PV will be provisioned from the default storage class.
kubectl get sc,pvc,pv will provide the relevant information
Actually, It has been done by
Dynamic provisioning of PersistentVolumes.
PersistentVolumes and PersistentVolumeClaims makes it easy to obtain persistent storage without the developer having to deal with the actual storage technology used underneath. But this still requires a cluster administrator to provision the actual storage up front. You think, PersistentVolumes have to been created, but It don't has to be like that all time. Luckily, Kubernetes can also perform this job automatically through dynamic provisioning of PersistentVolumes.
The cluster admin, instead of creating PersistentVolumes, can deploy a PersistentVolume provisioner and define one or more StorageClass objects to let users choose what type of PersistentVolume they want. The users can refer to the StorageClass in their PersistentVolumeClaims and the provisioner will take that into account when provisioning the persistent storage.
The kubernetes make it get simplier by including default StoregeClass definitions. You don't have to point a StorageClass in the yaml manifest like the following:
The PVC yaml file:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgresdb-pvc
spec:
resources:
requests:
storage: 1Gi
accessModes:
- ReadWriteOnce
This PVC definition includes only the storage size request and the desired accessmodes, but no storage class. When you create the PVC, whatever storage class is marked as default will be used.
$ kubectl get pvc postgresdb-pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS
postgresdb-pvc Bound pvc-95a5ec12 1Gi RWO standard
$ kubectl get pv pvc-95a5ec12
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS STORAGECLASS
pvc-95a5ec12 1Gi RWO Delete Bound standardThis image that it is from Kubernetes In Action book, summarize all steps, perfectly.
