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プロビジョナーによってサポートされていません。あなたの助けをありがとう
はあなたのために、このソリューションの仕事をしましたか? –
はい、PVCとPVが意図したとおりに結合されました – elmpp