検索

ストレージ

download PDF
OpenShift Container Platform 4.16

OpenShift Container Platform でのストレージの設定および管理

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、各種のストレージのバックエンドから永続ボリュームを設定し、Pod からの動的な割り当てを管理する方法を説明します。

第1章 OpenShift Container Platform ストレージの概要

OpenShift Container Platform は、オンプレミスおよびクラウドプロバイダーの両方で、複数のタイプのストレージをサポートします。OpenShift Container Platform クラスターで、永続データおよび非永続データ用のコンテナーストレージを管理できます。

1.1. OpenShift Container Platform ストレージの共通用語集

この用語集では、ストレージコンテンツで使用される一般的な用語を定義します。

アクセスモード

ボリュームアクセスモードは、ボリューム機能を表します。アクセスモードを使用して、永続ボリューム要求 (PVC) と永続ボリューム (PV) を一致させることができます。次に、アクセスモードの例を示します。

  • ReadWriteOnce (RWO)
  • ReadOnlyMany (ROX)
  • ReadWriteMany (RWX)
  • ReadWriteOncePod (RWOP)
Cinder
すべてのボリュームの管理、セキュリティー、およびスケジューリングを管理する Red Hat OpenStack Platform (RHOSP) 用の Block Storage サービス。
設定マップ
config map は、設定データを Pod に注入する方法を提供します。タイプ ConfigMap のボリューム内の config map に格納されたデータを参照できます。Pod で実行しているアプリケーションは、このデータを使用できます。
Container Storage Interface (CSI)
異なるコンテナーオーケストレーション (CO) システム間でコンテナーストレージを管理するための API 仕様。
動的プロビジョニング
このフレームワークを使用すると、ストレージボリュームをオンデマンドで作成できるため、クラスター管理者が永続ストレージを事前にプロビジョニングする必要がなくなります。
一時ストレージ
Pod とコンテナーは、その操作のために一時的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。
ファイバーチャネル
データセンター、コンピューターサーバー、スイッチ、およびストレージ間でデータを転送するために使用されるネットワークテクノロジー。
FlexVolume
FlexVolume は、EXEC ベースのモデルを使用してストレージドライバーとインターフェイス接続するツリー外プラグインインターフェイスです。FlexVolume ドライバーバイナリーは、各ノード、場合によってはコントロールプレーンノードの事前定義されたボリュームプラグインパスにインストールする必要があります。
fsGroup
fsGroup は、Pod のファイルシステムグループ ID を定義します。
iSCSI
iSCSI (Internet Small Computer Systems Interface) は、データストレージ施設をリンクするための Internet Protocol ベースのストレージネットワーク標準です。iSCSI ボリュームを使用すると、既存の iSCSI (SCSI over IP) ボリュームを Pod にマウントできます。
hostPath
OpenShift Container Platform クラスター内の hostPath ボリュームは、ファイルまたはディレクトリーをホストノードのファイルシステムから Pod にマウントします。
KMS キー
Key Management Service (KMS) は、さまざまなサービスで必要なレベルのデータ暗号化を実現するのに役立ちます。KMS キーを使用して、データの暗号化、復号化、および再暗号化を行うことができます。
ローカルボリューム
ローカルボリュームは、ディスク、パーティション、ディレクトリーなどのマウントされたローカルストレージデバイスを表します。
NFS
ネットワークファイルシステム (NFS) を利用すると、リモートのホストがネットワーク経由でファイルシステムをマウントし、そのファイルシステムを、ローカルにマウントしているファイルシステムと同じように操作できるようになります。また、システム管理者は、リソースをネットワーク上の中央サーバーに統合することができるようになります。
OpenShift Data Foundation
インハウスまたはハイブリッドクラウドのいずれの場合でもファイル、ブロック、およびオブジェクトストレージをサポートし、OpenShift Container Platform のすべてに対応する非依存永続ストレージのプロバイダーです。
永続ストレージ
Pod とコンテナーは、その操作のために永続的なストレージを必要とする場合があります。OpenShift Container Platform は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、基盤となるストレージインフラストラクチャーに関する特定の知識がなくても、PVC を使用して PV リソースを要求できます。
永続ボリューム (PV)
OpenShift Container Platform は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、基盤となるストレージインフラストラクチャーに関する特定の知識がなくても、PVC を使用して PV リソースを要求できます。
永続ボリューム要求 (PVC)
PVC を使用して、PersistentVolume を Pod にマウントできます。クラウド環境の詳細を知らなくてもストレージにアクセスできます。
Pod
OpenShift Container Platform クラスターで実行されている、ボリュームや IP アドレスなどの共有リソースを持つ 1 つ以上のコンテナー。Pod は、定義、デプロイ、および管理される最小のコンピュート単位です。
回収ポリシー
解放後のボリュームの処理方法をクラスターに指示するポリシー。ボリュームの回収ポリシーは、RetainRecycle または Delete のいずれかにすることができます。
ロールベースアクセス制御 (RBAC)
ロールベースのアクセス制御 (RBAC) は、組織内の個々のユーザーのロールに基づいて、コンピューターまたはネットワークリソースへのアクセスを規制する方法です。
ステートレスアプリケーション
ステートレスアプリケーションは、あるセッションで生成されたクライアントデータを、そのクライアントとの次のセッションで使用するために保存しないアプリケーションプログラムです。
ステートフルアプリケーション
ステートフルアプリケーションは、データを永続ディスクストレージに保存するアプリケーションプログラムです。サーバー、クライアント、およびアプリケーションは、永続ディスクストレージを使用できます。OpenShift Container Platform で Statefulset オブジェクトを使用して一連の Pod のデプロイメントとスケーリングを管理し、これらの Pod の順序と一意性を保証できます。
静的プロビジョニング
クラスター管理者は、多数の PV を作成します。PV にはストレージの詳細が含まれます。PV は Kubernetes API に存在し、消費することができます。
ストレージ
OpenShift Container Platform は、オンプレミスおよびクラウドプロバイダーの両方で、多くのタイプのストレージをサポートします。OpenShift Container Platform クラスターで、永続データおよび非永続データ用のコンテナーストレージを管理できます。
ストレージクラス
ストレージクラスは、管理者が提供するストレージのクラスを説明する方法を提供します。さまざまなクラスが、サービスレベルの品質、バックアップポリシー、クラスター管理者によって決定された任意のポリシーにマップされる場合があります。
VMware vSphere の仮想マシンディスク (VMDK) ボリューム
仮想マシンディスク (VMDK) は、仮想マシンで使用される仮想ハードディスクドライブのコンテナーを記述するファイル形式です。

1.2. ストレージタイプ

OpenShift Container Platform ストレージは、一時ストレージおよび永続ストレージという 2 つのカテゴリーに大別されます。

1.2.1. 一時ストレージ

Pod およびコンテナーは性質上、一時的または遷移的であり、ステートレスアプリケーション用に設計されています。一時ストレージを使用すると、管理者および開発者は一部の操作についてローカルストレージをより適切に管理できるようになります。一時ストレージの概要、タイプ、および管理の詳細は、一時ストレージについて を参照してください。

1.2.2. 永続ストレージ

コンテナーにデプロイされるステートフルアプリケーションには永続ストレージが必要です。OpenShift Container Platform は、永続ボリューム (PV) と呼ばれる事前にプロビジョニングされたストレージフレームワークを使用して、クラスター管理者が永続ストレージをプロビジョニングできるようにします。これらのボリューム内のデータは、個々の Pod のライフサイクルを超えて存在することができます。開発者は永続ボリューム要求 (PVC) を使用してストレージ要件を要求できます。永続ストレージの概要、設定、およびライフサイクルの詳細は、永続ストレージについて を参照してください。

1.3. Container Storage Interface (CSI)

CSI は、異なるコンテナーオーケストレーション (CO) システム間でコンテナーストレージを管理するための API 仕様です。基礎となるストレージインフラストラクチャーに関する特定の知識がなくても、コンテナーネイティブ環境でストレージボリュームを管理できます。CSI により、使用しているストレージベンダーに関係なく、ストレージは異なるコンテナーオーケストレーションシステム間で均一に機能します。CSI の詳細は、Container Storage Interface (CSI) の使用 を参照してください。

1.4. 動的プロビジョニング

動的プロビジョニングにより、ストレージボリュームをオンデマンドで作成し、クラスター管理者がストレージを事前にプロビジョニングする必要をなくすことができます。動的プロビジョニングの詳細は、動的プロビジョニング を参照してください。

第2章 一時ストレージについて

2.1. 概要

永続ストレージに加え、Pod とコンテナーは、操作に一時または短期的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。

Pod は、スクラッチ領域、キャッシュ、ログに一時ローカルストレージを使用します。ローカルストレージのアカウントや分離がないことに関連する問題には、以下が含まれます。

  • Pod が利用可能なローカルストレージの量を検出できない。
  • Pod がローカルストレージを要求しても確実に割り当てられない可能性がある。
  • ローカルストレージがベストエフォートのリソースである。
  • Pod は他の Pod でローカルストレージが一杯になるとエビクトされる可能性があり、十分なストレージが回収されるまで新しい Pod は許可されない。

一時ストレージは、永続ボリュームとは異なり、体系化されておらず、システム、コンテナーランタイム、OpenShift Container Platform での他の用途に加え、ノードで実行中のすべての Pod 間で領域を共有します。一時ストレージフレームワークにより、Pod は短期的なローカルストレージのニーズを指定できます。またこれにより、OpenShift Container Platform は該当する場合に Pod をスケジュールし、ローカルストレージの過剰な使用に対してノードを保護することができます。

一時ストレージフレームワークを使用すると、管理者および開発者はローカルストレージをより適切に管理できますが、I/O スループットやレイテンシーに直接影響はありません。

2.2. 一時ストレージのタイプ

一時ローカルストレージは常に、プライマリーパーティションで利用できるようになっています。プライマリーパーティションを作成する基本的な方法には、root、ランタイムの 2 つがあります。

Root

このパーティションでは、kubelet の root ディレクトリー /var/lib/kubelet/ (デフォルト) と /var/log/ ディレクトリーを保持します。このパーティションは、ユーザーの Pod、OS、Kubernetes システムのデーモン間で共有できます。Pod は、EmptyDir ボリューム、コンテナーログ、イメージ階層、コンテナーの書き込み可能な階層を使用して、このパーティションを使用できます。Kubelet はこのパーティションの共有アクセスおよび分離を管理します。このパーティションは一時的なもので、アプリケーションは、このパーティションからディスク IOPS などのパフォーマンス SLA は期待できません。

ランタイム

これは、ランタイムがオーバーレイファイルシステムに使用可能なオプションのパーティションです。OpenShift Container Platform は、このパーティションの分離および共有アクセスを特定して提供します。コンテナーイメージ階層と書き込み可能な階層は、ここに保存されます。ランタイムパーティションが存在すると、root パーティションにはイメージ階層もその他の書き込み可能階層も含まれません。

2.3. 一時ストレージ管理

クラスター管理者は、非終了状態のすべての Pod の一時ストレージに対して制限範囲や一時ストレージの要求数を定義するクォータを設定することで、プロジェクト内で一時ストレージを管理できます。開発者は Pod およびコンテナーのレベルで、このコンピュートリソースの要求および制限を設定することもできます。

要求と制限を指定することで、ローカルの一時ストレージを管理できます。Pod 内の各コンテナーは、以下を指定できます。

  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

2.3.1. 一時ストレージの制限と要求の単位

一時ストレージの制限と要求は、バイト単位で測定されます。ストレージは、E、P、T、G、M、k のいずれかの接尾辞を使用して、単純な整数または固定小数点数として表すことができます。Ei、Pi、Ti、Gi、Mi、Ki の 2 のべき乗も使用できます。

たとえば、128974848、129e6、129M、および 123Mi はすべてほぼ同じ値を表します。

重要

各バイト量の接尾辞では大文字と小文字が区別されます。必ず大文字と小文字を正しく使い分けてください。要求を 400 メガバイトに設定する場合は、"400M" のように、大文字の "M" を使用します。400 メビバイトを要求するには、大文字の "400Mi" を使用します。"400m" の一時ストレージを指定すると、ストレージが 0.4 バイトしか要求されません。

2.3.2. 一時ストレージの要求と制限の例

次のサンプル設定ファイルは、2 つのコンテナーを持つ Pod を示しています。

  • 各コンテナーは、2GiB のローカル一時ストレージを要求します。
  • 各コンテナーには、4GiB のローカル一時ストレージの制限があります。
  • Pod レベルでは、kubelet は、その Pod 内のすべてのコンテナーの制限を合計することで、Pod 全体のストレージ制限を計算します。

    • この場合、Pod レベルでの合計ストレージ使用量は、すべてのコンテナーからのディスク使用量と Pod の emptyDir ボリュームの合計になります。
    • したがって、Pod には 4GiB のローカル一時ストレージの要求と、8GiB のローカル一時ストレージの制限があります。

クォータと制限を含む一時ストレージ設定の例

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 1
      limits:
        ephemeral-storage: "4Gi" 2
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

1
ローカル一時ストレージに対するコンテナーの要求。
2
ローカル一時ストレージに対するコンテナーの制限。

2.3.3. Pod のスケジューリングとエビクションに影響する一時ストレージ設定

Pod 仕様の設定は、スケジューラーが Pod のスケジュールを決定する方法と、kubelet が Pod を削除するタイミングの両方に影響します。

  • まず、スケジューラーは、スケジュールされたコンテナーのリソース要求の合計がノードの容量よりも少ないことを確認します。この場合は、ノードの利用可能な一時ストレージ (割り当て可能なリソース) が 4 GiB を超える場合に限り、Pod をノードに割り当てることができます。
  • 次に、最初のコンテナーによってリソース制限が設定されるため、kubelet エビクションマネージャーがこのコンテナーのディスク使用量をコンテナーレベルで測定し、コンテナーのストレージ使用量がその制限 (4 GiB) を超えた場合に Pod をエビクトします。kubelet エビクションマネージャーは、合計使用量が全体の Pod ストレージ制限 (8 GiB) を超えた場合にも、Pod にエビクションのマークを付けます。

プロジェクトのクォータ定義の詳細は、プロジェクトごとのクォータ設定 を参照してください。

2.4. 一時ストレージのモニタリング

/bin/df をツールとして使用し、一時コンテナーデータが置かれているボリューム (/var/lib/kubelet および /var/lib/containers) の一時ストレージの使用を監視できます。/var/lib/kubelet のみが使用できる領域は、クラスター管理者によって /var/lib/containers が別のディスクに置かれる場合に df コマンドを使用すると表示されます。

/var/lib での使用済みおよび利用可能な領域の人間が判読できる値を表示するには、以下のコマンドを実行します。

$ df -h /var/lib

この出力には、/var/lib での一時ストレージの使用状況が表示されます。

出力例

Filesystem  Size  Used Avail Use% Mounted on
/dev/disk/by-partuuid/4cd1448a-01    69G   32G   34G  49% /

第3章 永続ストレージについて

3.1. 永続ストレージの概要

ストレージの管理は、コンピュートリソースの管理とは異なります。OpenShift Container Platform は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、永続ボリューム要求 (PVC) を使用すると、基礎となるストレージインフラストラクチャーについて特定の知識がなくても PV リソースを要求することができます。

PVC はプロジェクトに固有のもので、開発者が PV を使用する手段として作成し、使用します。PV リソース自体のスコープはいずれの単一プロジェクトにも設定されず、それらは OpenShift Container Platform クラスター全体で共有でき、すべてのプロジェクトから要求できます。PV が PVC にバインドされた後は、その PV を追加の PVC にバインドすることはできません。これにはバインドされた PV を単一の namespace (バインディングプロジェクトの namespace) にスコープ設定する作用があります。

PV は、クラスター管理者によって静的にプロビジョニングされているか、StorageClass オブジェクトを使用して動的にプロビジョニングされているクラスター内の既存ストレージの一部を表す、PersistentVolume API オブジェクトで定義されます。これは、ノードがクラスターリソースであるのと同様にクラスター内のリソースです。

PV は Volumes などのボリュームプラグインですが、PV を使用する個々の Pod から独立したライフサイクルを持ちます。PV オブジェクトは、NFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムのいずれの場合でも、ストレージの実装の詳細をキャプチャーします。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

PVC は、開発者によるストレージの要求を表す PersistentVolumeClaim API オブジェクトによって定義されます。これは Pod がノードリソースを消費する点で Pod に似ており、PVC は PV リソースを消費します。たとえば、Pod は特定のレベルのリソース (CPU およびメモリーなど) を要求し、PVC は特定のストレージ容量およびアクセスモードを要求できます。たとえば、それらは読み取り/書き込みで 1 回、読み取り専用で複数回マウントできます。

3.2. ボリュームおよび要求のライフサイクル

PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。

3.2.1. ストレージのプロビジョニング

PVC で定義される開発者からの要求に対応し、クラスター管理者はストレージおよび一致する PV をプロビジョニングする 1 つ以上の動的プロビジョナーを設定します。

または、クラスター管理者は、使用可能な実際のストレージの詳細を保持する多数の PV を前もって作成できます。PV は API に存在し、利用可能な状態になります。

3.2.2. 要求のバインド

PVC の作成時に、ストレージの特定容量の要求、必要なアクセスモードの指定のほか、ストレージクラスを作成してストレージの記述や分類を行います。マスターのコントロールループは新規 PVC の有無を監視し、新規 PVC を適切な PV にバインドします。適切な PV がない場合は、ストレージクラスのプロビジョナーが PV を作成します。

すべての PV のサイズが PVC サイズを超える可能性があります。これは、手動でプロビジョニングされる PV にとくに当てはまります。超過を最小限にするために、OpenShift Container Platform は他のすべての条件に一致する最小の PV にバインドします。

要求は、一致するボリュームが存在しないか、ストレージクラスを提供するいずれの利用可能なプロビジョナーで作成されない場合には無期限でバインドされないままになります。要求は、一致するボリュームが利用可能になるとバインドされます。たとえば、多数の手動でプロビジョニングされた 50Gi ボリュームを持つクラスターは 100Gi を要求する PVC に一致しません。PVC は 100Gi PV がクラスターに追加されるとバインドされます。

3.2.3. Pod および要求した PV の使用

Pod は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合は、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。

要求が存在し、その要求がバインドされている場合は、バインドされた PV を必要な期間保持できます。Pod のスケジュールおよび要求された PV のアクセスは、persistentVolumeClaim を Pod のボリュームブロックに組み込んで実行できます。

注記

ファイル数が多い永続ボリュームを Pod に割り当てる場合、それらの Pod は失敗するか、起動に時間がかかる場合があります。詳細は、When using Persistent Volumes with high file counts in OpenShift, why do pods fail to start or take an excessive amount of time to achieve "Ready" state? を参照してください。

3.2.4. 使用中のストレージオブジェクトの保護

使用中のストレージオブジェクトの保護機能を使用すると、Pod または PVC にバインドされる PV によってアクティブに使用されている PVC がシステムから削除されないようにすることができます。これらが削除されると、データが失われる可能性があります。

使用中のストレージオブジェクトの保護はデフォルトで有効にされています。

注記

PVC は、PVC を使用する Pod オブジェクトが存在する場合に Pod によってアクティブに使用されます。

ユーザーが Pod によってアクティブに使用されている PVC を削除する場合でも、PVC はすぐに削除されません。PVC の削除は、PVC が Pod によってアクティブに使用されなくなるまで延期されます。また、クラスター管理者が PVC にバインドされる PV を削除しても、PV はすぐに削除されません。PV の削除は、PV が PVC にバインドされなくなるまで延期されます。

3.2.5. 永続ボリュームの解放

ボリュームの処理が終了したら、API から PVC オブジェクトを削除できます。これにより、リソースを回収できるようになります。ボリュームは要求の削除時に解放 (リリース) されたものとみなされますが、別の要求で利用できる状態にはなりません。以前の要求側に関連するデータはボリューム上に残るため、ポリシーに基づいて処理される必要があります。

3.2.6. 永続ボリュームの回収ポリシー

永続ボリュームの回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法を指示します。ボリュームの回収ポリシーは、RetainRecycle または Delete のいずれかにすることができます。

  • Retain 回収ポリシーは、サポートするボリュームプラグインのリソースの手動による回収を許可します。
  • Recycle 回収ポリシーは、ボリュームがその要求からリリースされると、バインドされていない永続ボリュームのプールにボリュームをリサイクルします。
重要

Recycle 回収ポリシーは OpenShift Container Platform 4 では非推奨となっています。動的プロビジョニングは、同等またはそれ以上の機能で推奨されます。

  • Delete 回収ポリシーは、OpenShift Container Platform の PersistentVolume オブジェクトと、Amazon Elastic Block Store (Amazon EBS) または VMware vSphere などの外部インフラストラクチャーの関連するストレージアセットの両方を削除します。
注記

動的にプロビジョニングされたボリュームは常に削除されます。

3.2.7. 永続ボリュームの手動回収

永続ボリューム要求 (PVC) が削除されても、永続ボリューム (PV) は依然として存在し、"released" (リリース済み) とみなされます。ただし、PV は、直前の要求側のデータがボリューム上に残るため、別の要求には利用できません。

手順

クラスター管理者として PV を手動で回収するには、以下を実行します。

  1. PV を削除します。

    $ oc delete pv <pv-name>

    AWS EBS、GCE PD、Azure Disk、Cinder ボリュームなどの外部インフラストラクチャーの関連するストレージアセットは、PV の削除後も引き続き存在します。

  2. 関連するストレージアセットのデータをクリーンアップします。
  3. 関連するストレージアセットを削除します。または、同じストレージアセットを再利用するには、ストレージアセットの定義で新規 PV を作成します。

回収される PV が別の PVC で使用できるようになります。

3.2.8. 永続ボリュームの回収ポリシーの変更

永続ボリュームの回収ポリシーを変更するには、以下を実行します。

  1. クラスターの永続ボリュームをリスト表示します。

    $ oc get pv

    出力例

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
     pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
     pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
     pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s

  2. 永続ボリュームの 1 つを選択し、その回収ポリシーを変更します。

    $ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
  3. 選択した永続ボリュームに正しいポリシーがあることを確認します。

    $ oc get pv

    出力例

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
     pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
     pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
     pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     3s

    上記の出力では、要求 default/claim3 にバインドされたボリュームに Retain 回収ポリシーが含まれるようになりました。ユーザーが要求 default/claim3 を削除しても、ボリュームは自動的に削除されません。

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:
  ...

1
永続ボリュームの名前。
2
ボリュームに利用できるストレージの量。
3
読み取り書き込みおよびマウントパーミッションを定義するアクセスモード。
4
リソースのリリース後にそれらのリソースがどのように処理されるかを示す回収ポリシー。

3.3.1. PV の種類

OpenShift Container Platform は以下の永続ボリュームプラグインをサポートします。

  • AWS Elastic Block Store (EBS)
  • AWS Elastic File Store (EFS)
  • Azure Disk
  • Azure File
  • Cinder
  • ファイバーチャネル
  • GCP Persistent Disk
  • GCP Filestore
  • IBM Power Virtual Server Block
  • IBM® VPC Block
  • HostPath
  • iSCSI
  • ローカルボリューム
  • NFS
  • OpenStack Manila
  • Red Hat OpenShift Data Foundation
  • CIFS/SMB
  • 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 つのサイズが一致するまでそれぞれを (サイズの順序で) 繰り返し処理します。

重要

ボリュームアクセスモードは、ボリューム機能を表します。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。

たとえば、NFS は ReadWriteOnce アクセスモードを提供します。ボリュームの ROX 機能を使用する場合は、要求に ReadOnlyMany マークを付けます。

iSCSI およびファイバーチャネルボリュームには現在、フェンシングメカニズムがありません。ボリュームが一度に 1 つのノードでのみ使用されるようにする必要があります。ノードのドレイン (解放) などの特定の状況では、ボリュームは 2 つのノードで同時に使用できます。ノードをドレインする前に、そのボリュームを使用している Pod を削除します。

以下の表では、アクセスモードをまとめています。

表3.1 アクセスモード
アクセスモードCLI の省略形説明

ReadWriteOnce

RWO

ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。

ReadWriteOncePod [1]

RWOP

ボリュームは、1 つのノード上の 1 つの Pod によって読み取り/書き込みとしてマウントできます。

ReadOnlyMany

ROX

ボリュームは数多くのノードで読み取り専用としてマウントできます。

ReadWriteMany

RWX

ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。

  1. RWOP は SELinux マウント機能を使用します。この機能はドライバーに依存しており、ODF、AWS EBS、Azure Disk、GCP PD、IBM VPC Block、Cinder、vSphere ではデフォルトで有効になっています。サードパーティーのドライバーについては、ストレージベンダーにお問い合わせください。
表3.2 永続ボリュームでサポートされるアクセスモード
ボリュームプラグインReadWriteOnce [1]ReadWriteOncePodReadOnlyManyReadWriteMany

AWS EBS [2]

 ✅

 ✅

AWS EFS

 ✅

 ✅

 ✅

 ✅

Azure File

 ✅

 ✅

 ✅

Azure Disk

 ✅

 ✅

CIFS/SMB

 ✅

 ✅

 ✅

 ✅

Cinder

 ✅

 ✅

ファイバーチャネル

 ✅

 ✅

  ✅ [3]

GCP Persistent Disk

 ✅

GCP Filestore

 ✅

 ✅

 ✅

HostPath

 ✅

IBM Power Virtual Server Disk

 ✅

 ✅

  ✅

IBM® VPC Disk

 ✅

iSCSI

 ✅

 ✅

  ✅ [3]

ローカルボリューム

 ✅

LVM Storage

 ✅

 ✅

NFS

 ✅

 ✅

 ✅

OpenStack Manila

 ✅

Red Hat OpenShift Data Foundation

 ✅

 ✅

VMware vSphere

 ✅

  ✅ [4]

OpenStack Manila

 ✅

Red Hat OpenShift Data Foundation

 ✅

 ✅

  1. ReadWriteOnce (RWO) ボリュームは複数のノードにマウントできません。ノードに障害が発生すると、システムは、すでに障害が発生しているノードに割り当てられているため、割り当てられた RWO ボリュームを新規ノードにマウントすることはできません。複数割り当てのエラーメッセージが表示される場合には、シャットダウンまたはクラッシュしたノードで Pod を強制的に削除し、動的永続ボリュームの割り当て時などの重要なワークロードでのデータ損失を回避します。
  2. AWS EBS に依存する Pod の再作成デプロイメントストラテジーを使用します。
  3. raw ブロックボリュームのみが、ファイバーチャネルおよび iSCSI の ReadWriteMany (RWX) アクセスモードをサポートします。詳細は、「ブロックボリュームのサポート」を参照してください。
  4. 基盤となる vSphere 環境が vSAN ファイルサービスをサポートしている場合、OpenShift Container Platform によってインストールされた vSphere Container Storage Interface (CSI) Driver Operator は ReadWriteMany (RWX) ボリュームのプロビジョニングをサポートします。vSAN ファイルサービスが設定されていない場合に RWX を要求すると、ボリュームの作成に失敗し、エラーがログに記録されます。詳細は、"Using Container Storage Interface" → "VMware vSphere CSI Driver Operator" を参照してください。

3.3.4. フェーズ

ボリュームは以下のフェーズのいずれかにあります。

表3.3 ボリュームのフェーズ
フェーズ説明

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 Data Foundation (Ceph RBD のみ)
  • CIFS/SMB
  • VMware vSphere
注記

ファイバーチャネルおよび HostPath PV はマウントオプションをサポートしません。

3.4. 永続ボリューム要求

PersistentVolumeClaim オブジェクトには、永続ボリューム要求 (PVC) の仕様およびステータスである spec および status が含まれます。以下が例になります。

PersistentVolumeClaim オブジェクト定義の例

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim 1
spec:
  accessModes:
    - ReadWriteOnce 2
  resources:
    requests:
      storage: 8Gi 3
  storageClassName: gold 4
status:
  ...

1
PVC の名前。
2
読み取り書き込みおよびマウントパーミッションを定義するアクセスモード。
3
PVC に利用できるストレージの量。
4
要求で必要になる StorageClass の名前。

3.4.1. ストレージクラス

要求は、ストレージクラスの名前を storageClassName 属性に指定して特定のストレージクラスをオプションでリクエストできます。リクエストされたクラスの PV、つまり PVC と同じ storageClassName を持つ PV のみが PVC にバインドされます。クラスター管理者は 1 つ以上のストレージクラスを提供するように動的プロビジョナーを設定できます。クラスター管理者は、PVC の仕様に一致する PV をオンデマンドで作成できます。

重要

Cluster Storage Operator は、使用されるプラットフォームに応じてデフォルトのストレージクラスをインストールする可能性があります。このストレージクラスは Operator によって所有され、制御されます。アノテーションとラベルを定義するほかは、これを削除したり、変更したりすることはできません。異なる動作が必要な場合は、カスタムストレージクラスを定義する必要があります。

クラスター管理者は、すべての PVC にデフォルトストレージクラスを設定することもできます。デフォルトのストレージクラスが設定されると、PVC は "" に設定された StorageClass または storageClassName アノテーションがストレージクラスなしの PV にバインドされるように明示的に要求する必要があります。

注記

複数のストレージクラスがデフォルトとしてマークされている場合、PVC は storageClassName が明示的に指定されている場合にのみ作成できます。そのため、1 つのストレージクラスのみをデフォルトとして設定する必要があります。

3.4.2. アクセスモード

要求は、特定のアクセスモードのストレージを要求する際にボリュームと同じ規則を使用します。

3.4.3. リソース

