web-dev-qa-db-ja.com

Kubernetes / OpenShiftのコンテナー間で永続的なボリューム要求を共有する

これは馬鹿げた質問かもしれませんが、オンラインであまり知りませんでしたので、これを明確にしたいと思います。

2つのデプロイメントAとBがあり、両方にdifferentコンテナーイメージがある場合：

  • それらは、K8/OpenShiftクラスターの2つの異なるポッド（異なるrc、svcなど）にデプロイされます。
  • 彼らは両方とも、ファイルを読み取るために同じボリュームにアクセスする必要があります（今のところこれをロックアウトしないでください）、または少なくともそのボリュームの同じディレクトリ構造。
  • NFS共有に対して構成されたPV（永続ボリューム）に裏打ちされたPVC（永続ボリューム要求）を使用してこのボリュームをマウントします。

上記が実際に可能であることを確認できますか？つまり同じPVCで同じボリュームに接続された2つのdifferentポッド。したがって、両方とも同じボリュームから読み取っています。

それが理にかなっていると思います...

openshiftkubernetes
17
Donovan Muller

TL; DR共有ボリューム（nfs、glusterなど）の同じプロジェクト/名前空間内でPVとPVCを共有できます。複数のプロジェクト/名前空間から共有ボリュームにアクセスすることもできますが、プロジェクト専用のPVとPVCが必要です。 、PVは単一のプロジェクト/名前空間にバインドされ、PVCはプロジェクト/名前空間をスコープとするため。

以下では、現在の動作と、PVおよびPVCがOpenShift内でどのようにスコープされるかを説明しようとしました。これらは、永続ストレージレイヤーとしてNFSを使用する簡単な例です。

この時点でのaccessModesは単なるラベルであり、PVへのアクセスの制御に関して実際の機能はありません。以下は、これを示すいくつかの例です

pVは、任意のプロジェクト/名前空間から表示/アクセスできるという意味でグローバルですが、プロジェクトにバインドされると、同じプロジェクト/名前空間のコンテナからのみアクセスできます

pVCはプロジェクト/名前空間に固有です（複数のプロジェクトがある場合、共有NFSボリュームに接続するには、各プロジェクトに新しいPVとPVCが必要です-最初のプロジェクトのPVを再利用できません）

例1：
「デフォルト」のプロジェクト/名前空間で実行されている2つの異なるポッドがあり、どちらも同じPVおよびNFSエクスポート共有にアクセスしています。マウントして正常に動作します。

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

例2：
「デフォルト」のプロジェクト/名前空間で実行されている2つの異なるポッドがあり、同じPVを使用して別のポッドを作成しようとしますが、testprojectという新しいプロジェクトから同じNFSエクスポートにアクセスします。新しいtestprojectの3番目のポッドは、defaultプロジェクトによって既にバインドされているため、PVにバインドできません。

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

**別のプロジェクト（testproject）からの既存のPVに対して新しいクレームを作成すると、PVCは失敗します

[root@k8dev nfs_error]# oc get pvc 
NAME        LABELS    STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
nfs-claim   <none>    Pending                                      2s

**現在のプロジェクトスコープからそれを見ることができないため、nfs-claimはpv-nfs PVにバインドしません

例3：

「デフォルト」プロジェクトで2つの異なるポッドを実行していて、testprojectから別のPVおよびPVCとポッドを作成します。どちらのプロジェクトも同じNFSエクスポート共有にアクセスできますが、プロジェクトごとにPVとPVCが必要です。

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS     CLAIM                    REASON    AGE
pv-nfs    <none>    1Gi        RWX           Bound     default/nfs-claim                  14m
pv-nfs2   <none>    1Gi        RWX           Bound     testproject/nfs-claim2             9m



[root@k8dev nfs_error]# oc get pods --all-namespaces
NAMESPACE     NAME              READY     STATUS    RESTARTS   AGE
default       nfs-bb-pod2-pvc   1/1       Running   0          11m
default       nfs-bb-pod3-pvc   1/1       Running   0          11m
testproject   nfs-bb-pod4-pvc   1/1       Running   0          15s

**注意：2つのプロジェクトで同じNFS共有ボリュームに対して3つのポッドを実行していますが、単一のプロジェクトにバインドされているので2つのPVが必要で、各プロジェクトに1つ、2つのPVCが必要です。アクセス

例4：

PVとPVCをバイパスすると、nfsプラグインを直接使用して、任意のプロジェクトから共有NFSボリュームに直接接続できます

volumes:
- name: nfsvol
  nfs:
    path: /opt/data5
    server: nfs1.rhs

現在、ボリュームのセキュリティはこれに加えて、supplementalGroups（共有ストレージ、つまりnfs、glusterなど）を使用する別のレイヤーです。管理者と開発者は、共有NFSシステムへのアクセスをさらに管理および制御できるはずです。

それが役に立てば幸い

25
screeley

AFAIK、PVを複数回バインドすることはサポートされていません。ユースケースに直接ボリュームソース（ケースではNFS）を使用できます。

0
Huamin