第22章 ローカルボリュームの設定
22.1. 概要
OpenShift Container Platform は、アプリケーションデータのローカルボリュームにアクセスするように設定できます。
ローカルのボリュームとは、ローカルにマウントされたファイルシステムを表す永続ボリューム (PV) です。OpenShift Container Platform 3.10 の時点では、これには raw ブロックデバイスも含まれます。raw デバイスは、物理デバイスに、さらにダイレクトなルートを提供し、アプリケーションがその物理デバイスに対する I/O 操作のタイミングをより詳細に制御できるようにします。このように、raw デバイスは、通常独自のキャッシングを行うデータベース管理システムなどの複雑なアプリケーションに適しています。ローカルボリュームにはユニークな機能がいくつか含まれています。ローカルボリューム PV を使用する Pod は、ローカルボリュームがマウントされるノードでスケジューリングされます。
また、ローカルボリュームには、ローカルにマウントされたデバイスに PV を自動作成するプロビジョナーが含まれます。現時点で、このプロビジョナーは事前設定されたディレクトリーのみをスキャンします。このプロビジョナーは、ボリュームを動的にプロビジョニングする機能はありませんが、今後のリリースで実装される可能性はあります。
ローカルボリュームのプロビジョナーを使用すると、ローカルストレージを OpenShift Container Platform 内で使用することができます。ローカルボリュームのプロビジョナーは以下に対応しています。
- ボリューム
- PV
ローカルボリュームは、テクノロジープレビュー機能のみとなっています。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) ではサポートされていません。これらは、機能的に完全でない可能性があり、Red Hat では実稼働環境での使用を推奨しません。テクノロジープレビュー機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様に機能性をテストしていただき、開発プロセス中にフィードバックをお寄せいただくことを目的としています。Red Hat テクノロジープレビュー機能のサポート対象範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。
22.2. ローカルボリュームのマウント
すべてのローカルボリュームは、OpenShift Container Platform によって PV として使用される前に手動でマウントする必要があります。
ローカルボリュームをマウントします。
すべてのボリュームは、/mnt/local-storage/<storage-class-name>/<volume> パスにマウントしてください。管理者は、必要に応じてディスクパーティションまたは LVM などの方法でローカルデバイスを作成し、これらのデバイスに適切なファイルシステムを作成して、スクリプトまたは
/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.3. ローカルプロビジョナーの設定
OpenShift Container Platform は、ローカルデバイス用に PV を作成する場合や、再利用の有効化に使用されなくなり PV を消去する場合に、外部のプロビジョナーを使用します。
- ローカルボリュームのプロビジョナーは大半のプロビジョナーとは異なり、動的なプロビジョニングに対応していません。
- ローカルボリュームのプロビジョナーを使用する場合には、管理者は、各ノードでローカルボリュームを事前設定して、discovery ディレクトリーの配下にマウントする必要があります。その後にプロビジョナーは各ボリュームについて PV の作成とクリーンアップを実行してボリュームを管理します。
ローカルプロビジョナーを設定します。
ConfigMap を使用して外部プロビジョナーが、ストレージクラスとディレクトリーを関連付けられるように設定します。この設定は、プロビジョナーがデプロイされる前に作成する必要があります。以下に例を示します。
kind: ConfigMap metadata: name: local-volume-config data: storageClassMap: | 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-
(オプション) ローカルボリュームのプロビジョナーおよびその設定用にスタンドアロンの namespace を作成します。例:
oc new-project local-storage
上記の設定により、プロビジョナーは以下を作成します。
-
/mnt/local-storage/ssd ディレクトリーにマウントされる全サブディレクトリーに対して、
local-ssdのストレージクラスを指定した PV 1 つ -
/mnt/local-storage/hdd ディレクトリーにマウントされる全サブディレクトリーに対して、
local-hddのストレージクラスを指定した PV 1 つ
ConfigMap の構文は、OpenShift Container Platform 3.9 と 3.10 では変更されています。この機能はテクノロジープレビューであるため、ConfigMap は更新時に自動的に変換されません。
22.4. ローカルプロビジョナーのデプロイ
プロビジョナーを起動する前に、すべてのローカルデバイスをマウントし、ストレージクラスとそれらのディレクトリーと共に ConfigMap を作成します。
ローカルプロビジョナーをデプロイします。
- local-storage-provisioner-template.yaml ファイルからローカルプロビジョナーをインストールします。
サービスアカウントを作成して、root ユーザーでの Pod 実行、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/release-3.10/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
CONFIGMAP、SERVICE_ACCOUNT,NAMESPACEおよび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.10など、お使いの 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.5. 新規デバイスの追加
新規デバイスの追加は半自動で実行されます。プロビジョナーは設定されたディレクトリーで新規マウントについて定期的にチェックします。管理者は、以下のように、SELinux ラベルを適用して、新しいサブディレクトリーの作成、デバイスのマウント、Pod によるデバイスの使用許可を行う必要があります。
$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
上記のいずれかの操作を省くと、適切な PV が作成されなくなることがあります。
== Raw ブロックデバイスの設定: ローカルのボリュームプロビジョナーを使用すると、Raw ブロックデバイスを静的にプロビジョニングできます。この機能は、デフォルトでは無効になっており、追加の設定が必要です。
Raw ブロックデバイスを設定するには以下を行います。
全マスターで、
BlockVolume機能ゲートを有効化します。全マスターでマスター設定ファイルを編集または作成して (デフォルトは /etc/origin/master/master-config.yaml)、apiServerArgumentsおよびcontrollerArgumentsセクションに、BlockVolume=trueを追加します。apiServerArguments: feature-gates: - BlockVolume=true ... controllerArguments: feature-gates: - BlockVolume=true ...
ノード設定 ConfigMap を編集して、全ノードで機能ゲートを有効化します。
$ oc edit configmap node-config-compute --namespace openshift-node $ oc edit configmap node-config-master --namespace openshift-node $ oc edit configmap node-config-infra --namespace openshift-node
以下のように、すべての ConfigMaps の、
kubeletArgumentsの機能ゲートアレイにBlockVolume=trueが含まれていることを確認します。ノードの configmap feature-gates 設定
kubeletArguments: feature-gates: - RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true,BlockVolume=true
- マスターを再起動します。ノードは、設定の変更後に自動的に再起動されます。これは数分かかる可能性があります。
=== 新規 Raw ブロックデバイスの準備: プロビジョナーを起動する前に、Pod が使用できる全 Raw ブロックデバイスを /mnt/local-storage/<storage class> ディレクトリー構造にリンクします。たとえば、/dev/dm-36 のディレクトリーを利用できるようにします。
/mnt/local-storage に、デバイスのストレージクラスのディレクトリーを作成します。
$ mkdir -p /mnt/local-storage/block-devices
このデバイスを参照するシンボリックリンクを作成します。
$ ln -s /dev/dm-36 dm-uuid-LVM-1234
名前の競合が発生するのを回避するには、/dev/disk/by-uuid または /dev/disk/by-id ディレクトリーからのリンクと、シンボリックリンクに同じ名前を使用します。
プロビジョナー設定用の ConfigMap を作成するか、更新します。
kind: ConfigMap metadata: name: local-volume-config data: storageClassMap: | block-devices: 1 hostDir: /mnt/local-storage/block-devices 2 mountDir: /mnt/local-storage/block-devices 3デバイスと、/mnt/local-storage/ の
SELinuxラベルを変更します。$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/ $ chcon unconfined_u:object_r:svirt_sandbox_file_t:s0 /dev/dm-36
Raw ブロックデバイスのストレージクラスを作成します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: block-devices provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
プロビジョナーは、このブロックデバイス /dev/dm-36 を使用する準備ができ、PV としてプロビジョニングします。
=== Raw ブロックデバイスプロビジョナーのデプロイ
Raw ブロックデバイスへのプロビジョナーのデプロイは、ローカルボリュームへのプロビジョナーのデプロイに似ていますが、2 点相違点があります。
- プロビジョナーは特権付きのコンテナーで実行する必要があります。
- プロビジョナーは、ホストから /dev のファイルシステムにアクセスできる必要があります。
Raw ブロックデバイスにプロビジョナーをデプロイします。
- local-storage-provisioner-template.yaml ファイルからテンプレートをダウンロードします。
テンプレートを編集します。
コンテナー仕様の
securityContextのprivileged属性をtrueに設定します。... containers: ... name: provisioner ... securityContext: privileged: true ...hostPathを使用して、コンテナーにホストの /dev/ ファイルシステムをマウントします。... containers: ... name: provisioner ... volumeMounts: - mountPath: /dev name: dev ... volumes: - hostPath: path: /dev name: dev ...
変更済みの YAML ファイルからテンプレートを作成します。
$ oc create -f local-storage-provisioner-template.yaml
プロビジョナーを起動します。
$ 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.10 \ local-storage-provisioner
=== Raw ブロックデバイスの永続ボリューム
以下のように、Pod で raw ブロックデバイスを使用するには、volumeMode: を Block に、storageClassName を block-devices に設定して、永続ボリューム要求 (PVC) を作成します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
storageClassName: block-devices
accessModes:
- ReadWriteOnce
volumeMode: Block
resources:
requests:
storage: 1GiapiVersion: v1
kind: Pod
metadata:
name: busybox-test
labels:
name: busybox-test
spec:
restartPolicy: Never
containers:
- resources:
limits :
cpu: 0.5
image: gcr.io/google_containers/busybox
command:
- "/bin/sh"
- "-c"
- "while true; do date; sleep 1; done"
name: busybox
volumeDevices:
- name: vol
devicePath: /dev/xvda
volumes:
- name: vol
persistentVolumeClaim:
claimName: block-pvcボリュームは、Pod にマウントされていませんが、/dev/xvda Raw ブロックデバイスとして公開されます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.