我有一个看起来很简单的PV和PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: www-pvc
spec:
storageClassName: ""
volumeName: www-pv
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: www-pv
spec:
storageClassName: ""
claimRef:
name: www-pvc
capacity:
storage: 1Mi
accessModes:
- ReadOnlyMany
nfs:
server: 192.168.1.100
path: "/www"
由于某种原因，它们不能相互结合，PVC停留在"待定"状态。永远:
$ kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/www-pv 1Mi ROX Retain Available /www-pvc 107m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/www-pvc Pending www-pv 0 107m
如何调试匹配?哪个服务在k3s中进行匹配?我会在k3s二进制文件(在Debian下作为服务运行)的日志中查找吗?
在Kubernetes关于持久卷的文档中，你可以找到以下信息:
PersistentVolume(PV)是集群中的一块存储，由管理员提供或使用Storage Classes动态提供。A
PersistentVolumeClaim(PVC)是用户的存储请求。它类似于Pod。pod消耗节点资源，pvc消耗PV资源。
在Binding部分有如下信息:
如果不存在匹配的卷，索赔将无限期保持未绑定状态。索赔将在匹配卷可用时绑定。例如，配置了许多50Gi pv的集群将无法匹配请求100Gi的PVC。当集群中加入100Gi PV时，可以绑定PVC。
在Openshift文档-卷和索赔预绑定中，您可以找到使用pre-binding时跳过一些匹配的信息。
如果你确切地知道你想要你的persistentvolumecclaim绑定到什么PersistentVolume，你可以在PVC中使用volumeName字段指定PV。此方法跳过正常的匹配和绑定过程。PVC只能绑定到与volumeName中指定的名称相同的PV。如果这样一个具有该名称的PV存在并且是Available，则PV和PVC将被绑定，无论PV是否满足PVC的标签选择器、访问模式和资源请求。
一号
在PV配置中设置
capacity:
storage: 1Mi
这意味着你有1Mi的存储空间，大约1.04 MB。
您的PVC被配置为请求1Gi，即~ 1.07GB。
resources:
requests:
storage: 1Gi
您的PV没有满足您的PVC请求。
你可以有许多PV与5Gi的例子存储，但没有一个将被绑定，如果PVC请求高于5Gi，如6Gi。但是，如果PV的存储较高，6Gi和PVC的请求较低，则像5Gi一样，它将被限制，而1Gi将被浪费。
问题2
如果你将描述你的PVC，你会发现Warning如下:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedBinding 2s (x2 over 17s) persistentvolume-controller volume "www-pv" already bound to a different claim.
在您的配置中，您使用的是Pre-Binding，因为您在PVC中指定了volumeName，在PV中指定了claimRef。
这个例子在OpenShift文档-使用持久卷中有很好的描述。在当前设置中，您使用了claimRef.name，但没有指定claimRef.namespace。
$ kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/www-pv 1Gi ROX Retain Available /www-pvc 4m28s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/www-pvc Pending www-pv 0 4m28s
但是当你添加claimRef.namespace时，它将工作。
$ kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/www-pv 1Gi ROX Retain Bound default/www-pvc 7m3s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/www-pvc Bound www-pv 1Gi ROX 7m3s
您应该在PV's spec.claimRef.namespace中指定PVC's命名空间，因为PVC是namespaced资源。
$ kubectl api-resources | grep pv
persistentvolumeclaims pvc true PersistentVolumeClaim
persistentvolumes pv false PersistentVolume
解决方案在你的PV中将spec.capacity.storage改为1Gi。
在你的PV中添加spec.claimRef.namespace: default，就像下面的例子:
spec:
storageClassName: ""
claimRef:
name: www-pvc
namespace: default # adding namespace: defaults
capacity:
storage: 1Gi # changed storage size
请让我知道你是否能够绑定PV和PVC。
我认为问题是PVC正试图获得1Gi大小的PV，但您的PV大小为1M。
所以，绑定失败了。您可以通过增加PV的大小或减少PVC的大小来解决这个问题。
使用kubectl describe pvc获取有关事件和失败原因的更多信息。
为了进一步澄清，PVC是对存储的请求，所以如果你说你需要1G的存储，但你只提供1M的实际存储，PVC将保持在Pending状态。基于此，PVC中定义的大小应该总是小于或等于PV的大小。
这是对上述答案的补充，(pv/pvc尺寸修正)
您应该确保您已经安装了nfs-common包，并且您可以在节点本身中挂载该nfs导出。
由于storageClassName在您的定义中是空的-我可以建议查看https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
PV尺寸不能小于PVC大小。
换句话说PVC
1GB大小不能大于PV1MB大小。
请更新PV &PVC大小。