PVC có thể bị ràng buộc với một PV cụ thể không?

Question

này đã được thảo luận bởi k8s trì trong https://github.com/kubernetes/kubernetes/issues/7438#issuecomment-97148195:

Cho phép người dùng có thể yêu cầu một PV cụ thể phá vỡ sự tách biệt giữa chúng

Tôi không mua đó. Chúng tôi cho phép người dùng chọn một nút. Nó không phải là trường hợp phổ biến , nhưng nó tồn tại vì một lý do.

Kết thúc bằng cách nào? Cách dự định để có> 1 PV và PVC giống như trong https://github.com/kubernetes/kubernetes/tree/master/examples/nfs?

Chúng tôi sử dụng NFS và PersistentVolume là một sự trừu tượng tiện dụng vì chúng tôi có thể giữ IP server và path ở đó. Nhưng PersistentVolumeClaim nhận được bất kỳ PV nào có kích thước đầy đủ, ngăn không cho sử dụng lại path.

Có thể đặt volumeName trong khối PVC spec (xem https://github.com/kubernetes/kubernetes/pull/7529) nhưng không có sự khác biệt.

Answer 1

Có một cách để pre-ràng buộc PV để PVC ngày hôm nay, đây là một ví dụ cho thấy cách:

1) Tạo một đối tượng PV với một lĩnh vực ClaimRef tham khảo một PVC rằng bạn sẽ sau đó tạo:

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

nơi pv.yaml chứa:

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) Sau đó tạo PVC có cùng tên:

012.351.

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

3) Các PV và PVC nên bị trói buộc ngay lập tức:

$ 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 

Chúng tôi cũng đang có kế hoạch về giới thiệu "Selectors Volume", mà sẽ cho phép người dùng lựa chọn lưu trữ cụ thể dựa trên một số đặc điểm thực hiện cụ thể (cụ thể giá, ví dụ, hoặc trong trường hợp của bạn, một cách để thực thi PV 1: 1 để lập bản đồ PVC).

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

Answer 2

Tôi không nghĩ rằng chỉnh sửa của @ jayme đối với câu trả lời gốc là tương thích về phía trước.

Mặc dù chỉ được ghi nhận là proposal, label selectors trong PVC dường như hoạt động với Kubernetes 1.3.0.

Tôi đã viết một example xác định hai tập hợp giống hệt nhau trừ số labels. Cả hai sẽ làm hài lòng bất kỳ khiếu nại, nhưng khi tuyên bố chỉ định

selector: 
    matchLabels: 
     id: test2 

rõ ràng là một trong những cụm phụ thuộc sẽ không bắt đầu, và PV test1 vẫn không ràng buộc.

có thể được kiểm tra trong ví dụ minikube với:

$ 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

Bây giờ chúng ta có thể sử dụng storageClassName (ít nhất là từ kubernetes 1.7.x)

Xem chi tiết https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage

sao chép mẫu mã ở đây là 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