Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第22章 ローカルボリュームの設定

22.1. 概要

OpenShift Container Platform は、アプリケーションデータのローカルボリュームにアクセスするように設定できます。

ローカルボリュームは、ローカルにマウントされたファイルシステムを表す永続ボリューム (PV) です。今後は、これらが raw ブロックデバイスに拡張される可能性があります。

ローカルボリュームは hostPath とは異なります。これらには特殊なアノテーションがあり、このアノテーションを使用して PV を使用する Pod を、ローカルボリュームがマウントされているノードと同じノードにスケジュールします。

また、ローカルボリュームには、ローカルにマウントされたデバイスに PV を自動作成するプロビジョナーが含まれます。現時点で、このプロビジョナーは制限が付けられており、これは事前設定されたディレクトリーのみをスキャンします。ボリュームを動的にプロビジョニングする機能はありませんが、今後のリリースで実装される可能性はあります。

ローカルボリュームのプロビジョナーを使用すると、ローカルストレージを OpenShift Container Platform 内で使用することができます。ローカルボリュームのプロビジョナーは以下に対応しています。

  • ボリューム
  • PV
注記

ローカルボリュームはアルファ機能であり、OpenShift Container Platform の今後のリリースで変更される場合があります。

22.1.1. ローカルボリュームの有効化

すべてのマスターとノードで PersistentLocalVolumes 機能ゲートを有効にします。

  1. すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成して PersistentLocalVolumes=trueapiServerArgumentscontrollerArguments の各セクションの下に追加します。

    apiServerArguments:
       feature-gates:
       - PersistentLocalVolumes=true
    ...
    
    controllerArguments:
       feature-gates:
       - PersistentLocalVolumes=true
    ...
  2. すべてのノードでノード設定ファイル (デフォルトは /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"
      }
1
StorageClass の名前。
2
ホスト上のディレクトリーへのパス。/mnt/local-storage のサブディレクトリーでなければなりません。
3
プロビジョナー Pod のディレクトリーへのパス。ホストで使用されているディレクトリー構造と同じ構造を使用することを推奨します。

上記の設定により、プロビジョナーは以下を作成します。

  • /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 ファイルからローカルプロビジョナーをインストールします。

  1. 実行中の 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 が必要です。

  2. テンプレートをインストールします。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
  3. configmapaccountprovisioner_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 のバージョンに置き換えます。
  4. 必要なストレージクラスを追加します。

    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. 新規デバイスの追加

新規デバイスを追加するには、手動による操作がいくつか必要になります。

  1. プロビジョナーで DaemonSet を停止します。
  2. 新規デバイスを使ってノードの適切なディレクトリーにサブディレクトリーを作成し、これをマウントします。
  3. プロビジョナーを使って DeamonSet を起動します。
重要

上記のいずれかの操作を省くと、適切な PV が作成されなくなることがあります。