3.3. 永続ボリューム
各 PV には、以下の例のように、ボリュームの仕様およびステータスである spec
および status
が含まれます。
PersistentVolume
オブジェクト定義の例
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 1 spec: capacity: storage: 5Gi 2 accessModes: - ReadWriteOnce 3 persistentVolumeReclaimPolicy: Retain 4 ... status: ...
3.3.1. PV の種類
OpenShift Container Platform は以下の永続ボリュームプラグインをサポートします。
- AWS Elastic Block Store (EBS)
- Azure Disk
- Azure File
- Cinder
- ファイバーチャネル
- GCE Persistent Disk
- HostPath
- iSCSI
- ローカルボリューム
- NFS
- OpenStack Manila
- Red Hat OpenShift Container Storage
- VMware vSphere
3.3.2. 容量
通常、永続ボリューム (PV) には特定のストレージ容量があります。これは PV の capacity
属性を使用して設定されます。
現時点で、ストレージ容量は設定または要求できる唯一のリソースです。今後は属性として IOPS、スループットなどが含まれる可能性があります。
3.3.3. アクセスモード
永続ボリュームは、リソースプロバイダーでサポートされるすべての方法でホストにマウントできます。プロバイダーには各種の機能があり、それぞれの PV のアクセスモードは特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。それぞれの PV は、その特定の PV の機能について記述するアクセスモードの独自のセットを取得します。
要求は、同様のアクセスモードのボリュームに一致します。一致する条件はアクセスモードとサイズの 2 つの条件のみです。要求のアクセスモードは要求 (request) を表します。そのため、より多くのアクセスを付与することはできますが、アクセスを少なくすることはできません。たとえば、要求により RWO が要求されるものの、利用できる唯一のボリュームが NFS PV (RWO+ROX+RWX) の場合に、要求は RWO をサポートする NFS に一致します。
直接的なマッチングが常に最初に試行されます。ボリュームのモードは、要求モードと一致するか、要求した内容以上のものを含む必要があります。サイズは予想されるものより多いか、またはこれと同等である必要があります。2 つのタイプのボリューム (NFS および iSCSI など) のどちらにも同じセットのアクセスモードがある場合、それらのいずれかがそれらのモードを持つ要求に一致する可能性があります。ボリュームのタイプ間で順序付けすることはできず、タイプを選択することはできません。
同じモードのボリュームはすべて分類され、サイズ別 (一番小さいものから一番大きいもの順) に分類されます。バインダーは一致するモードのグループを取得し、1 つのサイズが一致するまでそれぞれを (サイズの順序で) 繰り返し処理します。
以下の表では、アクセスモードをまとめています。
アクセスモード | CLI の省略形 | 説明 |
---|---|---|
ReadWriteOnce |
| ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。 |
ReadOnlyMany |
| ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
ReadWriteMany |
| ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。 |
ボリュームのアクセスモードは、ボリューム機能の記述子になります。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。
たとえば、NFS は ReadWriteOnce
アクセスモードを提供します。ボリュームの ROX 機能を使用する必要がある場合は、要求に read-only
のマークを付ける必要があります。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。
iSCSI およびファイバーチャネルボリュームには現在、フェンシングメカニズムがありません。ボリュームが一度に 1 つのノードでのみ使用されるようにする必要があります。ノードのドレイン (解放) などの特定の状況では、ボリュームは 2 つのノードで同時に使用できます。ノードをドレイン (解放) する前に、まずこれらのボリュームを使用する Pod が削除されていることを確認してください。
ボリュームプラグイン | ReadWriteOnce [1] | ReadOnlyMany | ReadWriteMany |
---|---|---|---|
AWS EBS [2] | ✅ | - | - |
Azure File | ✅ | ✅ | ✅ |
Azure Disk | ✅ | - | - |
Cinder | ✅ | - | - |
ファイバーチャネル | ✅ | ✅ | - |
GCE Persistent Disk | ✅ | - | - |
HostPath | ✅ | - | - |
iSCSI | ✅ | ✅ | - |
ローカルボリューム | ✅ | - | - |
NFS | ✅ | ✅ | ✅ |
OpenStack Manila | - | - | ✅ |
Red Hat OpenShift Container Storage | ✅ | - | ✅ |
VMware vSphere | ✅ | - | - |
- ReadWriteOnce (RWO) ボリュームは複数のノードにマウントできません。ノードに障害が発生すると、システムは、すでに障害が発生しているノードに割り当てられているため、割り当てられた RWO ボリュームを新規ノードにマウントすることはできません。複数割り当てのエラーメッセージが表示される場合には、シャットダウンまたはクラッシュしたノードで Pod を強制的に削除し、動的永続ボリュームの割り当て時などの重要なワークロードでのデータ損失を回避します。
- AWS EBS に依存する Pod の再作成デプロイメントストラテジーを使用します。
3.3.4. フェーズ
ボリュームは以下のフェーズのいずれかにあります。
フェーズ | 説明 |
---|---|
Available | まだ要求にバインドされていない空きリソースです。 |
Bound | ボリュームが要求にバインドされています。 |
Released | 要求が削除されていますが、リソースがまだクラスターにより回収されていません。 |
Failed | ボリュームが自動回収に失敗しています。 |
以下を実行して PV にバインドされている PVC の名前を表示できます。
$ oc get pv <pv-claim>
3.3.4.1. マウントオプション
属性 mountOptions
を使用して PV のマウント中にマウントオプションを指定できます。
以下に例を示します。
マウントオプションの例
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
mountOptions: 1
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2
persistentVolumeReclaimPolicy: Retain
claimRef:
name: claim1
namespace: default
- 1
- 指定のマウントオプションは、PV がディスクにマウントされている時に使用されます。
以下の PV タイプがマウントオプションをサポートします。
- AWS Elastic Block Store (EBS)
- Azure Disk
- Azure File
- Cinder
- GCE Persistent Disk
- iSCSI
- ローカルボリューム
- NFS
- Red Hat OpenShift Container Storage (Ceph RBD のみ)
- VMware vSphere
ファイバーチャネルおよび HostPath PV はマウントオプションをサポートしません。