要求は、Pod の場合のようにリソースの特定の数量を要求できます。今回の例では、ストレージに対する要求です。同じリソースモデルがボリュームと要求の両方に適用されます。

3.4.4. ボリュームとしての要求

Pod は要求をボリュームとして使用することでストレージにアクセスします。この要求を使用して、Pod と同じ namespace 内に要求を共存させる必要があります。クラスターは Pod の namespace で要求を見つけ、これを使用して要求をサポートする PersistentVolume を取得します。以下のように、ボリュームはホストにマウントされ、Pod に組み込まれます。

ホストおよび Pod のサンプルへのボリュームのマウント

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 1
        name: mypd 2
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 3

1
Pod 内にボリュームをマウントするためのパス
2
マウントするボリュームの名前。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
3
使用する同じ namespace にある PVC の名前

3.5. ブロックボリュームのサポート

OpenShift Container Platform は、raw ブロックボリュームを静的にプロビジョニングできます。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込むアプリケーションや、独自のストレージサービスを実装するアプリケーションにはパフォーマンス上の利点があります。

raw ブロックボリュームは、PV および PVC 仕様で volumeMode: Block を指定してプロビジョニングされます。

重要

raw ブロックボリュームを使用する Pod は、特権付きコンテナーを許可するように設定する必要があります。

以下の表は、ブロックボリュームをサポートするボリュームプラグインを表示しています。

表3.4 ブロックボリュームのサポート
ボリュームプラグイン手動のプロビジョニング動的なプロビジョニングフルサポート

Amazon Elastic Block Store (Amazon EBS)

Amazon Elastic File Storage (Amazon EFS)

   

Azure Disk

Azure File

   

Cinder

ファイバーチャネル

 

GCP

HostPath

   

IBM VPC Disk

iSCSI

 

ローカルボリューム

 

LVM Storage

NFS

   

Red Hat OpenShift Data Foundation

CIFS/SMB

VMware vSphere

重要

手動でプロビジョニングできるものの、完全にサポートされていないブロックボリュームの使用は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.5.1. ブロックボリュームの例

PV の例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

1
volumeModeBlock に設定して、この PV が raw ブロックボリュームであることを示します。

PVC の例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  resources:
    requests:
      storage: 10Gi

1
volumeModeBlock に設定して、raw ブロック PVC が要求されていることを示します。

Pod 仕様の例

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  1
        - name: data
          devicePath: /dev/xvda 2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc 3

1
volumeMounts ではなく volumeDevices がブロックデバイスに使用されます。PersistentVolumeClaim ソースのみを raw ブロックボリュームと共に使用できます。
2
mountPath ではなく devicePath が raw ブロックがシステムにマップされる物理デバイスへのパスを表します。
3
ボリュームソースのタイプは persistentVolumeClaim であり、予想通りに PVC の名前に一致する必要があります。
表3.5 volumeMode の許容値
デフォルト

Filesystem

はい

Block

いいえ

表3.6 ブロックボリュームのバインディングシナリオ
PV volumeModePVC volumeModeバインディングの結果

Filesystem

Filesystem

バインド

Unspecified

Unspecified

バインド

Filesystem

Unspecified

バインド

Unspecified

Filesystem

バインド

Block

Block

バインド

Unspecified

Block

バインドなし

Block

Unspecified

バインドなし

Filesystem

Block

バインドなし

Block

Filesystem

バインドなし

重要

値を指定しないと、Filesystem のデフォルト値が指定されます。

3.6. fsGroup を使用した Pod タイムアウトの削減

ストレージボリュームに多数のファイル (~1,000,000 以上) が含まれる場合には、Pod のタイムアウトが生じる可能性があります。

デフォルトでは、OpenShift Container Platform は、ボリュームがマウントされる際に Pod の securityContext で指定される fsGroup に一致するよう、各ボリュームのコンテンツの所有者とパーミッションを再帰的に変更するため、これが発生する可能性があります。大規模なボリュームでは、所有者とパーミッションの確認と変更には時間がかかり、Pod の起動が遅くなる場合があります。securityContext 内で fsGroupChangePolicy フィールドを使用して、OpenShift Container Platform がボリュームの所有者およびパーミッションを確認し管理する方法を制御できます。

fsGroupChangePolicy は、Pod 内で公開される前にボリュームの所有者およびパーミッションを変更する動作を定義します。このフィールドは、fsGroupで制御される所有者およびパーミッションをサポートするボリュームタイプにのみ適用されます。このフィールドには、以下の 2 つの値を指定できます。

  • OnRootMismatch: ルートディレクトリーのパーミッションと所有者が、ボリュームの予想されるパーミッションと一致しない場合にのみ、パーミッションと所有者を変更します。これにより、ボリュームの所有者とパーミッションを変更するのに必要な時間を短縮でき、Pod のタイムアウトを減らすことができます。
  • Always: ボリュームのマウント時に、常にボリュームのパーミッションと所有者を変更します。

fsGroupChangePolicy の例

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" 1
  ...

1
OnRootMismatch は、再帰的なパーミッション変更をスキップさせるため、Pod のタイムアウトの問題を回避するのに役立ちます。
注記

fsGroupChangePolicyfield は、secret、configMap、および emptydir などの一時ボリュームタイプには影響を及ぼしません。

第4章 Configuring persistent storage

4.1. AWS Elastic Block Store を使用した永続ストレージ

OpenShift Container Platform は、Amazon Elastic Block Store (EBS) ボリュームをサポートします。Amazon EC2 を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。Amazon EBS ボリュームを動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。KMS キーを定義して、AWS のコンテナー永続ボリュームを暗号化できます。デフォルトでは、OpenShift Container Platform バージョン 4.10 以降を使用して新しく作成されたクラスターは、gp3 ストレージと AWS EBS CSI ドライバー を使用します。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

重要

OpenShift Container Platform 4.12 以降では、AWS Block インツリーボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。

4.1.1. EBS ストレージクラスの作成

ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。

4.1.2. 永続ボリューム要求の作成

前提条件

ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順

  1. OpenShift Container Platform コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
  3. 表示されるページで必要なオプションを定義します。

    1. ドロップダウンメニューから以前に作成したストレージクラスを選択します。
    2. ストレージ要求の一意の名前を入力します。
    3. アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
    4. ストレージ要求のサイズを定義します。
  4. Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。

4.1.3. ボリュームのフォーマット

OpenShift Container Platform は、ボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType パラメーターで指定されたファイルシステムがボリュームにあるかどうか確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

この確認により、OpenShift Container Platform がフォーマットされていない AWS ボリュームを初回の使用前にフォーマットするため、フォーマットされていない AWS ボリュームを永続ボリュームとして使用することが可能になります。

4.1.4. ノード上の EBS ボリュームの最大数

OpenShift Container Platform では、デフォルトで 1 つのノードに最大 39 の EBS ボリュームを割り当てることができます。この制限は、AWS ボリュームの制限 に合致します。ボリュームの制限は、インスタンスのタイプによって異なります。

重要

クラスター管理者は、In-tree または Container Storage Interface (CSI) ボリュームのいずれかと、それぞれのストレージクラスを使用する必要がありますが、ボリュームの両方のタイプを同時に使用することはできません。割り当てられている EBS ボリュームの最大数は、in-tree および CSI ボリュームについて別々にカウントされるため、各タイプの EBS ボリュームを最大 39 個使用できます。

in-tree ボリュームプラグインでは不可能な追加のストレージオプション (ボリュームスナップショットなど) へのアクセスに関する詳細は、AWS Elastic Block Store CSI Driver Operator を参照してください。

4.1.5. KMS キーを使用した AWS 上のコンテナー永続ボリュームの暗号化

AWS でコンテナー永続ボリュームを暗号化するための KMS キーを定義すると、AWS へのデプロイ時に明示的なコンプライアンスおよびセキュリティーのガイドラインがある場合に役立ちます。

前提条件

  • 基盤となるインフラストラクチャーには、ストレージが含まれている必要があります。
  • AWS で顧客 KMS キーを作成する必要があります。

手順

  1. ストレージクラスを作成します。

    $ cat << EOF | oc create -f -
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class-name> 1
    parameters:
      fsType: ext4 2
      encrypted: "true"
      kmsKeyId: keyvalue 3
    provisioner: ebs.csi.aws.com
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer
    EOF
    1
    ストレージクラスの名前を指定します。
    2
    プロビジョニングされたボリューム上に作成されるファイルシステム。
    3
    コンテナー永続ボリュームを暗号化するときに使用するキーの完全な Amazon リソースネーム (ARN) を指定します。キーを指定せず、encrypted フィールドが true に設定されていると、デフォルトの KMS キーが使用されます。AWS ドキュメントの Finding the key ID and key ARN on AWS の検索を参照してください。
  2. KMS キーを指定するストレージクラスで永続ボリューム要求 (PVC) を作成します。

    $ cat << EOF | oc create -f -
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Filesystem
      storageClassName: <storage-class-name>
      resources:
        requests:
          storage: 1Gi
    EOF
  3. PVC を使用するワークロードコンテナーを作成します。

    $ cat << EOF | oc create -f -
    kind: Pod
    metadata:
      name: mypod
    spec:
      containers:
        - name: httpd
          image: quay.io/centos7/httpd-24-centos7
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: /mnt/storage
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: mypvc
    EOF

4.1.6. 関連情報

  • in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどの追加のストレージオプションへのアクセスの詳細は、AWS Elastic Block Store CSI Driver Operator を参照してください。

4.2. Azure を使用した永続ストレージ

OpenShift Container Platform では、Microsoft Azure Disk ボリュームがサポートされます。Azure を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Azure についてある程度の理解があることが前提となります。Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。Azure Disk ボリュームは動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。

重要

OpenShift Container Platform 4.11 以降では、Azure Disk インツリーボリュームプラグインを同等の CSI ドライバーに自動的に移行します。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

関連情報

4.2.1. Azure ストレージクラスの作成

ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。

手順

  1. OpenShift Container Platform コンソールで、StorageStorage Classes をクリックします。
  2. ストレージクラスの概要では、Create Storage Class をクリックします。
  3. 表示されるページで必要なオプションを定義します。

    1. ストレージクラスを参照するための名前を入力します。
    2. オプションの説明を入力します。
    3. 回収ポリシーを選択します。
    4. ドロップダウンリストから kubernetes.io/azure-disk を選択します。

      1. ストレージアカウントのタイプを入力します。これは、Azure ストレージアカウントの SKU の層に対応します。有効なオプションは、Premium_LRSPremiumV2_LRSStandard_LRSStandardSSD_LRS、および UltraSSD_LRS です。

        重要

        skuname の PremiumV2_LRS は、すべてのリージョンでサポートされているわけではありません。また、一部のサポートされているリージョンでも、すべてのアベイラビリティゾーンがサポートされているわけではありません。詳細は、Azure ドキュメント を参照してください。

      2. アカウントの種類を入力します。有効なオプションは shareddedicated および managed です。

        重要

        Red Hat は、ストレージクラスでの kind: Managed の使用のみをサポートします。

        Shared および Dedicated の場合、Azure はマネージド外のディスクを作成しますが、OpenShift Container Platform はマシンの OS (root) ディスクの管理ディスクを作成します。ただし、Azure Disk はノードで管理ディスクおよびマネージド外ディスクの両方の使用を許可しないため、Shared または Dedicated で作成されたマネージド外ディスクを OpenShift Container Platform ノードに割り当てることはできません。

    5. 必要に応じてストレージクラスの追加パラメーターを入力します。
  4. Create をクリックしてストレージクラスを作成します。

4.2.2. 永続ボリューム要求の作成

前提条件

ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順

  1. OpenShift Container Platform コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
  3. 表示されるページで必要なオプションを定義します。

    1. ドロップダウンメニューから以前に作成したストレージクラスを選択します。
    2. ストレージ要求の一意の名前を入力します。
    3. アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
    4. ストレージ要求のサイズを定義します。
  4. Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。

4.2.3. ボリュームのフォーマット

OpenShift Container Platform は、ボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType パラメーターで指定されたファイルシステムがボリュームにあるかどうか確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

これにより、OpenShift Container Platform がフォーマットされていない Azure ボリュームを初回の使用前にフォーマットするため、それらを永続ボリュームとして使用することが可能になります。

4.2.4. PVC を使用して Ultra ディスクと共にマシンをデプロイするマシンセット

Ultra ディスクと共にマシンをデプロイする Azure で実行されるマシンセットを作成できます。Ultra ディスクは、最も要求の厳しいデータワークロードでの使用を目的とした高性能ストレージです。

in-tree プラグインおよび CSI ドライバーの両方が、Ultra ディスクを有効にするための PVC の使用をサポートします。PVC を作成せずに、データディスクとしての Ultra デイスクと共にマシンをデプロイすることもできます。

4.2.4.1. マシンセットを使用した Ultra ディスクを持つマシンの作成

マシンセットの YAML ファイルを編集することで、Azure 上に Ultra ディスクと共にマシンをデプロイできます。

前提条件

  • 既存の Microsoft Azure クラスターがある。

手順

  1. 既存の Azure MachineSet カスタムリソース (CR) をコピーし、次のコマンドを実行して編集します。

    $ oc edit machineset <machine-set-name>

    ここで、<machine-set-name> は、Ultra ディスクと共にマシンをプロビジョニングするマシンセットです。

  2. 示された位置に次の行を追加します。

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    spec:
      template:
        spec:
          metadata:
            labels:
              disk: ultrassd 1
          providerSpec:
            value:
              ultraSSDCapability: Enabled 2
    1
    このマシンセットによって作成されるノードを選択するために使用するラベルを指定します。この手順では、この値に disk.ultrassd を使用します。
    2
    これらの行により、Ultra ディスクの使用が可能になります。
  3. 次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。

    $ oc create -f <machine-set-name>.yaml
  4. 以下の YAML 定義が含まれるストレージクラスを作成します。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ultra-disk-sc 1
    parameters:
      cachingMode: None
      diskIopsReadWrite: "2000" 2
      diskMbpsReadWrite: "320" 3
      kind: managed
      skuname: UltraSSD_LRS
    provisioner: disk.csi.azure.com 4
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer 5
    1
    ストレージクラスの名前を指定します。この手順では、この値に ultra-disk-sc を使用しています。
    2
    ストレージクラスの IOPS の数値を指定します。
    3
    ストレージクラスのスループットを MBps 単位で指定します。
    4
    Azure Kubernetes Service (AKS) バージョン 1.21 以降の場合は、disk.csi.azure.com を使用します。以前のバージョンの AKS の場合は、kubernetes.io/azure-disk を使用します。
    5
    オプション: ディスクを使用する Pod の作成を待機するには、このパラメーターを指定します。
  5. 以下の YAML 定義が含まれる、ultra-disk-sc ストレージクラスを参照する永続ボリューム要求 (PVC) を作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ultra-disk 1
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: ultra-disk-sc 2
      resources:
        requests:
          storage: 4Gi 3
    1
    PVC の名前を指定します。この手順では、この値に ultra-disk を使用しています。
    2
    この PVC は ultra-disk-sc ストレージクラスを参照します。
    3
    ストレージクラスのサイズを指定します。最小値は 4Gi です。
  6. 以下の YAML 定義が含まれる Pod を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx-ultra
    spec:
      nodeSelector:
        disk: ultrassd 1
      containers:
      - name: nginx-ultra
        image: alpine:latest
        command:
          - "sleep"
          - "infinity"
        volumeMounts:
        - mountPath: "/mnt/azure"
          name: volume
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: ultra-disk 2
    1
    Ultra ディスクの使用を有効にするマシンセットのラベルを指定します。この手順では、この値に disk.ultrassd を使用します。
    2
    この Pod は ultra-disk PVC を参照します。

検証

  1. 次のコマンドを実行して、マシンが作成されていることを確認します。

    $ oc get machines

    マシンは Running 状態になっているはずです。

  2. 実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。

    $ oc debug node/<node-name> -- chroot /host lsblk

    このコマンドでは、oc debug node/<node-name> がノード <node-name> でデバッグシェルを開始し、-- を付けてコマンドを渡します。渡されたコマンド chroot /host は、基盤となるホスト OS バイナリーへのアクセスを提供し、lsblk は、ホスト OS マシンに接続されているブロックデバイスを表示します。

次のステップ

  • Pod 内から Ultra ディスクを使用するには、マウントポイントを使用するワークロードを作成します。次の例のような YAML ファイルを作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: ssd-benchmark1
    spec:
      containers:
      - name: ssd-benchmark1
        image: nginx
        ports:
          - containerPort: 80
            name: "http-server"
        volumeMounts:
        - name: lun0p1
          mountPath: "/tmp"
      volumes:
        - name: lun0p1
          hostPath:
            path: /var/lib/lun0p1
            type: DirectoryOrCreate
      nodeSelector:
        disktype: ultrassd
4.2.4.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

このセクションの情報を使用して、発生する可能性のある問題を理解し、回復してください。

4.2.4.2.1. Ultra ディスクがサポートする永続ボリューム要求をマウントできない

Ultra ディスクでサポートされる永続ボリューム要求のマウントに問題がある場合、Pod は ContainerCreating 状態のままになり、アラートがトリガーされます。

たとえば、additionalCapabilities.ultraSSDEnabled パラメーターが Pod をホストするノードをサポートするマシンで設定されていない場合、以下のエラーメッセージが表示されます。

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
  • この問題を解決するには、以下のコマンドを実行して Pod を記述します。

    $ oc -n <stuck_pod_namespace> describe pod <stuck_pod_name>

4.3. Azure File を使用した永続ストレージ

OpenShift Container Platform では、Microsoft Azure File ボリュームがサポートされます。Azure を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Azure についてある程度の理解があることが前提となります。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。Azure File ボリュームを動的にプロビジョニングできます。

永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、アプリケーションで使用できるようにユーザーによって要求されます。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

重要

Azure File ボリュームは Server Message Block を使用します。

重要

OpenShift Container Platform 4.13 以降では、Azure File インツリーボリュームプラグインを同等の CSI ドライバーに自動的に移行します。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。

関連情報

4.3.1. Azure File 共有永続ボリューム要求の作成

永続ボリューム要求を作成するには、最初に Azure アカウントおよびキーを含む Secret オブジェクトを定義する必要があります。このシークレットは PersistentVolume 定義に使用され、アプリケーションで使用できるように永続ボリューム要求によって参照されます。

前提条件

  • Azure File 共有があること。
  • この共有にアクセスするための認証情報 (とくにストレージアカウントおよびキー) が利用可能であること。

手順

  1. Azure File の認証情報が含まれる Secret オブジェクトを作成します。

    $ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 1
      --from-literal=azurestorageaccountkey=<storage-account-key> 2
    1
    Azure File ストレージアカウントの名前。
    2
    Azure File ストレージアカウントキー。
  2. 作成した Secret オブジェクトを参照する PersistentVolume を作成します。

    apiVersion: "v1"
    kind: "PersistentVolume"
    metadata:
      name: "pv0001" 1
    spec:
      capacity:
        storage: "5Gi" 2
      accessModes:
        - "ReadWriteOnce"
      storageClassName: azure-file-sc
      azureFile:
        secretName: <secret-name> 3
        shareName: share-1 4
        readOnly: false
    1
    永続ボリュームの名前。
    2
    この永続ボリュームのサイズ。
    3
    Azure File 共有の認証情報を含むシークレットの名前。
    4
    Azure File 共有の名前。
  3. 作成した永続ボリュームにマップする PersistentVolumeClaim オブジェクトを作成します。

    apiVersion: "v1"
    kind: "PersistentVolumeClaim"
    metadata:
      name: "claim1" 1
    spec:
      accessModes:
        - "ReadWriteOnce"
      resources:
        requests:
          storage: "5Gi" 2
      storageClassName: azure-file-sc 3
      volumeName: "pv0001" 4
    1
    永続ボリューム要求の名前。
    2
    この永続ボリューム要求のサイズ。
    3
    永続ボリュームのプロビジョニングに使用されるストレージクラスの名前。PersistentVolume 定義で使用されるストレージクラスを指定します。
    4
    Azure File 共有を参照する既存の PersistentVolume オブジェクトの名前。

4.3.2. Azure File 共有の Pod へのマウント

永続ボリューム要求の作成後に、これをアプリケーション内で使用できます。以下の例は、この共有を Pod 内にマウントする方法を示しています。

前提条件

  • 基礎となる Azure File 共有にマップされる永続ボリューム要求があること。

手順

  • 既存の永続ボリューム要求をマウントする Pod を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-name 1
    spec:
      containers:
        ...
        volumeMounts:
        - mountPath: "/data" 2
          name: azure-file-share
      volumes:
        - name: azure-file-share
          persistentVolumeClaim:
            claimName: claim1 3
    1
    Pod の名前。
    2
    Pod 内に Azure File 共有をマウントするパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
    3
    以前に作成された PersistentVolumeClaim オブジェクトの名前。

4.4. Cinder を使用した永続ストレージ

OpenShift Container Platform は OpenStack Cinder をサポートします。これには、Kubernetes と OpenStack についてある程度の理解があることが前提となります。

Cinder ボリュームは動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。

重要

OpenShift Container Platform 4.11 以降では、Cinder インツリーボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。

関連情報

  • OpenStack Block Storage が仮想ハードドライブの永続ブロックストレージ管理を提供する方法の詳細は、OpenStack Cinder を参照してください。

4.4.1. Cinder を使用した手動プロビジョニング

ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

前提条件

  • Red Hat OpenStack Platform (RHOSP) 用に設定された OpenShift Container Platform
  • Cinder ボリューム ID
4.4.1.1. 永続ボリュームの作成

OpenShift Container Platform に永続ボリューム (PV) を作成する前に、オブジェクト定義でこれを定義する必要があります。

手順

  1. オブジェクト定義をファイルに保存します。

    cinder-persistentvolume.yaml

    apiVersion: "v1"
    kind: "PersistentVolume"
    metadata:
      name: "pv0001" 1
    spec:
      capacity:
        storage: "5Gi" 2
      accessModes:
        - "ReadWriteOnce"
      cinder: 3
        fsType: "ext3" 4
        volumeID: "f37a03aa-6212-4c62-a805-9ce139fab180" 5

    1
    永続ボリューム要求または Pod によって使用されるボリュームの名前。
    2
    このボリュームに割り当てられるストレージの量。
    3
    Red Hat OpenStack Platform (RHOSP) Cinder ボリュームの cinder を示します。
    4
    ボリュームの初回マウント時に作成されるファイルシステム。
    5
    使用する Cinder ボリューム
    重要

    ボリュームをフォーマットしてプロビジョニングした後には、fstype パラメーターの値は変更しないでください。この値を変更すると、データの損失や、Pod の障害につながる可能性があります。

  2. 前のステップで保存したオブジェクト定義ファイルを作成します。

    $ oc create -f cinder-persistentvolume.yaml
4.4.1.2. 永続ボリュームのフォーマット

OpenShift Container Platform は初回の使用前にフォーマットするため、フォーマットされていない Cinder ボリュームを PV として使用できます。

OpenShift Container Platform がボリュームをマウントし、これをコンテナーに渡す前に、システムは PV 定義の fsType パラメーターで指定されたファイルシステムがボリュームに含まれるかどうかをチェックします。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

4.4.1.3. Cinder ボリュームのセキュリティー

お使いのアプリケーションで Cinder PV を使用する場合に、そのデプロイメント設定にセキュリティーを追加します。

前提条件

  • 適切な fsGroup ストラテジーを使用する SCC が作成される必要があります。

手順

  1. サービスアカウントを作成して、そのアカウントを SCC に追加します。

    $ oc create serviceaccount <service_account>
    $ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
  2. アプリケーションのデプロイ設定で、サービスアカウント名と securityContext を指定します。

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend-1
    spec:
      replicas: 1  1
      selector:    2
        name: frontend
      template:    3
        metadata:
          labels:  4
            name: frontend 5
        spec:
          containers:
          - image: openshift/hello-openshift
            name: helloworld
            ports:
            - containerPort: 8080
              protocol: TCP
          restartPolicy: Always
          serviceAccountName: <service_account> 6
          securityContext:
            fsGroup: 7777 7
    1
    実行する Pod のコピー数です。
    2
    実行する Pod のラベルセレクターです。
    3
    コントローラーが作成する Pod のテンプレート。
    4
    Pod のラベル。ラベルセレクターからのラベルを組み込む必要があります。
    5
    パラメーター拡張後の名前の最大長さは 63 文字です。
    6
    作成したサービスアカウントを指定します。
    7
    Pod の fsGroup を指定します。

4.5. ファイバーチャネルを使用した永続ストレージ

OpenShift Container Platform ではファイバーチャネルがサポートされており、ファイバーチャネルボリュームを使用して OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と Fibre Channel についてある程度の理解があることが前提となります。

重要

ファイバーチャネルを使用する永続ストレージは、ARM アーキテクチャーベースのインフラストラクチャーではサポートされません。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

4.5.1. プロビジョニング

PersistentVolume API を使用してファイバーチャネルボリュームをプロビジョニングするには、以下が利用可能でなければなりません。

  • targetWWN (ファイバーチャネルターゲットのワールドワイド名の配列)。
  • 有効な LUN 番号。
  • ファイルシステムの種類。

永続ボリュームと LUN は 1 対 1 でマッピングされます。

前提条件

  • ファイバーチャネル LUN は基礎となるインフラストラクチャーに存在している必要があります。

PersistentVolume オブジェクト定義

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  fc:
    wwids: [scsi-3600508b400105e210000900000490000] 1
    targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5'] 2
    lun: 2 3
    fsType: ext4

1
World wide identifier (WWID)FC wwids または FC targetWWNs および lun の組み合わせは設定する必要がありますが、両方を同時に設定することはできません。WWN ターゲットよりも FC WWID 識別子が推奨されます。FC WWID 識別子は、各ストレージデバイスに固有のものであり、デバイスのアクセスに使用されるパスに依存しないためです。この識別子は、SCSI Inquiry を発行して Device Identification Vital Product Data (page 0x83) または Unit Serial Number (page 0x80) を取得することにより獲得できます。FC WWID は、デバイスへのパスが変更したり、別のシステムからデバイスにアクセスする場合でも、ディスク上のデータ参照に /dev/disk/by-id/ と識別されます。
2 3
ファイバーチャネル WWN は、/dev/disk/by-path/pci-<IDENTIFIER>-fc-0x<WWN>-lun-<LUN#> として識別されます。ただし、WWN までのパス (0x を含む) と WWN の後の文字 (- (ハイフン) を含む) を入力する必要はありません。
重要

ボリュームをフォーマットしてプロビジョニングした後に fstype パラメーターの値を変更すると、データ損失や Pod にエラーが発生する可能性があります。

4.5.1.1. ディスククォータの実施

LUN パーティションを使用してディスククォータとサイズ制限を実施します。各 LUN は単一の永続ボリュームにマップされ、固有の名前を永続ボリュームにに使用する必要があります。

この方法でクォータを実施すると、エンドユーザーは永続ストレージを具体的な量 (10Gi など) で要求することができ、これを同等またはそれ以上の容量の対応するボリュームに一致させることができます。

4.5.1.2. ファイバーチャネルボリュームのセキュリティー

ユーザーは永続ボリューム要求でストレージを要求します。この要求はユーザーの namespace にのみ存在し、同じ namespace 内の Pod からのみ参照できます。namespace をまたいで永続ボリュームにアクセスしようとすると、Pod にエラーが発生します。

それぞれのファイバーチャネル LUN は、クラスター内のすべてのノードからアクセスできる必要があります。

4.6. FlexVolume を使用した永続ストレージ

重要

FlexVolume は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform でボリュームドライバーを作成するには、out-of-tree Container Storage Interface (CSI) ドライバーが推奨されます。FlexVolume ドライバーのメンテナーは、CSI ドライバーを実装し、FlexVolume のユーザーを CSI に移行する必要があります。FlexVolume のユーザーは、ワークロードを CSI ドライバーに移行する必要があります。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

OpenShift Container Platform は、ドライバーとのインターフェイスに実行可能なモデルを使用する out-of-tree 形式のプラグイン、FlexVolume をサポートします。

組み込みプラグインがないバックエンドのストレージを使用する場合は、FlexVolume ドライバーを使用して OpenShift Container Platform を拡張し、アプリケーションに永続ストレージを提供できます。

Pod は、flexvolume の in-tree 形式のプラグインを使用して FlexVolume ドライバーと対話します。

4.6.1. FlexVolume ドライバーについて

FlexVolume ドライバーは、クラスター内のすべてのノードの明確に定義されたディレクトリーに格納されている実行可能ファイルです。OpenShift Container Platform は、flexVolume をソースとする PersistentVolume オブジェクトによって表されるボリュームのマウントまたはアンマウントが必要になるたびに、FlexVolume ドライバーを呼び出します。

重要

OpenShift Container Platform では、FlexVolume について割り当ておよび割り当て解除の操作はサポートされません。

4.6.2. FlexVolume ドライバーの例

FlexVolume ドライバーの最初のコマンドライン引数は常に操作名です。その他のパラメーターは操作ごとに異なります。ほとんどの操作は、JSON (JavaScript Object Notation) 文字列をパラメーターとして取ります。このパラメーターは完全な JSON 文字列であり、JSON データを含むファイルの名前ではありません。

FlexVolume ドライバーには以下が含まれます。

  • すべての flexVolume.options
  • kubernetes.io/ という接頭辞が付いた flexVolume のいくつかのオプション。たとえば、fsTypereadwrite などです。
  • kubernetes.io/secret/ という接頭辞が付いた参照先シークレット (指定されている場合) の内容。

