2017-04-12 10 views
0

Kubernetesの新たに安定したAuto-Provisioning featuresは、を定義する必要性を一見排除し、そのStorageClassに基づいて、PersistentVolumeClaimという要件を満たしています。Kubernetes 1.6 NFSによる自動プロビジョニング

このすべては少し単純そうですが、私は損失のビットでよ何をすべきか、それは1.6前canonical NFS example

のための私のマニフェストを更新することになると、以下PVCとPVが一緒に結合されるだろうし、いくつかの他のサービスは、(私は今だけpersistentVolumeReclaimPolicyを追加したが、物事には影響しませんのでご注意ください)1.6、RUで、

しかし

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 

問題なくReadWriteMany PVC nfs-pvcを使用することができますこのマニフェストを設定すると、追加の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とか何か不足していると思いますか?私はselector -> matchLabelを追加しようとしましたが、これは明らかにGCEプロビジョナーによってサポートされていません。あなたの助けをありがとう

答えて

1

私はこれの底になったと思います。周りdocumentation

「クラス」(それが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$ 
+0

はあなたのために、このソリューションの仕事をしましたか? –

+0

はい、PVCとPVが意図したとおりに結合されました – elmpp

関連する問題