web-dev-qa-db-ja.com

Kubernetes NFS永続ボリューム-同じボリュームでの複数のクレーム?申し立ては保留中のままです。

使用事例:

NFSディレクトリが利用可能であり、それを使用して複数の展開とポッドのデータを保持したいと考えています。

PersistentVolumeを作成しました:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: http://mynfs.com
    path: /server/mount/point

複数のデプロイメントでこのPersistentVolumeを使用できるようにしたいので、必要なのは、このPersistentVolumeClaimsを指す複数のPersistentVolumeを作成する必要があるということです。

kind: PersistentVolumeClaim
apiVersion: v1
metaData:
  name: nfs-pvc-1
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Mi

これにより、PersistentVolumeに50MBの請求が作成されると考えています。 kubectl get pvcを実行すると、次のように表示されます。

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-1   Bound      nfs-pv    10Gi        RWX           35s

50Miではなく10Giの容量が表示される理由がわかりません。

PersistentVolumeClaimデプロイメントyamlを変更してnfs-pvc-2という名前のPVCを作成すると、次のようになります。

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-1   Bound      nfs-pv    10Gi        RWX           35s
nfs-pvc-2   Pending                                        10s

PVC2はPVにバインドしません。これは予想される動作ですか?同じPVを指す複数のPVCを持つことはできますか?

nfs-pvc-1を削除すると、同じことがわかります。

NAME        STATUS     VOLUME    CAPACITY    ACCESSMODES   AGE
nfs-pvc-2   Pending                                        10s

繰り返しますが、これは正常ですか?

複数の展開/ポッド間で共有NFSリソースを使用/再利用する適切な方法は何ですか?

18
John

PVC <-> PVの関係は1対1であるため、基本的には必要なことを実行できません。

NFSが使用可能な唯一のストレージであり、1つのnfsエクスポートで複数のPV/PVCが必要な場合は、Dynamic Provisioningとデフォルトのストレージクラスを使用します。

公式のK8にはまだありませんが、これはインキュベーターにあり、私はそれを試してみましたが、うまく機能します: https://github.com/kubernetes-incubator/external-storage/tree/master/nfs -client

これにより、PVCだけを処理する必要があるため、ボリュームのプロビジョニングが大幅に簡素化され、PVは、定義したnfsエクスポート/サーバー上のディレクトリとして作成されます。

12
Volker Kerkhoff

From: https://docs.openshift.org/latest/install_config/storage_examples/shared_storage.html

Baroudi Safwenが述べたように、2つのpvcを同じpvにバインドすることはできませんが、2つの異なるポッドで同じpvcを使用できます。

volumes:
- name: nfsvol-2
  persistentVolumeClaim:
    claimName: nfs-pvc-1 <-- USE THIS ONE IN BOTH PODS   
10
Javier Salmeron

永続ボリュームクレームは、永続ボリュームに排他的にバインドされます。
2つのpvcを同じpvにバインドすることはできません。

動的プロビジョニングに興味があると思います。ポッドの動的プロビジョニングを必要とするステートフルセットを展開しているときに、この問題に直面しました。したがって、クラスターにNFSプロビジョニング機能をデプロイする必要があります。NFSプロビジョニング機能(pod)はNFSフォルダー(ホストパス)にアクセスでき、ポッドがボリュームを要求するたびに、NFSプロビジョニング機能がNFSディレクトリーにマウントしますポッドの。
これをデプロイするgithubリポジトリを次に示します。
https://github.com/kubernetes-incubator/external-storage/tree/master/nfs/deploy/kubernetes
ただし、注意する必要があります。ボリュームはホストパス型であるため、ノードセレクターを使用して、nfsプロビジョニングツールが常にNFSフォルダーと同じマシンで実行されるようにする必要があります。

6
Baroudi Safwen

動的プロビジョニングに関するいくつかのポイント。

nfsの動的プロビジョニングを使用すると、デフォルトのnfsマウントオプションを変更できなくなります。私のプラットフォームでは、1Mのrsize/wsizeを使用しています。これは、小さなファイルを使用するアプリケーションや読み取りをブロックするアプリケーションで大きな問題を引き起こす可能性があります。 (私はこの問題を大々的にヒットしました)

dynamicは、ニーズに合った場合に最適なオプションです。 1対1の関係により、動的に処理されていたアプリケーション用に250 pv/pvcペアを作成することに固執しています。

0
Pete Smith