複数のプロジェクトに提示したいいくつかの読み取り専用メディア資産を含む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: {}
私は、「プロジェクト」の同等kubernetesは、「名前空間」 私は名前空間ごとに1曲のPVであなたのポイントを参照してください、私の計画は異なるためセレクタを変更することだったと思い環境(Dev Test Prod)があります。私はまだ可能であると思っていた名前空間を越えて1 PVに対して複数の主張をすることができません。 (configsの編集を参照してください) – thisguy123
はい、これは正常な動作です。アクセスが必要なすべてのデプロイメント/ステートフルセットで同じ「claimName」を使用して永続ボリュームクレームを再利用できるはずです(この例ではPVをPVCとともに1つのファイルにデプロイする理由があります)。 –
さて、質問に戻る...それは同じPVに対して複数のPVCクレームを作ることはできないということですか? – thisguy123