56- 第13章：永続ストレージの割り当て-1：永続ストレージプロビジョニングの説明

type

status

date

slug

summary

第13章

永続ストレージの割り当て

目標

永続ストレージを実装する。

学習目標

アプリケーションで使用するための永続ストレージをプロビジョニングする。

内部コンテナレジストリの永続化設定について説明できるようにする。

セクション

永続ストレージのプロビジョニング（およびガイド付き演習）

内部レジストリの永続化の説明（およびクイズ）

実習

永続ストレージの割り当て

永続ストレージのプロビジョニング

目的

このセクションを完了すると、受講者はアプリケーションで使用するための永続ストレージをプロビジョニングできるようになります。

永続ストレージ

デフォルトでは、実行中のコンテナはコンテナ内のエフェメラル（揮発性）ストレージを使用します。Podは、一つまたは複数のコンテナで構成され、共通のストレージやリソースを共有しながらデプロイされます。Podはいつでも作成、起動、停止、破棄される可能性があり、エフェメラルストレージを使用すると、コンテナ内のファイルシステムに書き込まれたデータは、コンテナが停止すると失われます。

コンテナが停止してもデータを保持する必要があるアプリケーションをデプロイする場合、OpenShift は**Kubernetes の永続ボリューム（Persistent Volumes, PV）**を使用して、Pod に永続ストレージをプロビジョニングします。

永続ストレージのユースケース

例えば、データベースコンテナが Pod 起動時にデフォルトのエフェメラルストレージを使用しているとします。この場合、データベース Pod が破棄されて再作成されると、エフェメラルストレージも失われ、データが消えてしまいます。

しかし、永続ストレージを使用すると、データベースは Pod の外部にある永続ボリューム（Persistent Volume） にデータを保存します。仮に Pod が破棄されて再作成されても、データベースアプリケーションは同じ外部ストレージを引き続き利用できるため、データが保持されます。

アプリケーション向けの永続ストレージの提供

永続ボリューム（PV）は、OpenShift の管理者によって作成および削除されるリソースであり、クラスタ内のすべての OpenShift ノードからアクセス可能なネットワーク接続ストレージを表します。

永続ストレージの構成要素

OpenShift Container Platform は、Kubernetes の Persistent Volume（PV）フレームワーク を使用して、管理者がクラスタに永続ストレージをプロビジョニングできるようにします。開発者は Persistent Volume Claim（PVC） を使用して PV をリクエストできます。これにより、開発者はストレージ基盤の詳細を知らなくてもストレージを利用できます。

永続ボリューム（PV）

PersistentVolume API オブジェクト によって定義されるリソース
クラスタ内のネットワーク接続ストレージの一部を表し、管理者が事前にプロビジョニングする
ノードと同様にクラスタリソースとして扱われる
どの Pod によって使用されるかに関係なく、独立したライフサイクルを持つ

永続ボリューム要求（PVC）

PersistentVolumeClaim API オブジェクト によって定義される
開発者がストレージをリクエストするためのリソース
Pod がノードリソースを消費するのと同様に、PVC は PV リソースを消費する

OpenShift がサポートする永続ストレージのプラグイン

OpenShift は、さまざまなローカルまたはネットワーク接続ストレージのバックエンドをサポートするためにプラグインを使用します。以下のストレージバックエンドをサポートしています：

NFS（Network File System）

GlusterFS

OpenStack Cinder

Ceph RBD（RADOS Block Device）

AWS Elastic Block Store（EBS）

Google Cloud Engine（GCE）Persistent Disk

iSCSI（Internet Small Computer System Interface）

Fibre Channel（ファイバーチャネル）

Azure Disk および Azure File

FlexVolume（プラグインのないストレージバックエンドの拡張を可能にする）

VMware vSphere

さらに、以下の機能もサポートされています：

動的プロビジョニングとストレージクラスの作成

ボリュームのセキュリティ管理

セレクターラベルを使用したボリュームのバインディング

永続ボリュームのアクセスモード

PV は、ストレージプロバイダーがサポートする方式でホストにマウントされます。ストレージプロバイダーごとに異なる機能があり、各 PV のアクセスモードは、そのボリュームのサポートするモードに設定されます。

例えば、NFS は複数のノードでの読み書きをサポートしますが、特定の NFS PV はサーバー側の設定によって読み取り専用に設定されることもあります。