FlexVolume ドライバーの JSON 入力例

{
	"fooServer": "192.168.0.1:1234", 1
        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 2
	"kubernetes.io/readwrite": "ro", 3
	"kubernetes.io/secret/<key name>": "<key value>", 4
	"kubernetes.io/secret/<another key name>": "<another key value>",
}

1
flexVolume.options のすべてのオプション。
2
flexVolume.fsType の値。
3
flexVolume.readOnly に基づく ro/rw
4
flexVolume.secretRef によって参照されるシークレットのすべてのキーと値。

OpenShift Container Platform は、ドライバーの標準出力に JSON データが含まれていると想定します。指定されていない場合、出力には操作の結果が示されます。

FlexVolume ドライバーのデフォルトの出力例

{
	"status": "<Success/Failure/Not supported>",
	"message": "<Reason for success/failure>"
}

ドライバーの終了コードは、成功の場合は 0、エラーの場合は 1 です。

操作はべき等です。 すでに割り当てられているボリュームのマウント操作は成功します。

4.6.3. FlexVolume ドライバーのインストール

OpenShift Container Platform を拡張するために使用される FlexVolume ドライバーはノードでのみ実行されます。FlexVolume を実装するには、呼び出す操作のリストとインストールパスのみが必要になります。

前提条件

  • FlexVolume ドライバーは、以下の操作を実装する必要があります。

    init

    ドライバーを初期化します。すべてのノードの初期化中に呼び出されます。

    • 引数: なし
    • 実行場所: ノード
    • 予期される出力: デフォルトの JSON
    mount

    ボリュームをディレクトリーにマウントします。これには、デバイスの検出、その後のデバイスのマウントを含む、ボリュームのマウントに必要なあらゆる操作が含まれます。

    • 引数: <mount-dir> <json>
    • 実行場所: ノード
    • 予期される出力: デフォルトの JSON
    unmount

    ボリュームをディレクトリーからアンマウントします。これには、アンマウント後にボリュームをクリーンアップするために必要なあらゆる操作が含まれます。

    • 引数: <mount-dir>
    • 実行場所: ノード
    • 予期される出力: デフォルトの JSON
    mountdevice
    ボリュームのデバイスを、個々の Pod がマウントをバインドするディレクトリーにマウントします。

この呼び出しでは FlexVolume 仕様に指定されるシークレットを渡しません。ドライバーでシークレットが必要な場合には、この呼び出しを実装しないでください。

  • 引数: <mount-dir> <json>
  • 実行場所: ノード
  • 予期される出力: デフォルトの JSON

    unmountdevice
    ボリュームのデバイスをディレクトリーからアンマウントします。
  • 引数: <mount-dir>
  • 実行場所: ノード
  • 予期される出力: デフォルトの JSON

    • その他のすべての操作は、{"status": "Not supported"} と終了コード 1 を出して JSON を返します。

手順

FlexVolume ドライバーをインストールします。

  1. この実行可能ファイルがクラスター内のすべてのノードに存在することを確認します。
  2. この実行可能ファイルをボリュームプラグインのパス (/etc/kubernetes/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver>) に配置します。

たとえば、ストレージ foo の FlexVolume ドライバーをインストールするには、実行可能ファイルを /etc/kubernetes/kubelet-plugins/volume/exec/openshift.com~foo/foo に配置します。

4.6.4. FlexVolume ドライバーを使用したストレージの使用

OpenShift Container Platform の各 PersistentVolume オブジェクトは、ストレージバックエンドの 1 つのストレージアセット (ボリュームなど) を表します。

手順

  • インストールされているストレージを参照するには、PersistentVolume オブジェクトを使用します。

FlexVolume ドライバーを使用した永続ボリュームのオブジェクト定義例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 1Gi 2
  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: openshift.com/foo 3
    fsType: "ext4" 4
    secretRef: foo-secret 5
    readOnly: true 6
    options: 7
      fooServer: 192.168.0.1:1234
      fooVolumeName: bar

1
ボリュームの名前。これは永続ボリューム要求を使用するか、Pod からボリュームを識別するために使用されます。この名前は、バックエンドストレージのボリューム名とは異なるものにすることができます。
2
このボリュームに割り当てられるストレージの量。
3
ドライバーの名前。このフィールドは必須です。
4
ボリュームに存在するオプションのファイルシステム。このフィールドはオプションです。
5
シークレットへの参照。このシークレットのキーと値は、起動時に FlexVolume ドライバーに渡されます。このフィールドはオプションです。
6
読み取り専用のフラグ。このフィールドはオプションです。
7
FlexVolume ドライバーの追加オプション。options フィールドでユーザーが指定するフラグに加え、以下のフラグも実行可能ファイルに渡されます。
"fsType":"<FS type>",
"readwrite":"<rw>",
"secret/key1":"<secret1>"
...
"secret/keyN":"<secretN>"
注記

シークレットは、呼び出しのマウント/マウント解除を目的とする場合にのみ渡されます。

4.7. GCE Persistent Disk を使用した永続ストレージ

OpenShift Container Platform では、GCE Persistent Disk ボリューム (gcePD) がサポートされます。GCE を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と GCE についてある程度の理解があることが前提となります。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

GCE Persistent Disk ボリュームは動的にプロビジョニングできます。

永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。

重要

OpenShift Container Platform 4.12 以降では、GCE Persist Disk in-tree ボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。

移行の詳細は、CSI の自動移行 を参照してください。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

関連情報

4.7.1. GCE ストレージクラスの作成

ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。

4.7.2. 永続ボリューム要求の作成

前提条件

ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順

  1. OpenShift Container Platform コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
  3. 表示されるページで必要なオプションを定義します。

    1. ドロップダウンメニューから以前に作成したストレージクラスを選択します。
    2. ストレージ要求の一意の名前を入力します。
    3. アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
    4. ストレージ要求のサイズを定義します。
  4. Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。

4.7.3. ボリュームのフォーマット

OpenShift Container Platform は、ボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType パラメーターで指定されたファイルシステムがボリュームにあるかどうか確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

この確認により、OpenShift Container Platform がフォーマットされていない GCE ボリュームを初回の使用前にフォーマットするため、フォーマットされていない GCE ボリュームを永続ボリュームとして使用することが可能になります。

4.8. iSCSI を使用した永続ストレージ

iSCSI を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と iSCSI についてある程度の理解があることが前提となります。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

重要

インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。

重要

Amazon Web Services で iSCSI を使用する場合、iSCSI ポートのノード間の TCP トラフィックを組み込むようにデフォルトのセキュリティーポリシーを更新する必要があります。デフォルトで、それらのポートは 860 および 3260 です。

重要

iscsi-initiator-utils パッケージをインストールし、/etc/iscsi/initiatorname.iscsi でイニシエーター名を設定して、iSCSI イニシエーターがすべての OpenShift Container Platform ノードですでに設定されていることを確認しておく。iscsi-initiator-utils パッケージは、Red Hat Enterprise Linux CoreOS (RHCOS) を使用するデプロイメントにすでにインストールされている。

詳細は、ストレージデバイスの管理 を参照してください。

4.8.1. プロビジョニング

OpenShift Container Platform でストレージをボリュームとしてマウントする前に、基礎となるインフラストラクチャーにストレージが存在することを確認します。iSCSI に必要になるのは、iSCSI ターゲットポータル、有効な iSCSI 修飾名 (IQN)、有効な LUN 番号、ファイルシステムタイプ、および PersistentVolume API のみです。

PersistentVolume オブジェクト定義

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
     targetPortal: 10.16.154.81:3260
     iqn: iqn.2014-12.example.server:storage.target00
     lun: 0
     fsType: 'ext4'

4.8.2. ディスククォータの実施

LUN パーティションを使用してディスククォータとサイズ制限を実施します。それぞれの LUN には 1 つの永続ボリュームです。Kubernetes では、永続ボリュームに一意の名前を使用する必要があります。

この方法でクォータを実施すると、エンドユーザーは永続ストレージを具体的な量 (10Gi など) で要求することができ、同等かそれ以上の容量の対応するボリュームに一致させることができます。

4.8.3. iSCSI ボリュームのセキュリティー

ユーザーは PersistentVolumeClaim オブジェクトでストレージを要求します。この要求はユーザーの namespace にのみ存在し、同じ namespace 内の Pod からのみ参照できます。namespace をまたいで永続ボリューム要求にアクセスしようとすると、Pod にエラーが発生します。

それぞれの iSCSI LUN は、クラスター内のすべてのノードからアクセスできる必要があります。

4.8.3.1. チャレンジハンドシェイク認証プロトコル (CHAP) 設定

オプションで、OpenShift Container Platform は CHAP を使用して iSCSI ターゲットに対して自己認証を実行できます。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    chapAuthDiscovery: true 1
    chapAuthSession: true 2
    secretRef:
      name: chap-secret 3
1
iSCSI 検出の CHAP 認証を有効にします。
2
iSCSI セッションの CHAP 認証を有効にします。
3
ユーザー名 + パスワードを使用してシークレットオブジェクトの名前を指定します。この Secret オブジェクトは、参照されるボリュームを使用できるすべての namespace で利用可能でなければなりません。

4.8.4. iSCSI のマルチパス化

iSCSI ベースのストレージの場合は、複数のターゲットポータルの IP アドレスに同じ IQN を使用することでマルチパスを設定できます。マルチパス化により、パス内の 1 つ以上のコンポーネントで障害が発生した場合でも、永続ボリュームにアクセスすることができます。

Pod 仕様でマルチパスを指定するには、portals フィールドを使用します。以下に例を示します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260'] 1
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    readOnly: false
1
portals フィールドを使用してターゲットポータルを追加します。

4.8.5. iSCSI のカスタムイニシエーター IQN

iSCSI ターゲットが特定に IQN に制限されている場合に、カスタムイニシエーターの iSCSI Qualified Name (IQN) を設定します。 ただし、iSCSI PV が割り当てられているノードが必ずこれらの IQN を使用する保証はありません。

カスタムのイニシエーター IQN を指定するには、initiatorName フィールドを使用します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260']
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    initiatorName: iqn.2016-04.test.com:custom.iqn 1
    fsType: ext4
    readOnly: false
1
イニシエーターの名前を指定します。

4.9. NFS を使用した永続ストレージ

OpenShift Container Platform クラスターは、NFS を使用する永続ストレージでプロビジョニングすることが可能です。永続ボリューム (PV) および永続ボリューム要求 (PVC) は、プロジェクト全体でボリュームを共有するための便利な方法を提供します。PV 定義に含まれる NFS に固有の情報は、Pod 定義で直接定義することも可能ですが、この方法の場合にはボリュームが一意のクラスターリソースとして作成されされないため、ボリュームが競合の影響を受けやすくなります。

4.9.1. プロビジョニング

ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。NFS ボリュームをプロビジョニングするには、NFS サーバーのリストとエクスポートパスのみが必要です。

手順

  1. PV のオブジェクト定義を作成します。

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv0001 1
    spec:
      capacity:
        storage: 5Gi 2
      accessModes:
      - ReadWriteOnce 3
      nfs: 4
        path: /tmp 5
        server: 172.17.0.2 6
      persistentVolumeReclaimPolicy: Retain 7
    1
    ボリュームの名前。これは、各種の oc <command> pod コマンドの PV アイデンティティーです。
    2
    このボリュームに割り当てられるストレージの量。
    3
    これはボリュームへのアクセスの制御に関連するように見えますが、実際はラベルの場合と同様に、PVC を PV に一致させるために使用されます。現時点では、accessModes に基づくアクセスルールは適用されていません。
    4
    使用されているボリュームタイプ。この場合は nfs プラグインです。
    5
    NFS サーバーがエクスポートしているパス。
    6
    NFS サーバーのホスト名または IP アドレス
    7
    PV の回収ポリシー。これはボリュームのリリース時に生じることを定義します。
    注記

    各 NFS ボリュームは、クラスター内のスケジュール可能なすべてのノードによってマウント可能でなければなりません。

  2. PV が作成されたことを確認します。

    $ oc get pv

    出力例

    NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
    pv0001   <none>    5Gi          RWO           Available                    31s

  3. 新規 PV にバインドされる永続ボリューム要求を作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: nfs-claim1
    spec:
      accessModes:
        - ReadWriteOnce 1
      resources:
        requests:
          storage: 5Gi 2
      volumeName: pv0001
      storageClassName: ""
    1
    アクセスモードはセキュリティーを実施するのではなく、PV を PVC と一致させるラベルとして機能します。
    2
    この要求は 5Gi 以上の容量を提供する PV を検索します。
  4. 永続ボリューム要求が作成されたことを確認します。

    $ oc get pvc

    出力例

    NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    nfs-claim1   Bound    pv0001   5Gi        RWO                           2m

4.9.2. ディスククォータの実施

ディスクパーティションを使用して、ディスククォータとサイズ制限を実施することができます。それぞれのパーティションを独自のエクスポートとすることができます。それぞれのエクスポートは 1 つの PV になります。OpenShift Container Platform は PV に固有の名前を適用しますが、NFS ボリュームのサーバーとパスの一意性については管理者に委ねられています。

この方法でクォータを実施すると、開発者は永続ストレージを具体的な量 (10Gi など) で要求することができ、同等かそれ以上の容量の対応するボリュームに一致させることができます。

4.9.3. NFS ボリュームのセキュリティー

このセクションでは、一致するパーミッションや SELinux の考慮点を含む、NFS ボリュームのセキュリティーを説明します。ユーザーは、POSIX パーミッションやプロセス UID、補助グループおよび SELinux の基礎的な点を理解している必要があります。

開発者は、Pod 定義の volumes セクションで、PVC を名前で参照するか、NFS ボリュームのプラグインを直接参照して NFS ストレージを要求します。

NFS サーバーの /etc/exports ファイルにはアクセス可能な NFS ディレクトリーが含まれています。ターゲットの NFS ディレクトリーには、POSIX の所有者とグループ ID があります。OpenShift Container Platform NFS プラグインは、同じ POSIX の所有者とエクスポートされる NFS ディレクトリーにあるパーミッションを使用して、コンテナーの NFS ディレクトリーをマウントします。ただし、コンテナーは NFS マウントの所有者と同等の有効な UID では実行されません。 これは期待される動作です。

ターゲットの NFS ディレクトリーが NFS サーバーに表示される場合を例に取って見てみましょう。

$ ls -lZ /opt/nfs -d

出力例

drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

$ id nfsnobody

出力例

uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

次に、コンテナーは SELinux ラベルに一致し、ディレクトリーにアクセスするために UID の 65534nfsnobody 所有者、または補助グループの 5555 のいずれかで実行される必要があります。

注記

所有者 ID 65534 は一例として使用されています。NFS の root_squashroot、uid 0nfsnobody、uid 65534 にマップしても、NFS エクスポートは任意の所有者 ID を持つことができます。所有者 65534 は NFS エクスポートには必要ありません。

4.9.3.1. グループ ID

NFS アクセスに対応する際の推奨される方法として、補助グループを使用することができます (NFS エクスポートのパーミッションを変更するオプションがないことを前提としています)。OpenShift Container Platform の補助グループは共有ストレージに使用されます (例: NFS)。これとは対照的に、iSCSI などのブロックストレージは、Pod の securityContextfsGroup SCC ストラテジーと fsGroup の値を使用します。

注記

永続ストレージへのアクセスを取得するには、通常はユーザー ID ではなく、補助グループ ID を使用することが推奨されます。

ターゲット NFS ディレクトリーの例で使用したグループ ID は 5555 なので、Pod は、supplementalGroups を使用してグループ ID を Pod の securityContext 定義の下で定義することができます。以下に例を示します。

spec:
  containers:
    - name:
    ...
  securityContext: 1
    supplementalGroups: [5555] 2
1
securityContext は特定のコンテナーの下位ではなく、この Pod レベルで定義します。
2
Pod 向けに定義される GID の配列。この場合、配列には 1 つの要素があります。追加の GID はコンマで区切られます。

Pod の要件を満たすカスタム SCC が存在しない場合、Pod は restricted SCC に一致する可能性があります。この SCC では、supplementalGroups ストラテジーが RunAsAny に設定されています。 これは、指定されるグループ ID は範囲のチェックなしに受け入れられることを意味します。

その結果、上記の Pod は受付をパスして起動します。しかし、グループ ID の範囲をチェックすることが望ましい場合は、カスタム SCC の使用が推奨されます。カスタム SCC は、最小および最大のグループ ID が定義され、グループ ID の範囲チェックが実施され、グループ ID の 5555 が許可されるように作成できます。

注記

カスタム SCC を使用するには、まずこれを適切なサービスアカウントに追加する必要があります。たとえば、Pod 仕様に指定がない場合には、指定されたプロジェクトで default サービスアカウントを使用します。

4.9.3.2. ユーザー ID

ユーザー ID は、コンテナーイメージまたは Pod 定義で定義することができます。

注記

永続ストレージへのアクセスを取得する場合、通常はユーザー ID ではなく、補助グループ ID を使用することが推奨されます。

上記のターゲット NFS ディレクトリーの例では、コンテナーは UID を 65534 (ここではグループ ID を省略します) に設定する必要があります。 したがって以下を Pod 定義に追加することができます。

spec:
  containers: 1
  - name:
  ...
    securityContext:
      runAsUser: 65534 2
1
Pod には、各コンテナーに固有の securityContext 定義と、その Pod で定義されたすべてのコンテナーに適用される Pod の securityContext が含まれます。
2
65534nfsnobody ユーザーです。

プロジェクトが default で、SCC が restricted の場合、Pod で要求されるユーザー ID の 65534 は許可されません。したがって、Pod は以下の理由で失敗します。

  • 65534 をそのユーザー ID として要求する。
  • ユーザー ID 65534 を許可する SCC を確認するために Pod で利用できるすべての SCC が検査される。SCC のすべてのポリシーがチェックされますが、ここでのフォーカスはユーザー ID になります。
  • 使用可能なすべての SCC が独自の runAsUser ストラテジーとして MustRunAsRange を使用しているため、UID の範囲チェックが要求される。
  • 65534 は SCC またはプロジェクトのユーザー ID 範囲に含まれていない。

一般に、事前定義された SCC は変更しないことが勧められています。ただし、この状況を改善するには、カスタム SCC を作成することが推奨されます。 カスタム SCC は、最小および最大のユーザー ID が定義され、UID 範囲のチェックの実施が設定されており、UID 65534 が許可されるように作成できます。

注記

カスタム SCC を使用するには、まずこれを適切なサービスアカウントに追加する必要があります。たとえば、Pod 仕様に指定がない場合には、指定されたプロジェクトで default サービスアカウントを使用します。

4.9.3.3. SELinux

Red Hat Enterprise Linux (RHEL) および Red Hat Enterprise Linux CoreOS (RHCOS) システムは、デフォルトでリモートの NFS サーバーで SELinux を使用するように設定されます。

RHEL および RHCOS 以外のシステムの場合、SELinux は Pod からリモートの NFS サーバーへの書き込みを許可しません。NFS ボリュームは正常にマウントされますが、読み取り専用です。以下の手順で、正しい SELinux パーミッションを有効にする必要があります。

前提条件

  • container-selinux パッケージがインストールされている必要があります。このパッケージは virt_use_nfs SELinux ブール値を提供します。

手順

  • 以下のコマンドを使用して virt_use_nfs ブール値を有効にします。-P オプションを使用すると、再起動後もこのブール値を永続化できます。

    # setsebool -P virt_use_nfs 1
4.9.3.4. エクスポート設定

任意のコンテナーユーザーにボリュームの読み取りと書き出しを許可するには、NFS サーバーにエクスポートされる各ボリュームは以下の条件を満たしている必要があります。

  • すべてのエクスポートは、次の形式を使用してエクスポートする必要があります。

    /<example_fs> *(rw,root_squash)
  • ファイアウォールは、マウントポイントへのトラフィックを許可するように設定する必要があります。

    • NFSv4 の場合、デフォルトのポート 2049 (nfs) を設定します。

      NFSv4

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT

    • NFSv3 の場合、以下の 3 つのポートを設定します。2049 (nfs)、20048 (mountd)、111 (portmapper)。

      NFSv3

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT

      # iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT
      # iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT
  • NFS エクスポートとディレクトリーは、ターゲット Pod からアクセスできるようにセットアップされる必要があります。この場合、エクスポートをコンテナーのプライマリー UID で所有されるように設定するか、上記のグループ ID に示されるように supplementalGroups を使用して Pod にグループアクセスを付与します。

4.9.4. リソースの回収

NFS は OpenShift Container Platform の Recyclable プラグインインターフェイスを実装します。回収タスクは、それぞれの永続ボリュームに設定されるポリシーに基づいて自動プロセスによって処理されます。

デフォルトで、PV は Retain に設定されます。

PV への要求が削除され、PV がリリースされると、PV オブジェクトを再利用できません。代わりに、新規の PV が元のボリュームと同じ基本ボリュームの情報を使用して作成されます。

たとえば、管理者は nfs1 という名前の PV を作成するとします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

ユーザーは、nfs1 にバインドされる PVC1 を作成します。次にユーザーは PVC1 を削除し、nfs1 への要求を解除します。これにより、nfs1Released になります。管理者が同じ NFS 共有を利用可能にする必要がある場合には、同じ NFS サーバー情報を使用して新規 PV を作成する必要があります。 この場合、PV の名前は元の名前とは異なる名前にします。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

元の PV を削除して、PV を同じ名前で再作成することは推奨されません。PV のステータスを Released から Available に手動で変更しようとすると、エラーが発生し、データが失われる可能性があります。

4.9.5. その他の設定とトラブルシューティング

適切なエクスポートとセキュリティーマッピングを行うため、使用している NFS のバージョンおよびその設定方法に応じて追加の設定が必要になることがあります。以下は例になります。

NFSv4 のマウントにすべてのファイルの所有者が nobody:nobody と誤って表示される。

NFSv4 の ID マッピングが無効になっている

  • NFS クライアントとサーバーの両方で以下を実行してください。

    # echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping

4.10. Red Hat OpenShift Data Foundation

Red Hat OpenShift Data Foundation は、インハウスまたはハイブリッドクラウドのいずれの場合でもファイル、ブロックおよびオブジェクトストレージをサポートし、OpenShift Container Platform のすべてに対応する永続ストレージのプロバイダーです。Red Hat のストレージソリューションとして、Red Hat OpenShift Data Foundation は、デプロイメント、管理およびモニタリングを行うために OpenShift Container Platform に完全に統合されています。詳細は、Red Hat OpenShift Data Foundation のドキュメント を参照してください。

重要

OpenShift Container Platform でインストールされた仮想マシンをホストするハイパーコンバージドノードを使用する Red Hat Hyperconverged Infrastructure (RHHI) for Virtualization の上部にある OpenShift Data Foundation は、サポート対象の設定ではありません。サポートされるプラットフォームの詳細は、Red Hat OpenShift Data Foundation Supportability and Interoperability Guide を参照してください。

4.11. VMware vSphere ボリュームを使用した永続ストレージ

OpenShift Container Platform では、VMware vSphere の仮想マシンディスク (VMDK: Virtual Machine Disk) ボリュームの使用が可能となります。VMware vSphere を使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これには、Kubernetes と VMware vSphere についてある程度の理解があることが前提となります。

VMware vSphere ボリュームは動的にプロビジョニングできます。OpenShift Container Platform は vSphere にディスクを作成し、このディスクを正しいイメージに割り当てます。

注記

OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームをバックアップしたり、スナップショットからボリュームを復元したりできません。詳細は、スナップショットの制限 を参照してください。

Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。

永続ボリュームは、単一のプロジェクトまたは namespace にバインドされず、OpenShift Container Platform クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。

重要

新規インストールの場合、OpenShift Container Platform 4.13 以降では、vSphere インツリーボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。OpenShift Container Platform 4.15 以降に更新した場合も、自動移行が可能になります。更新と移行の詳細は、CSI の自動移行 を参照してください。

CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。

関連情報

4.11.1. VMware vSphere ボリュームの動的プロビジョニング

VMware vSphere ボリュームの動的プロビジョニングは推奨される方法です。

4.11.2. 前提条件

  • 使用するコンポーネントの要件を満たす VMware vSphere バージョンにインストールされている OpenShift Container Platform クラスター。vSphere バージョンのサポートに関する詳細は、vSphere にクラスターをインストールする を参照してください。

以下のいずれかの手順を使用し、デフォルトのストレージクラスを使用してそれらのボリュームを動的にプロビジョニングできます。

4.11.2.1. UI を使用した VMware vSphere ボリュームの動的プロビジョニング

OpenShift Container Platform は、ボリュームをプロビジョニングするために thin ディスク形式を使用する thin という名前のデフォルトのストレージクラスをインストールします。

前提条件

  • ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順

  1. OpenShift Container Platform コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
  3. 結果のページで必要なオプションを定義します。

    1. thin ストレージクラスを選択します。
    2. ストレージ要求の一意の名前を入力します。
    3. アクセスモードを選択し、作成されるストレージ要求の読み取り/書き込みアクセスを決定します。
    4. ストレージ要求のサイズを定義します。
  4. Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
4.11.2.2. CLI を使用した VMware vSphere ボリュームの動的プロビジョニング

OpenShift Container Platform は、ボリュームをプロビジョニングするために thin ディスク形式を使用する thin という名前のデフォルトの StorageClass をインストールします。

前提条件

  • ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順 (CLI)

  1. 以下の内容でファイル pvc.yaml を作成して VMware vSphere PersistentVolumeClaim を定義できます。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc 1
    spec:
      accessModes:
      - ReadWriteOnce 2
      resources:
        requests:
          storage: 1Gi 3
    1
    永続ボリューム要求を表す一意の名前。
    2
    永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
    3
    永続ボリューム要求のサイズ。
  2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

    $ oc create -f pvc.yaml

4.11.3. VMware vSphere ボリュームの静的プロビジョニング

VMware vSphere ボリュームを静的にプロビジョニングするには、永続ボリュームフレームワークが参照する仮想マシンディスクを作成する必要があります。

前提条件

  • ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。

手順

  1. 仮想マシンディスクを作成します。VMware vSphere ボリュームを静的にプロビジョニングする前に、仮想マシンディスク (VMDK) を手動で作成する必要があります。以下の方法のいずれかを使用します。

    • vmkfstools を使用して作成します。セキュアシェル (SSH) を使用して ESX にアクセスし、以下のコマンドを使用して VMDK ボリュームを作成します。

      $ vmkfstools -c <size> /vmfs/volumes/<datastore-name>/volumes/<disk-name>.vmdk
    • vmware-diskmanager を使用して作成します。

      $ shell vmware-vdiskmanager -c -t 0 -s <size> -a lsilogic <disk-name>.vmdk
  2. VMDK を参照する永続ボリュームを作成します。PersistentVolume オブジェクト定義を使用して pv1.yaml ファイルを作成します。

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv1 1
    spec:
      capacity:
        storage: 1Gi 2
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      vsphereVolume: 3
        volumePath: "[datastore1] volumes/myDisk"  4
        fsType: ext4  5
    1
    ボリュームの名前。この名前は永続ボリューム要求または Pod で識別されるものです。
    2
    このボリュームに割り当てられるストレージの量。
    3
    vSphere ボリュームの vsphereVolume で使用されるボリュームタイプ。ラベルは vSphere VMDK ボリュームを Pod にマウントするために使用されます。ボリュームの内容はアンマウントされても保持されます。このボリュームタイプは、VMFS データストアと VSAN データストアの両方がサポートされます。
    4
    使用する既存の VMDK ボリューム。vmkfstools を使用した場合、前述のようにボリューム定義で、データストア名を角かっこ [] で囲む必要があります。
    5
    マウントするファイルシステムタイプです。ext4、xfs、または他のファイルシステムなどが例になります。
    重要

    ボリュームをフォーマットしてプロビジョニングした後に fsType パラメーターの値を変更すると、データ損失や Pod にエラーが発生する可能性があります。

  3. ファイルから PersistentVolume オブジェクトを作成します。

    $ oc create -f pv1.yaml
  4. 直前の手順で作成した永続ボリュームにマップする永続ボリューム要求を作成します。PersistentVolumeClaim オブジェクト定義を使用して、ファイル pvc1.yaml を作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc1 1
    spec:
      accessModes:
        - ReadWriteOnce 2
      resources:
       requests:
         storage: "1Gi" 3
      volumeName: pv1 4
    1
    永続ボリューム要求を表す一意の名前。
    2
    永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームはシングルノードによって読み取り/書き込みパーミッションでマウントできます。
    3
    永続ボリューム要求のサイズ。
    4
    既存の永続ボリュームの名前。
  5. ファイルから PersistentVolumeClaim オブジェクトを作成します。

    $ oc create -f pvc1.yaml
4.11.3.1. VMware vSphere ボリュームのフォーマット

OpenShift Container Platform は、ボリュームをマウントしてコンテナーに渡す前に、PersistentVolume (PV) 定義の fsType パラメーター値で指定されたファイルシステムがボリュームに含まれることを確認します。デバイスが指定されたファイルシステムでフォーマットされていない場合、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。

OpenShift Container Platform は初回の使用前にフォーマットするため、フォーマットされていない vSphere ボリュームを PV として使用できます。

4.12. ローカルストレージを使用した永続ストレージ

4.12.1. ローカルストレージの概要

ローカルストレージをプロビジョニングするには、次のいずれかのソリューションを使用できます。

  • HostPath Provisioner (HPP)
  • Local Storage Operator (LSO)
  • Logical Volume Manager (LVM) Storage
警告

