NFS卷的PersistentVolumeClaim待处理

Question

为了使yaml绑定到PersistentVolumeClaim，需要对下面的PersistentVolume进行哪些具体更改？

与Kubernetes工作者节点在同一VPC子网中的EC2实例的IP为10.0.0.112，并且已配置为在/ nfsfileshare路径中充当NFS服务器。

创建持久卷

我们使用pv-volume-network.yaml创建了一个PersistentVolume pv01：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv01
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: "/nfsfileshare"
    server: "10.0.0.112"

并输入：

kubectl create -f pv-volume-network.yaml

然后，当我们键入kubectl get pv pv01时，pv01 PersistentVolume将显示为“可用”状态。

创建PersistentVolumeClaim

然后我们用pv-claim.yaml创建了一个名为的PersistentVolumeClaim：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: my-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

然后输入：

kubectl create -f pv-claim.yaml

状态为待处理

但是当我们键入kubectl get pvc my-pv-claim时，我们看到STATUS正在挂起。只要我们继续进行检查，状态就会保持为待处理状态。

请注意，此OP与this other question不同，因为即使使用NFS IP和路径两边的引号，该问题仍然存在。

该PVC为什么不与PV结合？要解决此问题需要进行哪些具体更改？

Answer 1

我通过键入kubectl describe pvc my-pv-claim并查看结果的“事件”部分来诊断问题。

然后，根据报告的事件，我可以通过将storageClassName: manual更改为storageClassName: slow来解决此问题。

问题是PVC的StorageClassName不满足与PV中指定的类匹配的要求。