所以我在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阶段"；，绑定失败，并返回错误消息：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>
我已经尝试过复制您的场景(但是，如果您提供storageclassyaml以进行精确复制，并更改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发生的情况进行更改
我猜您正在使用静态配置。
集群管理员创建多个PV。它们携带了可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可供消费。
在这种情况下，您必须创建1个PV到1个PVC。
如果您要使用云环境，您将使用动态资源调配。
当管理员创建的静态PV都与用户的PersistentVolumeClaim不匹配时，集群可能会尝试动态地为PVC提供专门的卷。此资源调配基于StorageClasses：PVC必须请求一个存储类，并且管理员必须创建并配置了该类才能进行动态资源调配。
例如，在GKE上，我试图复制它和1个绑定到PV的PVC。由于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。
有关边界的更多详细信息，您可以查看此主题。如果您想了解有关PVC的更多信息，请查看此SO线程。
如果第二个PV没有帮助，请提供有关您的环境(Minikube/Kubedm、K8s版本、操作系统等(和storageclassYAML的更多详细信息。