Kubernetes 1.6使用NFS自动资源调配

新稳定的Kubernetes似乎不再需要定义

PersistentVolume

s，并基于其

StorageClass

，产生了一个满足其需求的

PersistentVolumeClaim

这一切似乎有点简单，但我有点不知所措，当涉及到更新我的清单的时候

在1.6之前，以下PVC和PV将绑定在一起，其他几个服务可以毫无问题地使用ReadWriteMany PVC

nfs PVC

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
  namespace: staging
spec:
  capacity:
    storage: 1Mi
  accessModes: [ "ReadWriteMany" ]
  persistentVolumeReclaimPolicy: Delete
  nfs:
    # FIXME: use the right IP
    server: 10.7.252.23
    path: "/exports"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pvc
  namespace: staging
spec:
  accessModes: [ "ReadWriteMany" ]
  resources:
    requests:
      storage: 1Mi

（请注意，我现在才添加了

persistentVolumeClaincolicy

，但并不影响任何内容）

但是，在1.6中，运行此清单会导致额外的PV

PV/pvc-75f9e8d1-1f69-11e7-b065-42010a84002d

。这大概是由于自动资源调配。不幸的是，这不是NFS

Matthews-iMac:gke matt$ k get pv,pvc
NAME                                          CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                            STORAGECLASS   REASON    AGE
pv/nfs                                        1Mi        RWX           Delete          Available                                                             18m
pv/postgres-volume                            100Gi      RWO           Retain          Bound       default/postgres-storage-claim   fast                     16h
pv/pvc-630748eb-1f69-11e7-b065-42010a84002d   100Gi      RWO           Delete          Bound       staging/nfs-server-pvc           standard                 18m
pv/pvc-75f9e8d1-1f69-11e7-b065-42010a84002d   1Gi        RWX           Delete          Bound       staging/nfs-pvc                  standard                 18m

NAME                 STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS   AGE
pvc/nfs-pvc          Bound     pvc-75f9e8d1-1f69-11e7-b065-42010a84002d   1Gi        RWX           standard       18m
pvc/nfs-server-pvc   Bound     pvc-630748eb-1f69-11e7-b065-42010a84002d   100Gi      RWO           standard       18m

---

我想我可能在

选择器

或其他方面遗漏了什么？我尝试添加

selector->matchLabel

，但GCE provisioner显然不支持这一点。谢谢你的帮助

所以，我想我已经追根究底了。

“类”中提到，当启用“准入插件”时（就像在GKE上一样），有必要在PVC中指定一个

storageClass:“

”。这实际上意味着PVC仅适用于没有

storageClass

的PV

这是我的更新清单：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
  namespace: staging
spec:
  capacity:
    storage: 1Mi
  accessModes: [ "ReadWriteMany" ]
  persistentVolumeReclaimPolicy: Delete
  nfs:
    # FIXME: use the right IP
    server: 10.7.252.23
    path: "/exports"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pvc
  namespace: staging
spec:
  accessModes: [ "ReadWriteMany" ]
  resources:
    requests:
      storage: 1Mi
  storageClassName: "" # setting this to empty means this pvc can only be bound to pv with no class (i.e. not dynamically provisioned!)

以及我的绑定实例：

Matthews-iMac:gke matt$ k get pv,pvc
NAME                                          CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS     CLAIM                            STORAGECLASS   REASON    AGE
pv/nfs                                        1Mi        RWX           Delete          Bound      staging/nfs-pvc                                           5m
pv/postgres-volume                            100Gi      RWO           Retain          Bound      default/postgres-storage-claim   fast                     18h
pv/pvc-1d61980f-1f67-11e7-b065-42010a84002d   1Gi        RWX           Delete          Released   staging/nfs-pvc                  standard                 2h
pv/pvc-630748eb-1f69-11e7-b065-42010a84002d   100Gi      RWO           Delete          Bound      staging/nfs-server-pvc           standard                 1h

NAME                 STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS   AGE
pvc/nfs-pvc          Bound     nfs                                        1Mi        RWX                          5m
pvc/nfs-server-pvc   Bound     pvc-630748eb-1f69-11e7-b065-42010a84002d   100Gi      RWO           standard       1h
Matthews-iMac:gke matt$

---

是的，PVC和PV按预期连接