Un PVC può essere associato a un PV specifico?

Question

Questo è stato discusso dal K8S manutentori in https://github.com/kubernetes/kubernetes/issues/7438#issuecomment-97148195:

Consentire agli utenti di chiedere un PV specifica rompe la separazione tra di loro

io non la bevo. Permettiamo agli utenti di scegliere un nodo. Non è il caso comune , ma esiste per un motivo.

Come è finita? Qual è il modo previsto per avere> 1 PV e PVC come quello di https://github.com/kubernetes/kubernetes/tree/master/examples/nfs?

Utilizziamo NFS e PersistentVolume è un'astrazione pratica perché possiamo mantenere l'IP server e lo path lì. Ma un PersistentVolumeClaim ottiene qualsiasi PV con dimensioni sufficienti, impedendo il riutilizzo di path.

È possibile impostare volumeName in un blocco PVC spec (vedere https://github.com/kubernetes/kubernetes/pull/7529) ma non fa alcuna differenza.

Answer 1

C'è un modo per controllare la validità-bind PV di PVC oggi, ecco un esempio che mostra come:

1) Creare un oggetto fotovoltaico con un campo ClaimRef riferimento a un PVC che si successivamente creare:

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

dove pv.yaml contiene:

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) Quindi creare il PVC con lo stesso nome:

012.351.

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

3) Il PV e PVC devono essere vincolati subito:

$ 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 

Stiamo anche pensando di introdurre "selettori Volume", che permetterà agli utenti di selezionare archiviazione specifico sulla base di alcune caratteristiche specifiche di implementazione (specifica rack, ad esempio, o nel tuo caso, un modo per applicare la mappatura da 1: 1 PV a PVC).

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

Answer 2

Non credo che la modifica di @ jayme alla risposta originale sia compatibile con le versioni precedenti.

Sebbene solo documentato come proposal, label selectors in PVC sembra funzionare con Kubernetes 1.3.0.

Ho scritto un example che definisce due volumi identici tranne che in labels. Entrambi avrebbero soddisfare qualsiasi delle rivendicazioni, ma quando pretese specificare

selector: 
    matchLabels: 
     id: test2 

è evidente che uno dei baccelli dipendenti non si avvia, e il PV test1 rimane legato.

può essere testato in, ad esempio con minikube:

$ kubectl create -f volumetest.yml 
$ sleep 5 
$ kubectl get pods 
NAME        READY  STATUS RESTARTS AGE 
volumetest1      1/1  Running 0   8m 
volumetest1-conflict    0/1  Pending 0   8m 
$ kubectl get pv 
NAME  CAPACITY ACCESSMODES STATUS  CLAIM   REASON AGE 
pv1  1Gi  RWO   Available       8m 
pv2  1Gi  RWO   Bound  default/test    8m 

Answer 3

Ora possiamo usare storageClassName (almeno dal kubernetes 1.7.x)

Vedi dettaglio https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage

codice di esempio copiato qui bene

 
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