各 PV には、そのボリュームの機能を示すアクセスモードが設定されます。

アクセスモード	CLI 略称	説明
ReadWriteOnce	RWO	1つのノードからのみ読み書き可能
ReadOnlyMany	ROX	複数のノードから読み取り専用でアクセス可能
ReadWriteMany	RWX	複数のノードから読み書き可能

PVC は、同じアクセスモードを持つ PV にバインドされます。PVC のリクエストが「RWO」だった場合、NFS PV（RWO+ROX+RWX）が存在すれば、この PV にマッチングされます。

すべてのボリュームは同じアクセスモードごとにグループ化され、**サイズ順（小さいものから順に）**でソートされます。マスターのサービスが、マッチするアクセスモードの PV を検索し、適切なサイズの PV を見つけて PVC にバインドします。

永続ボリュームのストレージクラス

PVC（永続ボリューム要求）は、オプションとして storageClassName 属性を指定することで特定のストレージクラスを要求できます。PVC に指定されたストレージクラスと同じ名前を持つ PV（永続ボリューム）のみが、その PVC にバインドされます。

クラスタ管理者は、すべての PVC に対してデフォルトのストレージクラスを設定することができ、また、ストレージクラスに対応する動的プロビジョニング機能を構成することで、PVC の要求に応じたストレージを自動的に作成することも可能です。

PV と PVC のリソース作成

PV はクラスタ内のリソースであり、PVC はそれらのリソースを要求するためのものです。PV と PVC の関係は以下のライフサイクルに従います。

1. 永続ボリューム（PV）の作成

クラスタ管理者が、クラスター内で利用可能なストレージを表す PV を作成します。これにより、OpenShift API を通じてクラスターのユーザーがストレージを利用できるようになります。

2. 永続ボリューム要求（PVC）の定義

ユーザーは、必要なストレージサイズやアクセスモード、オプションでストレージクラスを指定して PVC を作成します。クラスタのマスターは新しい PVC を監視し、一致する PV を探すか、ストレージクラスに対応するプロビジョナーが新しい PV を作成するのを待ちます。そして、見つかった PV を PVC にバインドします。

3. 永続ストレージの利用

Pod は PVC をボリュームとして利用します。クラスタは PVC にバインドされた PV を検出し、Pod にそのボリュームをマウントします。複数のアクセスモードに対応するボリュームの場合、ユーザーは Pod のボリューム設定時にどのモードで利用するか指定します。

一度 PVC が PV にバインドされると、その PV はユーザーのものとなり、必要な限り利用し続けることができます。ユーザーは Pod をスケジューリングし、PVC をボリュームとして指定することで、データを保持したまま PV にアクセスできます。

NFS を永続ボリュームとして使用する場合

OpenShift はコンテナをランダムな UID で実行するため、OpenShift ノード上の Linux ユーザーと NFS サーバー上のユーザーを直接マッピングすることはできません。そのため、NFS を OpenShift の PV として使用する場合は、以下のように設定する必要があります。

NFS の所有者を nfsnobody ユーザーおよびグループに設定する

パーミッションを rwx------（0700）に設定する

NFS を all_squash オプション付きでエクスポートする

NFS のエクスポート設定例

以下のように /etc/exports にエントリを追加します。

sync と async のどちらのオプションを使用しても OpenShift は正常に動作しますが、高遅延の環境では async を使用すると NFS への書き込みが速くなる ため推奨されます。

async：データがディスクに書き込まれる前に NFS サーバーがクライアントへ応答するため、高速。

sync：データがディスクに書き込まれてから NFS サーバーがクライアントへ応答するため、安全性が高いが遅い。

NFS ストレージの制限と SELinux の設定

PV のサイズ制限について

NFS のファイルシステムのサイズやユーザークォータは OpenShift に影響しません。

PV のサイズは PV のリソース定義内で指定されますが、実際のファイルシステムがそれより小さくても、PV は作成され、PVC にバインドされます。

逆に、PV のサイズが実際のファイルシステムより大きい場合でも、OpenShift は PV のサイズを制限しません。つまり、コンテナはファイルシステム全体の空き領域を利用できる状態になります。

OpenShift では、プロジェクトごとのストレージクォータや配置制限を設定することで、リソースの割り当てを制御できます。

