Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

23.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 テクノロジープレビュー機能のサポート対象範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

23.2. ローカルボリュームのマウント
リンクのコピー

注記

すべてのローカルボリュームは、OpenShift Container Platform によって PV として使用される前に手動でマウントする必要があります。

ローカルボリュームをマウントします。

  1. すべてのボリュームは、/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
    Copy to Clipboard Toggle word wrap

  2. Docker コンテナー内で実行中のプロセスに全ボリュームがアクセスできるようにします。これを可能にするには、以下のように、マウントされたファイルシステムのラベルを変更してください。 

    ---
$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
---
    Copy to Clipboard Toggle word wrap

23.3. ローカルプロビジョナーの設定
リンクのコピー

OpenShift Container Platform は、ローカルデバイス用に PV を作成する場合や、再利用の有効化に使用されなくなり PV を消去する場合に、外部のプロビジョナーを使用します。

注記
  • ローカルボリュームのプロビジョナーは大半のプロビジョナーとは異なり、動的なプロビジョニングに対応していません。
  • ローカルボリュームのプロビジョナーを使用する場合には、管理者は、各ノードでローカルボリュームを事前設定して、discovery ディレクトリーの配下にマウントする必要があります。その後にプロビジョナーは各ボリュームについて PV の作成とクリーンアップを実行してボリュームを管理します。

ローカルプロビジョナーを設定します。

  1. ConfigMap を使用して外部プロビジョナーが、ストレージクラスとディレクトリーを関連付けられるように設定します。この設定は、プロビジョナーがデプロイされる前に作成する必要があります。以下に例を示します。 

    apiVersion: v1
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
    Copy to Clipboard Toggle word wrap
    1
    ストレージクラス名
    2
    ホスト上のディレクトリーへのパス。/mnt/local-storage のサブディレクトリーでなければなりません。
    3
    プロビジョナー Pod のディレクトリーへのパス。ホストで使用されているディレクトリー構造と同じ構造を使用することを推奨します。今回の例では、mountDir は省略可能です。
  2. (オプション) ローカルボリュームのプロビジョナーおよびその設定用にスタンドアロンの 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 は更新時に自動的に変換されません。

23.4. ローカルプロビジョナーのデプロイ
リンクのコピー

注記

プロビジョナーを起動する前に、すべてのローカルデバイスをマウントし、ストレージクラスとそれらのディレクトリーと共に ConfigMap を作成します。

ローカルプロビジョナーをデプロイします。

  1. local-storage-provisioner-template.yaml ファイルからローカルプロビジョナーをインストールします。

  2. サービスアカウントを作成して、root ユーザーでの Pod 実行、hostPath ボリュームの使用をはじめ、SELinux コンテキストでローカルボリュームの監視、管理、消去ができるようにします。 

    $ oc create serviceaccount local-storage-admin
$ oc adm policy add-scc-to-user privileged -z local-storage-admin
    Copy to Clipboard Toggle word wrap

    プロビジョナー Pod で任意の Pod が作成したローカルボリュームのコンテンツを削除できるようにするには、root 権限と任意の SELinux コンテキストが必要です。ホスト上の /mnt/local-storage パスにアクセスするには hostPath が必要です。

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

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/release-3.10/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
    Copy to Clipboard Toggle word wrap

  4. 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
    Copy to Clipboard Toggle word wrap
    1
    v3.10 など、お使いの OpenShift Container Platform バージョン番号を指定します。

  5. 必要なストレージクラスを追加します。 

    $ oc create -f ./storage-class-ssd.yaml
$ oc create -f ./storage-class-hdd.yaml
    Copy to Clipboard Toggle word wrap

    以下は例を示しています。 

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: local-ssd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap 
    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: local-hdd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

その他の設定オプションについては、テンプレート を参照してください。このテンプレートは、全ノードで Pod を実行する DeamonSet を作成します。Pod は ConfigMap に指定されるディレクトリーを監視し、それらの PV を自動的に作成します。

このプロビジョナーは、PV が開放されると、変更されたディレクトリーからすべてのデータが削除されるので、Root パーミッションを使用して実行します。

23.5. 新規デバイスの追加
リンクのコピー

新規デバイスの追加は半自動で実行されます。プロビジョナーは設定されたディレクトリーで新規マウントについて定期的にチェックします。管理者は、以下のように、SELinux ラベルを適用して、新しいサブディレクトリーの作成、デバイスのマウント、Pod によるデバイスの使用許可を行う必要があります。 

$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
Copy to Clipboard Toggle word wrap
重要

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

23.6. raw ブロックデバイスの設定
リンクのコピー

