Can a PVC be bound to a specific PV

Question

This was discussed by k8s maintainers in https://github.com/kubernetes/kubernetes/issues/7438#issuecomment-97148195:

Allowing users to ask for a specific PV breaks the separation between them

I don't buy that. We allow users to choose a node. It's not the common case, but it exists for a reason.

How did it end? What's the intended way to have >1 PV's and PVC's like the one in https://github.com/kubernetes/kubernetes/tree/master/examples/nfs?

We use NFS, and PersistentVolume is a handy abstraction because we can keep the server IP and the path there. But a PersistentVolumeClaim gets any PV with sufficient size, preventing pathreuse.

Can set volumeName in a PVC spec block (see https://github.com/kubernetes/kubernetes/pull/7529) but it makes no difference.

Answer 1

There is a way to pre-bind PVs to PVCs today, here is an example showing how:

1) Create a PV object with a ClaimRef field referencing a PVC that you will subsequently create:

$ kubectl create -f pv.yaml
persistentvolume "pv0003" created

where pv.yaml contains:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  claimRef:
    namespace: default
    name: myclaim
  nfs:
    path: /tmp
    server: 172.17.0.2

2) Then create the PVC with the same name:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

3) The PV and PVC should be bound immediately:

$ kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
myclaim   Bound     pv0003    5Gi        RWO           4s
$ ./cluster/kubectl.sh get pv
NAME      CAPACITY   ACCESSMODES   STATUS    CLAIM             REASON    AGE
pv0003    5Gi        RWO           Bound     default/myclaim             57s

We are also planning on introducing "Volume Selectors", which will enable users to select specific storage based on some implementation specific characteristics (specific rack, for example, or in your case, a way to enforce 1:1 PV to PVC mapping).

See https://github.com/kubernetes/kubernetes/issues/18333.

Answer 2

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "data-pvc"
spec:
  accessModes:
    - "ReadWriteMany"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "data-pv"