SELinux の設定

デフォルトの SELinux ポリシーでは、コンテナが NFS にアクセスできません。そのため、以下の設定を OpenShift の各ノードで行う必要があります。

この設定は OpenShift インストーラーによって自動的に適用されますが、手動で設定が必要な場合もあります。

リクレームポリシー（Reclamation Policies）

NFS は OpenShift Container Platform の リサイクルプラグイン（Recyclable Plug-in） を実装しています。PV のリクレーム（再利用）ポリシーは、PV ごとに設定することが可能です。

リクレームポリシーの種類

ポリシー	説明
Retain（保持）	デフォルトの設定。PVC が削除されても PV は削除されず、そのデータはそのまま残る。管理者が手動で PV を削除または再利用する必要がある。
Recycle（再利用）	PVC が削除されると、PV のデータを `rm -rf` で削除し、PV を新しい PVC にバインドできる状態にする。

ファイルベースのボリュームと補助グループ（Supplemental Groups）

補助グループ（Supplemental Groups）は、Linux の通常のグループ ID（GID）を指します。Linux ではプロセスは UID（ユーザー ID）、GID（グループ ID）、および複数の補助グループを持つことができます。これらの属性はコンテナのメインプロセスに対して設定可能です。

補助グループ（Supplemental Groups）：NFS や GlusterFS などの共有ストレージにアクセス制御を適用するために使用される。

fsGroup：Ceph RBD や iSCSI などのブロックストレージにアクセス制御を適用するために使用される。

OpenShift の共有ストレージプラグインは、ターゲットストレージの POSIX パーミッションに合わせてボリュームをマウントします。そのため、コンテナのメインプロセスの UID や GID を、ターゲットストレージの所有者 ID に一致させる必要があります。

ノードVMでのNFSのマウント状況確認

ノードVMで以下のコマンドを実行すると、NFSのエクスポートリストが表示されます。

出力例：

この例では、/var/export/nfs-demo がエクスポートされており、すべてのクライアント（*）からアクセス可能になっています。

NFSサーバーの設定

サービスVM上のNFSサーバーで、エクスポート設定ファイル /etc/exports.d/nfs-demo.conf を確認すると、次のように記述されています：

また、ディレクトリのパーミッションとSELinuxコンテキストを確認すると：

この出力は、NFS共有ディレクトリ /var/export/nfs-demo の所有者が UID=10000000、グループが GID=650000 であることを示しています。

一般的に、コンテナは root 権限で実行するべきではありません。

この設定では、UID 10000000 または GID 650000 で実行されないコンテナは NFS へのアクセスが拒否されます。

ブロックストレージにおける fsGroup の使用

ファイルシステムのグループを指定する fsGroup は、Pod の「ファイルシステムグループ」のIDを定義し、コンテナの補助グループとして追加されます。

fsGroup は ブロックストレージ に適用されるのに対し、supplementalGroups は 共有ストレージ（NFSなど） に適用されます。

共有ストレージ（NFS、GlusterFS など）

supplementalGroups を設定してアクセス権を調整する

ブロックストレージ（Ceph RBD、iSCSI、クラウドストレージなど）

fsGroup を使用して権限を設定する

ブロックストレージは基本的に 1つの Pod に専用で割り当てられるため、コンテナの UID/GID が直接ストレージデバイスに適用されます。

これは、NFS のような共有ストレージとは異なり、複数のPodで共有することを前提としていません。

SELinux とボリュームのセキュリティ

OpenShift のほぼすべてのセキュリティコンテキスト制約（SCC）は、SELinuxの MustRunAs ポリシーを使用しています。（例外：privileged SCC）

この MustRunAs ポリシーにより、Pod には特定の SELinux コンテキストが適用されます。

SELinuxのラベル設定は、Pod の securityContext.seLinuxOptions に記述できます。

これにより、Pod 内のプロセスに適用する ユーザー、ロール、タイプ、レベル を指定できます。

SELinuxContext オプション

設定	説明
MustRunAs	`seLinuxOptions` が設定されている必要がある（事前定義された値がない場合）。デフォルトで `seLinuxOptions` を使用し、値を検証する。
RunAsAny	デフォルトなし。どの `seLinuxOptions` でも指定可能。