ローカルのボリュームプロビジョナーを使用すると、raw ブロックデバイスを静的にプロビジョニングできます。この機能はデフォルトでは無効になっており、追加の設定が必要です。

Raw ブロックデバイスを設定するには以下を行います。

  1. 全マスターで、BlockVolume 機能ゲートを有効化します。全マスターでマスター設定ファイルを編集または作成して (デフォルトは /etc/origin/master/master-config.yaml)、apiServerArguments および controllerArguments セクションに、BlockVolume=true を追加します。 

    apiServerArguments:
   feature-gates:
   - BlockVolume=true
...

 controllerArguments:
   feature-gates:
   - BlockVolume=true
...
    Copy to Clipboard Toggle word wrap

  2. ノード設定 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
    Copy to Clipboard Toggle word wrap

  3. 以下のように、すべての ConfigMaps の、kubeletArguments の機能ゲートアレイに BlockVolume=true が含まれていることを確認します。

    ノードの configmap feature-gates 設定

    kubeletArguments:
   feature-gates:
   - RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true,BlockVolume=true
    Copy to Clipboard Toggle word wrap

  4. マスターを再起動します。ノードは、設定の変更後に自動的に再起動されます。これは数分かかる可能性があります。

23.6.1. raw ブロックデバイスの準備
リンクのコピー

プロビジョナーを起動する前に、Pod が使用できるすべての raw ブロックデバイスを /mnt/local-storage/<storage class> ディレクトリー構造にリンクします。たとえば、/dev/dm-36 のディレクトリーを利用できるようにします。

  1. /mnt/local-storage に、デバイスのストレージクラスのディレクトリーを作成します。 

    $ mkdir -p /mnt/local-storage/block-devices
    Copy to Clipboard Toggle word wrap

  2. このデバイスを参照するシンボリックリンクを作成します。 

    $ ln -s /dev/dm-36 dm-uuid-LVM-1234
    Copy to Clipboard Toggle word wrap
    注記

    名前の競合が発生するのを回避するには、/dev/disk/by-uuid または /dev/disk/by-id ディレクトリーからのリンクと、シンボリックリンクに同じ名前を使用します。

  3. プロビジョナー設定用の ConfigMap を作成するか、更新します。 

    apiVersion: v1
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
    Copy to Clipboard Toggle word wrap
    1
    ストレージクラス名
    2
    ホスト上のディレクトリーへのパス。/mnt/local-storage のサブディレクトリーでなければなりません。
    3
    プロビジョナー Pod のディレクトリーへのパス。ホストが使用するディレクトリー構造を使用する場合 (推奨) には、mountDir パラメーターを省略します。

  4. デバイスと、/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
    Copy to Clipboard Toggle word wrap

  5. Raw ブロックデバイスのストレージクラスを作成します。 

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: block-devices
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

プロビジョナーは、このブロックデバイス /dev/dm-36 を使用する準備ができ、PV としてプロビジョニングします。

23.6.2. raw ブロックデバイスプロビジョナーのデプロイ
リンクのコピー

Raw ブロックデバイスへのプロビジョナーのデプロイは、ローカルボリュームへのプロビジョナーのデプロイに似ていますが、2 点相違点があります。

  1. プロビジョナーは特権付きのコンテナーで実行する必要があります。
  2. プロビジョナーは、ホストから /dev のファイルシステムにアクセスできる必要があります。

Raw ブロックデバイスにプロビジョナーをデプロイします。

  1. local-storage-provisioner-template.yaml ファイルからテンプレートをダウンロードします。

  2. テンプレートを編集します。

    1. コンテナー仕様の securityContext の privileged 属性を true に設定します。 

      ...
  containers:
...
    name: provisioner
...
      securityContext:
        privileged: true
...
      Copy to Clipboard Toggle word wrap

    2. hostPath を使用して、コンテナーにホストの /dev/ ファイルシステムをマウントします。 

      ...
  containers:
...
    name: provisioner
...
    volumeMounts:
    - mountPath: /dev
      name: dev
...
  volumes:
    - hostPath:
        path: /dev
        name: dev
...
      Copy to Clipboard Toggle word wrap

  3. 変更済みの YAML ファイルからテンプレートを作成します。 

    $ oc create -f local-storage-provisioner-template.yaml
    Copy to Clipboard Toggle word wrap

  4. プロビジョナーを起動します。 

    $ 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
    Copy to Clipboard Toggle word wrap

23.6.3. 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: 1Gi
Copy to Clipboard Toggle word wrap

raw ブロックデバイス PVC を使用する Pod

apiVersion: 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
Copy to Clipboard Toggle word wrap

注記

ボリュームは、Pod にマウントされていませんが、/dev/xvda Raw ブロックデバイスとして公開されます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat