Basically you can’t do what you want, as the relationship PVC <–> PV is one-on-one. If NFS is the only storage you have available and would like multiple PV/PVC on one nfs export, use Dynamic Provisioning and a default storage class. It’s not in official K8s yet, but this one is in the incubator and … Read more
I quickly realized that PersistentVolumeClaim defaults the storageClassName field to standard when not specified. However, when creating a PersistentVolume, storageClassName does not have a default, so the selector doesn’t find a match. The following worked for me: kind: PersistentVolume apiVersion: v1 metadata: name: models-1-0-0 labels: name: models-1-0-0 spec: capacity: storage: 200Gi storageClassName: standard accessModes: – … Read more
This happens when persistent volume is protected. You should be able to cross verify this: Command: kubectl describe pvc PVC_NAME | grep Finalizers Output: Finalizers: [kubernetes.io/pvc-protection] You can fix this by setting finalizers to null using kubectl patch: kubectl patch pvc PVC_NAME -p ‘{“metadata”:{“finalizers”: []}}’ –type=merge Ref; Storage Object in Use Protection
The Pod Security Context supports setting an fsGroup, which allows you to set the group ID that owns the volume, and thus who can write to it. The example in the docs: apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: # specification of the pod’s containers # … securityContext: fsGroup: 1234 More info on … Read more
From the docs PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. So a persistent volume (PV) is the “physical” volume on the host machine that stores your persistent data. A persistent volume claim (PVC) is a request for the platform to create … Read more