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 是Pending。只要我们继续查看，状态就会一直处于待处理状态。

请注意，此 OP 与 this other question 不同，因为即使在 NFS IP 和路径周围加上引号，此问题仍然存在。

为什么这个 PVC 没有绑定到 PV？需要进行哪些具体更改才能解决此问题？

Answer 1

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

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

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