これらのソリューションは、ノードローカルストレージのプロビジョニングのみをサポートします。ワークロードは、ストレージを提供するノードにバインドされます。ノードが使用できなくなると、ワークロードも使用できなくなります。ノード障害が発生したときにワークロードの可用性を維持するには、アクティブまたはパッシブのレプリケーションメカニズムにより、ストレージデータのレプリケーションを確実に実行する必要があります。

4.12.1.1. HostPath Provisioner 機能の概要

HostPath Provisioner (HPP) を使用すると、次の操作を実行できます。

  • ローカルストレージをプロビジョニングするために、ホストファイルシステムパスをストレージクラスにマップする。
  • ストレージを使用するために、ストレージクラスを静的に作成してノードにファイルシステムパスを設定する。
  • ストレージクラスに基づいて永続ボリューム (PV) を静的にプロビジョニングする。
  • 基盤となるストレージトポロジーを考慮しながら、ワークロードと PersistentVolumeClaim (PVC) を作成する。
注記

HPP はアップストリームの Kubernetes で利用できます。ただし、アップストリームの Kubernetes から HPP を使用することは推奨しません。

4.12.1.2. Local Storage Operator の機能の概要

Local Storage Operator (LSO) を使用すると、次の操作を実行できます。

  • デバイス設定を変更せずに、ストレージデバイス (ディスクまたはパーティション) をストレージクラスに割り当てる。
  • LocalVolume カスタムリソース (CR) を設定して、PV とストレージクラスを静的にプロビジョニングする。
  • 基盤となるストレージトポロジーを考慮しながら、ワークロードと PVC を作成する。
注記

LSO は Red Hat によって開発および提供されています。

4.12.1.3. LVM Storage の機能の概要

Logical Volume Manager (LVM) Storage を使用すると、次の操作を実行できます。

  • ストレージデバイス (ディスクまたはパーティション) を lvm2 ボリュームグループとして設定し、ボリュームグループをストレージクラスとして公開する。
  • ノードトポロジーを考慮せずに PVC を使用してワークロードを作成し、ストレージを要求する。

LVM Storage は TopoLVM CSI ドライバーを使用して、トポロジー内のノードにストレージスペースを動的に割り当て、PV をプロビジョニングします。

注記

LVM Storage は、Red Hat によって開発および保守されています。LVM Storage に付属する CSI ドライバーは、アップストリームプロジェクトの "topolvm" です。

4.12.1.4. LVM Storage、LSO、HPP の比較

次のセクションでは、LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) が提供する、ローカルストレージをプロビジョニングするための機能を比較します。

4.12.1.4.1. ストレージタイプおよびファイルシステムのサポートの比較

次の表は、ローカルストレージをプロビジョニングするために LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) によって提供されるストレージタイプおよびファイルシステムのサポートを比較したものです。

表4.1 ストレージタイプおよびファイルシステムのサポートの比較
機能LVM StorageLSOHPP

ブロックストレージのサポート

はい

はい

いいえ

ファイルストレージのサポート

はい

はい

はい

オブジェクトストレージのサポート [1]

いいえ

いいえ

いいえ

利用可能なファイルシステム

ext4xfs

ext4xfs

ノード上で使用できるマウントされたシステムがすべてサポートされます。

  1. いずれのソリューション (LVM Storage、LSO、HPP) もオブジェクトストレージをサポートしていません。したがって、オブジェクトストレージを使用する場合は、Red Hat OpenShift Data Foundation の MultiClusterGateway などの S3 オブジェクトストレージソリューションが必要です。どのソリューションも、S3 オブジェクトストレージソリューションの基盤となるストレージプロバイダーとして機能します。
4.12.1.4.2. コア機能のサポートの比較

次の表は、LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) によるローカルストレージのプロビジョニングに関するコア機能のサポート状況を比較したものです。

表4.2 コア機能のサポートの比較
機能LVM StorageLSOHPP

自動ファイルシステムフォーマット設定のサポート

はい

はい

該当なし

動的プロビジョニングのサポート

はい

いいえ

いいえ

ソフトウェア Redundant Array of Independent Disks (RAID) アレイの使用のサポート

はい

4.15 以降でサポートされています。

はい

はい

透過的なディスク暗号化のサポート

はい

4.16 以降でサポートされています。

はい

はい

ボリュームベースのディスク暗号化のサポート

いいえ

いいえ

いいえ

非接続インストールのサポート

はい

はい

はい

PVC 拡張のサポート

はい

いいえ

いいえ

ボリュームスナップショットとボリュームクローンのサポート

はい

いいえ

いいえ

シンプロビジョニングのサポート

はい

デバイスはデフォルトでシンプロビジョニングされます。

はい

シンプロビジョニングされたボリュームを参照するようにデバイスを設定できます。

はい

シンプロビジョニングされたボリュームを参照するパスを設定できます。

自動ディスク検出とセットアップのサポート

はい

インストール時および実行時に自動ディスク検出を利用できます。既存のストレージクラスのストレージ容量を増やすために、ディスクを LVMCluster カスタムリソース (CR) に動的に追加することもできます。

テクノロジープレビュー

インストール時に自動ディスク検出を利用できます。

いいえ

4.12.1.4.3. パフォーマンス機能と分離機能の比較

次の表は、ローカルストレージのプロビジョニングにおける LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) のパフォーマンス機能と分離機能を比較したものです。

表4.3 パフォーマンス機能と分離機能の比較
機能LVM StorageLSOHPP

パフォーマンス

I/O スピードが、同じストレージクラスを使用するすべてのワークロードで共有されます。

ブロックストレージでは直接 I/O 操作が可能です。

シンプロビジョニングがパフォーマンスに影響を与える可能性があります。

I/O は LSO 設定によって異なります。

ブロックストレージでは直接 I/O 操作が可能です。

I/O スピードが、同じストレージクラスを使用するすべてのワークロードで共有されます。

基盤となるファイルシステムによる制限が、I/O スピードに影響を与える可能性があります。

分離境界 [1]

LVM 論理ボリューム (LV)

HPP と比較して、より高いレベルの分離を提供します。

LVM 論理ボリューム (LV)

HPP と比較して、より高いレベルの隔離を提供します。

ファイルシステムパス

LSO および LVM Storage と比較して、より低いレベルの分離を提供します。

  1. 分離境界とは、ローカルストレージリソースを使用するさまざまなワークロードまたはアプリケーション間の分離レベルを指します。
4.12.1.4.4. 追加機能のサポートの比較

次の表は、LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) が提供する、ローカルストレージをプロビジョニングするための追加機能を比較したものです。

表4.4 追加機能のサポートの比較
機能LVM StorageLSOHPP

汎用一時ボリュームのサポート

はい

いいえ

いいえ

CSI インライン一時ボリュームのサポート

いいえ

いいえ

いいえ

ストレージトポロジーのサポート

はい

CSI ノードトポロジーのサポート

はい

LSO は、ノード容認を通じてストレージトポロジーの部分的なサポートを提供します。

いいえ

ReadWriteMany (RWX) アクセスモードのサポート [1]

いいえ

いいえ

いいえ

  1. どのソリューション (LVM Storage、LSO、HPP) にも、ReadWriteOnce (RWO) アクセスモードがあります。RWO アクセスモードでは、同じノード上の複数の Pod からのアクセスが可能になります。

4.12.2. ローカルボリュームを使用した永続ストレージ

OpenShift Container Platform は、ローカルボリュームを使用する永続ストレージでプロビジョニングすることが可能です。ローカルの永続ボリュームを使用すると、標準の永続ボリューム要求インターフェイスを使用して、ディスクやパーティションなどのローカルのストレージデバイスにアクセスできます。

ローカルボリュームは、Pod をノードに手動でスケジュールせずに使用できます。ボリュームのノード制約がシステムによって認識されるためです。ただし、ローカルボリュームは、依然として基礎となるノードの可用性に依存しており、すべてのアプリケーションに適している訳ではありません。

注記

ローカルボリュームは、静的に作成された永続ボリュームとしてのみ使用できます。

4.12.2.1. ローカルストレージ Operator のインストール

ローカルストレージ Operator はデフォルトで OpenShift Container Platform にインストールされません。以下の手順を使用してこの Operator をインストールし、クラスター内でローカルボリュームを有効にできるように設定します。

前提条件

  • OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) へのアクセス。

手順

  1. openshift-local-storage プロジェクトを作成します。

    $ oc adm new-project openshift-local-storage
  2. オプション: インフラストラクチャーノードでのローカルストレージの作成を許可します。

    ロギングやモニタリングなどのコンポーネントに対応するために、ローカルストレージ Operator を使用してインフラストラクチャーノードでボリュームを作成する必要がある場合があります。

    ローカルストレージ Operator にワーカーノードだけでなくインフラストラクチャーノードが含まれるように、デフォルトのノードセレクターを調整する必要があります。

    ローカルストレージ Operator がクラスター全体のデフォルトセレクターを継承しないようにするには、以下のコマンドを実行します。

    $ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
  3. オプション: 単一ノードデプロイメントの CPU の管理プールでローカルストレージを実行できるようにします。

    シングルノードデプロイメントで Local Storage Operator を使用し、literal プールに属する CPU の使用を許可します。この手順は、管理ワークロードパーティショニングを使用する単一ノードインストールで実行します。

    Local Storage Operator が管理 CPU プールで実行できるようにするには、次のコマンドを実行します。

    $ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'

UI での操作

Web コンソールからローカルストレージ Operator をインストールするには、以下の手順を実行します。

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsOperatorHub に移動します。
  3. Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
  4. Install をクリックします。
  5. Install Operator ページで、A specific namespace on the cluster を選択します。ドロップメニューから openshift-local-storage を選択します。
  6. Update Channel および Approval Strategy の値を必要な値に調整します。
  7. Install をクリックします。

これが完了すると、ローカルストレージ Operator は Web コンソールの Installed Operators セクションにリスト表示されます。

