This was discussed by k8s maintainers in https://github.com/kubernetes/kubernetes/issues/7438#issuecomment-97148195:
Allowing users to ask f
Now we can use storageClassName
(at least from kubernetes 1.7.x)
See detail https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage
Copied sample code here as well
kind: PersistentVolume apiVersion: v1 metadata: name: task-pv-volume labels: type: local spec: storageClassName: manual capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: "/tmp/data" --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: task-pv-claim spec: storageClassName: manual accessModes: - ReadWriteOnce resources: requests: storage: 3Gi
There is a way to pre-bind PVs to PVCs today, here is an example showing how:
$ kubectl create -f pv.yaml
persistentvolume "pv0003" created
where pv.yaml
contains:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
storageClassName: ""
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
claimRef:
namespace: default
name: myclaim
nfs:
path: /tmp
server: 172.17.0.2
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
storageClassName: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
$ 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
Yes, you can actually provide the volumeName
in the PVC. It will bind exactly to that PV name provided in the volumeName (also spec should be in sync)
storageClassName in PV and PVC should be same. Add the persistent-volume name as volumeName in PVC to bound PVC to a specific PV.
like:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-name
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 40Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-name
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
volumeName: pv-name
Better to specify both volumeName
in pvc
and claimRef
in pvc
.
By using storageClassName: manual
in both pv
and pvc
we can bind each other, but it does not guarantee if there are many manual
pv and pvc's.
Specifying a volumeName in your PVC does not prevent a different PVC from binding to the specified PV before yours does. Your claim will remain Pending until the PV is Available.
Specifying a claimRef in a PV does not prevent the specified PVC from being bound to a different PV. The PVC is free to choose another PV to bind to according to the normal binding process. Therefore, to avoid these scenarios and ensure your claim gets bound to the volume you want, you must ensure that both volumeName and claimRef are specified.
You can tell that your setting of volumeName and/or claimRef influenced the matching and binding process by inspecting a Bound PV and PVC pair for the pv.kubernetes.io/bound-by-controller annotation. The PVs and PVCs where you set the volumeName and/or claimRef yourself will have no such annotation, but ordinary PVs and PVCs will have it set to "yes".
When a PV has its claimRef set to some PVC name and namespace, and is reclaimed according to a Retain reclaim policy, its claimRef will remain set to the same PVC name and namespace even if the PVC or the whole namespace no longer exists.
source: https://docs.openshift.com/container-platform/3.11/dev_guide/persistent_volumes.html
It can be done using the keyword volumeName:
for example
apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
name: "claimapp80"
spec:
accessModes:
- "ReadWriteOnce"
resources:
requests:
storage: "10Gi"
volumeName: "app080"
will claim specific PV app080