如何解决Kubernetes：将2个命名空间中的2个PVC绑定到同一PV，一个成功，一个失败
所以我在2个命名空间中有2个PVC绑定到1个PV：
以下是PVC：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-git
namespace: mlo-dev
labels:
type: local
spec:
storageClassName: mlo-git
volumeMode: Filesystem
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-git
namespace: mlo-stage
labels:
type: local
spec:
storageClassName: mlo-git
volumeMode: Filesystem
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
和PV：
kind: PersistentVolume
apiVersion: v1
metadata:
name: pv-git
labels:
type: local
spec:
storageClassName: mlo-git
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
hostPath:
path: /git
在名称空间“ mlo-dev”中，绑定成功：
$ kubectl describe pvc pvc-git -n mlo-dev
Name: pvc-git
Namespace: mlo-dev
StorageClass: mlo-git
Status: Bound
Volume: pv-git
Labels: type=local
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 1Gi
Access Modes: RWX
VolumeMode: Filesystem
Mounted By:
...
various different pods here...
...
Events: <none>
在命名空间“ mlo-stage”中，绑定失败并显示错误消息：storageclass.storage.k8s.io“ mlo-git”未找到
$ kubectl describe pvc pvc-git -n mlo-stage
Name: pvc-git
Namespace: mlo-stage
StorageClass: mlo-git
Status: Pending
Volume:
Labels: type=local
Annotations: Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By:
...
various different pods here...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ProvisioningFailed 3m4s (x302 over 78m) persistentvolume-controller storageclass.storage.k8s.io "mlo-git" not found
据我所知，PV并不限于名称空间，因此不同名称空间中的PVC应该可以绑定到同一PV吗？
+++++ 添加： +++++
当“ kubectl描述pv pv-git”时，我得到以下信息：
$ kubectl describe pv pv-git
Name: pv-git
Labels: type=local
Annotations: pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pv-protection]
StorageClass: mlo-git
Status: Bound
Claim: mlo-dev/pvc-git
Reclaim Policy: Retain
Access Modes: RWX
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /git
HostPathType:
Events: <none>
解决方法
我试图重现您的情况（但是，如果您将storageclass yaml提供给精确的重现，并更改了AccessMode进行测试），我认为这种行为是正确的（按设计方式工作） ）。
要检查特定对象是否为namespaced时，可以使用命令：
$ kubectl api-resources | grep pv
persistentvolumeclaims pvc true PersistentVolumeClaim
persistentvolumes pv false PersistentVolume
由于PVC是正确的，因此其平均值pvc是命名空间，而PV不是。
PersistentVolumeClain和PersistentVolume的边界为1：1。当您的第一个PVC绑定到PV时，此PV为taken，并且此刻不能再次使用。 您应该创建第二个PV。可以根据reclaimPolicy和pop / deployment
我想您正在使用Static设置。
集群管理员创建许多PV。它们带有实际存储的详细信息，可供群集用户使用。它们存在于Kubernetes API中，可供使用。
在这种情况下，您必须创建1 PV到1 PVC。
如果要使用云环境，则应使用Dynamic设置。
当管理员创建的所有静态PV均与用户的PersistentVolumeClaim不匹配时，群集可能会尝试动态地为PVC专门配置一个卷。此设置基于StorageClasses：PVC必须请求存储类，并且管理员必须已经创建并配置了该类，才能进行动态设置。
例如，在GKE上，我尝试重现它，并将1 PVC绑定到PV。由于GKE使用Dynamic provisioning，因此当您仅定义PVC时，它会使用default storageclass并自动创建PV。
$ kubectl get pv,pvc -A
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pv-git 1Gi RWO Retain Bound mlo-dev/pvc-git mlo-git 15s
persistentvolume/pvc-e7a1e950-396b-40f6-b8d1-8dffc9a304d0 1Gi RWO Delete Bound mlo-stage/pvc-git mlo-git 6s
NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mlo-dev persistentvolumeclaim/pvc-git Bound pv-git 1Gi RWO mlo-git 10s
mlo-stage persistentvolumeclaim/pvc-git Bound pvc-e7a1e950-396b-40f6-b8d1-8dffc9a304d0 1Gi RWO mlo-git 9s
解决方案
要解决此问题，您应该创建另一个PersistentVolume来绑定第二个PVC。
有关边界的更多详细信息，您可以选中this topic。如果您想要有关PVC的更多信息，请选中this SO thread。
如果第二个PV无法解决，请提供有关您的环境（Minikube / Kubeadm，K8s版本，操作系统等）和您的storageclass YAML的更多详细信息
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。