CLI からの操作

  1. CLI からローカルストレージ Operator をインストールします。

    1. ローカルストレージ Operator の Operator グループおよびサブスクリプションを定義するために、オブジェクト YAML ファイル (例: openshift-local-storage.yaml) を作成します。

      例: openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        channel: stable
        installPlanApproval: Automatic 1
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      1
      インストール計画のユーザー認可ポリシー。
  2. 以下のコマンドを実行して、ローカルストレージ Operator オブジェクトを作成します。

    $ oc apply -f openshift-local-storage.yaml

    この時点で、Operator Lifecycle Manager (OLM) はローカルストレージ Operator を認識できるようになります。Operator の ClusterServiceVersion (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

  3. すべての Pod およびローカルストレージ Operator が作成されていることを確認して、ローカルストレージのインストールを検証します。

    1. 必要な Pod すべてが作成されていることを確認します。

      $ oc -n openshift-local-storage get pods

      出力例

      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

    2. ClusterServiceVersion (CSV) YAML マニフェストをチェックして、ローカルストレージ Operator が openshift-local-storage プロジェクトで利用できることを確認します。

      $ oc get csvs -n openshift-local-storage

      出力例

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

すべてのチェックが渡されると、ローカルストレージ Operator が正常にインストールされます。

4.12.2.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング

ローカルボリュームは動的プロビジョニングで作成できません。代わりに、永続ボリュームがローカルストレージ Operator によって作成されることがあります。このローカルボリュームプロビジョナーは、定義されたリソースで指定されているパスでファイルシステムまたはブロックボリュームデバイスを検索します。

前提条件

  • ローカルストレージ Operator がインストールされていること。
  • 以下の条件を満たすローカルディスクがある。

    • ノードに接続されている。
    • マウントされていない。
    • パーティションが含まれていない。

手順

  1. ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。これを行うと、複数の永続ボリューム (PV) が作成されます。

    例: ファイルシステム

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 1
    spec:
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-140-183
              - ip-10-0-158-139
              - ip-10-0-164-33
      storageClassDevices:
        - storageClassName: "local-sc" 3
          forceWipeDevicesAndDestroyAllData: false 4
          volumeMode: Filesystem 5
          fsType: xfs 6
          devicePaths: 7
            - /path/to/device 8

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。
    4
    この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator (LSO) プロビジョニングに使用できるようにする、winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。ノードを複数回再デプロイできるシングルノード OpenShift (SNO) クラスター環境や、オブジェクトストレージデバイス (OSD) として使用する予定のディスクに以前のデータを残すことができる OpenShift Data Foundation (ODF) を使用する場合も、これに該当します。
    5
    ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。
    注記

    raw ブロックボリューム (volumeMode: Block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

    6
    ローカルボリュームの初回マウント時に作成されるファイルシステム。
    7
    選択するローカルストレージデバイスの一覧を含むパスです。
    8
    この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: /dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
    注記

    RHEL KVM を使用して OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

    例: ブロック

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 1
    spec:
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 3
          forceWipeDevicesAndDestroyAllData: false 4
          volumeMode: Block 5
          devicePaths: 6
            - /path/to/device 7

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。
    4
    この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator (LSO) プロビジョニングに使用できるようにする、winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。ノードを複数回再デプロイできるシングルノード OpenShift (SNO) クラスター環境や、オブジェクトストレージデバイス (OSD) として使用する予定のディスクに以前のデータを残すことができる OpenShift Data Foundation (ODF) を使用する場合も、これに該当します。
    5
    ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。
    6
    選択するローカルストレージデバイスの一覧を含むパスです。
    7
    この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
    注記

    RHEL KVM を使用して OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

  2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

    $ oc create -f <local-volume>.yaml
  3. プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。

    $ oc get all -n openshift-local-storage

    出力例

    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    デーモンセットプロセスの必要な数と現在の数に注意してください。必要な数が 0 の場合、これはラベルセレクターが無効であることを示します。

  4. 永続ボリュームが作成されていることを確認します。

    $ oc get pv

    出力例

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

重要

LocalVolume オブジェクトを編集しても、既存の永続ボリュームの fsType または volumeMode は変更されません。これが破壊的な操作になる可能性があるためです。

4.12.2.3. ローカルストレージ Operator のないローカルボリュームのプロビジョニング

ローカルボリュームは動的プロビジョニングで作成できません。代わりに、永続ボリュームは、永続ボリューム (PV) をオブジェクト定義に定義して作成できます。このローカルボリュームプロビジョナーは、定義されたリソースで指定されているパスでファイルシステムまたはブロックボリュームデバイスを検索します。

重要

PV の手動プロビジョニングには、PVC の削除時に PV 全体でデータ漏洩が発生するリスクが含まれます。ローカルストレージ Operator は、ローカル PV のプロビジョニング時にデバイスのライフサイクルを自動化するために使用することが推奨されます。

前提条件

  • ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。

手順

  1. PV を定義します。PersistentVolume オブジェクト定義を使用して、example-pv-filesystem.yaml または example-pv-block.yaml などのファイルを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。同じ名前を使用すると、複数の PV が作成されます。

    example-pv-filesystem.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-filesystem
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Filesystem 1
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 2
      local:
        path: /dev/xvdf 3
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node

    1
    PV のタイプを定義するボリュームモード (Filesystem または Block)。
    2
    PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用にしてください。
    3
    選択するローカルストレージデバイスのリスト、またはディレクトリーが含まれるパスです。Filesystem volumeMode のディレクトリーのみを指定できます。
    注記

    raw ブロックボリューム (volumeMode: block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

    example-pv-block.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-block
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Block 1
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 2
      local:
        path: /dev/xvdf 3
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node

    1
    PV のタイプを定義するボリュームモード (Filesystem または Block)。
    2
    PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用するようにしてください。
    3
    選択するローカルストレージデバイスの一覧を含むパスです。
  2. OpenShift Container Platform クラスターに PV リソースを作成します。作成したばかりのファイルを指定します。

    $ oc create -f <example-pv>.yaml
  3. ローカル PV が作成されていることを確認します。

    $ oc get pv

    出力例

    NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
    example-pv-filesystem   100Gi      RWO            Delete           Available                        local-sc            3m47s
    example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-sc            12h
    example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-sc            12h
    example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-sc            12h

4.12.2.4. ローカルボリュームの永続ボリューム要求の作成

ローカルボリュームは、Pod でアクセスされる永続ボリューム要求として静的に作成される必要があります。

前提条件

  • 永続ボリュームがローカルボリュームプロビジョナーを使用して作成されていること。

手順

  1. 対応するストレージクラスを使用して PVC を作成します。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: local-pvc-name 1
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Filesystem 2
      resources:
        requests:
          storage: 100Gi 3
      storageClassName: local-sc 4
    1
    PVC の名前。
    2
    PVC のタイプ。デフォルトは Filesystem です。
    3
    PVC に利用できるストレージの量。
    4
    要求で必要になるストレージクラスの名前。
  2. 作成したファイルを指定して、PVC を OpenShift Container Platform クラスターに作成します。

    $ oc create -f <local-pvc>.yaml
4.12.2.5. ローカル要求を割り当てます。

ローカルボリュームが永続ボリューム要求にマップされた後に、これをリソース内に指定できます。

前提条件

  • 永続ボリューム要求が同じ namespace に存在する。

手順

  1. 定義された要求をリソースの仕様に追加します。以下の例では、Pod 内で永続ボリューム要求を宣言します。

    apiVersion: v1
    kind: Pod
    spec:
    # ...
      containers:
        volumeMounts:
        - name: local-disks 1
          mountPath: /data 2
      volumes:
      - name: local-disks
        persistentVolumeClaim:
          claimName: local-pvc-name 3
    # ...
    1
    マウントするボリュームの名前。
    2
    ボリュームがマウントされる Pod 内のパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
    3
    使用する既存の永続ボリューム要求の名前。
  2. 作成したファイルを指定して、OpenShift Container Platform クラスターにリソースを作成します。

    $ oc create -f <local-pod>.yaml
4.12.2.6. 詳細は、ローカルストレージデバイスの自動検出およびプロビジョニングを参照してください。

ローカルストレージ Operator はローカルストレージ検出およびプロビジョニングを自動化します。この機能を使用すると、ベアメタル、VMware、または割り当てられたデバイスを持つ AWS ストアインスタンスなど、デプロイメント時に動的プロビジョニングが利用できない場合にインストールを単純化できます。

重要

自動検出およびプロビジョニングはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

重要

Red Hat OpenShift Data Foundation をオンプレミスでデプロイするために使用する場合、またはプラットフォームに依存しないデプロイメントで使用する場合、自動検出とプロビジョニングは完全にサポートされます。

ローカルデバイスを自動的に検出し、選択したデバイスのローカルボリュームを自動的にプロビジョニングするには、以下の手順を使用します。

警告

LocalVolumeSet オブジェクトの使用には注意が必要です。ローカルディスクから永続ボリューム (PV) を自動的にプロビジョニングする場合、ローカル PV は一致するすべてのデバイスを要求する可能性があります。LocalVolumeSet オブジェクトを使用している場合、ローカルストレージ Operator がノードでローカルデバイスを管理する唯一のエンティティーであることを確認します。ノードを複数回ターゲットにする Local VolumeSet のインスタンスを複数作成することはサポートされていません。

前提条件

  • クラスター管理者パーミッションがある。
  • ローカルストレージ Operator がインストールされていること。
  • ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。
  • OpenShift Container Platform Web コンソールまたは oc コマンドラインインターフェイス (CLI) へのアクセスがあること。

手順

  1. Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。

    1. OperatorsInstalled Operators をクリックします。
    2. openshift-local-storage namespace で Local Storage をクリックします。
    3. Local Volume Discovery タブをクリックします。
    4. Create Local Volume Discovery をクリックし、Form view または YAML view のいずれかを選択します。
    5. LocalVolumeDiscovery オブジェクトパラメーターを設定します。
    6. Create をクリックします。

      Local Storage Operator は、auto-discover-devices という名前のローカルボリューム検出インスタンスを作成します。

  2. ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。

    1. OpenShift Container Platform Web コンソールにログインします。
    2. ComputeNodes に移動します。
    3. 開くノードの名前をクリックします。「Node Details」ページが表示されます。
    4. Disks タブを選択して、選択したデバイスのリストを表示します。

      ローカルディスクを追加または削除しても、デバイスリストの更新が継続的に行われます。名前、ステータス、タイプ、モデル、容量、およびモードでデバイスをフィルターできます。

  3. Web コンソールから検出されたデバイスのローカルボリュームを自動的にプロビジョニングするには、以下を実行します。

    1. OperatorsInstalled Operators に移動し、Operator のリストから Local Storage を選択します。
    2. Local Volume SetCreate Local Volume Set を選択します。
    3. ボリュームセット名とストレージクラス名を入力します。
    4. All nodes または Select nodes を選択し、適宜フィルターを適用します。

      注記

      All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。

    5. ローカルボリュームセットに適用するディスクタイプ、モード、サイズ、および制限を選択し、Create をクリックします。

      メッセージが数分後に表示され、「Operator reconciled successfully」という Operator の調整が正常に行われたことが示唆されます。

  4. または、CLI から検出されたデバイスのローカルボリュームをプロビジョニングするには、以下を実行します。

    1. 以下の例に示されるように、オブジェクト YAML ファイルを作成し、local-volume-set.yaml などのローカルボリュームセットを定義します。

      apiVersion: local.storage.openshift.io/v1alpha1
      kind: LocalVolumeSet
      metadata:
        name: example-autodetect
      spec:
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                    - worker-0
                    - worker-1
        storageClassName: local-sc 1
        volumeMode: Filesystem
        fsType: ext4
        maxDeviceCount: 10
        deviceInclusionSpec:
          deviceTypes: 2
            - disk
            - part
          deviceMechanicalProperties:
            - NonRotational
          minSize: 10G
          maxSize: 100G
          models:
            - SAMSUNG
            - Crucial_CT525MX3
          vendors:
            - ATA
            - ST2000LM
      1
      検出されたデバイスからプロビジョニングされる永続ボリューム用に作成されるストレージクラスを判別します。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。
      2
      ローカルボリュームセット機能を使用する場合、ローカルストレージ Operator は論理ボリューム管理 (LVM) デバイスの使用をサポートしません。
    2. ローカルボリュームセットオブジェクトを作成します。

      $ oc apply -f local-volume-set.yaml
    3. ローカル永続ボリュームがストレージクラスに基づいて動的にプロビジョニングされていることを確認します。

      $ oc get pv

      出力例

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
      local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

注記

結果は、ノードから削除された後に削除されます。シンボリックリンクは手動で削除する必要があります。

4.12.2.7. ローカルストレージ Operator Pod での容認の使用

テイントはノードに適用し、それらが一般的なワークロードを実行しないようにすることができます。ローカルストレージ Operator がテイントのマークが付けられたノードを使用できるようにするには、容認を Pod または DaemonSet 定義に追加する必要があります。これにより、作成されたリソースをこれらのテイントのマークが付けられたノードで実行できるようになります。

容認を LocalVolume リソースでローカルストレージ Operator Pod に適用し、テイントをノード仕様でノードに適用します。ノードのテイントはノードに対し、テイントを容認しないすべての Pod を拒否するよう指示します。他の Pod にはない特定のテイントを使用することで、ローカルストレージ Operator Pod がそのノードでも実行されるようにできます。

重要

taint および toleration は、key、value、および effect で構成されます。引数として、これは key=value:effect として表現されます。演算子により、これらの 3 つのパラメーターのいずれかを空のままにすることができます。

前提条件

  • ローカルストレージ Operator がインストールされていること。
  • ローカルディスクがテイントを持つ OpenShift Container Platform ノードに割り当てられている。
  • テイントのマークが付けられたノードがローカルストレージのプロビジョニングを行うことが想定されます。

手順

テイントのマークが付けられたノードでスケジュールするようにローカルボリュームを設定するには、以下を実行します。

  1. 以下の例に示されるように、Pod を定義する YAML ファイルを変更し、LocalVolume 仕様を追加します。

      apiVersion: "local.storage.openshift.io/v1"
      kind: "LocalVolume"
      metadata:
        name: "local-disks"
        namespace: "openshift-local-storage"
      spec:
        tolerations:
          - key: localstorage 1
            operator: Equal 2
            value: "localstorage" 3
        storageClassDevices:
            - storageClassName: "local-sc"
              volumeMode: Block 4
              devicePaths: 5
                - /dev/xvdg
    1
    ノードに追加したキーを指定します。
    2
    Equal Operator を指定して、key/value パラメーターが一致するようにします。Operator が Exists の場合、システムはキーが存在することを確認し、値を無視します。Operator が Equal の場合、キーと値が一致する必要があります。
    3
    テイントのマークが付けられたノードの値 local を指定します。
    4
    ボリュームモード (Filesystem または Block) で、ローカルボリュームのタイプを定義します。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。
  2. オプション: テイントのマークが付けられたノードでのみローカル永続ボリュームを作成するには、以下の例のように YAML ファイルを変更し、LocalVolume 仕様を追加します。

    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          operator: Exists

定義された容認は結果として作成されるデーモンセットに渡されます。これにより、diskmaker およびプロビジョナー Pod を指定されたテイントが含まれるノード用に作成できます。

4.12.2.8. ローカルストレージ Operator メトリクス

OpenShift Container Platform は、ローカルストレージ Operator の以下のメトリクスを提供します。

  • lso_discovery_disk_count: 各ノードで検出されたデバイスの合計数
  • lso_lvset_provisioned_PV_count: LocalVolumeSet オブジェクトによって作成される PV の合計数
  • lso_lvset_unmatched_disk_count: 条件の不一致により、ローカルストレージ Operator がプロビジョニング用に選択しなかったディスクの合計数
  • lso_lvset_orphaned_symlink_count: LocalVolumeSet オブジェクト基準に一致しなくなった PV のあるデバイスの数
  • lso_lv_orphaned_symlink_count: LocalVolume オブジェクト基準に一致しなくなった PV のあるデバイスの数
  • lso_lv_provisioned_PV_count: LocalVolume のプロビジョニングされた PV の合計数

これらのメトリクスを使用するには、以下の点を確認してください。

  • ローカルストレージ Operator のインストール時に、モニタリングのサポートを有効にする。
  • OpenShift Container Platform 4.9 以降にアップグレードする場合は、namespace に operator-metering=true ラベルを追加してメトリクスサポートを手動で有効にしてください。

メトリクスの詳細は、メトリクスの管理 を参照してください。

4.12.2.9. ローカルストレージ Operator のリソースの削除
4.12.2.9.1. ローカルボリュームまたはローカルボリュームセットの削除

ローカルボリュームおよびローカルボリュームセットを削除する必要がある場合があります。リソースのエントリーを削除し、永続ボリュームを削除することで通常は十分ですが、同じデバイスパスを再使用する場合や別のストレージクラスでこれを管理する必要がある場合には、追加の手順が必要になります。

注記

以下の手順では、ローカルボリュームを削除する例の概要を説明します。同じ手順を使用して、ローカルボリュームセットのカスタムリソースのシンボリックリンクを削除することもできます。

前提条件

  • 永続ボリュームの状態は Released または Available である必要があります。

    警告

    使用中の永続ボリュームを削除すると、データの損失や破損につながる可能性があります。

手順

  1. 以前に作成したローカルボリュームを編集して、不要なディスクを削除します。

    1. クラスターリソースを編集します。

      $ oc edit localvolume <name> -n openshift-local-storage
    2. devicePaths の下の行に移動し、不要なディスクを表すものを削除します。
  2. 作成した永続ボリュームを削除します。

    $ oc delete pv <pv-name>
  3. ノード上のディレクトリーと含まれるシンボリックリンクを削除します。

    警告

    以下の手順では、root ユーザーとしてノードにアクセスする必要があります。この手順のステップ以外にノードの状態を変更すると、クラスターが不安定になる可能性があります。

    $ oc debug node/<node-name> -- chroot /host rm -rf /mnt/local-storage/<sc-name> 1
    1
    ローカルボリュームの作成に使用されるストレージクラスの名前。
4.12.2.9.2. ローカルストレージ Operator のアンインストール

ローカルストレージ Operator をアンインストールするには、Operator および openshift-local-storage プロジェクトの作成されたすべてのリソースを削除する必要があります。

警告

ローカルストレージ PV がまだ使用中の状態でローカルストレージ Operator をアンインストールすることは推奨されません。PV は Operator の削除後も残りますが、PV およびローカルストレージリソースを削除せずに Operator がアンインストールされ、再インストールされる場合に予測できない動作が生じる可能性があります。

前提条件

  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. プロジェクトにインストールされているローカルボリュームリソースを削除します (localvolumelocalvolumesetlocalvolumediscovery等)。

    $ oc delete localvolume --all --all-namespaces
    $ oc delete localvolumeset --all --all-namespaces
    $ oc delete localvolumediscovery --all --all-namespaces
  2. Web コンソールからローカルストレージ Operator をアンインストールします。

    1. OpenShift Container Platform Web コンソールにログインします。
    2. OperatorsInstalled Operators に移動します。
    3. Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
    4. ローカルストレージ Operator の末尾にある Options メニュー kebab をクリックします。
    5. Uninstall Operator をクリックします。
    6. 表示されるウィンドウで Remove をクリックします。
  3. ローカルストレージ Operator で作成された PV は削除されるまでクラスターに残ります。これらのボリュームが使用されなくなったら、以下のコマンドを実行してこれらのボリュームを削除します。

    $ oc delete pv <pv-name>
  4. openshift-local-storage プロジェクトを削除します。

    $ oc delete project openshift-local-storage

4.12.3. hostPath を使用した永続ストレージ

OpenShift Container Platform クラスター内の hostPath ボリュームは、ファイルまたはディレクトリーをホストノードのファイルシステムから Pod にマウントします。ほとんどの Pod には hostPath ボリュームは必要ありませんが、アプリケーションが必要とする場合は、テスト用のクイックオプションが提供されます。

重要

クラスター管理者は、特権付き Pod として実行するように Pod を設定する必要があります。これにより、同じノードの Pod へのアクセスが付与されます。

4.12.3.1. 概要

OpenShift Container Platform はシングルノードクラスターでの開発およびテスト用の hostPath マウントをサポートします。

実稼働クラスターでは、hostPath を使用しません。代わりにクラスター管理者は、GCE Persistent Disk ボリューム、NFS 共有、Amazon EBS ボリュームなどのネットワークリソースをプロビジョニングします。ネットワークリソースは、ストレージクラスを使用した動的プロビジョニングの設定をサポートします。

hostPath ボリュームは静的にプロビジョニングする必要があります。

重要

コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合、ホストシステムを破壊する可能性があります。ホストをマウントするには、/host を使用するのが安全です。以下の例では、ホストの / ディレクトリーが /host でコンテナーにマウントされています。

apiVersion: v1
kind: Pod
metadata:
  name: test-host-mount
spec:
  containers:
  - image: registry.access.redhat.com/ubi9/ubi
    name: test-container
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /host
      name: host-slash
  volumes:
   - name: host-slash
     hostPath:
       path: /
       type: ''
4.12.3.2. hostPath ボリュームの静的なプロビジョニング

hostPath ボリュームを使用する Pod は、手動の (静的) プロビジョニングで参照される必要があります。

手順

  1. 永続ボリューム (PV) を定義します。PersistentVolume オブジェクト定義を使用して pv.yaml ファイルを作成します。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: task-pv-volume 1
        labels:
          type: local
      spec:
        storageClassName: manual 2
        capacity:
          storage: 5Gi
        accessModes:
          - ReadWriteOnce 3
        persistentVolumeReclaimPolicy: Retain
        hostPath:
          path: "/mnt/data" 4
    1
    ボリュームの名前。この名前は永続ボリューム要求または Pod で識別されるものです。
    2
    永続ボリューム要求をこの永続ボリュームにバインドするために使用されます。
    3
    ボリュームはシングルノードで read-write としてマウントできます。
    4
    設定ファイルでは、ボリュームがクラスターのノードの /mnt/data にあるように指定します。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これにより、ホストシステムを破壊する可能性があります。ホストをマウントするには、/host を使用するのが安全です。
  2. ファイルから PV を作成します。

    $ oc create -f pv.yaml
  3. 永続ボリューム要求 (PVC) を定義します。PersistentVolumeClaim オブジェクト定義を使用して、ファイル pvc.yaml を作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: task-pvc-volume
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: manual
  4. ファイルから PVC を作成します。

    $ oc create -f pvc.yaml
4.12.3.3. 特権付き Pod での hostPath 共有のマウント

永続ボリューム要求の作成後に、これをアプリケーション内で使用できます。以下の例は、この共有を Pod 内にマウントする方法を示しています。

前提条件

  • 基礎となる hostPath 共有にマップされる永続ボリューム要求があること。

手順

  • 既存の永続ボリューム要求をマウントする特権付き Pod を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-name 1
    spec:
      containers:
        ...
        securityContext:
          privileged: true 2
        volumeMounts:
        - mountPath: /data 3
          name: hostpath-privileged
      ...
      securityContext: {}
      volumes:
        - name: hostpath-privileged
          persistentVolumeClaim:
            claimName: task-pvc-volume 4
    1
    Pod の名前。
    2
    Pod は、ノードのストレージにアクセスするために特権付き Pod として実行される必要があります。
    3
    特権付き Pod 内にホストパス共有をマウントするパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
    4
    以前に作成された PersistentVolumeClaim オブジェクトの名前。

4.12.4. Logical Volume Manager Storage を使用した永続ストレージ

論理ボリュームマネージャー (LVM) ストレージは、TopoLVM CSI ドライバーを介して LVM2 を使用して、リソースが制限されたクラスター上でローカルストレージを動的にプロビジョニングします。

LVM Storage を使用すると、ボリュームグループ、永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンを作成できます。

4.12.4.1. Logical Volume Manager Storage のインストール

OpenShift Container Platform クラスターに論理ボリュームマネージャー (LVM) ストレージをインストールし、ワークロードのストレージを動的にプロビジョニングするように設定できます。

LVM Storage は、OpenShift Container Platform CLI (oc)、OpenShift Container Platform Web コンソール、または Red Hat Advanced Cluster Management (RHACM) を使用してインストールできます。

警告

マルチノードクラスターで LVM Storage を使用する場合、LVM Storage はローカルストレージのプロビジョニングのみをサポートします。LVM Storage は、ノード間のストレージデータレプリケーションメカニズムをサポートしていません。単一障害点を回避するために、アクティブまたはパッシブレプリケーションメカニズムを通じてストレージデータを確実にレプリケーションする必要があります。

4.12.4.1.1. LVM Storage をインストールするための前提条件

LVM Storage をインストールするための前提条件は次のとおりです。

  • 最低でも 10 ミリの CPU と 100 MiB の RAM があることを確認してください。
  • すべてのマネージドクラスターに、ストレージのプロビジョニングに使用される専用のディスクがあることを確認してください。LVM Storage は、ファイルシステム署名が含まれていない空のディスクのみを使用します。確実にディスクが空で、ファイルシステム署名が含まれていないようにするには、使用する前にディスクを消去します。
  • 以前の LVM Storage のインストールで設定したストレージデバイスを再利用できるプライベート CI 環境に LVM Storage をインストールする前に、使用されていないディスクが消去されていることを確認してください。LVM Storage をインストールする前にディスクをワイプしないと、ディスクを再利用するのに手動による介入が必要になります。

    注記

    使用中のディスクは消去できません。

  • Red Hat Advanced Cluster Management (RHACM) を使用して LVM Storage をインストールする場合は、RHACM が OpenShift Container Platform クラスターにインストールされていることを確認してください。「RHACM を使用した LVM Storage のインストール」セクションを参照してください。
4.12.4.1.2. CLI を使用した LVM Storage のインストール

クラスター管理者は、OpenShift CLI を使用して LVM Storage をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin および Operator インストール権限を持つユーザーとして OpenShift Container Platform にログインしている。

手順

  1. namespace を作成するための設定を含む YAML ファイルを作成します。

    namespace を作成するための YAML 設定の例

    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/audit: privileged
        pod-security.kubernetes.io/warn: privileged
      name: openshift-storage

  2. 以下のコマンドを実行して namespace を作成します。

    $ oc create -f <file_name>
  3. OperatorGroup CR YAML ファイルを作成します。

    OperatorGroup CR の例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-storage-operatorgroup
      namespace: openshift-storage
    spec:
      targetNamespaces:
      - openshift-storage

  4. 以下のコマンドを実行して OperatorGroup CR を作成します。

    $ oc create -f <file_name>
  5. Subscription CR YAML ファイルを作成します。

    Subscription CR の例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: lvms
      namespace: openshift-storage
    spec:
      installPlanApproval: Automatic
      name: lvms-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace

  6. 以下のコマンドを実行して Subscription CR を作成します。

    $ oc create -f <file_name>

検証

  1. LVM Storage がインストールされていることを確認するには、次のコマンドを実行します。

    $ oc get csv -n openshift-storage -o custom-columns=Name:.metadata.name,Phase:.status.phase

    出力例

    Name                         Phase
    4.13.0-202301261535          Succeeded

4.12.4.1.3. Web コンソールを使用した LVM Storage のインストール

OpenShift Container Platform Web コンソールを使用して LVM Storage をインストールできます。

前提条件

  • クラスターにアクセスできる。
  • cluster-admin および Operator インストール権限で OpenShift Container Platform にアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators → OperatorHub をクリックします。
  3. OperatorHub ページで LVM Storage をクリックします。
  4. Operator Installation ページで次のオプションを設定します。

    1. Update Channelstable-4.16 に設定します。
    2. Installation ModeA specific namespace on the cluster に設定します。
    3. Installed NamespaceOperator recommended namespace openshift-storage に設定します。openshift-storage namespace が存在しない場合は、Operator のインストール中に作成されます。
    4. Update approvalAutomatic または Manual を選択します。

      注記

      Automatic (自動) 更新を選択すると、手動による介入なしで、Operator Lifecycle Manager (OLM) によって LVM Storage の実行中のインスタンスが自動的に更新されます。

      Manual 更新を選択した場合、OLM は更新要求を作成します。LVM Storage を新しいバージョンに更新するには、クラスター管理者が更新要求を手動で承認する必要があります。

  5. オプション: Enable Operator recommended cluster monitoring on this Namespace チェックボックスを選択します。
  6. Install をクリックします。

検証手順

  • インストールが成功したことを示す緑色のチェックマークが LVM Storage に表示されていることを確認します。
4.12.4.1.4. 非接続環境での LVM Storage のインストール

非接続環境の OpenShift Container Platform に LVM Storage をインストールできます。「関連情報」セクションに、この手順で参照されているすべてのセクションのリンクが記載されています。

前提条件

  • 「非接続インストールミラーリングについて」セクションを確認した。
  • OpenShift Container Platform イメージリポジトリーにアクセスできる。
  • ミラーレジストリーを作成した。

手順

  1. 「イメージセット設定の作成」手順の手順に従います。LVM Storage の ImageSetConfiguration カスタムリソース (CR) を作成するには、次の ImageSetConfiguration CR 設定の例を使用できます。

    LVM Storage 用の ImageSetConfiguration CR の例

    kind: ImageSetConfiguration
    apiVersion: mirror.openshift.io/v1alpha2
    archiveSize: 4 1
    storageConfig: 2
      registry:
        imageURL: example.com/mirror/oc-mirror-metadata 3
        skipTLS: false
    mirror:
      platform:
        channels:
        - name: stable-4.16 4
          type: ocp
        graph: true 5
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16 6
        packages:
        - name: lvms-operator 7
          channels:
          - name: stable 8
      additionalImages:
      - name: registry.redhat.io/ubi9/ubi:latest 9
      helm: {}

    1
    イメージセット内の各ファイルの最大サイズ (GiB 単位) を設定します。
    2
    イメージセットを保存する場所を指定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。テクノロジープレビューの OCI 機能を使用している場合を除き、storageConfig フィールドを設定する必要があります。
    3
    レジストリーを使用する場合は、イメージストリームのストレージ URL を指定します。詳細は、イメージストリームを使用する理由 を参照してください。
    4
    OpenShift Container Platform イメージの取得元のチャネルを指定します。
    5
    OpenShift Update Service (OSUS) グラフイメージを生成するには、このフィールドを true に設定します。詳細は、OpenShift Update Service について を参照してください。
    6
    OpenShift Container Platform イメージの取得元の Operator カタログを指定します。
    7
    イメージセットに含める Operator パッケージを指定します。このフィールドが空の場合、カタログ内のすべてのパッケージが取得されます。
    8
    イメージセットに含める Operator パッケージのチャネルを指定します。Operator パッケージのデフォルトチャネルは、そのチャネルのバンドルを使用しない場合でも含める必要があります。コマンド $ oc mirror list operators --catalog=<catalog_name> --package=<package_name> を実行すると、デフォルトチャネルを見つけることができます。
    9
    イメージセットに含める追加のイメージを指定します。
  2. 「イメージセットをミラーレジストリーにミラーリングする」セクションの手順に従います。
  3. 「イメージレジストリーのリポジトリーミラーリングの設定」セクションの手順に従います。
4.12.4.1.5. RHACM を使用した LVM Storage のインストール

Red Hat Advanced Cluster Management (RHACM) を使用してクラスターに LVM Storage をインストールするには、Policy カスタムリソース (CR) を作成する必要があります。LVM Storage をインストールするクラスターを選択するための基準を設定することもできます。

注記

LVM Storage をインストールするために作成した Policy CR は、Policy CR の作成後にインポートまたは作成したクラスターにも適用されます。

前提条件

  • cluster-admin および Operator のインストール権限を持つアカウントを使用して、RHACM クラスターにアクセスできる。
  • 各クラスターに、LVM Storage が使用できる専用のディスクがある。
  • クラスターが RHACM によって管理されている。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. namespace を作成します。

    $ oc create ns <namespace>
  3. Policy CR YAML ファイルを作成します。

    LVM Storage をインストールして設定するための Policy CR の例

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-install-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector: 1
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-install-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-install-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: install-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: install-lvms
    spec:
      disabled: false
      remediationAction: enforce
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: install-lvms
          spec:
            object-templates:
            - complianceType: musthave
              objectDefinition: 2
                apiVersion: v1
                kind: Namespace
                metadata:
                  labels:
                    openshift.io/cluster-monitoring: "true"
                    pod-security.kubernetes.io/enforce: privileged
                    pod-security.kubernetes.io/audit: privileged
                    pod-security.kubernetes.io/warn: privileged
                  name: openshift-storage
            - complianceType: musthave
              objectDefinition: 3
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: musthave
              objectDefinition: 4
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms
                  namespace: openshift-storage
                spec:
                  installPlanApproval: Automatic
                  name: lvms-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
            remediationAction: enforce
            severity: low

    1
    PlacementRule.spec.clusterSelectorkey フィールドと values フィールドを、LVM Storage をインストールするクラスターに設定されているラベルと一致するように設定します。
    2
    namespace の設定。
    3
    OperatorGroup CR の設定。
    4
    Subscription CR の設定。
  4. 次のコマンドを実行して Policy CR を作成します。

    $ oc create -f <file_name> -n <namespace>

    Policy CR を作成すると、PlacementRule CR で設定された選択基準に一致するクラスターに次のカスタムリソースが作成されます。

    • Namespace
    • OperatorGroup
    • Subscription
4.12.4.2. LVM Storage で使用するデバイスのサイズを設定する際の制限事項

LVM Storage を使用したストレージのプロビジョニングで使用できるデバイスのサイズを設定する際の制限は、次のとおりです。

  • プロビジョニングできる合計ストレージサイズは、基礎となる論理ボリュームマネージャー (LVM) シンプールのサイズとオーバープロビジョニング係数によって制限されます。
  • 論理ボリュームのサイズは、物理エクステント (PE) のサイズと論理エクステント (LE) のサイズによって異なります。

    • PE および LE のサイズは、物理デバイスおよび論理デバイスの作成時に定義できます。
    • デフォルトの PE および LE サイズは 4 MB です。
    • PE のサイズを大きくした場合、LVM の最大サイズは、カーネルの制限とディスク領域によって決定されます。
表4.5 デフォルトの PE および LE サイズを使用した各アーキテクチャーのサイズ制限
アーキテクチャーRHEL 6RHEL 7RHEL 8RHEL 9

32 ビット

16 TB

-

-

-

64 ビット

8 EB [1]

100 TB [2]

8 EB [1]

500 TB [2]

8 EB

8 EB

  1. 理論的サイズ。
  2. テスト済みサイズ。
4.12.4.3. LVMCluster カスタムリソースについて

次の操作を実行するように LVMCluster CR を設定できます。

  • 永続ボリューム要求 (PVC) のプロビジョニングに使用できる LVM ボリュームグループを作成する。
  • LVM ボリュームグループに追加するデバイスのリストを設定する。
  • LVM ボリュームグループを作成するノードを選択するための要件と、ボリュームグループのシンプール設定を設定する。
  • 選択したデバイスを強制的にワイプする。

LVM Storage をインストールした後、LVMCluster カスタムリソース (CR) を作成する必要があります。

LVMCluster CR YAML ファイルの例

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
  namespace: openshift-storage
spec:
  tolerations:
  - effect: NoSchedule
    key: xyz
    operator: Equal
    value: "true"
  storage:
    deviceClasses:
    - name: vg1
      fstype: ext4 1
      default: true
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
          - key: mykey
            operator: In
            values:
            - ssd
      deviceSelector: 3
        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        optionalPaths:
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
        forceWipeDevicesAndDestroyAllData: true
      thinPoolConfig:
        name: thin-pool-1
        sizePercent: 90 4
        overprovisionRatio: 10

1 2 3 4
オプションのフィールド
LVMCluster CR のフィールドの説明

LVMCluster CR のフィールドについて、次の表で説明します。

表4.6 LVMCluster CR のフィールド
フィールド説明

spec.storage.deviceClasses

array

ローカルストレージデバイスを LVM ボリュームグループに割り当てるための設定を含めます。

LVM Storage は、ユーザーが作成する各デバイスクラスに対してストレージクラスとボリュームスナップショットクラスを作成します。

deviceClasses.name

string

LVM ボリュームグループ (VG) の名前を指定します。

以前のインストールで作成したボリュームグループを再利用するようにこのフィールドを設定することもできます。詳細は、「以前の LVM ストレージインストールからのボリュームグループの再利用」を参照してください。

deviceClasses.fstype

string

このフィールドは、ext4 または xfs に設定します。デフォルトでは、このフィールドは xfs に設定されています。

deviceClasses.default

boolean

デバイスクラスがデフォルトであることを指定するには、このフィールドを true に設定します。それ以外の場合は、false に設定できます。設定できるデフォルトのデバイスクラスは 1 つだけです。

deviceClasses.nodeSelector

object

LVM ボリュームグループを作成するノードを選択するための設定を含めます。このフィールドが空の場合、no-schedule テイントのないすべてのノードが考慮されます。

コントロールプレーンノードでは、クラスター内で新しいノードがアクティブになると、LVM Storage が追加のワーカーノードを検出して使用します。

nodeSelector.nodeSelectorTerms

array

ノードの選択に使用する要件を設定します。

deviceClasses.deviceSelector

object

次の操作を実行するための設定を含めます。

  • LVM ボリュームグループに追加するデバイスへのパスを指定する。
  • LVM ボリュームグループに追加されたデバイスを強制的にワイプする。

詳細は、「ボリュームグループへのデバイスの追加について」を参照してください。

deviceSelector.paths

array

デバイスパスを指定します。

このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage でサポートされていない場合、LVMCluster CR が Failed 状態に移行します。

deviceSelector.optionalPaths

array

オプションのデバイスパスを指定します。

このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage によってサポートされていない場合、LVM Storage はエラーを起こすことなくデバイスを無視します。

deviceSelector. forceWipeDevicesAndDestroyAllData

boolean

LVM Storage は、ファイルシステム署名が含まれていない空のディスクのみを使用します。確実にディスクが空で、ファイルシステム署名が含まれていないようにするには、使用する前にディスクを消去します。

選択したデバイスを強制的にワイプするには、このフィールドを true に設定します。デフォルトでは、このフィールドは false に設定されています。

警告

このフィールドが true に設定されている場合、LVM Storage がデバイス上の以前のデータをすべてワイプします。この機能は注意して使用してください。

次の条件のいずれかが満たされている場合にデバイスをワイプすると、データの整合性が失われる可能性があります。

  • デバイスがスワップ領域として使用されている。
  • デバイスが RAID アレイの一部である。
  • デバイスがマウントされている。

これらの条件のいずれかに該当する場合は、ディスクを強制的にワイプしないでください。代わりに、ディスクを手動でワイプする必要があります。

deviceClasses.thinPoolConfig

object

LVM ボリュームグループにシンプールを作成するための設定を含めます。

このフィールドを除外すると、論理ボリュームはシックプロビジョニングされます。

シックプロビジョニングされたストレージを使用する場合、次の制限があります。

  • ボリュームのクローン作成ではコピーオンライトはサポートされません。
  • スナップショットクラスはサポートされていません。
  • オーバープロビジョニングはサポートされていません。その結果、PersistentVolumeClaims (PVC) のプロビジョニングされた容量が、ボリュームグループからすぐに削減されます。
  • シンメトリクスはサポートされていません。シックプロビジョニングされたデバイスは、ボリュームグループメトリクスのみをサポートします。

thinPoolConfig.name

string

シンプールの名前を指定します。

thinPoolConfig.sizePercent

integer

シンプールを作成するための LVM ボリュームグループ内の領域の割合を指定します。

デフォルトでは、このフィールドは 90 に設定されています。設定できる最小値は 10、最大値は 90 です。

thinPoolConfig.overprovisionRatio

integer

シンプールで使用可能なストレージに基づいて追加のストレージをプロビジョニングするのに使用する係数を指定します。

たとえば、このフィールドが 10 に設定されている場合、シンプールで使用可能なストレージの量の最大 10 倍をプロビジョニングできます。

オーバープロビジョニングを無効にするには、このフィールドを 1 に設定します。

4.12.4.3.1. ボリュームグループへのデバイスの追加について

LVMCluster CR の deviceSelector フィールドには、論理ボリュームマネージャー (LVM) ボリュームグループに追加するデバイスへのパスを指定するための設定が含まれています。

デバイスへのパスは、deviceSelector.paths フィールド、deviceSelector.optionalPaths フィールド、またはその両方で指定できます。deviceSelector.paths フィールドと deviceSelector.optionalPaths フィールドのどちらにもデバイスパスを指定しなかった場合、LVM Storage によって、サポートされている未使用のデバイスがボリュームグループ (VG) に追加されます。

deviceSelector フィールドに Redundant Array of Independent Disks (RAID) アレイへのパスを追加して、RAID アレイを LVM ストレージと統合できます。mdadm ユーティリティーを使用して RAID アレイを作成できます。LVM ストレージはソフトウェア RAID の作成をサポートしていません。

注記

RAID アレイは、OpenShift Container Platform のインストール中にのみ作成できます。RAID アレイの作成に関する詳細は、以下のセクションを参照してください。

暗号化されたデバイスをボリュームグループに追加することもできます。OpenShift Container Platform のインストール中に、クラスターノードでディスク暗号化を有効にすることができます。デバイスを暗号化した後、deviceSelector フィールドで LUKS 暗号化デバイスへのパスを指定できます。ディスク暗号化の詳細は、「ディスク暗号化について」および「ディスク暗号化とミラーリングの設定」を参照してください。

VG に追加するデバイスは、LVM ストレージでサポートされている必要があります。サポートされていないデバイスの詳細は、「LVM ストレージでサポートされていないデバイス」を参照してください。

LVM ストレージは、次の条件が満たされた場合にのみ、デバイスを VG に追加します。

  • デバイスパスが存在する。
  • デバイスが LVM Storage によってサポートされている。
重要

デバイスを VG に追加した後は、そのデバイスを削除することはできません。

LVM ストレージは動的デバイス検出をサポートします。LVMCluster CR に deviceSelector フィールドを追加しない場合、デバイスが利用可能になると、LVM Storage は新しいデバイスを自動的に VG に追加します。

警告

以下の理由により、動的デバイス検出を通じてデバイスを VG に追加することは推奨されません。

  • VG に追加するつもりのない新しいデバイスを追加すると、LVM ストレージは動的デバイス検出を通じてこのデバイスを VG に自動的に追加します。
  • LVM ストレージが動的デバイス検出を通じて VG にデバイスを追加する場合、LVM ストレージはノードからデバイスを削除することを制限しません。VG にすでに追加されているデバイスを削除または更新すると、VG が中断される可能性があります。これにより、データが失われ、手動でのノードの修復が必要になる可能性もあります。
4.12.4.3.2. LVM Storage でサポートされないデバイス

LVMCluster カスタムリソース (CR) の deviceSelector フィールドにデバイスパスを追加する場合は、そのデバイスが LVM Storage でサポートされていることを確認してください。サポートされていないデバイスへのパスを追加すると、論理ボリュームの管理が複雑になることを回避するために、LVM Storage はそのデバイスを除外します。

deviceSelector フィールドでデバイスパスを指定しない場合、LVM Storage はサポート対象の未使用デバイスのみ追加します。

注記

デバイスに関する情報を取得するには、次のコマンドを実行します。

$ lsblk --paths --json -o \
NAME,ROTA,TYPE,SIZE,MODEL,VENDOR,RO,STATE,KNAME,SERIAL,PARTLABEL,FSTYPE

LVM Storage は、次のデバイスをサポートしません。

読み取り専用デバイス
ro パラメーターが true に設定されているデバイス。
一時停止されたデバイス
state パラメーターが suspended に設定されているデバイス。
ROM デバイス
type パラメーターが rom に設定されているデバイス。
LVM パーティションデバイス
type パラメーターが lvm に設定されているデバイス。
無効なパーティションラベルを持つデバイス
partlabel パラメーターが biosboot、または reserved に設定されているデバイス。
無効なファイルシステムを持つデバイス

fstype パラメーターが、null または LVM2_member 以外の値に設定されているデバイス。

重要

LVM Storage は、そのデバイスに子デバイスが含まれていない場合に限り、fstype パラメーターが LVM2_member に設定されているデバイスをサポートします。

別のボリュームグループの一部であるデバイス

デバイスのボリュームグループに関する情報を取得するには、次のコマンドを実行します。

$ pvs <device-name> 1
1
<device-name> をデバイス名に置き換えます。
バインドマウントを備えたデバイス

デバイスのマウントポイントを取得するには、次のコマンドを実行します。

$ cat /proc/1/mountinfo | grep <device-name> 1
1
<device-name> をデバイス名に置き換えます。
子デバイスを含むデバイス
注記

予期しない動作を防ぐために、LVM Storage で使用する前にデバイスをワイプすることが推奨されます。

4.12.4.4. LVMCluster カスタムリソースを作成する方法

LVMCluster カスタムリソース (CR) は、OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して作成できます。Red Hat Advanced Cluster Management (RHACM) を使用して LVM Storage をインストールした場合は、RHACM を使用して LVMCluster CR を作成することもできます。

LVMCluster CR を作成すると、LVM Storage によって次のシステム管理 CR が作成されます。

  • 各デバイスクラスの storageClassvolumeSnapshotClass

    注記

    LVM Storage は、ストレージクラスとボリュームスナップショットクラスの名前を lvms-<device_class_name> の形式で設定します。<device_class_name> は、LVMCluster CR の deviceClasses.name フィールドの値です。たとえば、deviceClasses.name フィールドが vg1 に設定されている場合、ストレージクラスとボリュームスナップショットクラスの名前は lvms-vg1 になります。

  • LVMVolumeGroup: この CR は、LVM ボリュームグループによってサポートされる特定のタイプの永続ボリューム (PV) です。複数のノードにわたる個々のボリュームグループを追跡します。
  • LVMVolumeGroupNodeStatus: この CR は、ノード上のボリュームグループのステータスを追跡します。
4.12.4.4.1. 以前の LVM Storage インストールからのボリュームグループを再利用する

新しいボリュームグループ (VG) を作成する代わりに、以前の LVM Storage インストールからの既存の VG を再利用できます。

再利用できるのは VG のみです。VG に関連付けられた論理ボリュームは再利用できません。

重要

この手順は、LVMCluster カスタムリソース (CR) の作成中にのみ実行できます。

前提条件

手順

  1. LVMCluster CR YAML ファイルを開きます。
  2. 次の例の説明に従って、LVMCluster CR のパラメーターを設定します。

    LVMCluster CR YAML ファイルの例

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
      namespace: openshift-storage
    spec:
    # ...
      storage:
        deviceClasses:
        - name: vg1  1
          fstype: ext4 2
          default: true
          deviceSelector: 3
    # ...
            forceWipeDevicesAndDestroyAllData: false 4
          thinPoolConfig: 5
    # ...
          nodeSelector: 6
    # ...

    1
    このフィールドは、以前の LVM Storage インストールの VG 名に設定します。
    2
    このフィールドは、ext4 または xfs に設定します。デフォルトでは、このフィールドは xfs に設定されています。
    3
    deviceSelector フィールドに新しいデバイスパスを指定すると、再利用する新しいデバイスを VG に追加できます。新しいデバイスを VG に追加する必要がない場合は、現在の LVM Storage インストールの deviceSelector 設定が以前の LVM Storage インストールの設定と同じであることを確認してください。
    4
    このフィールドを true に設定すると、LVM Storage が VG に追加されたデバイス上のすべてのデータをワイプします。
    5
    再利用する VG の thinPoolConfig 設定を保持するには、現在の LVM Storage インストールの thinPoolConfig 設定が以前の LVM Storage インストールの thinPoolConfig 設定と同じであることを確認してください。保持しない場合は、必要に応じて thinPoolConfig フィールドを設定できます。
    6
    LVM ボリュームグループを作成するノードを選択するための要件を設定します。このフィールドが空の場合、no-schedule テイントのないすべてのノードが考慮されます。
  3. LVMCluster CR YAML ファイルを保存します。
注記

ボリュームグループに含まれているデバイスを表示するには、次のコマンドを実行します。

$ pvs -S vgname=<vg_name> 1
1
<vg_name> は、ボリュームグループの名前に置き換えます。
4.12.4.4.2. CLI を使用した LVMCluster CR の作成

OpenShift CLI (oc) を使用して、ワーカーノード上に LVMCluster カスタムリソース (CR) を作成できます。

重要

OpenShift Container Platform クラスターでは、LVMCluster カスタムリソース (CR) のインスタンスを 1 つだけ作成できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform にログインしている。
  • LVM Storage がインストールされている。
  • クラスターにワーカーノードがインストールされている。
  • 「LVMCluster カスタムリソースについて」セクションを確認した。

手順

  1. LVMCluster カスタムリソース (CR) YAML ファイルを作成します。

    LVMCluster CR YAML ファイルの例

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
      namespace: openshift-storage
    spec:
    # ...
      storage:
        deviceClasses: 1
    # ...
          nodeSelector: 2
    # ...
          deviceSelector: 3
    # ...
          thinPoolConfig: 4
    # ...

    1
    ローカルストレージデバイスを LVM ボリュームグループに割り当てるための設定を含めます。
    2
    LVM ボリュームグループを作成するノードを選択するための設定を含めます。このフィールドが空の場合、no-schedule テイントのないすべてのノードが考慮されます。
    3
    LVM ボリュームグループに追加するデバイスへのパスを指定し、LVM ボリュームグループに追加されたデバイスを強制的にワイプするための設定を含めます。
    4
    LVM ボリュームグループにシンプールを作成するための設定を含めます。このフィールドを除外すると、論理ボリュームはシックプロビジョニングされます。
  2. 次のコマンドを実行して、LVMCluster CR を作成します。

    $ oc create -f <file_name>

    出力例

    lvmcluster/lvmcluster created

検証

  1. LVMCluster CR が Ready 状態であることを確認します。

    $ oc get lvmclusters.lvm.topolvm.io -o jsonpath='{.items[*].status}' -n <namespace>

    出力例

    {"deviceClassStatuses": 1
    [
      {
        "name": "vg1",
        "nodeStatus": [ 2
            {
                "devices": [ 3
                    "/dev/nvme0n1",
                    "/dev/nvme1n1",
                    "/dev/nvme2n1"
                ],
                "node": "kube-node", 4
                "status": "Ready" 5
            }
        ]
      }
    ]
    "state":"Ready"} 6

    1
    デバイスクラスのステータス。
    2
    各ノードの LVM ボリュームグループのステータス。
    3
    LVM ボリュームグループの作成に使用されるデバイスのリスト。
    4
    デバイスクラスが作成されるノード。
    5
    ノード上の LVM ボリュームグループのステータス。
    6
    LVMCluster CR のステータス。
    注記

    LVMCluster CR が Failed 状態の場合、status フィールドに失敗の理由が表示されます。

    失敗の理由を示す status フィールドの例:

    status:
      deviceClassStatuses:
        - name: vg1
          nodeStatus:
            - node: my-node-1.example.com
              reason: no available devices found for volume group
              status: Failed
      state: Failed
  2. オプション: 各デバイスクラスに対して LVM Storage によって作成されたストレージクラスを表示するには、次のコマンドを実行します。

    $ oc get storageclass

    出力例

    NAME          PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    lvms-vg1      topolvm.io           Delete          WaitForFirstConsumer   true                   31m

  3. オプション: 各デバイスクラスに対して LVM Storage によって作成されたボリュームスナップショットクラスを表示するには、次のコマンドを実行します。

    $ oc get volumesnapshotclass

    出力例

    NAME          DRIVER               DELETIONPOLICY   AGE
    lvms-vg1      topolvm.io           Delete           24h

4.12.4.4.3. Web コンソールを使用した LVMCluster CR の作成

OpenShift Container Platform Web コンソールを使用して、ワーカーノード上に LVMCluster CR を作成できます。

重要

OpenShift Container Platform クラスターでは、LVMCluster カスタムリソース (CR) のインスタンスを 1 つだけ作成できます。

前提条件

  • cluster-admin 権限を使用して OpenShift Container Platform クラスターにアクセスできる。
  • LVM Storage がインストールされている。
  • クラスターにワーカーノードがインストールされている。
  • 「LVMCluster カスタムリソースについて」セクションを確認した。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. openshift-storage namespace で、LVM Storage をクリックします。
  4. Create LVMCluster をクリックし、Form view または YAML view のいずれかを選択します。
  5. LVMCluster CR の必要なパラメーターを設定します。
  6. Create をクリックします。
  7. オプション: LVMCLuster CR を編集する場合は、次の操作を実行します。

    1. LVMCluster タブをクリックします。
    2. Actions メニューから Edit LVMCluster を選択します。
    3. YAML をクリックし、LVMCLuster CR の必要なパラメーターを編集します。
    4. Save をクリックします。

検証

  1. LVMCLuster ページで、LVMCluster CR が Ready 状態であることを確認します。
  2. オプション: 各デバイスクラスに対して LVM Storage によって作成された使用可能なストレージクラスを表示するには、StorageStorageClasses をクリックします。
  3. オプション: 各デバイスクラスに対して LVM Storage によって作成された使用可能なボリュームスナップショットクラスを表示するには、StorageVolumeSnapshotClasses をクリックします。
4.12.4.4.4. RHACM を使用した LVMCluster CR の作成

RHACM を使用して LVM Storage をインストールした後、LVMCluster カスタムリソース (CR) を作成する必要があります。

前提条件

  • RHACM を使用して LVM Storage をインストールした。
  • cluster-admin 権限を持つアカウントを使用して RHACM クラスターにアクセスできる。
  • 「LVMCluster カスタムリソースについて」セクションを確認した。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. LVMCluster CR を作成するための設定を含む ConfigurationPolicy CR YAML ファイルを作成します。

    LVMCluster CR を作成するための ConfigurationPolicy CR YAML ファイルの例

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: lvms
      namespace: openshift-storage
    spec:
      object-templates:
      - complianceType: musthave
        objectDefinition:
          apiVersion: lvm.topolvm.io/v1alpha1
          kind: LVMCluster
          metadata:
            name: my-lvmcluster
            namespace: openshift-storage
          spec:
            storage:
              deviceClasses: 1
    # ...
                deviceSelector: 2
    # ...
                thinPoolConfig: 3
    # ...
                nodeSelector: 4
    # ...
      remediationAction: enforce
      severity: low

    1
    ローカルストレージデバイスを LVM ボリュームグループに割り当てるための設定を含めます。
    2
    LVM ボリュームグループに追加するデバイスへのパスを指定し、LVM ボリュームグループに追加されたデバイスを強制的にワイプするための設定を含めます。
    3
    LVM ボリュームグループにシンプールを作成するための設定を含めます。このフィールドを除外すると、論理ボリュームはシックプロビジョニングされます。
    4
    LVM ボリュームグループを作成するノードを選択するための設定を含めます。このフィールドが空の場合、no-schedule テイントのないすべてのノードが考慮されます。
  3. 次のコマンドを実行して、ConfigurationPolicy CR を作成します。

    $ oc create -f <file_name> -n <cluster_namespace> 1
    1
    LVM Storage がインストールされている OpenShift Container Platform クラスターの namespace。
4.12.4.5. LVMCluster カスタムリソースを削除する方法

LVMCluster カスタムリソース (CR) は、OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して削除できます。Red Hat Advanced Cluster Management (RHACM) を使用して LVM Storage をインストールした場合は、RHACM を使用して LVMCluster CR を削除することもできます。

LVMCluster CR を削除すると、LVM Storage によって次の CR が削除されます。

  • storageClass
  • volumeSnapshotClass
  • LVMVolumeGroup
  • LVMVolumeGroupNodeStatus
4.12.4.5.1. CLI を使用した LVMCluster CR の削除

OpenShift CLI (oc) を使用して、LVMCluster カスタムリソース (CR) を削除できます。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、LVMCluster CR を削除します。

    $ oc delete lvmcluster <lvmclustername> -n openshift-storage

検証

  • LVMCluster CR が削除されたことを確認するには、次のコマンドを実行します。

    $ oc get lvmcluster -n <namespace>

    出力例

    No resources found in openshift-storage namespace.

4.12.4.5.2. Web コンソールを使用した LVMCluster CR の削除

OpenShift Container Platform Web コンソールを使用して、LVMCluster カスタムリソース (CR) を削除できます。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックして、インストールされているすべての Operators を表示します。
  3. openshift-storage namespace で LVM Storage をクリックします。
  4. LVMCluster タブをクリックします。
  5. Actions から Delete LVMCluster を選択します。
  6. Delete をクリックします。

検証

  • LVMCLuster ページで、LVMCluster CR が削除されたことを確認します。
4.12.4.5.3. RHACM を使用した LVMCluster CR の削除

Red Hat Advanced Cluster Management (RHACM) を使用して LVM Storage をインストールした場合は、RHACM を使用して LVMCluster CR を削除できます。

前提条件

  • cluster-admin 権限を持つユーザーとして RHACM クラスターにアクセスできる。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. LVMCluster CR 用に作成した ConfigurationPolicy CR YAML ファイルを削除します。

    $ oc delete -f <file_name> -n <cluster_namespace> 1
    1
    LVM Storage がインストールされている OpenShift Container Platform クラスターの namespace。
  3. LVMCluster CR を削除するための Policy CR YAML ファイルを作成します。

    LVMCluster CR を削除するための Policy CR の例

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-delete
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: enforce
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal
            spec:
              remediationAction: enforce 1
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 2
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-delete
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-delete
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-delete
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-delete
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector: 3
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue

    1
    policy-templatespec.remediationAction は、spec.remediationAction の前のパラメーター値によってオーバーライドされます。
    2
    この namespace フィールドには openshift-storage 値が必要です。
    3
    クラスターを選択するための要件を設定します。選択基準に一致するクラスターから LVM Storage がアンインストールされます。
  4. 次のコマンドを実行して Policy CR を作成します。

    $ oc create -f <file_name> -n <namespace>
  5. LVMCluster CR が削除されたかどうかを確認するための Policy CR YAML ファイルを作成します。

    LVMCluster CR が削除されたかどうかを確認するための Policy CR の例

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-inform
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: inform
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal-inform
            spec:
              remediationAction: inform 1
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 2
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-check
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-check
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-inform
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-check
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue

    1
    policy-templatespec.remediationAction は、spec.remediationAction の前のパラメーター値によってオーバーライドされます。
    2
    namespace フィールドには openshift-storage 値が必要です。
  6. 次のコマンドを実行して Policy CR を作成します。

    $ oc create -f <file_name> -n <namespace>

検証

  • 次のコマンドを実行して、Policy CR のステータスを確認します。

    $ oc get policy -n <namespace>

    出力例

    NAME                       REMEDIATION ACTION   COMPLIANCE STATE   AGE
    policy-lvmcluster-delete   enforce              Compliant          15m
    policy-lvmcluster-inform   inform               Compliant          15m

    重要

    Policy CR が Compliant 状態である必要があります。

4.12.4.6. ストレージのプロビジョニング

LVMCluster カスタムリソース (CR) を使用して LVM ボリュームグループを作成した後、永続ボリューム要求 (PVC) を作成してストレージをプロビジョニングできます。

以下は、各ファイルシステムタイプに対して要求できる最小ストレージサイズです。

  • block: 8 MiB
  • xfs: 300 MiB
  • ext4: 32 MiB

PVC を作成するには、PersistentVolumeClaim オブジェクトを作成する必要があります。

前提条件

  • LVMCluster CR が作成されている。

手順

  1. OpenShift CLI (oc) にログインします。
  2. PersistentVolumeClaim オブジェクトを作成します。

    PersistentVolumeClaim オブジェクトの例

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: lvm-block-1 1
      namespace: default
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Block 2
      resources:
        requests:
          storage: 10Gi 3
        limits:
          storage: 20Gi 4
      storageClassName: lvms-vg1 5

    1
    PVC の名前を指定します。
    2
    ブロック PVC を作成するには、このフィールドを Block に設定します。ファイル PVC を作成するには、このフィールドを Filesystem に設定します。
    3
    ストレージサイズを指定します。値が最小ストレージサイズより小さい場合、要求されるストレージサイズは最小ストレージサイズに切り上げられます。プロビジョニングできる合計ストレージサイズは、Logical Volume Manager (LVM) シンプールのサイズとオーバープロビジョニング係数によって制限されます。
    4
    オプション: ストレージ制限を指定します。このフィールドには、最小ストレージサイズ以上の値を設定します。それ以外の場合、PVC の作成はエラーが発生して失敗します。
    5
    storageClassName フィールドの値は lvms-<device_class_name> の形式である必要があります。ここで、<device_class_name> は、LVMCluster CR の deviceClasses.name フィールドの値になります。たとえば、deviceClasses.name フィールドが vg1 に設定されている場合、storageClassName フィールドを lvms-vg1 に設定する必要があります。
    注記

    ストレージクラスの volumeBindingMode フィールドは WaitForFirstConsumer に設定されます。

  3. 以下のコマンドを実行して PVC を作成します。

    # oc create -f <file_name> -n <application_namespace>
    注記

    作成された PVC は、それらを使用する Pod をデプロイするまで Pending 状態のままになります。

検証

  • PVC が作成されたことを確認するには、次のコマンドを実行します。

    $ oc get pvc -n <namespace>

    出力例

    NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s

4.12.4.7. クラスターのストレージをスケールアップする方法

OpenShift Container Platform は、ベアメタル user-provisioned infrastructure 上のクラスターの追加のワーカーノードをサポートします。クラスターのストレージをスケールアップするには、使用可能なストレージを備えた新しいワーカーノードを追加するか、既存のワーカーノードに新しいデバイスを追加します。

Logical Volume Manager (LVM) Storage は、ノードがアクティブになると、追加のワーカーノードを検出して使用します。

クラスター上の既存のワーカーノードに新しいデバイスを追加するには、LVMCluster カスタムリソース (CR) の deviceSelector フィールドに新しいデバイスへのパスを追加する必要があります。

重要

LVMCluster CR に deviceSelector フィールドを追加できるのは、LVMCluster CR の作成時にのみです。LVMCluster CR の作成時に deviceSelector フィールドを追加しなかった場合は、LVMCluster CR を削除し、deviceSelector フィールドを含む新しい LVMCluster CR を作成する必要があります。

LVMCluster CR に deviceSelector フィールドを追加しない場合、デバイスが利用可能になると、LVM Storage は新しいデバイスを自動的に追加します。

注記

LVM Storage は、サポートされるデバイスのみを追加します。サポートされていないデバイスの詳細は、「LVM ストレージでサポートされていないデバイス」を参照してください。

4.12.4.7.1. CLI を使用したクラスターのストレージのスケールアップ

OpenShift CLI (oc) を使用して、クラスター上のワーカーノードのストレージ容量をスケールアップできます。

前提条件

  • 各クラスターには、Logical Volume Manager (LVM) Storage で使用される追加の未使用デバイスがある。
  • OpenShift CLI (oc) がインストールされている。
  • LVMCluster カスタムリソース (CR) が作成されている。

手順

  1. 次のコマンドを実行して、LVMCluster CR を編集します。

    $ oc edit <lvmcluster_file_name> -n <namespace>
  2. deviceSelector フィールドに新しいデバイスへのパスを追加します。

    LVMCluster CR の例

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
    # ...
          deviceSelector: 1
            paths: 2
            - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            optionalPaths: 3
            - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
    # ...

    1
    LVM ボリュームグループに追加するデバイスへのパスを指定するための設定が含まれています。デバイスパスは、paths フィールド、optionalPaths フィールド、またはその両方で指定できます。pathsoptionalPaths の両方でデバイスパスを指定しない場合、Logical Volume Manager (LVM) Storage は、サポートされている未使用のデバイスを LVM ボリュームグループに追加します。LVM Storage は、次の条件が満たされている場合にのみ、デバイスを LVM ボリュームグループに追加します。
    • デバイスパスが存在する。
    • デバイスが LVM Storage によってサポートされている。サポートされていないデバイスの詳細は、「LVM ストレージでサポートされていないデバイス」を参照してください。
    2
    デバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage でサポートされていない場合、LVMCluster CR が Failed 状態に移行します。
    3
    オプションのデバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage によってサポートされていない場合、LVM Storage はエラーを起こすことなくデバイスを無視します。
    重要

    デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。

  3. LVMCluster CR を保存します。
4.12.4.7.2. Web コンソールを使用したクラスターのストレージのスケールアップ

OpenShift Container Platform Web コンソールを使用して、クラスター上のワーカーノードのストレージ容量をスケールアップできます。

前提条件

  • 各クラスターには、Logical Volume Manager (LVM) Storage で使用される追加の未使用デバイスがある。
  • LVMCluster カスタムリソース (CR) が作成されている。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. openshift-storage namespace で LVM Storage をクリックします。
  4. LVMCluster タブをクリックして、クラスター上に作成された LVMCluster CR を表示します。
  5. Actions メニューから Edit LVMCluster を選択します。
  6. YAML タブをクリックします。
  7. LVMCluster CR を編集して、deviceSelector フィールドに新しいデバイスパスを追加します。

    LVMCluster CR の例

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
    # ...
          deviceSelector: 1
            paths: 2
            - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            optionalPaths: 3
            - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
    # ...

    1
    LVM ボリュームグループに追加するデバイスへのパスを指定するための設定が含まれています。デバイスパスは、paths フィールド、optionalPaths フィールド、またはその両方で指定できます。pathsoptionalPaths の両方でデバイスパスを指定しない場合、Logical Volume Manager (LVM) Storage は、サポートされている未使用のデバイスを LVM ボリュームグループに追加します。LVM Storage は、次の条件が満たされている場合にのみ、デバイスを LVM ボリュームグループに追加します。
    • デバイスパスが存在する。
    • デバイスが LVM Storage によってサポートされている。サポートされていないデバイスの詳細は、「LVM ストレージでサポートされていないデバイス」を参照してください。
    2
    デバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage でサポートされていない場合、LVMCluster CR が Failed 状態に移行します。
    3
    オプションのデバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage によってサポートされていない場合、LVM Storage はエラーを起こすことなくデバイスを無視します。
    重要

    デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。

  8. Save をクリックします。
4.12.4.7.3. RHACM を使用したクラスターのストレージのスケールアップ

RHACM を使用すると、クラスター上のワーカーノードのストレージ容量をスケールアップできます。

前提条件

  • cluster-admin 権限を持つアカウントを使用して RHACM クラスターにアクセスできる。
  • RHACM を使用して LVMCluster カスタムリソース (CR) を作成した。
  • 各クラスターには、Logical Volume Manager (LVM) Storage で使用される追加の未使用デバイスがある。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. 次のコマンドを実行して、RHACM を使用して作成した LVMCluster CR を編集します。

    $ oc edit -f <file_name> -ns <namespace> 1
    1
    <file_name> は、LVMCluster CR の名前に置き換えます。
  3. LVMCluster CR で、deviceSelector フィールドに新しいデバイスへのパスを追加します。

    LVMCluster CR の例

    apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: lvms
          spec:
            object-templates:
               - complianceType: musthave
                 objectDefinition:
                   apiVersion: lvm.topolvm.io/v1alpha1
                   kind: LVMCluster
                   metadata:
                     name: my-lvmcluster
                     namespace: openshift-storage
                   spec:
                     storage:
                       deviceClasses:
    # ...
                         deviceSelector: 1
                           paths: 2
                           - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                           optionalPaths: 3
                           - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
    # ...

    1
    LVM ボリュームグループに追加するデバイスへのパスを指定するための設定が含まれています。デバイスパスは、paths フィールド、optionalPaths フィールド、またはその両方で指定できます。pathsoptionalPaths の両方でデバイスパスを指定しない場合、Logical Volume Manager (LVM) Storage は、サポートされている未使用のデバイスを LVM ボリュームグループに追加します。LVM Storage は、次の条件が満たされている場合にのみ、デバイスを LVM ボリュームグループに追加します。
    • デバイスパスが存在する。
    • デバイスが LVM Storage によってサポートされている。サポートされていないデバイスの詳細は、「LVM ストレージでサポートされていないデバイス」を参照してください。
    2
    デバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage でサポートされていない場合、LVMCluster CR が Failed 状態に移行します。
    3
    オプションのデバイスパスを指定します。このフィールドに指定されたデバイスパスが存在しない場合、またはデバイスが LVM Storage によってサポートされていない場合、LVM Storage はエラーを起こすことなくデバイスを無視します。
    重要

    デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。

  4. LVMCluster CR を保存します。
4.12.4.8. 永続ボリューム要求の拡張

クラスターのストレージをスケールアップした後、既存の永続ボリューム要求 (PVC) を拡張できます。

PVC を拡張するには、PVC 内の storage フィールドを更新する必要があります。

前提条件

  • 動的プロビジョニングが使用される。
  • PVC に関連付けられた StorageClass オブジェクトには、allowVolumeExpansion フィールドが true に設定されています。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、spec.resources.requests.storage フィールドの値を現在の値より大きい値に更新します。

    $ oc patch <pvc_name> -n <application_namespace> -p \ 1
    '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}} --type=merge' 2
    1
    <pvc_name> を、拡張する PVC の名前に置き換えます。
    2
    <desired_size> を、新しいサイズに置き換えて PVC を拡張します。

検証

  • サイズ変更が完了したことを確認するには、次のコマンドを実行します。

    $ oc get pvc <pvc_name> -n <application_namespace> -o=jsonpath={.status.capacity.storage}

    LVM Storage は、拡張中に PVC に Resizing 条件を追加します。PVC の拡張後、Resizing 条件を削除します。

4.12.4.9. 永続ボリューム要求の削除

OpenShift CLI (oc) を使用して、永続ボリューム要求 (PVC) を削除できます。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、PVC を削除します。

    $ oc delete pvc <pvc_name> -n <namespace>

検証

  • PVC が削除されたことを確認するには、次のコマンドを実行します。

    $ oc get pvc -n <namespace>

    削除された PVC は、このコマンドの出力には存在しません。

4.12.4.10. ボリュームスナップショットについて

LVM Storage によってプロビジョニングされる永続ボリューム要求 (PVC) のスナップショットを作成できます。

ボリュームスナップショットを使用して、次のアクションを実行できます。

  • アプリケーションデータをバックアップします。

    重要

    ボリュームスナップショットは元のデータと同じデバイスにあります。ボリュームスナップショットをバックアップとして使用するには、スナップショットを安全な場所に移動する必要があります。OpenShift API for Data Protection (OADP) のバックアップおよび復元ソリューションを使用できます。OADP の詳細は、「OADP の機能」を参照してください。

  • ボリュームスナップショットが作成された状態に戻します。
注記

ボリュームクローンのボリュームスナップショットを作成することもできます。

4.12.4.10.1. マルチノードトポロジーでボリュームスナップショットを作成する場合の制限事項

LVM Storage には、マルチノードトポロジーでのボリュームスナップショットの作成に関して、次の制限があります。

  • ボリュームスナップショットの作成は、LVM シンプール機能に基づいています。
  • ボリュームスナップショットを作成した後、元のデータソースをさらに更新するために、ノードには追加のストレージ領域が必要です。
  • ボリュームスナップショットは、元のデータソースをデプロイしたノード上でのみ作成できます。
  • スナップショットデータを使用する PVC に依存する Pod は、元のデータソースをデプロイしたノードでのみスケジュールできます。

関連情報

4.12.4.10.2. ボリュームスナップショットの作成

シンプールの利用可能な容量とオーバープロビジョニングの制限に基づいて、ボリュームスナップショットを作成できます。ボリュームスナップショットを作成するには、VolumeSnapshotClass オブジェクトを作成する必要があります。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • 永続ボリューム要求 (PVC) が Bound 状態であることが確認されている。これは、一貫性のあるスナップショットに必要です。
  • PVC へのすべての I/O が停止されている。

手順

  1. OpenShift CLI (oc) にログインします。
  2. VolumeSnapshot オブジェクトを作成します。

    VolumeSnapshot オブジェクトの例

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: lvm-block-1-snap 1
    spec:
      source:
        persistentVolumeClaimName: lvm-block-1 2
      volumeSnapshotClassName: lvms-vg1 3

    1
    ボリュームスナップショットの名前を指定します。
    2
    ソース PVC の名前を指定します。LVM Storage は、この PVC のスナップショットを作成します。
    3
    このフィールドをボリュームスナップショットクラスの名前に設定します。
    注記

    使用可能なボリュームスナップショットクラスのリストを取得するには、次のコマンドを実行します。

    $ oc get volumesnapshotclass
  3. 次のコマンドを実行して、ソース PVC を作成した namespace にボリュームスナップショットを作成します。

    $ oc create -f <file_name> -n <namespace>

    LVM Storage は、PVC の読み取り専用コピーをボリュームスナップショットとして作成します。

検証

  • ボリュームスナップショットが作成されたことを確認するには、次のコマンドを実行します。

    $ oc get volumesnapshot -n <namespace>

    出力例

    NAME               READYTOUSE   SOURCEPVC     SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                                    CREATIONTIME   AGE
    lvm-block-1-snap   true         lvms-test-1                           1Gi           lvms-vg1        snapcontent-af409f97-55fc-40cf-975f-71e44fa2ca91   19s            19s

    作成したボリュームスナップショットの READYTOUSE フィールドの値は true である必要があります。

4.12.4.10.3. ボリュームスナップショットの復元

ボリュームスナップショットを復元するには、dataSource.name フィールドをボリュームスナップショットの名前に設定して、永続ボリューム要求 (PVC) を作成する必要があります。

復元される PVC はボリュームスナップショットおよびソース PVC とは切り離されています。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • ボリュームスナップショットが作成されている。

手順

  1. OpenShift CLI (oc) にログインします。
  2. ボリュームスナップショットを復元するための設定を使用して PersistentVolumeClaim オブジェクトを作成します。

    ボリュームスナップショットを復元するための PersistentVolumeClaim オブジェクトの例

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lvm-block-1-restore
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Block
      Resources:
        Requests:
          storage: 2Gi 1
      storageClassName: lvms-vg1 2
      dataSource:
        name: lvm-block-1-snap 3
        kind: VolumeSnapshot
        apiGroup: snapshot.storage.k8s.io

    1
    復元された PVC のストレージサイズを指定します。要求された PVC のストレージサイズは、復元するボリュームスナップショットのストレージサイズ以上である必要があります。より大きな PVC が必要な場合は、ボリュームスナップショットを復元した後に PVC のサイズを変更することもできます。
    2
    このフィールドを、復元するボリュームスナップショットのソース PVC の storageClassName フィールドの値に設定します。
    3
    このフィールドを、復元するボリュームスナップショットの名前に設定します。
  3. 次のコマンドを実行して、ボリュームスナップショットを作成した namespace に PVC を作成します。

    $ oc create -f <file_name> -n <namespace>

検証

  • ボリュームスナップショットが復元されたことを確認するには、次のコマンドを実行します。

    $ oc get pvc -n <namespace>

    出力例

    NAME                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1-restore   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s

4.12.4.10.4. ボリュームスナップショットの削除

永続ボリューム要求 (PVC) のボリュームスナップショットを削除できます。

重要

永続ボリューム要求 (PVC) を削除すると、LVM Storage は永続ボリューム要求のみを削除し、永続ボリューム要求のスナップショットは削除しません。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • 削除するボリュームスナップショットが使用されていないことを確認している。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、ボリュームのスナップショットを削除します。

    $ oc delete volumesnapshot <volume_snapshot_name> -n <namespace>

検証

  • ボリュームスナップショットが削除されたことを確認するには、次のコマンドを実行します。

    $ oc get volumesnapshot -n <namespace>

    削除されたボリュームのスナップショットは、このコマンドの出力には存在しません。

4.12.4.11. ボリュームクローンについて

ボリュームクローンは、既存の永続ボリューム要求 (PVC) の複製です。ボリュームクローンを作成して、データのポイントインタイムコピーを作成できます。

4.12.4.11.1. マルチノードトポロジーでボリュームクローンを作成する場合の制限事項

LVM Storage には、マルチノードトポロジーでのボリュームクローンの作成に関して、次の制限があります。

  • ボリュームクローンの作成は、LVM シンプール機能に基づいています。
  • ボリュームクローンを作成した後、元のデータソースをさらに更新するには、ノードに追加のストレージが必要です。
  • ボリュームクローンは、元のデータソースをデプロイしたノード上でのみ作成できます。
  • クローンデータを使用する PVC に依存する Pod は、元のデータソースをデプロイしたノード上でのみスケジュールできます。
4.12.4.11.2. ボリュームクローンの作成

永続ボリューム要求 (PVC) のクローンを作成するには、ソース永続ボリューム要求を作成した namespace に PersistentVolumeClaim オブジェクトを作成する必要があります。

重要

クローン作成された PVC には書き込みアクセス権限があります。

前提条件

  • ソース PVC が Bound 状態であることが確認されている。これは一貫性のあるクローンに必要です。

手順

  1. OpenShift CLI (oc) にログインします。
  2. PersistentVolumeClaim オブジェクトを作成します。

    ボリュームクローンを作成するための PersistentVolumeClaim オブジェクトの例

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lvm-pvc-clone
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: lvms-vg1 1
      volumeMode: Filesystem 2
      dataSource:
        kind: PersistentVolumeClaim
        name: lvm-pvc 3
      resources:
        requests:
          storage: 1Gi 4

    1
    このフィールドを、ソース PVC の storageClassName フィールドの値に設定します。
    2
    このフィールドを、ソース PVC の volumeMode フィールドに設定します。
    3
    ソース PVC の名前を指定します。
    4
    クローン作成された PVC のストレージサイズを指定します。クローン作成された PVC のストレージサイズは、ソース PVC のストレージサイズ以上である必要があります。
  3. 次のコマンドを実行して、ソース PVC を作成した namespace に PVC を作成します。

    $ oc create -f <file_name> -n <namespace>

検証

  • ボリュームクローンが作成されたことを確認するには、次のコマンドを実行します。

    $ oc get pvc -n <namespace>

    出力例

    NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1-clone   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s

4.12.4.11.3. ボリュームクローンの削除

ボリュームクローンを削除できます。

重要

永続ボリューム要求 (PVC) を削除すると、LVM Storage はソース永続ボリューム要求のみを削除し、永続ボリューム要求のクローンは削除しません。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、クローン作成された PVC を削除します。

    # oc delete pvc <clone_pvc_name> -n <namespace>

検証

  • ボリュームクローンが削除されたことを確認するには、次のコマンドを実行します。

    $ oc get pvc -n <namespace>

    削除されたボリュームクローンは、このコマンドの出力には存在しません。

4.12.4.12. LVM Storage の更新

LVM Storage を更新して、OpenShift Container Platform バージョンとの互換性を確保できます。

前提条件

  • OpenShift Container Platform クラスターが更新されている。
  • 以前のバージョンの LVM Storage がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを実行して、LVM Storage のインストール時に作成した Subscription カスタムリソース (CR) を更新します。

    $ oc patch subscription lvms-operator -n openshift-storage --type merge --patch '{"spec":{"channel":"<update_channel>"}}' 1
    1
    <update_channel> を、インストールする LVM Storage のバージョンに置き換えます。たとえば、stable-4.16 などです。
  3. 次のコマンドを実行して、更新イベントを表示し、インストールが完了していることを確認します。

    $ oc get events -n openshift-storage

    出力例

    ...
    8m13s       Normal    RequirementsUnknown   clusterserviceversion/lvms-operator.v4.16   requirements not yet checked
    8m11s       Normal    RequirementsNotMet    clusterserviceversion/lvms-operator.v4.16   one or more requirements couldn't be found
    7m50s       Normal    AllRequirementsMet    clusterserviceversion/lvms-operator.v4.16   all requirements found, attempting install
    7m50s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.16   waiting for install components to report healthy
    7m49s       Normal    InstallWaiting        clusterserviceversion/lvms-operator.v4.16   installing: waiting for deployment lvms-operator to become ready: deployment "lvms-operator" waiting for 1 outdated replica(s) to be terminated
    7m39s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.16   install strategy completed with no errors
    ...

検証

  • 次のコマンドを実行して、LVM Storage のバージョンを確認します。

    $ oc get subscription lvms-operator -n openshift-storage -o jsonpath='{.status.installedCSV}'

    出力例

    lvms-operator.v4.16

4.12.4.13. LVM Storage の監視

クラスターモニタリングを有効にするには、LVM Storage をインストールした namespace に次のラベルを追加する必要があります。

openshift.io/cluster-monitoring=true
重要

RHACM でクラスターモニタリングを有効化する方法の詳細は、可観測性カスタムメトリクスの追加 を参照してください。

4.12.4.13.1. メトリクス

メトリクスを表示することで、LVM Storage を監視できます。

次の表は、topolvm メトリクスを説明しています。

表4.7 topolvm メトリクス
アラート設定

topolvm_thinpool_data_percent

LVM シンプールで使用されているデータ領域の割合を示します。

topolvm_thinpool_metadata_percent

LVM シンプールで使用されているメタデータ領域の割合を示します。

topolvm_thinpool_size_bytes

LVM シンプールのサイズをバイト単位で示します。

topolvm_volumegroup_available_bytes

LVM ボリュームグループ内の利用可能な領域をバイト単位で示します。

topolvm_volumegroup_size_bytes

LVM ボリュームグループのサイズをバイト単位で示します。

topolvm_thinpool_overprovisioned_available

LVM シンプールの利用可能なオーバープロビジョニングサイズをバイト単位で示します。

注記

メトリクスは 10 分ごとに、または変更 (シンプールに新しい論理ボリュームが作成されるなど) があったときに更新されます。

4.12.4.13.2. アラート

シンプールとボリュームグループが最大ストレージ容量に達すると、それ以降の操作は失敗します。これにより、データ損失が発生する可能性があります。

LVM Storage は、シンプールとボリュームグループの使用量が特定の値を超えると、次のアラートを送信します。

表4.8 LVM Storage アラート
アラート設定

VolumeGroupUsageAtThresholdNearFull

このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 75% を超えるとトリガーされます。データの削除またはボリュームグループの拡張が必要です。

VolumeGroupUsageAtThresholdCritical

このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 85% を超えるとトリガーされます。この場合、ボリュームグループは、かなりいっぱいになっています。データの削除またはボリュームグループの拡張が必要です。

ThinPoolDataUsageAtThresholdNearFull

このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolDataUsageAtThresholdCritical

このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolMetaDataUsageAtThresholdNearFull

このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolMetaDataUsageAtThresholdCritical

このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

4.12.4.14. CLI を使用した LVM Storage のインストール

OpenShift CLI (oc) を使用して LVM ストレージをアンインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとして oc にログインしている。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
  • LVMCluster カスタムリソース (CR) が削除されている。

手順

  1. 次のコマンドを実行して、LVM Storage Operator の currentCSV の値を取得します。

    $ oc get subscription.operators.coreos.com lvms-operator -n <namespace> -o yaml | grep currentCSV

    出力例

    currentCSV: lvms-operator.v4.15.3

  2. 次のコマンドを実行して、サブスクリプションを削除します。

    $ oc delete subscription.operators.coreos.com lvms-operator -n <namespace>

    出力例

    subscription.operators.coreos.com "lvms-operator" deleted

  3. 次のコマンドを実行して、ターゲット namespace 内の LVM Storage Operator の CSV を削除します。

    $ oc delete clusterserviceversion <currentCSV> -n <namespace> 1
    1
    <currentCSV> は、LVM Storage Operator の currentCSV 値に置き換えます。

    出力例

    clusterserviceversion.operators.coreos.com "lvms-operator.v4.15.3" deleted

検証

  • LVM Storage Operator がアンインストールされたことを確認するには、次のコマンドを実行します。

    $ oc get csv -n <namespace>

    LVM Storage Operator が正常にアンインストールされた場合、このコマンドの出力には表示されません。

4.12.4.15. Web コンソールを使用した LVM ストレージのアンインストール

OpenShift Container Platform Web コンソールを使用して LVM Storage をアンインストールできます。

前提条件

  • cluster-admin パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
  • LVMCluster カスタムリソース (CR) が削除されている。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. openshift-storage namespace で LVM Storage をクリックします。
  4. Details タブをクリックします。
  5. Actions メニューから、Uninstall Operator を選択します。
  6. オプション: プロンプトが表示されたら、Delete all operand instances for this operator チェックボックスを選択して、LVM Storage のオペランドインスタンスを削除します。
  7. Uninstall をクリックします。
4.12.4.16. RHACM を使用してインストールされた LVM Storage のアンインストール

RHACM を使用してインストールした LVM Storage をアンインストールするには、LVM Storage のインストールと設定用に作成した RHACM Policy カスタムリソース (CR) を削除する必要があります。

前提条件

  • cluster-admin 権限を持つユーザーとして RHACM クラスターにアクセスできる。
  • LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
  • RHACM を使用して作成した LVMCluster CR を削除した。

手順

  1. OpenShift CLI (oc) にログインします。
  2. 次のコマンドを使用して、LVM Storage のインストールと設定用に作成した RHACM Policy CR を削除します。

    $ oc delete -f <policy> -n <namespace> 1
    1
    <policy> は、Policy CR YAML ファイルの名前に置き換えます。
  3. LVM Storage をアンインストールするための設定を含む Policy CR YAML ファイルを作成します。

    LVM Storage をアンインストールするための Policy CR の例

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-uninstall-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-uninstall-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-uninstall-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: uninstall-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: uninstall-lvms
    spec:
      disabled: false
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: uninstall-lvms
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  name: openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms-operator
                  namespace: openshift-storage
            remediationAction: enforce
            severity: low
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: policy-remove-lvms-crds
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: logicalvolumes.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmclusters.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroupnodestatuses.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroups.lvm.topolvm.io
            remediationAction: enforce
            severity: high

  4. 次のコマンドを実行して Policy CR を作成します。

    $ oc create -f <policy> -ns <namespace>
4.12.4.17. must-gather を使用したログファイルおよび診断情報のダウンロード

LVM Storage が問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、ユーザーまたは Red Hat サポートが問題を確認して解決策を決定できるようにします。

手順

  • LVM Storage クラスターに接続されているクライアントから must-gather コマンドを実行します。

    $ oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel9:v4.16 --dest-dir=<directory_name>
4.12.4.18. 永続ストレージのトラブルシューティング

論理ボリュームマネージャー (LVM) ストレージを使用して永続ストレージを設定するときに、トラブルシューティングが必要ないくつかの問題が発生する可能性があります。

4.12.4.18.1. 保留状態でスタックしている PVC を調査する

永続ボリューム要求 (PVC) は、次の理由により Pending 状態のままになることがあります。

  • コンピューティングリソースが足りない
  • ネットワークの問題
  • ストレージクラスまたはノードセレクターが一致していない
  • 利用可能な永続ボリューム (PV) がない
  • PV を持つノードが Not Ready 状態にある

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift CLI (oc) にログインしている。

手順

  1. 次のコマンドを実行して、PVC のリストを取得します。

    $ oc get pvc

    出力例

    NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvms-test   Pending                                      lvms-vg1       11s

  2. 次のコマンドを実行して、Pending 状態のままになっている PVC に関連するイベントを検査します。

    $ oc describe pvc <pvc_name> 1
    1
    <pvc_name> を PVC の名前に置き換えます。たとえば、lvms-vg1 です。

    出力例

    Type     Reason              Age               From                         Message
    ----     ------              ----              ----                         -------
    Warning  ProvisioningFailed  4s (x2 over 17s)  persistentvolume-controller  storageclass.storage.k8s.io "lvms-vg1" not found

4.12.4.18.2. ストレージクラスがない状態からの回復

storage class not found というエラーが発生した場合は、LVMCluster カスタムリソース (CR) をチェックし、すべての論理ボリュームマネージャー (LVM) ストレージ Pod が Running 状態であることを確認します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift CLI (oc) にログインしている。

手順

  1. 以下のコマンドを実行して、LVMCluster CR が存在することを確認します。

    $ oc get lvmcluster -n openshift-storage

    出力例

    NAME            AGE
    my-lvmcluster   65m

  2. LVMCluster CR が存在しない場合は、LVMCluster CR を作成します。詳細は、「LVMCluster カスタムリソースを作成する方法」を参照してください。
  3. openshift-storage namespace で、次のコマンドを実行して、すべての LVM ストレージ Pod が Running 状態であることを確認します。

    $ oc get pods -n openshift-storage

    出力例

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    vg-manager-r6zdv                      1/1     Running   0             66m

    このコマンドの出力には、以下の Pod の実行中のインスタンスが含まれている必要があります。

    • lvms-operator
    • vg-manager

      設定ファイルの読み込み中に vg-manager Pod が停止する場合は、LVM ストレージが使用できるディスクが見つからないことが原因です。この問題のトラブルシューティングに必要な情報を取得するには、以下のコマンドを実行して vg-manager Pod のログを確認します。

      $ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage
4.12.4.18.3. ノード障害からの回復

クラスター内のノード障害が原因で、永続ボリューム要求 (PVC) が Pending 状態のままになることがあります。

障害が発生したノードを特定するには、topolvm-node Pod の再起動回数を調べることができます。再起動回数の増加は、基礎となるノードに潜在的な問題があることを示しており、さらなる調査とトラブルシューティングが必要になる場合があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift CLI (oc) にログインしている。

手順

  • 次のコマンドを実行して、topolvm-node Pod インスタンスの再起動回数を調べます。

    $ oc get pods -n openshift-storage

    出力例

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    topolvm-node-54as8                    4/4     Running   0             66m
    topolvm-node-78fft                    4/4     Running   17 (8s ago)   66m
    vg-manager-r6zdv                      1/1     Running   0             66m
    vg-manager-990ut                      1/1     Running   0             66m
    vg-manager-an118                      1/1     Running   0             66m

次のステップ

  • ノードの問題を解決した後も PVC が Pending 状態のままになっている場合は、強制クリーンアップを実行する必要があります。詳細は、「強制クリーンアップの実行」を参照してください。
4.12.4.18.4. ディスク障害からの回復

永続ボリューム要求 (PVC) に関連するイベントの検査中にエラーメッセージが表示された場合は、基になるボリュームまたはディスクに問題がある可能性があります。

ディスクおよびボリュームのプロビジョニングの問題が発生すると、Failed to provision volume with storage class <storage_class_name> などの一般的なエラーメッセージが表示されます。一般的なエラーメッセージの後には、特定のボリューム障害のエラーメッセージが続きます。

以下の表は、ボリューム障害のエラーメッセージを説明しています。

表4.9 ボリューム障害のエラーメッセージ
エラーメッセージ設定

Failed to check volume existence

ボリュームがすでに存在するかどうかを確認する際に問題が発生したことを示します。ボリューム検証の失敗は、ネットワーク接続の問題やその他の障害によって発生する可能性があります。

Failed to bind volume

使用可能な永続ボリューム (PV) が PVC の要件と一致しない場合、ボリュームのバインドに失敗する可能性があります。

FailedMount または FailedAttachVolume

このエラーは、ボリュームをノードにマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。

FailedUnMount

このエラーは、ノードからボリュームをアンマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。

Volume is already exclusively attached to one node and cannot be attached to another

このエラーは、ReadWriteMany アクセスモードをサポートしていないストレージソリューションで発生する可能性があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift CLI (oc) にログインしている。

手順

  1. 次のコマンドを実行して、PVC に関連付けられたイベントを検査します。

    $ oc describe pvc <pvc_name> 1
    1
    <pvc_name> を PVC の名前に置き換えます。
  2. 問題が発生しているホストへの直接接続を確立します。
  3. ディスクの問題を解決します。

次のステップ

  • ディスクの問題を解決した後もボリューム障害メッセージが続く場合や再発する場合は、強制クリーンアップを実行する必要があります。詳細は、「強制クリーンアップの実行」を参照してください。
4.12.4.18.5. 強制クリーンアップの実行

トラブルシューティング手順を完了した後もディスクまたはノード関連の問題が解決しない場合は、強制クリーンアップを実行する必要があります。強制クリーンアップは、永続的な問題に対処し、論理ボリュームマネージャー (LVM) ストレージが確実に適切に機能するために使用されます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift CLI (oc) にログインしている。
  • LVM ストレージを使用して作成されたすべての永続ボリューム要求 (PVC) が削除されている。
  • LVM ストレージを使用して作成された PVC を使用している Pod を停止している。

手順

  1. 次のコマンドを実行して、openshift-storage namespace に切り替えます。

    $ oc project openshift-storage
  2. 以下のコマンドを実行して、LogicalVolume カスタムリソース (CR) が存在するか確認します。

    $ oc get logicalvolume
    1. LogicalVolume CR が存在する場合は、以下のコマンドを実行して削除します。

      $ oc delete logicalvolume <name> 1
      1
      <name>LogicalVolume CR の名前に置き換えます。
    2. LogicalVolume CR を削除した後、以下のコマンドを実行してファイナライザーを削除します。

      $ oc patch logicalvolume <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
      1
      <name>LogicalVolume CR の名前に置き換えます。
  3. 以下のコマンドを実行して、LVMVolumeGroup CR が存在するか確認します。

    $ oc get lvmvolumegroup
    1. LVMVolumeGroup CR が存在する場合は、以下のコマンドを実行して削除します。

      $ oc delete lvmvolumegroup <name> 1
      1
      <name>LVMVolumeGroup CR の名前に置き換えます。
    2. LVMVolumeGroup CR を削除した後、以下のコマンドを実行してファイナライザーを削除します。

      $ oc patch lvmvolumegroup <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
      1
      <name>LVMVolumeGroup CR の名前に置き換えます。
  4. 以下のコマンドを実行して、LVMVolumeGroupNodeStatus CR を削除します。

    $ oc delete lvmvolumegroupnodestatus --all
  5. 次のコマンドを実行して、LVMCluster CR を削除します。

    $ oc delete lvmcluster --all
    1. LVMCluster CR を削除した後、以下のコマンドを実行してファイナライザーを削除します。

      $ oc patch lvmcluster <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
      1
      <name>LVMCluster CR の名前に置き換えます。

第5章 Container Storage Interface (CSI) の使用

5.1. CSI ボリュームの設定

Container Storage Interface (CSI) により、OpenShift Container Platform は CSI インターフェイス を永続ストレージとして実装するストレージバックエンドからストレージを使用できます。

注記

OpenShift Container Platform 4.16 は、CSI 仕様 のバージョン 1.6.0 をサポートします。

5.1.1. CSI アーキテクチャー

CSI ドライバーは通常、コンテナーイメージとして提供されます。これらのコンテナーは、実行先の OpenShift Container Platform を認識しません。OpenShift Container Platform でサポートされる CSI 互換のストレージバックエンドを使用するには、クラスター管理者は、OpenShift Container Platform とストレージドライバーの橋渡しとして機能するコンポーネントを複数デプロイする必要があります。

以下の図では、OpenShift Container Platform クラスターの Pod で実行されるコンポーネントの俯瞰図を示しています。

CSI コンポーネントのアーキテクチャー

異なるストレージバックエンドに対して複数の CSI ドライバーを実行できます。各ドライバーには、独自の外部コントローラーのデプロイメントおよびドライバーと CSI レジストラーを含むデーモンセットが必要です。

5.1.1.1. 外部の CSI コントローラー

外部の CSI コントローラーは、5 つのコンテナーを含む 1 つまたは複数の Pod を配置するデプロイメントです。

  • スナップショットコンテナーは、VolumeSnapshot オブジェクトおよび VolumeSnapshotContent オブジェクトを監視し、VolumeSnapshotContent オブジェクトの作成および削除を担当します。
  • リサイザーコンテナーは、PersistentVolumeClaim オブジェクトでより多くのストレージを要求した場合に、PersistentVolumeClaim の更新を監視し、CSI エンドポイントに対して ControllerExpandVolume 操作をトリガーするサイドカーコンテナーです。
  • OpenShift Container Platform からの attach および detach の呼び出しを適切な CSI ドライバーへの ControllerPublish および ControllerUnpublish 呼び出しに変換する外部の CSI アタッチャーコンテナー。
  • OpenShift Container Platform からの provision および delete 呼び出しを適切な CSI ドライバーへの CreateVolume および DeleteVolume 呼び出しに変換する外部の CSI プロビジョナーコンテナー。
  • CSI ドライバーコンテナー。

CSI アタッチャーおよび CSI プロビジョナーコンテナーは、Unix Domain Socket を使用して、CSI ドライバーコンテナーと通信し、CSI の通信が Pod 外に出ないようにします。CSI ドライバーは Pod 外からはアクセスできません。

注記

通常、attachdetachprovision、および delete 操作では、CSI ドライバーがストレージバックエンドに対する認証情報を使用する必要があります。CSI コントローラー Pod をインフラストラクチャーノードで実行し、コンピュートノードで致命的なセキュリティー違反が発生した場合でも認証情報がユーザープロセスに漏洩されないようにします。

注記

外部のアタッチャーは、サードパーティーの attach または detach 操作をサポートしない CSI ドライバーに対しても実行する必要があります。外部のアタッチャーは、CSI ドライバーに対して ControllerPublish または ControllerUnpublish 操作を実行しません。ただし、必要な OpenShift Container Platform 割り当て API を実装できるように依然として実行する必要があります。

5.1.1.2. CSI ドライバーのデーモンセット

CSI ドライバーのデーモンセットは、OpenShift Container Platform が CSI ドライバーによって提供されるストレージをノードにマウントして、永続ボリューム (PV) としてユーザーワークロード (Pod) で使用できるように、全ノードで Pod を実行します。CSI ドライバーがインストールされた Pod には、以下のコンテナーが含まれます。

  • ノード上で実行中の openshift-node サービスに CSI ドライバーを登録する CSI ドライバーレジストラー。このノードで実行中の openshift-node プロセスは、ノードで利用可能な UNIX Domain Socket を使用して CSI ドライバーに直接接続します。
  • CSI ドライバー

ノードにデプロイされた CSI ドライバーには、ストレージバックエンドへの認証情報をできる限り少なく指定する必要があります。OpenShift Container Platform は、NodePublish/NodeUnpublish および NodeStage/NodeUnstage (実装されている場合) などの CSI 呼び出しのノードプラグインセットのみを使用します。

5.1.2. OpenShift Container Platform でサポートされる CSI ドライバー

OpenShift Container Platform はデフォルトで特定の CSI ドライバーをインストールし、インツリーボリュームプラグインでは不可能なユーザーストレージオプションを提供します。

これらのサポートされるストレージアセットにマウントする CSI でプロビジョニングされた永続ボリュームを作成するには、OpenShift Container Platform は必要な CSI Driver Operator、CSI ドライバー、および必要なストレージクラスをインストールします。Operator およびドライバーのデフォルト namespace の詳細は、特定の CSI Driver Operator のドキュメントを参照してください。

重要

AWS EFS および GCP Filestore CSI ドライバーは、デフォルトではインストールされないため、手動でインストールする必要があります。AWS EFS CSI ドライバーのインストール手順は、AWS Elastic File Service CSI Driver Operator のセットアップ を参照してください。GCP Filestore CSI ドライバーのインストール手順については、Google Compute Platform Filestore CSI Driver Operator を参照してください。

以下の表は、OpenShift Container Platform でサポートされる OpenShift Container Platform とともにインストールされる CSI ドライバーと、ボリュームスナップショットやサイズ変更などのサポート対象 CSI 機能を説明します。

重要

CSI ドライバーが以下の表に記載されていない場合は、CSI ストレージベンダーが提供するインストール手順に従って、サポートされている CSI 機能を使用する必要があります。

表5.1 OpenShift Container Platform でサポートされる CSI ドライバーおよび機能
CSI ドライバーCSI ボリュームスナップショットCSI のクローン作成CSI のサイズ変更インラインの一時ボリューム

AWS EBS

 ✅

 ✅

AWS EFS

Google Compute Platform (GCP) persistent disk (PD)

  ✅

  ✅

 ✅

GCP Filestore

 ✅

 ✅

IBM Power® 仮想サーバーブロック

 ✅

IBM Cloud® Block

 ✅[3]

 ✅[3]

LVM Storage

 ✅

 ✅

 ✅

Microsoft Azure Disk

 ✅

 ✅

 ✅

Microsoft Azure Stack Hub

 ✅

 ✅

 ✅

Microsoft Azure File

 ✅[4]

 ✅

 ✅

OpenStack Cinder

 ✅

 ✅

 ✅

OpenShift Data Foundation

 ✅

 ✅

 ✅

OpenStack Manila

 ✅

Shared Resource

 ✅

CIFS/SMB

 ✅

VMware vSphere

 ✅[1]

 ✅[2]

1.

  • vCenter Server と ESXi の両方に、vSphere バージョン 7.0 Update 3 以降が必要です。
  • ファイル共有ボリュームはサポートされません。

2.

  • オフラインボリューム拡張: 必要な vSphere の最低バージョンは 6.7 Update 3 P06 です。
  • オンラインボリューム拡張: 必要な vSphere の最低バージョンは 7.0 Update 2 です。

3.

  • オフラインスナップショットまたはサイズ変更はサポートされていません。ボリュームは、実行中の Pod にアタッチする必要があります。

4.

  • Azure ファイルのクローン作成では、NFS プロトコルはサポートされません。SMB プロトコルを使用する azurefile-csi ストレージクラスをサポートします。
  • Azure ファイルのクローン作成はテクノロジープレビュー機能です。
重要

Azure File CSI クローン作成はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

5.1.3. 動的プロビジョニング

永続ストレージの動的プロビジョニングは、CSI ドライバーおよび基礎となるストレージバックエンドの機能により異なります。CSI ドライバーのプロバイダーは、OpenShift Container Platform でのストレージクラスの作成方法および設定に利用でじるパラメーターに関する文書を作成する必要があります。

作成されたストレージクラスは、動的プロビジョニングを有効にするために設定できます。

手順

  • デフォルトのストレージクラスを作成します。 これにより、特殊なストレージクラスを必要としないすべての PVC がインストールされた CSI ドライバーでプロビジョニングされます。

    # oc create -f - << EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class> 1
      annotations:
        storageclass.kubernetes.io/is-default-class: "true"
    provisioner: <provisioner-name> 2
    parameters:
    EOF
    1
    作成されるストレージクラスの名前。
    2
    インストールされている CSI ドライバーの名前。

5.1.4. CSI ドライバーの使用例

以下の例では、テンプレートを変更せずにデフォルトの MySQL テンプレートをインストールします。

前提条件

  • CSI ドライバーがデプロイされている。
  • 動的プロビジョニング用にストレージクラスが作成されている。

手順

  • MySQL テンプレートを作成します。

    # oc new-app mysql-persistent

    出力例

    --> Deploying template "openshift/mysql-persistent" to project default
    ...

    # oc get pvc

    出力例

    NAME              STATUS    VOLUME                                   CAPACITY
    ACCESS MODES   STORAGECLASS   AGE
    mysql             Bound     kubernetes-dynamic-pv-3271ffcb4e1811e8   1Gi
    RWO            cinder         3s

5.1.5. ボリュームポピュレーター

ボリュームポピュレーターは、永続ボリュームクレーム (PVC) 仕様の datasource フィールドを使用して、事前に入力されたボリュームを作成します。

ボリュームの作成は現在有効になっており、テクノロジープレビュー機能としてサポートされています。ただし、OpenShift Container Platform にはボリュームポピュレーターは同梱されていません。

重要

ボリュームポピュレーターはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

ボリュームポピュレーターの詳細は、Kubernetes ボリュームポピュレーター を参照してください。

5.2. CSI インラインの一時ボリューム

Container Storage Interface (CSI) のインライン一時ボリュームを使用すると、Pod のデプロイ時にインラインの一時ボリュームを作成し、Pod の破棄時にそれらを削除する Pod 仕様を定義できます。

この機能は、サポートされている Container Storage Interface (CSI) ドライバーでのみ利用できます。

  • Shared Resource CSI ドライバー
  • Azure File CSI ドライバー
  • Secrets Store CSI ドライバー

5.2.1. CSI インラインの一時ボリュームの概要

従来は、Container Storage Interface (CSI) ドライバーでサポートされるボリュームは PersistentVolume および PersistentVolumeClaim オブジェクトの組み合わせでのみ使用できます。

この機能により、PersistentVolume オブジェクトではなく、Pod 仕様に CSI ボリュームを直接指定できます。インラインボリュームは一時的なボリュームであり、Pod の再起動後は永続化されません。

5.2.1.1. サポートの制限

デフォルトで、OpenShift Container Platform は以下の制限下で CSI インラインの一時ボリュームのクローン作成をサポートします。

  • サポートは CSI ドライバーでのみ利用可能です。インツリーおよび FlexVolumes はサポートされません。
  • 共有リソース CSI ドライバーは、テクノロジープレビュー機能として、複数の namespace にまたがる Secrets または ConfigMap にアクセスするためだけに、インラインのエフェメラルボリュームを使用することをサポートします。
  • コミュニティーまたはストレージベンダーは、これらのボリュームをサポートする他の CSI ドライバーを提供します。CSI ドライバーのプロバイダーが提供するインストール手順に従います。

CSI ドライバーは、Ephemeral 機能を含む、インラインボリューム機能を実装していない可能性があります。詳細は、CSI ドライバーのドキュメントを参照してください。

重要

Shared Resource CSI Driver は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

5.2.2. CSI Volume Admission プラグイン

Container Storage Interface (CSI) Volume Admission プラグインを使用すると、Pod アドミッション時に CSI 一時ボリュームをプロビジョニングできる個別の CSI ドライバーの使用を制限できます。管理者は csi-ephemeral-volume-profile ラベルを追加できます。このラベルは Admission プラグインによって検査され、施行、警告、監査の決定に使用されます。

5.2.2.1. 概要

CSI Volume Admission プラグインを使用するには、管理者は security.openshift.io/csi-ephemeral-volume-profile ラベルを CSIDriver オブジェクトに追加します。これは、CSI 一時ボリュームを提供するために使用される CSI ドライバーの有効な Pod セキュリティープロファイルを次のように宣言します。次の例に示されています。

kind: CSIDriver
metadata:
  name: csi.mydriver.company.org
  labels:
    security.openshift.io/csi-ephemeral-volume-profile: restricted 1
1
csi-ephemeral-volume-profile ラベルが restricted に設定された CSI ドライバーオブジェクト YAML ファイル

この有効なプロファイルは、Pod の namespace が Pod のセキュリティー標準によって管理されている場合に、Pod が CSI ドライバーを使用して CSI 一時ボリュームをマウントできることを伝えます。

CSI Volume Admission プラグインは、Pod の作成時に Pod ボリュームを検査します。CSI ボリュームを使用する既存の Pod は影響を受けません。Pod がコンテナーストレージインターフェイス (CSI) ボリュームを使用する場合、プラグインは CSIDriver オブジェクトを検索して csi-ephemeral-volume-profile ラベルを検査し、そのラベルの値を適用、警告、および監査の決定に使用します。

5.2.2.2. Pod セキュリティープロファイルの適用

CSI ドライバーに csi-ephemeral-volume-profile ラベルが付いている場合、CSI ドライバーを使用して CSI 一時ボリュームをマウントする Pod は、同等以上のアクセス許可の Pod セキュリティー標準を強制する namespace で実行する必要があります。namespace がより制限的な標準を適用する場合、CSI Volume Admission プラグインは受付を拒否します。以下の表は、指定のラベル値に対するさまざまな Pod セキュリティープロファイルの適用動作を説明しています。

表5.2 Pod セキュリティープロファイルの適用
Pod セキュリティープロファイルドライバーラベル: restrictedドライバーラベル: baselineドライバーラベル: privileged

Restricted

Allowed

Denied

Denied

Baseline

Allowed

Allowed

Denied

Privileged

Allowed

Allowed

Allowed

5.2.2.3. Pod セキュリティープロファイルの警告

CSI Volume Admission プラグインは、CSI ドライバーの有効なプロファイルが Pod namespace の Pod セキュリティー警告プロファイルよりも許容度が高い場合に警告できます。次の表は、指定されたラベル値のさまざまな Pod セキュリティープロファイルで警告がいつ発生するかを示しています。

表5.3 Pod セキュリティープロファイルの警告
Pod セキュリティープロファイルドライバーラベル: restrictedドライバーラベル: baselineドライバーラベル: privileged

Restricted

No warning

Warning

Warning

Baseline

No warning

No warning

Warning

Privileged

No warning

No warning

No warning

5.2.2.4. Pod セキュリティープロファイル監査

CSI ボリュームの受付プラグインは、CSI ドライバーの有効なプロファイルが Pod namespace の Pod セキュリティー監査プロファイルよりも許容されている場合に、監査アノテーションを Pod に適用できます。以下の表は、指定のラベル値のさまざまな Pod セキュリティープロファイルに適用される監査アノテーションを示しています。

表5.4 Pod セキュリティープロファイル監査
Pod セキュリティープロファイルドライバーラベル: restrictedドライバーラベル: baselineドライバーラベル: privileged

Restricted

No audit

Audit

Audit

Baseline

No audit

No audit

Audit

Privileged

No audit

No audit

No audit

5.2.2.5. CSI Volume Admission プラグインのデフォルト動作

CSI エフェメラルボリュームの参照 CSI ドライバーに csi-ephemeral-volume-profile ラベルがない場合、CSI Volume Admission プラグインは、ドライバーに強制、警告、および監査動作用の特権プロファイルがあると見なされます。同様に、Pod の namespace に Pod セキュリティーアドミッションラベルが設定されていない場合、受付プラグインは restricted プロファイルが強制、警告、および監査の決定について許可されていると見なします。そのため、ラベルが設定されていない場合、その CSI ドライバーを使用する CSI 一時ボリュームはデフォルトで特権付き namespace でのみ利用できます。

OpenShift Container Platform に同梱され、一時ボリュームをサポートする CSI ドライバーには、csi-ephemeral-volume-profile ラベルの妥当なデフォルトセットがあります。

  • Shared Resource CSI ドライバー: restricted
  • Azure File CSI ドライバー: privileged

管理者は、必要に応じてラベルのデフォルト値を変更できます。

5.2.3. Pod 仕様への CSI インライン一時ボリュームの埋め込み

CSI インラインの一時ボリュームを OpenShift Container Platform の Pod 仕様に埋め込むことができます。ランタイム時に、ネストされたインラインボリュームは、関連付けられた Pod の一時的なライフサイクルに従うため、CSI ドライバーは Pod の作成および破棄時にボリューム操作のすべてのフェーズをすべて処理できます。

手順

  1. Pod オブジェクト定義を作成し、これをファイルに保存します。
  2. CSI インラインの一時ボリュームをファイルに埋め込みます。

    my-csi-app.yaml

    kind: Pod
    apiVersion: v1
    metadata:
      name: my-csi-app
    spec:
      containers:
        - name: my-frontend
          image: busybox
          volumeMounts:
          - mountPath: "/data"
            name: my-csi-inline-vol
          command: [ "sleep", "1000000" ]
      volumes: 1
        - name: my-csi-inline-vol
          csi:
            driver: inline.storage.kubernetes.io
            volumeAttributes:
              foo: bar

    1
    Pod で使用されるボリュームの名前。
  3. 直前のステップで保存したオブジェクト定義ファイルを作成します。

    $ oc create -f my-csi-app.yaml

5.2.4. 関連情報

5.3. Shared Resource CSI Driver Operator

クラスター管理者は、OpenShift Container Platform で Shared Resource CSI Driver を使用して、Secret または ConfigMap オブジェクトの内容が含まれるインライン一時ボリュームをプロビジョニングできます。これにより、ボリュームマウントを公開する Pod および他の Kubernetes タイプ、ならびに OpenShift Container Platform Builds は、クラスター内の namespace 全体でそれらのオブジェクトの内容を安全に使用できます。そのために、現在、SharedSecret カスタムリソース (Secret オブジェクト用) および SharedConfigMap カスタムリソース ConfigMap オブジェクト用) という 2 種類の共有リソースがあります。

重要

Shared Resource CSI Driver は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

注記

Shared Resource CSI Driver を有効にするには、フィーチャーゲートを使用して機能を有効化 する必要があります。

5.3.1. CSI について

ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。

CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。

5.3.2. namespace 間でのシークレットの共有

クラスター内の namespace 間でシークレットを共有するには、共有する Secret オブジェクトの SharedSecret カスタムリソース (CR) インスタンスを作成します。

前提条件

次のアクションを実行するためのパーミッションがある。

  • cluster スコープレベルで sharedsecrets.sharedresource.openshift.io カスタムリソース定義 (CRD) のインスタンスを作成する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
  • ロールおよびロールバインディングを管理し、Pod で指定されたサービスアカウントが、使用する SharedSecret CR インスタンスを参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。
  • 共有する Secret が含まれる namespace にアクセスする。

手順

  • クラスター内の namespace 間で共有する Secret オブジェクトの SharedSecret CR インスタンスを作成します。

    $ oc apply -f - <<EOF
    apiVersion: sharedresource.openshift.io/v1alpha1
    kind: SharedSecret
    metadata:
      name: my-share
    spec:
      secretRef:
        name: <name of secret>
        namespace: <namespace of secret>
    EOF

5.3.3. Pod での SharedSecret インスタンスの使用

Pod から SharedSecret カスタムリソース (CR) インスタンスにアクセスするには、その SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

前提条件

  • クラスター内の namespace 間で共有する Secret の SharedSecret CR インスタンスを作成している。
  • 次のアクションを実行するためのパーミッションがある。

    • oc get sharedsecretsコマンドを入力し、空でないリストを取得して、使用可能なSharedSecret CR インスタンスを見つけます。
    • Pod が指定するサービスアカウントが、指定された SharedSecret CR インスタンスの使用を許可されているかどうかを判断します。つまり、oc adm policy who-can use <identifier of specific SharedSecret> 実行して、namespace のサービスアカウントが一覧に表示されるかどうかを確認できます。
    • Pod が指定するサービスアカウントが csi ボリュームの使用を許可されているかどうか、または Pod を直接作成したリクエストユーザーとして csi ボリュームの使用が許可されているかどうかを確認します。詳細は、「Pod セキュリティーアドミッションの理解と管理」を参照してください。
注記

このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedSecret CR インスタンスを検出し、サービスアカウントを有効にして SharedSecret CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。

手順

  1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

    注記

    現在、kubectloc には、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedSecret CR インスタンスの使用に必要なロールを作成することはできません。

    $ oc apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: shared-resource-my-share
      namespace: my-namespace
    rules:
      - apiGroups:
          - sharedresource.openshift.io
        resources:
          - sharedsecrets
        resourceNames:
          - my-share
        verbs:
          - use
    EOF
  2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
  3. Pod から SharedSecret CR インスタンスにアクセスします。

    $ oc apply -f - <<EOF
    kind: Pod
    apiVersion: v1
    metadata:
      name: my-app
      namespace: my-namespace
    spec:
      serviceAccountName: default
    
    # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
    
        volumes:
        - name: my-csi-volume
          csi:
            readOnly: true
            driver: csi.sharedresource.openshift.io
            volumeAttributes:
              sharedSecret: my-share
    
    EOF

5.3.4. namespace 間での設定マップの共有

クラスター内の namespace 間で設定マップを共有するには、その設定マップの SharedConfigMap カスタムリソース (CR) インスタンスを作成します。

前提条件

次のアクションを実行するためのパーミッションがある。

  • cluster スコープレベルで sharedconfigmaps.sharedresource.openshift.io カスタムリソース定義 (CRD) のインスタンスを作成する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
  • クラスター内の namespace 全体でロールおよびロールバインディングを管理し、Container Storage Interface (CSI) ボリュームをマウントする Pod のどのサービスアカウントが、それらのインスタンスを使用できるかを制御する。
  • 共有する Secret が含まれる namespace にアクセスする。

手順

  1. クラスター内の namespace 間で共有する設定マップの SharedConfigMap CR インスタンスを作成します。

    $ oc apply -f - <<EOF
    apiVersion: sharedresource.openshift.io/v1alpha1
    kind: SharedConfigMap
    metadata:
      name: my-share
    spec:
      configMapRef:
        name: <name of configmap>
        namespace: <namespace of configmap>
    EOF

5.3.5. Pod での SharedConfigMap インスタンスの使用

次のステップ

Pod から SharedConfigMap カスタムリソース (CR) インスタンスにアクセスするには、その SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

前提条件

  • クラスター内の namespace 間で共有する設定マップの SharedConfigMap CR インスタンスを作成している。
  • 次のアクションを実行するためのパーミッションがある。

    • oc get sharedconfigmapsコマンドを入力し、空でないリストを取得して、使用可能なSharedConfigMap CR インスタンスを検出します。
    • Pod が指定するサービスアカウントが、指定された SharedSecret CR インスタンスの使用を許可されているかどうかを判断します。つまり、oc adm policy who-can use <identifier of specific SharedSecret> 実行して、namespace のサービスアカウントが一覧に表示されるかどうかを確認できます。
    • Pod が指定するサービスアカウントが csi ボリュームの使用を許可されているかどうか、または Pod を直接作成したリクエストユーザーとして csi ボリュームの使用が許可されているかどうかを確認します。詳細は、「Pod セキュリティーアドミッションの理解と管理」を参照してください。
注記

このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedConfigMap CR インスタンスを検出し、サービスアカウントを有効にして SharedConfigMap CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。

手順

  1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

    注記

    現在、kubectloc には、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedConfigMap CR インスタンスの使用に必要なロールを作成することはできません。

    $ oc apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: shared-resource-my-share
      namespace: my-namespace
    rules:
      - apiGroups:
          - sharedresource.openshift.io
        resources:
          - sharedconfigmaps
        resourceNames:
          - my-share
        verbs:
          - use
    EOF
  2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

    oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
  3. Pod から SharedConfigMap CR インスタンスにアクセスします。

    $ oc apply -f - <<EOF
    kind: Pod
    apiVersion: v1
    metadata:
      name: my-app
      namespace: my-namespace
    spec:
      serviceAccountName: default
    
    # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
    
        volumes:
        - name: my-csi-volume
          csi:
            readOnly: true
            driver: csi.sharedresource.openshift.io
            volumeAttributes:
              sharedConfigMap: my-share
    
    EOF

5.3.6. Shared Resource CSI Driver に対するその他のサポート制限

Shared Resource CSI Driver には、以下の重要な制限があります。

  • ドライバーは、Container Storage Interface (CSI) のインライン一時ボリュームの制限の対象となります。
  • readOnly フィールドの値は true である必要があります。Pod の作成時に、readOnlyfalse の場合、検証受付 Webhook は Pod の作成を拒否します。なんらかの理由で検証用アドミッション Webhook に接続できない場合、Pod の起動中のボリュームプロビジョニングで、ドライバーは kubelet にエラーを返します。readOnlytrue であることを要求することは、アップストリームの Kubernetes CSI ドライバーが関連するボリュームに SELinux ラベルを適用するための提案されたベストプラクティスに沿っています。
  • ドライバーは、tmpfs ボリュームしかサポートしないため、FSType フィールドを無視します。
  • ドライバーは NodePublishSecretRef フィールドを無視します。代わりに、ドライバーはuse動詞で SubjectAccessReviews を使用して、Pod が SharedSecret または SharedConfigMap カスタムリソース (CR) インスタンスが含まれるボリュームを取得できるかどうかを評価します。
  • 名前が openshift で始まる SharedSecret または SharedConfigMap カスタムリソース (CR) インスタンスを作成することはできません。

5.3.7. 共有リソース Pod ボリュームの VolumeAttributes に関する追加情報

以下の属性は、さまざまな形で共有リソース Pod ボリュームに影響を及ぼします。

  • volumeAttributes プロパティーの refreshResource 属性。
  • Shared Resource CSI Driver 設定の refreshResources 属性。
  • volumeAttributes プロパティーの sharedSecret および sharedConfigMap 属性。
5.3.7.1. refreshResource 属性

Shared Resource CSI Driver は、ボリュームの volumeAttributes プロパティーの refreshResource 属性を尊重します。この属性は、Pod 起動の一環としてボリュームが初回にプロビジョニングされた に、基礎となる Secret または ConfigMap オブジェクトの内容に対する更新がボリュームにコピーされるかどうかを制御します。refreshResource のデフォルト値は true です。これは、コンテンツが更新されることを意味します。

重要

Shared Resource CSI Driver 設定により、共有 SharedSecret および SharedConfigMap カスタムリソース (CR) インスタンス両方の更新が無効にされている場合、volumeAttribute プロパティーの refreshResource 属性は影響を及ぼしません。この属性の目的は、更新が一般的に許可されている場合に、特定のボリュームマウントの更新を無効にすることです。

5.3.7.2. refreshResources 属性

グローバルスイッチを使用して、共有リソースの更新を有効または無効にできます。このスイッチは Shared Resource CSI Driver の csi-driver-shared-resource-config 設定マップの refreshResources 属性で、openshift-cluster-csi-drivers namespace で確認できます。この refreshResources 属性を false に設定する場合、ボリュームに保存されている Secret または ConfigMap オブジェクト関連のコンテンツは、ボリュームの初回プロビジョニング後に更新されません。

重要

この Shared Resource CSI Driver 設定を使用して更新を無効にすると、ボリュームの volumeAttributes プロパティーの refreshResource 属性に関係なく、Shared Resource CSI Driver を使用するすべてのクラスターのボリュームマウントが影響を受けます。

5.3.7.3. Pod の共有リソースボリュームをプロビジョニングする前の volumeAttributes の検証

1 つのボリュームの volumeAttributes で、sharedSecret または sharedConfigMap 属性いずれかの値を、SharedSecret または SharedConfigMap CS インスタンスの値に設定する必要があります。設定しないと、Pod の起動時にボリュームがプロビジョニングされる際に、検証でそのボリュームの volumeAttributes がチェックされ、以下の条件下では kubelet にエラーが返されます。

  • sharedSecret および sharedConfigMap 属性の両方に値が指定されている。
  • sharedSecret および sharedConfigMap 属性の両方に値が指定されていない。
  • sharedSecret または sharedConfigMap 属性の値が、クラスター内の SharedSecret または SharedConfigMap CR インスタンスの名前に対応していない。

5.3.8. 共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーション

共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーションにより、Red Hat サブスクリプション (RHEL エンタイトルメント) を OpenShift Container Platform Builds で簡単に使用できます。

従来、OpenShift Container Platform 4.9.x 以前では、認証情報を手動でインポートし、ビルドを実行している各プロジェクトまたは namespace にコピーしていました。

OpenShift Container Platform 4.10 以降では、OpenShift Container Platform Builds では、共有リソースおよび Insights Operator によって提供される単純なコンテンツアクセス機能を参照して、Red Hat サブスクリプション (RHEL エンタイトルメント) を使用できるようになりました。

  • シンプルなコンテンツアクセス機能は、サブスクリプションの認証情報を、既知の Secret オブジェクトにインポートします。以下の「関連情報」セクションのリンクを参照してください。
  • クラスター管理者は、その Secret オブジェクトに関する SharedSecret カスタムリソース (CR) インスタンスを作成し、特定のプロジェクトまたは namespace にパーミッションを付与します。特に、クラスター管理者は、その SharedSecret CR インスタンスを使用するための、builder サービスアカウントパーミッションを付与します。
  • それらのプロジェクトまたは namespace 内で実行されるビルドは、SharedSecret CR インスタンスおよびそのエンタイトルメントが適用された RHEL コンテンツを参照する CSI Volume をマウントできます。

5.4. CSI ボリュームスナップショット

このドキュメントでは、サポートされる Container Storage Interface (CSI) ドライバーでボリュームスナップショットを使用して、OpenShift Container Platform でデータ損失から保護する方法を説明します。永続ボリューム についてある程度理解していることが推奨されます。

5.4.1. CSI ボリュームスナップショットの概要

スナップショット は、特定の時点におけるクラスター内のストレージボリュームの状態を表します。ボリュームスナップショットは新規ボリュームのプロビジョニングに使用できます。

OpenShift Container Platform は、デフォルトで Container Storage Interface (CSI) ボリュームスナップショットをサポートします。ただし、特定の CSI ドライバーが必要です。

CSI ボリュームのスナップショットを使用して、クラスター管理者は以下を行うことができます。

  • スナップショットをサポートするサードパーティーの CSI ドライバーをデプロイします。
  • 既存のボリュームスナップショットから永続ボリューム要求 (PVC) を新たに作成します。
  • 既存の PVC のスナップショットを作成します。
  • スナップショットを別の PVC として復元します。
  • 既存のボリュームスナップショットを削除します。

CSI ボリュームスナップショットを使用すると、アプリケーション開発者は以下を行うことができます。

  • ボリュームスナップショットは、アプリケーションレベルまたはクラスターレベルのストレージバックアップソリューションを開発するためのビルディングブロックとして使用します。
  • 迅速に直前の開発バージョンにロールバックします。
  • 毎回フルコピーを作成する必要がないため、ストレージをより効率的に使用できます。

ボリュームスナップショットを使用する場合は、以下の点に注意してください。

  • サポートは CSI ドライバーでのみ利用可能です。インツリーおよび FlexVolumes はサポートされません。
  • OpenShift Container Platform には一部の CSI ドライバーのみが同梱されます。OpenShift Container Platform ドライバー Operator によって提供されない CSI ドライバーについては、コミュニティーまたはストレージベンダー が提供する CSI ドライバーを使用することが推奨されます。CSI ドライバーのプロバイダーが提供するインストール手順に従います。
  • CSI ドライバーは、ボリュームのスナップショット機能を実装している場合もあれば、実装していない場合もあります。ボリュームスナップショットのサポートを提供している CSI ドライバーは、csi-external-snapshotter サイドカーコンテナーを使用する可能性があります。詳細は、CSI ドライバーで提供されるドキュメントを参照してください。

5.4.2. CSI スナップショットコントローラーおよびサイドカー

OpenShift Container Platform は、コントロールプレーンにデプロイされるスナップショットコントローラーを提供します。さらに、CSI ドライバーベンダーは、CSI ドライバーのインストール時にインストールされるヘルパーコンテナーとして CSI スナップショットサイドカーコンテナーを提供します。

CSI スナップショットコントローラーおよびサイドカーは、OpenShift Container Platform API を使用してボリュームのスナップショットを提供します。これらの外部コンポーネントはクラスターで実行されます。

外部コントローラーは CSI スナップショットコントローラー Operator によってデプロイされます。

5.4.2.1. 外部コントローラー

CSI スナップショットコントローラーは VolumeSnapshot および VolumeSnapshotContent オブジェクトをバインドします。コントローラーは、VolumeSnapshotContent オブジェクトを作成し、削除して動的プロビジョニングを管理します。

5.4.2.2. 外部サイドカー

CSI ドライバーベンダーは、csi-external-snapshotter サイドカーを提供します。これは、CSI ドライバーでデプロイされる別のヘルパーコンテナーです。サイドカーは、CreateSnapshot および DeleteSnapshot 操作をトリガーしてスナップショットを管理します。ベンダーが提供するインストールの手順に従います。

5.4.3. CSI スナップショットコントローラー Operator について

CSI スナップショットコントローラー Operator は openshift-cluster-storage-operator namespace で実行されます。これは、デフォルトですべてのクラスターの Cluster Version Operator (CVO) によってインストールされます。

CSI スナップショットコントローラー Operator は、openshift-cluster-storage-operator namespace で実行される CSI スナップショットコントローラーをインストールします。

5.4.3.1. ボリュームスナップショット CRD

OpenShift Container Platform のインストール時に、CSI スナップショットコントローラー Operator は、snapshot.storage.k8s.io/v1 API グループに以下のスナップショットのカスタムリソース定義 (CRD) を作成します。

VolumeSnapshotContent

クラスター管理者がプロビジョニングしたクラスター内のボリュームのスナップショット。

PersistentVolume オブジェクトと同様に、VolumeSnapshotContent CRD はストレージバックエンドの実際のスナップショットを参照するクラスターリソースです。

手動でプロビジョニングされたスナップショットの場合、クラスター管理者は多くの VolumeSnapshotContent CRD を作成します。これらには、ストレージシステム内の実際のボリュームスナップショットの詳細が含まれます。

VolumeSnapshotContent CRD には namespace が使用されず、これはクラスター管理者によって使用されるものです。

VolumeSnapshot

PersistentVolumeClaim オブジェクトと同様に、VolumeSnapshot CRD はスナップショットの開発者要求を定義します。CSI スナップショットコントローラー Operator は、適切な VolumeSnapshotContent CRD で VolumeSnapshot CRD のバインディングを処理する CSI スナップショットコントローラーを実行します。バインディングは 1 対 1 のマッピングです。

VolumeSnapshot CRD には namespace が使用されます。開発者は、CRD をスナップショットの個別の要求として使用します。

VolumeSnapshotClass

クラスター管理者は、VolumeSnapshot オブジェクトに属する異なる属性を指定できます。これらの属性は、ストレージシステムの同じボリュームで作成されるスナップショット間で異なる場合があります。この場合、それらは永続ボリューム要求の同じストレージクラスを使用して表現できません。

VolumeSnapshotClass CRD は、スナップショットの作成時に使用する csi-external-snapshotter サイドカーのパラメーターを定義します。これにより、ストレージバックエンドは、複数のオプションがサポートされる場合に動的に作成するスナップショットの種類を認識できます。

動的にプロビジョニングされるスナップショットは VolumeSnapshotClass CRD を使用して、スナップショットの作成時に使用するストレージプロバイダー固有のパラメーターを指定します。

VolumeSnapshotContentClass CRD には namespace が使用されず、クラスター管理者がストレージバックエンドのグローバル設定オプションを有効にするために使用します。

5.4.4. ボリュームスナップショットのプロビジョニング

スナップショットをプロビジョニングする方法は、動的な方法と手動による方法の 2 種類があります。

5.4.4.1. 動的プロビジョニング

既存のスナップショットを使用する代わりに、スナップショットを永続ボリューム要求から動的に取得するように要求できます。パラメーターは VolumeSnapshotClass CRD を使用して指定されます。

5.4.4.2. 手動プロビジョニング

クラスター管理者は、多数の VolumeSnapshotContent オブジェクトを手動で事前にプロビジョニングできます。これらは、クラスターユーザーが利用できる実際のボリュームのスナップショットの詳細を保持します。

5.4.5. ボリュームスナップショットの作成

VolumeSnapshot オブジェクトを作成すると、OpenShift Container Platform はボリュームスナップショットを作成します。

前提条件

  • 実行中の OpenShift Container Platform クラスターにログインしている。
  • VolumeSnapshot オブジェクトをサポートする CSI ドライバーを使用して作成される PVC。
  • ストレージバックエンドをプロビジョニングするストレージクラス。
  • スナップショットの作成に使用する必要のある永続ボリューム要求 (PVC) を使用している Pod はありません。

    警告

    Pod によって使用されている PVC のボリュームスナップショットを作成すると、書き込まれていないデータやキャッシュされたデータがスナップショットから除外される可能性があります。すべてのデータがディスクに確実に書き込まれるようにするには、PVC を使用している Pod を削除してから、スナップショットを作成してください。

手順

ボリュームのスナップショットを動的に作成するには、以下を実行します。

  1. 以下の YAML によって記述される VolumeSnapshotClass オブジェクトを使用してファイルを作成します。

    volumesnapshotclass.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: csi-hostpath-snap
    driver: hostpath.csi.k8s.io 1
    deletionPolicy: Delete

    1
    この VolumeSnapshotClass オブジェクトのスナップショットを作成するために使用される CSI ドライバーの名前。名前は、スナップショットが作成される PVC に対応するストレージクラスの Provisioner フィールドと同じである必要があります。
    注記

    永続ストレージの設定に使用したドライバーによっては、追加のパラメーターが必要になる場合があります。既存の VolumeSnapshotClass オブジェクトを使用することもできます。

  2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

    $ oc create -f volumesnapshotclass.yaml
  3. VolumeSnapshot オブジェクトを作成します。

    volumesnapshot-dynamic.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: mysnap
    spec:
      volumeSnapshotClassName: csi-hostpath-snap 1
      source:
        persistentVolumeClaimName: myclaim 2

    1
    ボリュームスナップショットによる特定クラスの要求。volumeSnapshotClassName 設定がなく、デフォルトのボリュームスナップショットクラスがある場合、スナップショットはデフォルトのボリュームスナップショットクラス名で作成されます。ただし、フィールドがなく、デフォルトのボリュームスナップショットクラスが存在しない場合には、スナップショットは作成されません。
    2
    永続ボリュームにバインドされる PersistentVolumeClaim オブジェクトの名前。これは、スナップショットの作成に使用する内容を定義します。スナップショットの動的プロビジョニングに必要です。
  4. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

    $ oc create -f volumesnapshot-dynamic.yaml

スナップショットを手動でプロビジョニングするには、以下を実行します。

  1. 上記のようにボリュームスナップショットクラスを定義するだけでなく、volumeSnapshotContentName パラメーターの値をスナップショットのソースとして指定します。

    volumesnapshot-manual.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: snapshot-demo
    spec:
      source:
        volumeSnapshotContentName: mycontent 1

    1
    事前にプロビジョニングされたスナップショットには、volumeSnapshotContentName パラメーターが必要です。
  2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

    $ oc create -f volumesnapshot-manual.yaml

検証

スナップショットがクラスターで作成されると、スナップショットに関する追加情報が利用可能になります。

  1. 作成したボリュームスナップショットの詳細を表示するには、以下のコマンドを実行します。

    $ oc describe volumesnapshot mysnap

    以下の例は、mysnap ボリュームスナップショットの詳細を表示します。

    volumesnapshot.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: mysnap
    spec:
      source:
        persistentVolumeClaimName: myclaim
      volumeSnapshotClassName: csi-hostpath-snap
    status:
      boundVolumeSnapshotContentName: snapcontent-1af4989e-a365-4286-96f8-d5dcd65d78d6 1
      creationTime: "2020-01-29T12:24:30Z" 2
      readyToUse: true 3
      restoreSize: 500Mi

    1
    コントローラーによって作成された実際のストレージコンテンツへのポインター。
    2
    スナップショットが作成された時間。スナップショットには、このタイミングで利用できるボリュームコンテンツが含まれます。
    3
    値が true に設定されている場合、スナップショットを使用して新規 PVC として復元できます。
    値が false に設定されている場合、スナップショットが作成されています。ただし、ストレージバックエンドは、スナップショットを新規ボリュームとして復元できるようにするために、追加のタスクを実行してスナップショットを使用できる状態にする必要があります。たとえば、Amazon Elastic Block Store データを別の低コストの場所に移動する場合があり、これには数分の時間がかかる可能性があります。
  2. ボリュームのスナップショットが作成されたことを確認するには、以下のコマンドを実行します。

    $ oc get volumesnapshotcontent

    実際のコンテンツへのポインターが表示されます。boundVolumeSnapshotContentName フィールドにデータが設定される場合、VolumeSnapshotContent オブジェクトが存在し、スナップショットが作成されています。

  3. スナップショットの準備が完了していることを確認するには、VolumeSnapshot オブジェクトに readyToUse: true があることを確認します。

5.4.6. ボリュームスナップショットの削除

OpenShift Container Platform によるボリュームスナップショットの削除方法を設定できます。

手順

  1. 以下の例のように、VolumeSnapshotClass オブジェクトで必要な削除ポリシーを指定します。

    volumesnapshotclass.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: csi-hostpath-snap
    driver: hostpath.csi.k8s.io
    deletionPolicy: Delete 1

    1
    ボリュームスナップショットの削除時に Delete 値を設定すると、VolumeSnapshotContent オブジェクトと共に基礎となるスナップショットが削除されます。Retain 値を設定すると、基礎となるスナップショットと VolumeSnapshotContent オブジェクトの両方が残ります。
    Retain 値を設定し、対応する VolumeSnapshotContent オブジェクトを削除せずに VolumeSnapshot オブジェクトを削除すると、コンテンツは残ります。スナップショット自体はストレージバックエンドにも保持されます。
  2. 以下のコマンドを入力してボリュームスナップショットを削除します。

    $ oc delete volumesnapshot <volumesnapshot_name>

    出力例

    volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted

  3. 削除ポリシーが Retain に設定されている場合は、以下のコマンドを入力してボリュームスナップショットのコンテンツを削除します。

    $ oc delete volumesnapshotcontent <volumesnapshotcontent_name>
  4. オプション: VolumeSnapshot オブジェクトが正常に削除されていない場合は、以下のコマンドを実行して残されているリソースのファイナライザーを削除し、削除操作を続行できるようにします。

    重要

    永続ボリューム要求またはボリュームスナップショットのコンテンツのいずれかから VolumeSnapshot オブジェクトへの既存の参照がない場合にのみファイナライザーを削除します。--force オプションを使用する場合でも、すべてのファイナライザーが削除されるまで削除操作でスナップショットオブジェクトは削除されません。

    $ oc patch -n $PROJECT volumesnapshot/$NAME --type=merge -p '{"metadata": {"finalizers":null}}'

    出力例

    volumesnapshotclass.snapshot.storage.k8s.io "csi-ocs-rbd-snapclass" deleted

    ファイナライザーが削除され、ボリュームスナップショットが削除されます。

5.4.7. ボリュームスナップショットの復元

VolumeSnapshot CRD コンテンツは、既存のボリュームを以前の状態に復元するために使用されます。

VolumeSnapshot CRD がバインドされ、readyToUse 値が true に設定された後に、そのリソースを使用して、スナップショットからのデータが事前に設定されている新規ボリュームをプロビジョニングできます。

前提条件