第22章 ローカルボリュームの設定
22.1. 概要
OpenShift Container Platform は、アプリケーションデータのローカルボリュームにアクセスするように設定できます。
ローカルボリュームは、ローカルにマウントされたファイルシステムを表す永続ボリューム (PV) です。今後は、これらが raw ブロックデバイスに拡張される可能性があります。
ローカルボリュームは hostPath とは異なります。これらには特殊なアノテーションがあり、このアノテーションを使用して PV を使用する Pod を、ローカルボリュームがマウントされているノードと同じノードにスケジュールします。
また、ローカルボリュームには、ローカルにマウントされたデバイスに PV を自動作成するプロビジョナーが含まれます。現時点で、このプロビジョナーは制限が付けられており、これは事前設定されたディレクトリーのみをスキャンします。ボリュームを動的にプロビジョニングする機能はありませんが、今後のリリースで実装される可能性はあります。
ローカルボリュームのプロビジョナーを使用すると、ローカルストレージを OpenShift Container Platform 内で使用することができます。ローカルボリュームのプロビジョナーは以下に対応しています。
- ボリューム
- PV
ローカルボリュームはアルファ機能であり、OpenShift Container Platform の今後のリリースで変更される場合があります。
22.1.1. ローカルボリュームの有効化
すべてのマスターとノードで PersistentLocalVolumes
機能ゲートを有効にします。
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成して
PersistentLocalVolumes=true
をapiServerArguments
とcontrollerArguments
の各セクションの下に追加します。apiServerArguments: feature-gates: - PersistentLocalVolumes=true ... controllerArguments: feature-gates: - PersistentLocalVolumes=true ...
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成して
PersistentLocalVolumes=true
機能ゲートをkubeletArguments
の下に追加します。kubeletArguments: feature-gates: - PersistentLocalVolumes=true
22.1.2. ローカルボリュームのマウント
すべてのローカルボリュームは、OpenShift Container Platform によって PV として使用される前に手動でマウントする必要があります。
すべてのボリュームは、/mnt/local-storage/<storage-class-name>/<volume> パスにマウントされる必要があります。管理者は、必要に応じてローカルデバイスを作成し (ディスクパーティションまたは LVM などの方法を使用する)、これらのデバイスに適切なファイルシステムを作成して、スクリプトまたは /etc/fstab
エントリーを使用してそれらをマウントします。
/etc/fstab
エントリーの例
# device name # mount point # FS # options # extra /dev/sdb1 /mnt/local-storage/ssd/disk1 ext4 defaults 1 2 /dev/sdb2 /mnt/local-storage/ssd/disk2 ext4 defaults 1 2 /dev/sdb3 /mnt/local-storage/ssd/disk3 ext4 defaults 1 2 /dev/sdc1 /mnt/local-storage/hdd/disk1 ext4 defaults 1 2 /dev/sdc2 /mnt/local-storage/hdd/disk2 ext4 defaults 1 2
すべてのボリュームは、Docker コンテナー内で実行されているプロセスからアクセスできる必要があります。そのためには、マウントしたファイルシステムのラベルを変更します。
$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
22.1.3. ローカルプロビジョナーの設定
OpenShift Container Platform は、ローカルデバイス用に PV を作成する場合やそれら (の再利用の有効化) が不要になった際のクリーンアップ時に、外部のプロビジョナーを使用します。
- ローカルボリュームのプロビジョナーは大半のプロビジョナーとは異なり、動的なプロビジョニングに対応していません。
- ローカルボリュームのプロビジョナーは、管理者に対し、各ノードでローカルボリュームを事前設定し、それらを discovery ディレクトリーの下にマウントすることを要求します。その後にプロビジョナーは各ボリュームについて PV の作成とクリーンアップを実行してボリュームを管理します。
この外部のプロビジョナーは、ディレクトリーを StorageClasses に関連付けるために ConfigMap
を使って設定される必要があります。この設定は、プロビジョナーをデプロイする前に作成する必要があります。
(オプション) ローカルボリュームのプロビジョナーおよびその設定用にスタンドアロンの namespace を作成します。例: oc new-project local-storage
apiVersion: v1 kind: ConfigMap metadata: name: local-volume-config data: "local-ssd": | 1 { "hostDir": "/mnt/local-storage/ssd", 2 "mountDir": "/mnt/local-storage/ssd" 3 } "local-hdd": | { "hostDir": "/mnt/local-storage/hdd", "mountDir": "/mnt/local-storage/hdd" }
上記の設定により、プロビジョナーは以下を作成します。
-
/mnt/local-storage/ssd のすべてのサブディレクトリーについて StorageClass が
local-ssd
に設定されている 1 つの PV。 -
/mnt/local-storage/hdd のすべてのサブディレクトリーについて StorageClass が
local-hdd
に設定されている 1 つの PV。
LocalPersistentVolumes
のアルファ機能には、VolumeScheduling
のアルファ機能も必要になります。この変更に伴って以下の変更を実行することが必要になります。
-
VolumeScheduling
機能ゲートを kube-scheduler と kube-controller-manager の各コンポーネントで有効にする。 -
NoVolumeNodeConflict
述語を削除する。デフォルト以外のスケジューラーの場合、ユーザーのスケジューラーポリシーを更新する。 -
CheckVolumeBinding
述語は、デフォルト以外のスケジューラーで有効にする必要があります。
22.1.4. ローカルプロビジョナーのデプロイ
プロビジョナーを起動する前に、すべてのローカルデバイスをマウントし、ストレージクラスとそれらのディレクトリーと共に ConfigMap
を作成します。
local-storage-provisioner-template.yaml ファイルからローカルプロビジョナーをインストールします。
実行中の Pod を root ユーザーとして許可するサービスアカウントを作成し、hostPath ボリュームを使用して、SELinux コンテキストを使用してローカルボリュームの監視、管理、および消去を実行できるようにします。
$ oc create serviceaccount local-storage-admin $ oc adm policy add-scc-to-user privileged -z local-storage-admin
プロビジョナー Pod で任意の Pod が作成したローカルボリュームのコンテンツを削除できるようにするには、root 権限と任意の SELinux コンテキストが必要です。ホスト上の /mnt/local-storage パスにアクセスするには hostPath が必要です。
テンプレートをインストールします。
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
configmap
、account
、provisioner_image
のパラメーターの値を指定して、テンプレートをインスタンス化します。$ oc new-app -p CONFIGMAP=local-volume-config \ -p SERVICE_ACCOUNT=local-storage-admin \ -p NAMESPACE=local-storage \ -p PROVISIONER_IMAGE=registry.access.redhat.com/openshift3/local-storage-provisioner:v3.9 \ 1 local-storage-provisioner
- 1
v3.9
を適切な OpenShift Container Platform のバージョンに置き換えます。
必要なストレージクラスを追加します。
oc create -f ./storage-class-ssd.yaml oc create -f ./storage-class-hdd.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: local-ssd provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: local-hdd provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
その他の設定オプションについては、テンプレート 参照してください。このテンプレートは、すべてのノード上で Pod を実行する DeamonSet を作成します。Pod は
ConfigMap
に指定されるディレクトリーを監視し、それらの PV を自動的に作成します。プロビジョナーは、PV が解放され、すべてのデータの削除が必要になる場合にディレクトリーをクリーンアップできるよう root として実行されます。
22.1.5. 新規デバイスの追加
新規デバイスを追加するには、手動による操作がいくつか必要になります。
- プロビジョナーで DaemonSet を停止します。
- 新規デバイスを使ってノードの適切なディレクトリーにサブディレクトリーを作成し、これをマウントします。
- プロビジョナーを使って DeamonSet を起動します。
上記のいずれかの操作を省くと、適切な PV が作成されなくなることがあります。