2

需要对yaml以下内容进行哪些具体更改才能使PersistentVolumeClaim绑定到PersistentVolume？

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

创建持久卷

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

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，pv01PersistentVolume 显示“可用”的状态。

创建 PersistentVolumeClaim

然后我们创建了一个名为 `` 的 PersistentVolumeClaim 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

状态待定

但是当我们输入 时kubectl get pvc my-pv-claim，我们看到 STATUS 是 Pending。只要我们继续检查，状态就会一直处于待处理状态。

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

为什么这个 PVC 没有绑定到 PV？需要做出哪些具体的改变来解决这个问题？

4

1 回答 1

3

I diagnosed the problem by typing kubectl describe pvc my-pv-claim and looking in the Events section of the results.

Then, based on the reported Events, I was able to fix this by changing storageClassName: manual to storageClassName: slow.

The problem was that the PVC's StorageClassName did not meet the requirement that it match the class specified in the PV.

于 2018-08-10T21:28:29.473 回答