kubernetes PVC共享一个PV?

kubernetes PVCs sharing a single PV?

我正在尝试为 3 pods 部署一个持久卷来继续工作,我想使用集群的节点存储,即不是像 ebs spin off 这样的外部存储。

为了实现上述目标,我做了以下实验 -

1) 我只应用了下面定义的 PVC 资源 -

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: pv1
  name: pv1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
status: {}

这个旋转的存储设置为默认存储class,在我的例子中是数字海洋的体积。所以它创建了一个 1Gi 的卷。

2) 创建了如下所示的 PV 资源和 PVC 资源 -

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: pv1
  name: pv1
spec:
  storageClassName: manual
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
status: {}

Post 我看到我的声明受到约束。

    pavan@p1:~$ kubectl get pvc
    NAME        STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    pv1   Bound    task-pv-volume   10Gi       RWO            manual         2m5s
    pavan@p1:~$ kubectl get pv
    NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
    task-pv-volume   10Gi       RWO            Retain           Bound    default/pv1   manual                  118m
pavan@p1:~$ kubectl describe pvc
Name:          pv1
Namespace:     default
StorageClass:  manual
Status:        Bound
Volume:        task-pv-volume
Labels:        io.kompose.service=pv1
Annotations:   kubectl.kubernetes.io/last-applied-configuration:
                 {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"creationTimestamp":null,"labels":{"io.kompose.service":"mo...
               pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      10Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Mounted By:    <none>
Events:
  Type     Reason              Age                 From                         Message
  ----     ------              ----                ----                         -------
  Warning  ProvisioningFailed  28s (x8 over 2m2s)  persistentvolume-controller  storageclass.storage.k8s.io "manual" not found

以下是我希望 answers/pointers 到 -

的问题
  1. 以上警告,找不到存储class,是否需要 创造一个?如果是这样,你能告诉我为什么以及如何吗?或任何指针。 (不知何故,这个 link 没有说明 - https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/

  2. 注意到 PV 有 10Gi 的存储容量,PVC 有 1Gi 的请求容量,但是 PVC 仍然绑定了 10Gi 容量?我不能与其他 PVC 共享相同的 PV 容量吗?

对于问题 2)如果我必须为具有所需容量的不同 PVC 创建不同的 PV,我是否也必须创建存储class?还是同样的存储class并使用select或select对应的PV?

  1. 是的,你必须创建存储class,check,但我猜digital-ocean提供默认存储class,你可以检查一下和: kubectl get storageclasses

  2. 您可以共享一个 PV,但只能在 read-only 访问,如果您需要对所有 pods 的写入权限,您必须创建多个 PV,check

我试图重现所有行为来回答您的所有问题。但是,我无法访问 DigitalOcean,所以我在 GKE 上对其进行了测试。

The above warning, storage class could not be found, do i need to create one?

根据文档和最佳实践,强烈建议创建一个storageclass,然后基于它创建PV/PVC。然而,有一种东西叫做"manual provisioning"。你在这种情况下所做的。

手动配置是指您需要先手动创建 PV,然后再创建具有匹配 spec.storageClassName: 字段的 PVC。示例:

  • 如果你创建的 PVC 没有 default storageclassPVstorageClassName 参数(afaik kubeadm 没有提供默认值 storageclass)- PVC 将卡在 Pending 事件:没有可用于此声明的持久卷,也没有设置存储 class。
  • 如果您创建带有 default storageclass setup on cluster 但没有 storageClassName 参数的 PVC,它将根据默认存储class.
  • 创建它
  • 如果您使用 storageClassName 参数创建 PVC(在云端、Minikube 或 kubeadm 中的某处)- PVC 也将是 Pending 并带有警告:storageclass.storage.k8s.io "manual" 未找到。 但是,如果你用相同的storageClassName参数创建PV,一会儿就会被绑定。

示例:

$ kubectl get pv,pvc
NAME                              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
persistentvolume/task-pv-volume   10Gi       RWO            Retain           Available           manual                  4s

NAME                        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/pv1   Pending                                      manual         4m12s

...

kubectl get pv,pvc
NAME                              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM         STORAGECLASS   REASON   AGE
persistentvolume/task-pv-volume   10Gi       RWO            Retain           Bound    default/pv1   manual                  9s

NAME                        STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/pv1   Bound    task-pv-volume   10Gi       RWO            manual         4m17s

manual provisioning的缺点是你必须为每个PVC创建PV。如果你使用 storageclass 你可以只创建 PVC.

If so, can you tell me why and how? or any pointer.

您可以使用 documentation examples or check here。当您使用默认 storageclass 的云时,您可以通过以下方式将其导出到 yaml:
$ kubectl get sc -oyaml >> storageclass.yaml。 或者,如果您有多个,则必须指定是哪一个。 storageclass的名字可以通过
$ kubectl get sc获得。 稍后你可以参考K8s API自定义你的storageclass.

Notice the PV has storage capacity of 10Gi and PVC with request capacity of 1Gi, but still PVC was bound with 10Gi capacity?

您手动创建了一个 10Gi 的 PV,而 PVC 请求了 1Gi。由于PVC和PV绑定1:1,PVC搜索满足所有条件的PV并绑定到它。 PVC (pv1) 请求 1Gi,PV (task-pv-volume) 满足这些要求,因此 Kubernetes 绑定了它们。不幸的是,在这种情况下浪费了很多 space。

Can't i share the same PV capacity with other PVCs

很遗憾,您不能将 2 个 PVC 绑定到 1 个 PV,因为 PVC 和 PV 之间的关系是 1:1,但是您可以配置多个 pods/deployments 使用相同的 PVC。

我可以建议您查看 ,因为它很好地解释了 AccessMode 细节。

If i have to create different PVs for different PVC with the required capacity, do i have to create storageclass as-well? Or same storage class and use selectors to select corresponding PV?

正如我之前提到的,如果您手动创建具有特定大小的 PV 和绑定到它的 PVC,请求较少,额外的 space 将被浪费。因此,您必须使用相同的资源请求创建 PV 和 PVC,或者让 storageclass 根据 PVC 请求调整存储。