What is use of using VOLUME ID while creating PV? - amazon-web-services

Question

Observed two kinds of syntaxes for PV & PVC creation in AWS EKS.
1)Using vol Id while creating both PV & PVC (Create volume manually and using that id)
2)Without using vol Id (dynamic provisioning of PV)
example-1:
- apiVersion: "v1"
kind: "PersistentVolume"
metadata:
name: "pv-aws"
spec:
capacity:
storage: 10G
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
storageClassName: gp2
awsElasticBlockStore:
volumeID: vol-xxxxxxxx
fsType: ext4
In this case, I am creating volume manually and using that I'm creating both PV & PVC
example-2:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2
resources:
requests:
storage: 20Gi
In this case by just creating PVC its creating volume in the backend (AWS) and PV.
What is the difference and in which to use in which scenarios? Pros and cons?

Answer 1

It should be based on your requirements. Static provisioning is generally not scalable. You have to create the volumes outside of the k8s context. Mounting existing volumes would be useful in disaster recovery scenarios.
Using Storage classes, or dynamic provisioning, is generally preferred because of the convenience. You can create roles and resource quotas to control and limit the storage usage and decrease operational overhead.