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 到 -
的问题
以上警告,找不到存储class,是否需要
创造一个?如果是这样,你能告诉我为什么以及如何吗?或任何指针。 (不知何故,这个 link 没有说明 - https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)
注意到 PV 有 10Gi 的存储容量,PVC 有 1Gi 的请求容量,但是 PVC 仍然绑定了 10Gi 容量?我不能与其他 PVC 共享相同的 PV 容量吗?
对于问题 2)如果我必须为具有所需容量的不同 PVC 创建不同的 PV,我是否也必须创建存储class?还是同样的存储class并使用select或select对应的PV?
我试图重现所有行为来回答您的所有问题。但是,我无法访问 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 storageclass
、PV
和 storageClassName
参数(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 请求调整存储。
我正在尝试为 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 到 -
的问题以上警告,找不到存储class,是否需要 创造一个?如果是这样,你能告诉我为什么以及如何吗?或任何指针。 (不知何故,这个 link 没有说明 - https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)
注意到 PV 有 10Gi 的存储容量,PVC 有 1Gi 的请求容量,但是 PVC 仍然绑定了 10Gi 容量?我不能与其他 PVC 共享相同的 PV 容量吗?
对于问题 2)如果我必须为具有所需容量的不同 PVC 创建不同的 PV,我是否也必须创建存储class?还是同样的存储class并使用select或select对应的PV?
我试图重现所有行为来回答您的所有问题。但是,我无法访问 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 storageclass
、PV
和storageClassName
参数(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 请求调整存储。