NFS卷的PersistentVolumeClaim处于挂起状态。

Question

以下是关于如何使 PersistentVolumeClaim 绑定到 PersistentVolume 的具体更改需要进行哪些修改的 yaml 代码：

一个在同一VPC子网中的EC2实例，其ip为10.0.0.112，并已配置为在 /nfsfileshare 路径下充当NFS服务器。

创建PersistentVolume

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

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持久卷的状态显示为“可用”。

创建持久卷声明

然后，我们使用pv-claim.yaml创建了一个名为``的持久卷声明：

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

通过输入以下内容：

kubectl create -f pv-claim.yaml

状态为Pending

但是当我们输入kubectl get pvc my-pv-claim时，我们发现状态为Pending。只要我们继续检查，状态就会保持为Pending。

请注意，此操作与其他问题不同，因为即使在NFS IP和路径周围加上引号，此问题仍然存在。

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

- CodeMed

Answer 1

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

基于报告的事件，我将 storageClassName: manual 更改为 storageClassName: slow 以解决这个问题。

问题在于 PVC 的 StorageClassName 不符合 PV 中指定的类别要求。

- CodeMed