问题描述
我正在尝试为3个Pod部署一个持久卷来工作，我想使用集群的节点存储，即不像ebs那样剥离外部存储.
I am trying to deploy a persistentvolume for 3 pods to work on and i want to use the cluster's node storage i.e. not an external storage like ebs spin off.
为达到上述目的，我做了以下实验-
To achieve the above i did the following experiment's -
1)我仅应用了下面定义的以下PVC资源-
1) I applied only the below PVC resource defined below -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: null
labels:
io.kompose.service: pv1
name: pv1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
status: {}
此旋转是默认情况下的存储集storageclass，在我的情况下，它是数字海洋的容量.因此，它创建了一个1Gi的卷.
This spin's up a storage set by default storageclass, which in my case was digital ocean's volume. So it created a 1Gi volume.
2)如下创建了PV资源和PVC资源-
2) Created a PV resource and PVC resource like below -
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 this i see my claim is bound.
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
以下是我希望得到的答案/指标-
Below are my questions that i am hoping to get answers/pointers to -
-
以上警告，找不到存储类，我需要创建一个?如果是这样，您能告诉我原因和方式吗?或任何指针. (以某种方式，该链接未声明- https: //kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)
The above warning, storage class could not be found, do i need tocreate one? If so, can you tell me why and how? or any pointer. (Somehow this link misses to state that - https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)
请注意，PV的存储容量为10Gi，PVC的请求容量为1Gi，但是PVC仍然具有10Gi的容量吗?我不能与其他PVC共享相同的PV容量吗?
Notice the PV has storage capacity of 10Gi and PVC with request capacity of 1Gi, but still PVC was bound with 10Gi capacity? Can't i share the same PV capacity with other PVCs?
对于问题2)如果我必须为具有所需容量的不同PVC创建不同的PV，我是否还需要创建storageclass?还是相同的存储类别，并使用选择器选择相应的PV?
For question 2) 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?
推荐答案
我试图重现所有行为以回答您的所有问题.但是，我无权访问DigitalOcean，所以我在GKE上对其进行了测试.
I was trying to reproduce all behavior to answer all your questions. However, I don't have access to DigitalOcean, so I tested it on GKE.
根据文档和最佳实践，强烈建议创建一个storageclass，然后再基于它创建PV/PVC.但是，有一种称为手动配置"的东西.您在这种情况下所做的.
According to the documentation and best practices, it is highly recommended to create a storageclass and later create PV / PVC based on it. However, there is something called "manual provisioning". Which you did in this case.
手动配置是指您需要先手动创建PV，然后再创建具有匹配的spec.storageClassName:字段的PVC.例子:
Manual provisioning is when you need to manually create a PV first, and then a PVC with matching spec.storageClassName: field. Examples:
- 如果创建不带
default storageclass，PV和storageClassName参数的PVC(afaik kubeadm不提供默认的storageclass)-PVC将卡在Pending上，并带有事件:此事件没有持久卷可用声明并且未设置存储类别. - 如果您创建具有
default storageclass setup on cluster但不具有storageClassName参数的PVC，它将基于默认的存储类来创建它. - 如果使用
storageClassName参数(在Cloud，Minikube或kubeadm中的某个地方)创建PVC，则PVC也将成为Pending，并显示警告:storageclass.storage.k8s.io手动".但是，如果使用相同的storageClassName参数创建PV，则将在一段时间内绑定它.
- If you create a PVC without
default storageclass,PVandstorageClassNameparameter (afaik kubeadm is not providing defaultstorageclass) - PVC will be stuck onPendingwith event: no persistent volumes available for this claim and no storage class is set. - If you create a PVC with
default storageclass setup on clusterbut withoutstorageClassNameparameter it will create it based on default storageclass. - If you create a PVC with
storageClassNameparameter (somewhere in the Cloud, Minikube or kubeadm) - PVC will also bePendingwith the warning: storageclass.storage.k8s.io "manual" not found.However, if you create PV with the samestorageClassNameparameter, it will be bound in a while.
示例:
$ 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.
The disadvantage of manual provisioning is that you have to create PV for each PVC. If you use storageclass you can just create PVC.
您可以使用文档示例或查看此处.当您使用默认storageclass的云时，可以通过以下方式将其导出到yaml:$ kubectl get sc -oyaml >> storageclass.yaml.或者，如果您有多个，则必须指定哪个. storageclass的名称可以通过
$ kubectl get sc获得.以后您可以参考 K8s API 自定义您的storageclass.
You can use documentation examples or check here. As you are using cloud with default storageclass you can export it to yaml by: $ kubectl get sc -oyaml >> storageclass.yaml.Or if you have more than one, you have to specify which one. Names of storageclass can be obtained by
$ kubectl get sc.Later you can refer to K8s API to customize your storageclass.
您手动创建了具有10Gi的PV，PVC请求了1Gi.由于PVC和PV的边界为1:1，因此PVC寻找一个满足所有条件的PV并绑定到该PV. PVC(pv1)请求了1Gi，PV(task-pv-volume)满足了这些要求，因此Kubernetes对其进行了绑定.不幸的是，在这种情况下，很多空间都被浪费了.
You created manually a PV with 10Gi and the PVC requested 1Gi. As PVC and PV are bounding 1:1, PVC searched for a PV which meets all conditions and bound to it. PVC (pv1) requested 1Gi and the PV (task-pv-volume) meet those requirements so Kubernetes bound them. Unfortunately much of the space was wasted in this case.
不幸的是，您无法将2个PVC绑定到1个PV，因为PVC和PV之间的关系是1:1，但是您可以配置许多吊舱/部署以使用同一PVC.
Unfortunately, you cannot bound 2 PVC to 1 PV as the relationship between PVC and PV is 1:1, but you can configure many pods/deployments to use the same PVC.
我建议您查看此stackoverflow情况，因为它很好地说明了AccessMode的具体情况.
I can advise you to look at this stackoverflow case as it explains very well AccessMode specifics.
正如我之前提到的，如果手动创建具有特定大小的PV并绑定了PVC，而对PVC的请求较少，则会浪费额外的空间.因此，您必须使用相同的资源请求创建PV和PVC，或者让storageclass根据PVC请求调整存储空间.
As I mentioned before, if you create PV manually with a specific size and a PVC bounded to it, which request less, the extra space will be wasted. So, you have to create PV and PVC with the same resource request, or let storageclass adjust the storage based on PVC request.
这篇关于Kubernetes PVC共享一个PV?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！