2017-04-05 1 views
0

複数のプロジェクトに提示したいいくつかの読み取り専用メディア資産を含むNFSマウントが1つあります。複数のプロジェクトにNFSを提示する

同じNFSパスを持つプロジェクトごとに新しいPVを作成するのは難しいようです。他のPVCが偶然に自分のアセットディレクトリを要求するとどうなるでしょうか?

これ以外に私はこれを行う方法が分かりません。どうすればこれを達成できますか?

編集:明確にする - 私はクラスタ管理者の介入を避けたい。 PVを作成するときは、クラスタ管理者権限が必要です。

PV CONFIG my_namespaceこのPVに対して請求することができない以外の名前空間から

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    annotations: 
    pv.kubernetes.io/bound-by-controller: "yes" 
    creationTimestamp: null 
    labels: 
    app: my_app 
    name: my-assets 
spec: 
    accessModes: 
    - ReadWriteMany 
    capacity: 
    storage: 25Gi 
    claimRef: 
    apiVersion: v1 
    kind: PersistentVolumeClaim 
    name: my-assets 
    namespace: my_namespace 
    resourceVersion: "13480134" 
    uid: ea36d352-1a22-11e7-a443-0050568b4a96 
    nfs: 
    path: /nfs_volume 
    server: nfs_server 
    persistentVolumeReclaimPolicy: Recycle 
status: {} 

のPVC。ここには、別の名前空間からのPVC設定があります。これは、既存のPVに対して、ReadWriteManyと主張することはできません。

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    annotations: 
    openshift.io/generated-by: OpenShiftNewApp 
    creationTimestamp: null 
    name: my-assets 
spec: 
    accessModes: 
    - ReadWriteMany 
    resources: 
    requests: 
     storage: 25Gi 
    selector: 
    matchLabels: 
     app: my_app 
    volumeName: my-assets 
status: {} 

答えて

0

私はあなたのプロジェクトが何を意味するかわからないが、あなたは別のアプリケーションのDeploymentsを参照している場合、それはReadWriteMany型を持つNFSのための単一のPVの定義で動作するはずです。しかし、NFSへのアクセスが必要な展開ごとにPVとPVCの定義を常に1つ含めることをお勧めします。そうすれば展開から明示的になり、すべてのアプリごとに別々に変更することができます。 1つのアプリでは変更したいが、他のアプリでは変更したくないと思っているだけです。

ここでは、バックアップを書き込むためのCockroachDBデプロイメントのすべてのPODにamazon EFS NFSマウントを使用する例を示します。私はそれを2つのyamlsに分割していますが、それらを1つのファイルに折り畳むこともできます。すべてのPODに対して同じPersistentVolumeClaimを使用できることに注意してください。あなただけのようにもPVの定義におよびPVCでaccess modeとしてReadWriteManyをリストする必要が

1 cockroachdbPV.yaml

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    name: cockroachdbpv 
spec: 
    capacity: 
    storage: 100Gi 
    accessModes: 
    - ReadWriteMany 
    nfs: 
    server: {amazon path here} 
    path: "/" 
--- 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: cockroachdbpv 
spec: 
    accessModes: 
    - "ReadWriteMany" 
    resources: 
    requests: 
     storage: 10Gi 

2 cockroachdb.yaml

apiVersion: apps/v1beta1 
kind: StatefulSet 
metadata: 
    name: cockroachdb 
spec: 
    serviceName: "cockroachdb" 
    replicas: 3 
    template: 
    metadata: 
     labels: 
     app: cockroachdb 
     annotations: 
     {...}   
    spec: 
     containers: 
     - name: cockroachdb 
     {...} 
     volumes: 
     {...} 
     - name: efsdir 
      persistentVolumeClaim: 
      claimName: cockroachdbpv 
+0

私は、「プロジェクト」の同等kubernetesは、「名前空間」 私は名前空間ごとに1曲のPVであなたのポイントを参照してください、私の計画は異なるためセレクタを変更することだったと思い環境(Dev Test Prod)があります。私はまだ可能であると思っていた名前空間を越えて1 PVに対して複数の主張をすることができません。 (configsの編集を参照してください) – thisguy123

+0

はい、これは正常な動作です。アクセスが必要なすべてのデプロイメント/ステートフルセットで同じ「claimName」を使用して永続ボリュームクレームを再利用できるはずです(この例ではPVをPVCとともに1つのファイルにデプロイする理由があります)。 –

+0

さて、質問に戻る...それは同じPVに対して複数のPVCクレームを作ることはできないということですか? – thisguy123

0

例はここに利用できるがある: https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/nfs

+0

編集を参照してください。 PVは 'ReadWriteMany'として定義されていますが、まだ異なる名前空間で申し立てることはできません – thisguy123

+0

残念ながら、PersistentVolumeは名前空間を持つオブジェクトです。別の名前空間からPVCを作成することはできません。これは意図したとおりに動作しており修正されません。 –

関連する問題