ストレージ
OpenShift Container Platform でのストレージの設定および管理
概要
第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 は、定義、デプロイ、および管理される最小のコンピュート単位です。
- 回収ポリシー
-
解放後のボリュームの処理方法をクラスターに指示するポリシー。ボリュームの回収ポリシーは、
Retain
、Recycle
または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 のローカル一時ストレージの制限があります。
-
この場合、Pod レベルでの合計ストレージ使用量は、すべてのコンテナーからのディスク使用量と Pod の
クォータと制限を含む一時ストレージ設定の例
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: {}
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. 永続ボリュームの回収ポリシー
永続ボリュームの回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法を指示します。ボリュームの回収ポリシーは、Retain
、Recycle
または 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 を手動で回収するには、以下を実行します。
PV を削除します。
$ oc delete pv <pv-name>
AWS EBS、GCE PD、Azure Disk、Cinder ボリュームなどの外部インフラストラクチャーの関連するストレージアセットは、PV の削除後も引き続き存在します。
- 関連するストレージアセットのデータをクリーンアップします。
- 関連するストレージアセットを削除します。または、同じストレージアセットを再利用するには、ストレージアセットの定義で新規 PV を作成します。
回収される PV が別の PVC で使用できるようになります。
3.2.8. 永続ボリュームの回収ポリシーの変更
永続ボリュームの回収ポリシーを変更するには、以下を実行します。
クラスターの永続ボリュームをリスト表示します。
$ 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
永続ボリュームの 1 つを選択し、その回収ポリシーを変更します。
$ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
選択した永続ボリュームに正しいポリシーがあることを確認します。
$ 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: ...
3.3.1. PV の種類
OpenShift Container Platform は以下の永続ボリュームプラグインをサポートします。
- AliCloud Disk
- 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
- 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 を削除します。
以下の表では、アクセスモードをまとめています。
アクセスモード | CLI の省略形 | 説明 |
---|---|---|
ReadWriteOnce |
| ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
ReadWriteOncePod [1] |
| ボリュームは、1 つのノード上の 1 つの Pod によって読み取り/書き込みとしてマウントできます。 |
ReadOnlyMany |
| ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
ReadWriteMany |
| ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。 |
- 永続ボリュームの ReadWriteOncePod アクセスモードはテクノロジープレビュー機能です。
永続ボリュームの ReadWriteOncePod アクセスモードは、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ボリュームプラグイン | ReadWriteOnce [1] | ReadWriteOncePod [2] | ReadOnlyMany | ReadWriteMany |
---|---|---|---|---|
AliCloud Disk |
✅ |
✅ |
- |
- |
AWS EBS [3] |
✅ |
✅ |
- |
- |
AWS EFS |
✅ |
✅ |
✅ |
✅ |
Azure File |
✅ |
✅ |
✅ |
✅ |
Azure Disk |
✅ |
✅ |
- |
- |
Cinder |
✅ |
✅ |
- |
- |
ファイバーチャネル |
✅ |
✅ |
✅ |
✅ [4] |
GCP Persistent Disk |
✅ |
✅ |
- |
- |
GCP Filestore |
✅ |
✅ |
✅ |
✅ |
HostPath |
✅ |
✅ |
- |
- |
IBM Power Virtual Server Disk |
✅ |
✅ |
✅ |
✅ |
IBM® VPC Disk |
✅ |
✅ |
- |
- |
iSCSI |
✅ |
✅ |
✅ |
✅ [4] |
ローカルボリューム |
✅ |
✅ |
- |
- |
LVM Storage |
✅ |
✅ |
- |
- |
NFS |
✅ |
✅ |
✅ |
✅ |
OpenStack Manila |
- |
✅ |
- |
✅ |
Red Hat OpenShift Data Foundation |
✅ |
✅ |
- |
✅ |
VMware vSphere |
✅ |
✅ |
- |
✅ [5] |
- ReadWriteOnce (RWO) ボリュームは複数のノードにマウントできません。ノードに障害が発生すると、システムは、すでに障害が発生しているノードに割り当てられているため、割り当てられた RWO ボリュームを新規ノードにマウントすることはできません。複数割り当てのエラーメッセージが表示される場合は、シャットダウンまたはクラッシュしたノードで Pod を強制的に削除し、動的永続ボリュームの割り当て時などの重要なワークロードでのデータ損失を回避します。
- ReadWriteOncePod はテクノロジープレビュー機能です。
- AWS EBS に依存する Pod の再作成デプロイメントストラテジーを使用します。
- raw ブロックボリュームのみが、ファイバーチャネルおよび iSCSI の ReadWriteMany (RWX) アクセスモードをサポートします。詳細は、「ブロックボリュームのサポート」を参照してください。
- 基盤となる 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. フェーズ
ボリュームは以下のフェーズのいずれかにあります。
フェーズ | 説明 |
---|---|
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 のみ)
- 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: ...
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
3.5. ブロックボリュームのサポート
OpenShift Container Platform は、raw ブロックボリュームを静的にプロビジョニングできます。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込むアプリケーションや、独自のストレージサービスを実装するアプリケーションにはパフォーマンス上の利点があります。
raw ブロックボリュームは、PV および PVC 仕様で volumeMode: Block
を指定してプロビジョニングされます。
raw ブロックボリュームを使用する Pod は、特権付きコンテナーを許可するように設定する必要があります。
以下の表は、ブロックボリュームをサポートするボリュームプラグインを表示しています。
ボリュームプラグイン | 手動のプロビジョニング | 動的なプロビジョニング | フルサポート |
---|---|---|---|
Amazon Elastic Block Store (Amazon EBS) | ✅ | ✅ | ✅ |
Amazon Elastic File Storage (Amazon EFS) | |||
AliCloud Disk | ✅ | ✅ | ✅ |
Azure Disk | ✅ | ✅ | ✅ |
Azure File | |||
Cinder | ✅ | ✅ | ✅ |
ファイバーチャネル | ✅ | ✅ | |
GCP | ✅ | ✅ | ✅ |
HostPath | |||
IBM VPC Disk | ✅ | ✅ | ✅ |
iSCSI | ✅ | ✅ | |
ローカルボリューム | ✅ | ✅ | |
LVM Storage | ✅ | ✅ | ✅ |
NFS | |||
Red Hat OpenShift Data Foundation | ✅ | ✅ | ✅ |
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
volumeMode
をBlock
に設定して、この PV が raw ブロックボリュームであることを示します。
PVC の例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block 1
resources:
requests:
storage: 10Gi
- 1
volumeMode
をBlock
に設定して、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
値 | デフォルト |
---|---|
Filesystem | はい |
Block | いいえ |
PV volumeMode | PVC 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 にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順
- OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- 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 キーを作成する必要があります。
手順
ストレージクラスを作成します。
$ 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 の検索を参照してください。
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
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 ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
手順
- OpenShift Container Platform コンソールで、Storage → Storage Classes をクリックします。
- ストレージクラスの概要では、Create Storage Class をクリックします。
表示されるページで必要なオプションを定義します。
- ストレージクラスを参照するための名前を入力します。
- オプションの説明を入力します。
- 回収ポリシーを選択します。
ドロップダウンリストから
kubernetes.io/azure-disk
を選択します。-
ストレージアカウントのタイプを入力します。これは、Azure ストレージアカウントの SKU の層に対応します。有効なオプションは、
Premium_LRS
、Standard_LRS
、StandardSSD_LRS
、およびUltraSSD_LRS
です。 アカウントの種類を入力します。有効なオプションは
shared
、dedicated
およびmanaged
です。重要Red Hat は、ストレージクラスでの
kind: Managed
の使用のみをサポートします。Shared
およびDedicated
の場合、Azure はマネージド外のディスクを作成しますが、OpenShift Container Platform はマシンの OS (root) ディスクの管理ディスクを作成します。ただし、Azure Disk はノードで管理ディスクおよびマネージド外ディスクの両方の使用を許可しないため、Shared
またはDedicated
で作成されたマネージド外ディスクを OpenShift Container Platform ノードに割り当てることはできません。
-
ストレージアカウントのタイプを入力します。これは、Azure ストレージアカウントの SKU の層に対応します。有効なオプションは、
- 必要に応じてストレージクラスの追加パラメーターを入力します。
- Create をクリックしてストレージクラスを作成します。
4.2.2. 永続ボリューム要求の作成
前提条件
ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順
- OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- 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 クラスターがある。
手順
既存の Azure
MachineSet
カスタムリソース (CR) をコピーし、次のコマンドを実行して編集します。$ oc edit machineset <machine-set-name>
ここで、
<machine-set-name>
は、Ultra ディスクとともにマシンをプロビジョニングするマシンセットです。示された位置に次の行を追加します。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet spec: template: spec: metadata: labels: disk: ultrassd 1 providerSpec: value: ultraSSDCapability: Enabled 2
次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。
$ oc create -f <machine-set-name>.yaml
以下の 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
以下の 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
以下の 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
検証
次のコマンドを実行して、マシンが作成されていることを確認します。
$ oc get machines
マシンは
Running
状態になっているはずです。実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。
$ 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 共有があること。
- この共有にアクセスするための認証情報 (とくにストレージアカウントおよびキー) が利用可能であること。
手順
Azure File の認証情報が含まれる
Secret
オブジェクトを作成します。$ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 1 --from-literal=azurestorageaccountkey=<storage-account-key> 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
作成した永続ボリュームにマップする
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
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
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) を作成する前に、オブジェクト定義でこれを定義する必要があります。
手順
オブジェクト定義をファイルに保存します。
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
重要ボリュームをフォーマットしてプロビジョニングした後には、
fstype
パラメーターの値は変更しないでください。この値を変更すると、データの損失や、Pod の障害につながる可能性があります。前のステップで保存したオブジェクト定義ファイルを作成します。
$ 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 が作成される必要があります。
手順
サービスアカウントを作成して、そのアカウントを SCC に追加します。
$ oc create serviceaccount <service_account>
$ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
アプリケーションのデプロイ設定で、サービスアカウント名と
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
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
または FCtargetWWNs
および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
のいくつかのオプション。たとえば、fsType
やreadwrite
などです。 -
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>", }
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 ドライバーをインストールします。
- この実行可能ファイルがクラスター内のすべてのノードに存在することを確認します。
-
この実行可能ファイルをボリュームプラグインのパス (
/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 にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順
- OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- 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
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 サーバーのリストとエクスポートパスのみが必要です。
手順
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 ボリュームは、クラスター内のスケジュール可能なすべてのノードによってマウント可能でなければなりません。
PV が作成されたことを確認します。
$ oc get pv
出力例
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE pv0001 <none> 5Gi RWO Available 31s
新規 PV にバインドされる永続ボリューム要求を作成します。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-claim1 spec: accessModes: - ReadWriteOnce 1 resources: requests: storage: 5Gi 2 volumeName: pv0001 storageClassName: ""
永続ボリューム要求が作成されたことを確認します。
$ 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 の 65534
、nfsnobody
所有者、または補助グループの 5555
のいずれかで実行される必要があります。
所有者 ID 65534
は一例として使用されています。NFS の root_squash
が root
、uid 0
を nfsnobody
、uid 65534
にマップしても、NFS エクスポートは任意の所有者 ID を持つことができます。所有者 65534
は NFS エクスポートには必要ありません。
4.9.3.1. グループ ID
NFS アクセスに対応する際の推奨される方法として、補助グループを使用することができます (NFS エクスポートのパーミッションを変更するオプションがないことを前提としています)。OpenShift Container Platform の補助グループは共有ストレージに使用されます (例: NFS)。これとは対照的に、iSCSI などのブロックストレージは、Pod の securityContext
で fsGroup
SCC ストラテジーと fsGroup
の値を使用します。
永続ストレージへのアクセスを取得するには、通常はユーザー ID ではなく、補助グループ ID を使用することが推奨されます。
ターゲット NFS ディレクトリーの例で使用したグループ ID は 5555
なので、Pod は、supplementalGroups
を使用してグループ ID を Pod の securityContext
定義の下で定義することができます。以下に例を示します。
spec: containers: - name: ... securityContext: 1 supplementalGroups: [5555] 2
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
プロジェクトが 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
への要求を解除します。これにより、nfs1
は Released
になります。管理者が同じ 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 のマウントにすべてのファイルの所有者が |
|
NFSv4 の ID マッピングが無効になっている |
|
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 に固有のもので、ユーザーによって要求されます。
vSphere の場合:
OpenShift Container Platform 4.13 以降の新規インストールの場合、自動移行はデフォルトで有効になっています。OpenShift Container Platform 4.15 以降に更新した場合も、自動移行が可能になります。
CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。
- OpenShift Container Platform 4.12 以前から 4.13 にアップグレードする場合、vSphere の自動 CSI 移行は、オプトインした場合にのみ発生します。オプトインしない場合、OpenShift Container Platform はデフォルトでツリー内 (非 CSI) プラグインを使用して vSphere ストレージをプロビジョニングします。移行をオプトインする前に、提示された影響を慎重に確認してください。
関連情報
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 にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順
- OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
結果のページで必要なオプションを定義します。
-
thin
ストレージクラスを選択します。 - ストレージ要求の一意の名前を入力します。
- アクセスモードを選択し、作成されるストレージ要求の読み取り/書き込みアクセスを決定します。
- ストレージ要求のサイズを定義します。
-
- Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
4.11.2.2. CLI を使用した VMware vSphere ボリュームの動的プロビジョニング
OpenShift Container Platform は、ボリュームをプロビジョニングするために thin
ディスク形式を使用する thin
という名前のデフォルトの StorageClass をインストールします。
前提条件
- ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順 (CLI)
以下の内容でファイル
pvc.yaml
を作成して VMware vSphere PersistentVolumeClaim を定義できます。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc 1 spec: accessModes: - ReadWriteOnce 2 resources: requests: storage: 1Gi 3
次のコマンドを入力して、ファイルから
PersistentVolumeClaim
オブジェクトを作成します。$ oc create -f pvc.yaml
4.11.3. VMware vSphere ボリュームの静的プロビジョニング
VMware vSphere ボリュームを静的にプロビジョニングするには、永続ボリュームフレームワークが参照する仮想マシンディスクを作成する必要があります。
前提条件
- ストレージは、ボリュームとして OpenShift Container Platform にマウントされる前に基礎となるインフラストラクチャーになければなりません。
手順
仮想マシンディスクを作成します。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
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 にエラーが発生する可能性があります。
ファイルから
PersistentVolume
オブジェクトを作成します。$ oc create -f pv1.yaml
直前の手順で作成した永続ボリュームにマップする永続ボリューム要求を作成します。
PersistentVolumeClaim
オブジェクト定義を使用して、ファイルpvc1.yaml
を作成します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc1 1 spec: accessModes: - ReadWriteOnce 2 resources: requests: storage: "1Gi" 3 volumeName: pv1 4
ファイルから
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) によって提供されるストレージタイプおよびファイルシステムのサポートを比較したものです。
機能 | LVM Storage | LSO | HPP |
---|---|---|---|
ブロックストレージのサポート | はい | はい | いいえ |
ファイルストレージのサポート | はい | はい | はい |
オブジェクトストレージのサポート [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) によるローカルストレージのプロビジョニングに関するコア機能のサポート状況を比較したものです。
機能 | LVM Storage | LSO | HPP |
---|---|---|---|
自動ファイルシステムフォーマット設定のサポート | はい | はい | 該当なし |
動的プロビジョニングのサポート | はい | いいえ | いいえ |
ソフトウェア Redundant Array of Independent Disks (RAID) アレイの使用のサポート | はい 4.15 以降でサポートされています。 | はい | はい |
透過的なディスク暗号化のサポート | はい 4.16 以降でサポートされています。 | はい | はい |
ボリュームベースのディスク暗号化のサポート | いいえ | いいえ | いいえ |
非接続インストールのサポート | はい | はい | はい |
PVC 拡張のサポート | はい | いいえ | いいえ |
ボリュームスナップショットとボリュームクローンのサポート | はい | いいえ | いいえ |
シンプロビジョニングのサポート | はい デバイスはデフォルトでシンプロビジョニングされます。 | はい シンプロビジョニングされたボリュームを参照するようにデバイスを設定できます。 | はい シンプロビジョニングされたボリュームを参照するパスを設定できます。 |
自動ディスク検出とセットアップのサポート | はい
インストール時および実行時に自動ディスク検出を利用できます。既存のストレージクラスのストレージ容量を増やすために、ディスクを | テクノロジープレビュー インストール時に自動ディスク検出を利用できます。 | いいえ |
4.12.1.4.3. パフォーマンス機能と分離機能の比較
次の表は、ローカルストレージのプロビジョニングにおける LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) のパフォーマンス機能と分離機能を比較したものです。
機能 | LVM Storage | LSO | HPP |
---|---|---|---|
パフォーマンス | I/O スピードが、同じストレージクラスを使用するすべてのワークロードで共有されます。 ブロックストレージでは直接 I/O 操作が可能です。 シンプロビジョニングがパフォーマンスに影響を与える可能性があります。 | I/O は LSO 設定によって異なります。 ブロックストレージでは直接 I/O 操作が可能です。 | I/O スピードが、同じストレージクラスを使用するすべてのワークロードで共有されます。 基盤となるファイルシステムによる制限が、I/O スピードに影響を与える可能性があります。 |
分離境界 [1] | LVM 論理ボリューム (LV) HPP と比較して、より高いレベルの分離を提供します。 | LVM 論理ボリューム (LV) HPP と比較して、より高いレベルの隔離を提供します。 | ファイルシステムパス LSO および LVM Storage と比較して、より低いレベルの分離を提供します。 |
- 分離境界とは、ローカルストレージリソースを使用するさまざまなワークロードまたはアプリケーション間の分離レベルを指します。
4.12.1.4.4. 追加機能のサポートの比較
次の表は、LVM Storage、Local Storage Operator (LSO)、および HostPath Provisioner (HPP) が提供する、ローカルストレージをプロビジョニングするための追加機能を比較したものです。
機能 | LVM Storage | LSO | HPP |
---|---|---|---|
汎用一時ボリュームのサポート | はい | いいえ | いいえ |
CSI インライン一時ボリュームのサポート | いいえ | いいえ | いいえ |
ストレージトポロジーのサポート | はい CSI ノードトポロジーのサポート | はい LSO は、ノード容認を通じてストレージトポロジーの部分的なサポートを提供します。 | いいえ |
| いいえ | いいえ | いいえ |
-
どのソリューション (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) へのアクセス。
手順
openshift-local-storage
プロジェクトを作成します。$ oc adm new-project openshift-local-storage
オプション: インフラストラクチャーノードでのローカルストレージの作成を許可します。
ロギングやモニタリングなどのコンポーネントに対応するために、ローカルストレージ Operator を使用してインフラストラクチャーノードでボリュームを作成する必要がある場合があります。
ローカルストレージ Operator にワーカーノードだけでなくインフラストラクチャーノードが含まれるように、デフォルトのノードセレクターを調整する必要があります。
ローカルストレージ Operator がクラスター全体のデフォルトセレクターを継承しないようにするには、以下のコマンドを実行します。
$ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
オプション: 単一ノードデプロイメントの CPU の管理プールでローカルストレージを実行できるようにします。
シングルノードデプロイメントで Local Storage Operator を使用し、
literal
プールに属する CPU の使用を許可します。この手順は、管理ワークロードパーティショニングを使用する単一ノードインストールで実行します。Local Storage Operator が管理 CPU プールで実行できるようにするには、次のコマンドを実行します。
$ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'
UI での操作
Web コンソールからローカルストレージ Operator をインストールするには、以下の手順を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- Operators → OperatorHub に移動します。
- Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
- Install をクリックします。
- Install Operator ページで、A specific namespace on the cluster を選択します。ドロップメニューから openshift-local-storage を選択します。
- Update Channel および Approval Strategy の値を必要な値に調整します。
- Install をクリックします。
これが完了すると、ローカルストレージ Operator は Web コンソールの Installed Operators セクションにリスト表示されます。
CLI からの操作
CLI からローカルストレージ Operator をインストールします。
ローカルストレージ 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
- インストール計画のユーザー認可ポリシー。
以下のコマンドを実行して、ローカルストレージ Operator オブジェクトを作成します。
$ oc apply -f openshift-local-storage.yaml
この時点で、Operator Lifecycle Manager (OLM) はローカルストレージ Operator を認識できるようになります。Operator の ClusterServiceVersion (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
すべての Pod およびローカルストレージ Operator が作成されていることを確認して、ローカルストレージのインストールを検証します。
必要な Pod すべてが作成されていることを確認します。
$ oc -n openshift-local-storage get pods
出力例
NAME READY STATUS RESTARTS AGE local-storage-operator-746bf599c9-vlt5t 1/1 Running 0 19m
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 がインストールされていること。
以下の条件を満たすローカルディスクがある。
- ノードに接続されている。
- マウントされていない。
- パーティションが含まれていない。
手順
ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。
注記同じデバイスに別のストレージクラス名を使用しないでください。これを行うと、複数の永続ボリューム (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 volumeMode: Filesystem 4 fsType: xfs 5 devicePaths: 6 - /path/to/device 7
- 1
- ローカルストレージ Operator がインストールされている namespace。
- 2
- オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、
oc get node
から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。 - 3
- 永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。
- 4
- ローカルボリュームのタイプを定義するボリュームモード (
Filesystem
またはBlock
)。注記raw ブロックボリューム (
volumeMode: Block
) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。 - 5
- ローカルボリュームの初回マウント時に作成されるファイルシステム。
- 6
- 選択するローカルストレージデバイスの一覧を含むパスです。
- 7
- この値を、
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 volumeMode: Block 4 devicePaths: 5 - /path/to/device 6
- 1
- ローカルストレージ Operator がインストールされている namespace。
- 2
- オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、
oc get node
から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。 - 3
- 永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。
- 4
- ローカルボリュームのタイプを定義するボリュームモード (
Filesystem
またはBlock
)。 - 5
- 選択するローカルストレージデバイスの一覧を含むパスです。
- 6
- この値を、
LocalVolume
リソースby-id
への実際のローカルディスクのファイルパスに置き換えます (例:dev/disk/by-id/wwn
)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
注記RHEL KVM を使用して OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。
virsh edit <VM>
コマンドを使用して、<serial>mydisk</serial>
定義を追加できます。OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。
$ oc create -f <local-volume>.yaml
プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。
$ 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
の場合、これはラベルセレクターが無効であることを示します。永続ボリュームが作成されていることを確認します。
$ 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 ノードに割り当てられていること。
手順
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
注記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
OpenShift Container Platform クラスターに PV リソースを作成します。作成したばかりのファイルを指定します。
$ oc create -f <example-pv>.yaml
ローカル 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 でアクセスされる永続ボリューム要求として静的に作成される必要があります。
前提条件
- 永続ボリュームがローカルボリュームプロビジョナーを使用して作成されていること。
手順
対応するストレージクラスを使用して 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
作成したファイルを指定して、PVC を OpenShift Container Platform クラスターに作成します。
$ oc create -f <local-pvc>.yaml
4.12.2.5. ローカル要求を割り当てます。
ローカルボリュームが永続ボリューム要求にマップされた後に、これをリソース内に指定できます。
前提条件
- 永続ボリューム要求が同じ namespace に存在する。
手順
定義された要求をリソースの仕様に追加します。以下の例では、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 # ...
作成したファイルを指定して、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) へのアクセスがあること。
手順
Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。
- Operators → Installed Operators をクリックします。
-
openshift-local-storage
namespace で Local Storage をクリックします。 - Local Volume Discovery タブをクリックします。
- Create Local Volume Discovery をクリックし、Form view または YAML view のいずれかを選択します。
-
LocalVolumeDiscovery
オブジェクトパラメーターを設定します。 Create をクリックします。
Local Storage Operator は、
auto-discover-devices
という名前のローカルボリューム検出インスタンスを作成します。
ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- Compute → Nodes に移動します。
- 開くノードの名前をクリックします。「Node Details」ページが表示されます。
Disks タブを選択して、選択したデバイスのリストを表示します。
ローカルディスクを追加または削除しても、デバイスリストの更新が継続的に行われます。名前、ステータス、タイプ、モデル、容量、およびモードでデバイスをフィルターできます。
Web コンソールから検出されたデバイスのローカルボリュームを自動的にプロビジョニングするには、以下を実行します。
- Operators → Installed Operators に移動し、Operator のリストから Local Storage を選択します。
- Local Volume Set → Create Local Volume Set を選択します。
- ボリュームセット名とストレージクラス名を入力します。
All nodes または Select nodes を選択し、適宜フィルターを適用します。
注記All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。
ローカルボリュームセットに適用するディスクタイプ、モード、サイズ、および制限を選択し、Create をクリックします。
メッセージが数分後に表示され、「Operator reconciled successfully」という Operator の調整が正常に行われたことが示唆されます。
または、CLI から検出されたデバイスのローカルボリュームをプロビジョニングするには、以下を実行します。
以下の例に示されるように、オブジェクト 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
ローカルボリュームセットオブジェクトを作成します。
$ oc apply -f local-volume-set.yaml
ローカル永続ボリュームがストレージクラスに基づいて動的にプロビジョニングされていることを確認します。
$ 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 ノードに割り当てられている。
- テイントのマークが付けられたノードがローカルストレージのプロビジョニングを行うことが想定されます。
手順
テイントのマークが付けられたノードでスケジュールするようにローカルボリュームを設定するには、以下を実行します。
以下の例に示されるように、
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
オプション: テイントのマークが付けられたノードでのみローカル永続ボリュームを作成するには、以下の例のように 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
である必要があります。警告使用中の永続ボリュームを削除すると、データの損失や破損につながる可能性があります。
手順
以前に作成したローカルボリュームを編集して、不要なディスクを削除します。
クラスターリソースを編集します。
$ oc edit localvolume <name> -n openshift-local-storage
-
devicePaths
の下の行に移動し、不要なディスクを表すものを削除します。
作成した永続ボリュームを削除します。
$ oc delete pv <pv-name>
ノード上のディレクトリーと含まれるシンボリックリンクを削除します。
警告以下の手順では、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 コンソールにアクセスできる。
手順
プロジェクトにインストールされているローカルボリュームリソースを削除します (
localvolume
、localvolumeset
、localvolumediscovery
等)。$ oc delete localvolume --all --all-namespaces $ oc delete localvolumeset --all --all-namespaces $ oc delete localvolumediscovery --all --all-namespaces
Web コンソールからローカルストレージ Operator をアンインストールします。
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
- Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
- ローカルストレージ Operator の末尾にある Options メニュー をクリックします。
- Uninstall Operator をクリックします。
- 表示されるウィンドウで Remove をクリックします。
ローカルストレージ Operator で作成された PV は削除されるまでクラスターに残ります。これらのボリュームが使用されなくなったら、以下のコマンドを実行してこれらのボリュームを削除します。
$ oc delete pv <pv-name>
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 は、手動の (静的) プロビジョニングで参照される必要があります。
手順
PersistentVolume
オブジェクト定義を含むpv.yaml
ファイルを作成して、永続ボリューム (PV) を定義します。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
ファイルから PV を作成します。
$ oc create -f pv.yaml
PersistentVolumeClaim
オブジェクト定義を含むpvc.yaml
ファイルを作成して PVC を定義します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: task-pvc-volume spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: manual
ファイルから 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
4.12.4. Logical Volume Manager Storage を使用した永続ストレージ
論理ボリュームマネージャー(LVM)ストレージは、TopoLVM Container Storage Interface (CSI)ドライバーを介して論理ボリュームマネージャー(LVM2)を使用して、リソースが制限されたクラスターでローカルストレージを動的にプロビジョニングします。
LVM Storage を使用すると、ボリュームグループ、永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンを作成できます。
4.12.4.1. Logical Volume Manager Storage のインストール
単一ノードの OpenShift クラスターに論理ボリュームマネージャー(LVM)ストレージをインストールし、ワークロードのストレージを動的にプロビジョニングするように設定できます。
OpenShift Container Platform CLI (oc
)、OpenShift Container Platform Web コンソール、または Red Hat Advanced Cluster Management (RHACM)を使用して、シングルノード OpenShift クラスターに LVM ストレージをデプロイできます。
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 ストレージのインストール を参照してください。
4.12.4.1.2. CLI を使用した LVM Storage のインストール
クラスター管理者は、OpenShift CLI (oc
)を使用して論理ボリュームマネージャー(LVM)ストレージをインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
および Operator インストール権限を持つユーザーとして OpenShift Container Platform にログインしている。
手順
YAML ファイルを作成し、namespace を作成するための設定を追加します。
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
以下のコマンドを実行して namespace を作成します。
$ oc create -f <file_name>
OperatorGroup
カスタムリソース(CR) YAML ファイルを作成します。OperatorGroup
CR の例apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage
以下のコマンドを実行して
OperatorGroup
CR を作成します。$ oc create -f <file_name>
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
以下のコマンドを実行して
Subscription
CR を作成します。$ oc create -f <file_name>
検証
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)ストレージをインストールできます。
前提条件
- シングルノード OpenShift クラスターにアクセスできます。
-
cluster-admin
および Operator インストール権限で OpenShift Container Platform にアクセスできる。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
- OperatorHub ページで LVM Storage をクリックします。
Operator Installation ページで次のオプションを設定します。
- Update Channel を stable-4.14 に設定します。
- Installation Mode を A specific namespace on the cluster に設定します。
-
Installed Namespace を Operator recommended namespace openshift-storage に設定します。
openshift-storage
namespace が存在しない場合は、Operator のインストール中に作成されます。 Update approval で Automatic または Manual を選択します。
注記Automatic (自動) 更新を選択すると、手動による介入なしで、Operator Lifecycle Manager (OLM) によって LVM Storage の実行中のインスタンスが自動的に更新されます。
Manual 更新を選択した場合、OLM は更新要求を作成します。LVM Storage を新しいバージョンに更新するには、クラスター管理者が更新要求を手動で承認する必要があります。
- オプション: Enable Operator recommended cluster monitoring on this Namespace チェックボックスを選択します。
- Install をクリックします。
検証手順
- インストールが成功したことを示す緑色のチェックマークが LVM Storage に表示されていることを確認します。
4.12.4.1.4. 非接続環境での LVM Storage のインストール
非接続環境で、OpenShift Container Platform 4.14 に論理ボリュームマネージャー(LVM)ストレージをインストールできます。「関連情報」セクションに、この手順で参照されているすべてのセクションのリンクが記載されています。
前提条件
- 「非接続インストールミラーリングについて」セクションを確認した。
- OpenShift Container Platform イメージリポジトリーにアクセスできる。
- ミラーレジストリーを作成した。
手順
「イメージセット設定の作成」手順の手順に従います。LVM ストレージ用のイメージセット設定を作成するには、次の
ImageSetConfiguration
オブジェクト設定を使用できます。LVM Storage 用の ImageSetConfiguration ファイルの例
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.14 4 type: ocp graph: true 5 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 6 packages: - name: lvms-operator 7 channels: - name: stable 8 additionalImages: - name: registry.redhat.io/ubi9/ubi:latest 9 helm: {}
- 1
- イメージセット内の各ファイルの最大サイズをギビバイト単位で設定します。
- 2
- イメージセットを保存する場所を指定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。
- 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
- イメージセットに含める追加のイメージを指定します。
- 「イメージセットをミラーレジストリーにミラーリングする」セクションの手順に従います。
- 「イメージレジストリーのリポジトリーミラーリングの設定」セクションの手順に従います。
4.12.4.1.5. RHACM を使用した LVM Storage のインストール
Red Hat Advanced Cluster Management (RHACM)を使用してクラスターに論理ボリュームマネージャー(LVM)ストレージをインストールするには、Policy
カスタムリソース(CR)を作成する必要があります。LVM Storage をインストールするクラスターを選択するための基準を設定することもできます。
LVM Storage をインストールするために作成した Policy
CR は、Policy
CR の作成後にインポートまたは作成したクラスターにも適用されます。
前提条件
-
cluster-admin
および Operator のインストール権限を持つアカウントを使用して、RHACM クラスターにアクセスできる。 - 各クラスターに、LVM Storage が使用できる専用のディスクがある。
- クラスターが RHACM によって管理されている。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
次のコマンドを実行して、namespace を作成します。
$ oc create ns <namespace>
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
次のコマンドを実行して
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 の最大サイズは、カーネルの制限とディスク領域によって決定されます。
アーキテクチャー | RHEL 6 | RHEL 7 | RHEL 8 | RHEL 9 |
---|---|---|---|---|
32 ビット | 16 TB | - | - | - |
64 ビット | 8 EB [1] 100 TB [2] | 8 EB [1] 500 TB [2] | 8 EB | 8 EB |
- 理論的サイズ。
- テスト済みサイズ。
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 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 thinPoolConfig: name: thin-pool-1 sizePercent: 90 4 overprovisionRatio: 10
LVMCluster CR のフィールドの説明
LVMCluster
CR のフィールドについて、次の表で説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| ローカルストレージデバイスを LVM ボリュームグループに割り当てるための設定を含めます。 LVM Storage は、ユーザーが作成する各デバイスクラスに対してストレージクラスとボリュームスナップショットクラスを作成します。
|
|
| LVM ボリュームグループ (VG) の名前を指定します。 |
|
|
このフィールドは、 |
|
|
デバイスクラスがデフォルトであることを指定するには、このフィールドを |
|
| LVM ボリュームグループを作成するノードを選択するための設定を含めます。このフィールドが空の場合、no-schedule テイントのないすべてのノードが考慮されます。 コントロールプレーンノードでは、クラスター内で新しいノードがアクティブになると、LVM Storage が追加のワーカーノードを検出して使用します。 |
|
| ノードの選択に使用する要件を設定します。 |
|
| LVM ボリュームグループに追加するデバイスへのパスを指定するための設定が含まれています。 詳細は、「ボリュームグループへのデバイスの追加について」を参照してください。 |
|
| デバイスパスを指定します。
このフィールドで指定されたデバイスパスが存在しない場合、 |
|
| オプションのデバイスパスを指定します。 このフィールドで指定されたデバイスパスが存在しない場合、LVM ストレージはエラーを発生させずにデバイスを無視します。 |
|
| LVM ボリュームグループにシンプールを作成するための設定を含めます。 |
|
| シンプールの名前を指定します。 |
|
| シンプールを作成するための LVM ボリュームグループ内の領域の割合を指定します。 デフォルトでは、このフィールドは 90 に設定されています。設定できる最小値は 10、最大値は 90 です。 |
|
| シンプールで使用可能なストレージに基づいて追加のストレージをプロビジョニングするのに使用する係数を指定します。 たとえば、このフィールドが 10 に設定されている場合、シンプールで使用可能なストレージの量の最大 10 倍をプロビジョニングできます。 オーバープロビジョニングを無効にするには、このフィールドを 1 に設定します。 |
4.12.4.3.1. ボリュームグループへのデバイスの追加について
LVMCluster
CR の deviceSelector
フィールドには、LVM ボリュームグループに追加するデバイスへのパスを指定するための設定を含めます。
デバイスへのパスは、deviceSelector.paths
フィールド、deviceSelector.optionalPaths
フィールド、またはその両方で指定できます。deviceSelector.paths フィールドと deviceSelector.optionalPaths フィールドのどちらにもデバイスパスを指定しなかった場合、LVM Storage によって、サポートされている未使用のデバイスが LVM ボリュームグループに追加されます。
これらの名前は RHCOS 内の再起動後も変更される可能性があるため、/dev/sdX
などのシンボリック命名を使用してディスクを参照しないようにすることが推奨されます。代わりに、ディスク識別に一貫性を持たせるために、/dev/disk/by-path/
または /dev/disk/by-id/
などの安定した命名スキームを使用する必要があります。
この変更により、モニタリングで各ノードのインストールデバイスに関する情報が収集される場合、既存の自動化ワークフローの調整が必要になる可能性があります。
詳細は、RHEL ドキュメント を参照してください。
LVMCluster
CR に deviceSelector
フィールドを追加しない場合、デバイスが利用可能になると、LVM Storage は新しいデバイスを自動的に追加します。
LVM ストレージは、デバイスパスが存在する場合にのみ、デバイスを LVM ボリュームグループに追加します。
デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。
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 が作成されます。
各デバイスクラスの
storageClass
とvolumeSnapshotClass
。注記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. 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 カスタムリソースについて」セクションを確認した。
手順
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 # ...
次のコマンドを実行して、
LVMCluster
CR を作成します。$ oc create -f <file_name>
出力例
lvmcluster/lvmcluster created
検証
LVMCluster
CR がReady
状態であることを確認します。$ oc get lvmclusters.lvm.topolvm.io -o jsonpath='{.items[*].status.state}' -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
注記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
オプション: 各デバイスクラスに対して LVM Storage によって作成されたストレージクラスを表示するには、次のコマンドを実行します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE lvms-vg1 topolvm.io Delete WaitForFirstConsumer true 31m
オプション: 各デバイスクラスに対して LVM Storage によって作成されたボリュームスナップショットクラスを表示するには、次のコマンドを実行します。
$ oc get volumesnapshotclass
出力例
NAME DRIVER DELETIONPOLICY AGE lvms-vg1 topolvm.io Delete 24h
4.12.4.4.2. Web コンソールを使用した LVMCluster CR の作成
OpenShift Container Platform Web コンソールを使用して、ワーカーノード上に LVMCluster
CR を作成できます。
OpenShift Container Platform クラスターでは、LVMCluster
カスタムリソース (CR) のインスタンスを 1 つだけ作成できます。
前提条件
-
cluster-admin
権限を使用して OpenShift Container Platform クラスターにアクセスできる。 - LVM Storage がインストールされている。
- クラスターにワーカーノードがインストールされている。
- 「LVMCluster カスタムリソースについて」セクションを確認した。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators をクリックします。
-
openshift-storage
namespace で、LVM Storage をクリックします。 - Create LVMCluster をクリックし、Form view または YAML view のいずれかを選択します。
-
LVMCluster
CR の必要なパラメーターを設定します。 - Create をクリックします。
オプション:
LVMCLuster
CR を編集する場合は、次の操作を実行します。- LVMCluster タブをクリックします。
- Actions メニューから Edit LVMCluster を選択します。
-
YAML をクリックし、
LVMCLuster
CR の必要なパラメーターを編集します。 - Save をクリックします。
検証
-
LVMCLuster ページで、
LVMCluster
CR がReady
状態であることを確認します。 - オプション: 各デバイスクラスに対して LVM Storage によって作成された使用可能なストレージクラスを表示するには、Storage → StorageClasses をクリックします。
- オプション: 各デバイスクラスに対して LVM Storage によって作成された使用可能なボリュームスナップショットクラスを表示するには、Storage → VolumeSnapshotClasses をクリックします。
4.12.4.4.3. RHACM を使用した LVMCluster CR の作成
RHACM を使用して論理ボリュームマネージャー(LVM)ストレージをインストールした後、LVMCluster
カスタムリソース(CR)を作成する必要があります。
前提条件
- RHACM を使用して LVM Storage をインストールした。
-
cluster-admin
権限を持つアカウントを使用して RHACM クラスターにアクセスできる。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
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
次のコマンドを実行して、
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)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、
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)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators をクリックして、インストールされているすべての Operators を表示します。
-
openshift-storage
namespace で LVM Storage をクリックします。 - LVMCluster タブをクリックします。
- Actions から Delete LVMCluster を選択します。
- Delete をクリックします。
検証
-
LVMCLuster
ページで、LVMCluster
CR が削除されたことを確認します。
4.12.4.5.3. RHACM を使用した LVMCluster CR の削除
Red Hat Advanced Cluster Management (RHACM)を使用して論理ボリュームマネージャー(LVM)ストレージをインストールした場合は、RHACM を使用して LVMCluster
カスタムリソース(CR)を削除できます。
前提条件
-
cluster-admin
権限を持つユーザーとして RHACM クラスターにアクセスできる。 LVM ストレージによってプロビジョニングされた次のリソースを削除しました。
- 永続ボリューム要求 (PVC)
- ボリュームスナップショット
ボリュームのクローン
これらのリソースを使用しているアプリケーションも削除されている。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
次のコマンドを実行して、
LVMCluster
CR のConfigurationPolicy
CR を削除します。$ oc delete -f <file_name> -n <cluster_namespace> 1
- 1
- LVM Storage がインストールされている OpenShift Container Platform クラスターの namespace。
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
次のコマンドを実行して
Policy
CR を作成します。$ oc create -f <file_name> -n <namespace>
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
次のコマンドを実行して
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) を作成してストレージをプロビジョニングできます。
PVC を作成するには、PersistentVolumeClaim
オブジェクトを作成する必要があります。
前提条件
-
LVMCluster
CR が作成されている。
手順
-
OpenShift CLI (
oc
) にログインします。 次のような
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 storageClassName: lvms-vg1 4
- 1
- PVC の名前を指定します。
- 2
- ブロック PVC を作成するには、このフィールドを
Block
に設定します。ファイル PVC を作成するには、このフィールドをFilesystem
に設定します。 - 3
- ストレージサイズを指定します。論理ボリュームマネージャー(LVM)ストレージは、1 GiB (ギビバイト)単位で PVC をプロビジョニングします。要求されたストレージは、最も近い GiB に切り上げられます。プロビジョニングできるストレージサイズの合計は、LVM シンプールのサイズとオーバープロビジョニング係数によって制限されます。
- 4
storageClassName
フィールドの値はlvms-<device_class_name>
の形式である必要があります。ここで、<device_class_name>
は、LVMCluster
CR のdeviceClasses.name
フィールドの値になります。たとえば、deviceClasses.name
フィールドがvg1
に設定されている場合、storageClassName
フィールドをlvms-vg1
に設定する必要があります。
注記ストレージクラスの
volumeBindingMode
フィールドはWaitForFirstConsumer
に設定されます。以下のコマンドを実行して 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 クラスターのストレージをスケールアップする方法
新しいデバイスを既存のノードに追加することで、シングルノード OpenShift クラスターのストレージをスケールアップできます。
シングルノード OpenShift クラスターの既存のノードに新しいデバイスを追加するには、LVMCluster
カスタムリソース(CR)の deviceSelector
フィールドに新しいデバイスへのパスを追加する必要があります。
LVMCluster
CR に deviceSelector
フィールドを追加できるのは、LVMCluster
CR の作成時にのみです。LVMCluster
CR の作成時に deviceSelector
フィールドを追加しなかった場合は、LVMCluster
CR を削除し、deviceSelector
フィールドを含む新しい LVMCluster
CR を作成する必要があります。
LVMCluster
CR に deviceSelector
フィールドを追加しない場合、デバイスが利用可能になると、LVM Storage は新しいデバイスを自動的に追加します。
4.12.4.7.1. CLI を使用した単一ノード OpenShift クラスターのストレージをスケールアップする
OpenShift CLI (oc
)を使用して、シングルノード OpenShift クラスターの既存ノードのストレージ容量をスケールアップできます。
前提条件
- 論理ボリュームマネージャー(LVM)ストレージで使用される、シングルノード OpenShift クラスター上に追加の未使用デバイスがあります。
-
OpenShift CLI (
oc
) がインストールされている。 -
LVMCluster
カスタムリソース (CR) が作成されている。
手順
次のコマンドを実行して、
LVMCluster
CR を編集します。$ oc edit <lvmcluster_file_name> -n <namespace>
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
フィールド、またはその両方で指定できます。path
とoptionalPaths
の両方でデバイスパスを指定しなかった場合、サポートされている未使用のデバイスが LVM Storage によって LVM ボリュームグループに追加されます。LVM ストレージは、デバイスパスが存在する場合にのみ、デバイスを LVM ボリュームグループに追加します。 - 2
- デバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、
LVMCluster
CR はFailed
状態に移行します。 - 3
- オプションのデバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、LVM ストレージはエラーを発生させずにデバイスを無視します。
重要デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。
-
LVMCluster
CR を保存します。
4.12.4.7.2. Web コンソールを使用したシングルノード OpenShift クラスターのストレージのスケールアップ
OpenShift Container Platform Web コンソールを使用して、シングルノード OpenShift クラスターの既存ノードのストレージ容量をスケールアップできます。
前提条件
- 論理ボリュームマネージャー(LVM)ストレージで使用される、シングルノード OpenShift クラスター上に追加の未使用デバイスがあります。
-
LVMCluster
カスタムリソース (CR) が作成されている。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators をクリックします。
-
openshift-storage
namespace で LVM Storage をクリックします。 -
LVMCluster タブをクリックして、クラスター上に作成された
LVMCluster
CR を表示します。 - Actions メニューから Edit LVMCluster を選択します。
- YAML タブをクリックします。
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
フィールド、またはその両方で指定できます。path
とoptionalPaths
の両方でデバイスパスを指定しなかった場合、サポートされている未使用のデバイスが LVM Storage によって LVM ボリュームグループに追加されます。LVM ストレージは、デバイスパスが存在する場合にのみ、デバイスを LVM ボリュームグループに追加します。 - 2
- デバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、
LVMCluster
CR はFailed
状態に移行します。 - 3
- オプションのデバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、LVM ストレージはエラーを発生させずにデバイスを無視します。
重要デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。
- Save をクリックします。
4.12.4.7.3. RHACM を使用したシングルノード OpenShift クラスターのストレージをスケールアップする
RHACM を使用すると、シングルノード OpenShift クラスター内の既存のノードのストレージ容量をスケールアップできます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して RHACM クラスターにアクセスできる。 -
RHACM を使用して
LVMCluster
カスタムリソース (CR) を作成した。 - 論理ボリュームマネージャー(LVM)ストレージで使用される、シングルノード OpenShift クラスターごとに、追加の未使用デバイスがあります。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
次のコマンドを実行して、RHACM を使用して作成した
LVMCluster
CR を編集します。$ oc edit -f <file_name> -ns <namespace> 1
- 1
<file_name>
は、LVMCluster
CR の名前に置き換えます。
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
フィールド、またはその両方で指定できます。path と optionalPaths の両方でデバイスパスを指定しなかった場合、サポートされている未使用のデバイスが LVM Storage によって LVM ボリュームグループに追加されます。LVM ストレージは、デバイスパスが存在する場合にのみ、デバイスを LVM ボリュームグループに追加します。 - 2
- デバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、
LVMCluster
CR はFailed
状態に移行します。 - 3
- オプションのデバイスパスを指定します。このフィールドで指定されたデバイスパスが存在しない場合、LVM ストレージはエラーを発生させずにデバイスを無視します。
重要デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。
-
LVMCluster
CR を保存します。
4.12.4.8. 永続ボリューム要求の拡張
クラスターのストレージをスケールアップした後、既存の永続ボリューム要求 (PVC) を拡張できます。
PVC を拡張するには、PVC の requests.storage
フィールドを更新する必要があります。
前提条件
- 動的プロビジョニングが使用される。
-
PVC に関連付けられた
StorageClass
オブジェクトには、allowVolumeExpansion
フィールドがtrue
に設定されています。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、
spec.resources.requests.storage
フィールドの値を現在の値より大きい値に更新します。$ oc patch pvc <pvc_name> -n <application_namespace> -p \1 '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}' --type=merge 2
検証
サイズ変更が完了したことを確認するには、次のコマンドを実行します。
$ oc get pvc <pvc_name> -n <application_namespace> -o=jsonpath={.status.capacity.storage}
Logical Volume Manager (LVM)ストレージは、拡張中に
Resizing
条件を PVC に追加します。PVC の拡張後、Resizing
条件を削除します。
4.12.4.9. 永続ボリューム要求の削除
OpenShift CLI (oc
) を使用して、永続ボリューム要求 (PVC) を削除できます。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、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. ボリュームスナップショットの作成
シンプールの利用可能な容量とオーバープロビジョニングの制限に基づいて、ボリュームスナップショットを作成できます。ボリュームスナップショットを作成するには、VolumeSnapshot
オブジェクトを作成する必要があります。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。 -
永続ボリューム要求 (PVC) が
Bound
状態であることが確認されている。これは、一貫性のあるスナップショットに必要です。 - PVC へのすべての I/O が停止されている。
手順
-
OpenShift CLI (
oc
) にログインします。 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
注記使用可能なボリュームスナップショットクラスのリストを取得するには、次のコマンドを実行します。
$ oc get volumesnapshotclass
次のコマンドを実行して、ソース 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.2. ボリュームスナップショットの復元
ボリュームスナップショットを復元するには、dataSource.name
フィールドをボリュームスナップショットの名前に設定して、永続ボリューム要求 (PVC) を作成する必要があります。
復元される PVC はボリュームスナップショットおよびソース PVC とは切り離されています。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。 - ボリュームスナップショットが作成されている。
手順
-
OpenShift CLI (
oc
) にログインします。 ボリュームスナップショットを復元するための設定を使用して
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
次のコマンドを実行して、ボリュームスナップショットを作成した namespace に PVC を作成します。
$ oc create -f <file_name> -n <namespace>
検証
ボリュームスナップショットが復元されたことを確認するには、復元された PVC を使用してワークロードを作成してから、以下のコマンドを実行します。
$ 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.3. ボリュームスナップショットの削除
永続ボリューム要求 (PVC) のボリュームスナップショットを削除できます。
永続ボリューム要求 (PVC) を削除すると、LVM Storage は永続ボリューム要求のみを削除し、永続ボリューム要求のスナップショットは削除しません。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。 - 削除するボリュームスナップショットが使用されていないことを確認している。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、ボリュームのスナップショットを削除します。
$ oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
検証
ボリュームスナップショットが削除されたことを確認するには、次のコマンドを実行します。
$ oc get volumesnapshot -n <namespace>
削除されたボリュームのスナップショットは、このコマンドの出力には存在しません。
4.12.4.11. ボリュームクローンについて
ボリュームクローンは、既存の永続ボリューム要求 (PVC) の複製です。ボリュームクローンを作成して、データのポイントインタイムコピーを作成できます。
4.12.4.11.1. ボリュームクローンの作成
永続ボリューム要求 (PVC) のクローンを作成するには、ソース永続ボリューム要求を作成した namespace に PersistentVolumeClaim
オブジェクトを作成する必要があります。
クローン作成された PVC には書き込みアクセス権限があります。
前提条件
-
ソース PVC が
Bound
状態であることが確認されている。これは一貫性のあるクローンに必要です。
手順
-
OpenShift CLI (
oc
) にログインします。 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
次のコマンドを実行して、ソース PVC を作成した namespace に PVC を作成します。
$ oc create -f <file_name> -n <namespace>
検証
ボリュームクローンが作成されたことを確認するには、クローン作成された PVC を使用してワークロードを作成してから、以下のコマンドを実行します。
$ 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.2. ボリュームクローンの削除
ボリュームクローンを削除できます。
永続ボリューム要求 (PVC) を削除すると、LVM Storage はソース永続ボリューム要求のみを削除し、永続ボリューム要求のクローンは削除しません。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform にアクセスできる。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、クローン作成された PVC を削除します。
# oc delete pvc <clone_pvc_name> -n <namespace>
検証
ボリュームクローンが削除されたことを確認するには、次のコマンドを実行します。
$ oc get pvc -n <namespace>
削除されたボリュームクローンは、このコマンドの出力には存在しません。
4.12.4.12. シングルノード OpenShift クラスターでの LVM ストレージの更新
LVM ストレージを更新して、単一ノードの OpenShift バージョンとの互換性を確保できます。
前提条件
- 単一ノードの OpenShift クラスターを更新している。
- 以前のバージョンの LVM Storage がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを実行して、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.18 です。
次のコマンドを実行して、更新イベントを表示し、インストールが完了していることを確認します。
$ oc get events -n openshift-storage
出力例
... 8m13s Normal RequirementsUnknown clusterserviceversion/lvms-operator.v4.14 requirements not yet checked 8m11s Normal RequirementsNotMet clusterserviceversion/lvms-operator.v4.14 one or more requirements couldn't be found 7m50s Normal AllRequirementsMet clusterserviceversion/lvms-operator.v4.14 all requirements found, attempting install 7m50s Normal InstallSucceeded clusterserviceversion/lvms-operator.v4.14 waiting for install components to report healthy 7m49s Normal InstallWaiting clusterserviceversion/lvms-operator.v4.14 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.14 install strategy completed with no errors ...
検証
次のコマンドを実行して、LVM Storage のバージョンを確認します。
$ oc get subscription lvms-operator -n openshift-storage -o jsonpath='{.status.installedCSV}'
出力例
lvms-operator.v4.14
4.12.4.13. LVM Storage の監視
クラスターモニタリングを有効にするには、LVM Storage をインストールした namespace に次のラベルを追加する必要があります。
openshift.io/cluster-monitoring=true
RHACM でクラスターモニタリングを有効化する方法の詳細は、可観測性 と カスタムメトリクスの追加 を参照してください。
4.12.4.13.1. メトリクス
メトリクスを表示することで、LVM Storage を監視できます。
次の表は、topolvm
メトリクスを説明しています。
アラート | 説明 |
---|---|
| LVM シンプールで使用されているデータ領域の割合を示します。 |
| LVM シンプールで使用されているメタデータ領域の割合を示します。 |
| LVM シンプールのサイズをバイト単位で示します。 |
| LVM ボリュームグループ内の利用可能な領域をバイト単位で示します。 |
| LVM ボリュームグループのサイズをバイト単位で示します。 |
| LVM シンプールの利用可能なオーバープロビジョニングサイズをバイト単位で示します。 |
メトリクスは 10 分ごとに、または変更 (シンプールに新しい論理ボリュームが作成されるなど) があったときに更新されます。
4.12.4.13.2. アラート
シンプールとボリュームグループが最大ストレージ容量に達すると、それ以降の操作は失敗します。これにより、データ損失が発生する可能性があります。
LVM Storage は、シンプールとボリュームグループの使用量が特定の値を超えると、次のアラートを送信します。
アラート | 説明 |
---|---|
| このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 75% を超えるとトリガーされます。データの削除またはボリュームグループの拡張が必要です。 |
| このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 85% を超えるとトリガーされます。この場合、ボリュームグループは、かなりいっぱいになっています。データの削除またはボリュームグループの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
4.12.4.14. CLI を使用した LVM Storage のインストール
OpenShift CLI (oc
) を使用して LVM ストレージをアンインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてoc
にログインしている。 - LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
-
LVMCluster
カスタムリソース (CR) が削除されている。
手順
次のコマンドを実行して、LVM Storage Operator の
currentCSV
の値を取得します。$ oc get subscription.operators.coreos.com lvms-operator -n <namespace> -o yaml | grep currentCSV
出力例
currentCSV: lvms-operator.v4.15.3
次のコマンドを実行して、サブスクリプションを削除します。
$ oc delete subscription.operators.coreos.com lvms-operator -n <namespace>
出力例
subscription.operators.coreos.com "lvms-operator" deleted
次のコマンドを実行して、ターゲット 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)ストレージをアンインストールできます。
前提条件
-
cluster-admin
パーミッションを持つユーザーとして、シングルノード OpenShift クラスターにアクセスできます。 - LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
-
LVMCluster
カスタムリソース (CR) が削除されている。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators をクリックします。
-
openshift-storage
namespace で LVM Storage をクリックします。 - Details タブをクリックします。
- Actions メニューから Uninstall Operator をクリックします。
- オプション: プロンプトが表示されたら、Delete all operand instances for this operator チェックボックスを選択して、LVM Storage のオペランドインスタンスを削除します。
- Uninstall をクリックします。
4.12.4.16. RHACM を使用してインストールされた LVM Storage のアンインストール
RHACM を使用してインストールした LVM Storage をアンインストールするには、LVM Storage のインストールと設定用に作成した RHACM Policy
カスタムリソース (CR) を削除する必要があります。
前提条件
-
cluster-admin
権限を持つユーザーとして RHACM クラスターにアクセスできる。 LVM ストレージによってプロビジョニングされた次のリソースを削除しました。
- 永続ボリューム要求 (PVC)
- ボリュームスナップショット
ボリュームのクローン
これらのリソースを使用しているアプリケーションも削除されている。
-
RHACM を使用して作成した
LVMCluster
CR を削除した。
手順
-
OpenShift CLI (
oc
) にログインします。 次のコマンドを使用して、LVM Storage のインストールと設定用に作成した RHACM
Policy
CR を削除します。$ oc delete -f <policy> -n <namespace> 1
- 1
<policy>
は、Policy
CR YAML ファイルの名前に置き換えます。
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
次のコマンドを実行して
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.14 --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
) にログインしている。
手順
次のコマンドを実行して、PVC のリストを取得します。
$ oc get pvc
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvms-test Pending lvms-vg1 11s
次のコマンドを実行して、
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
) にログインしている。
手順
以下のコマンドを実行して、
LVMCluster
CR が存在することを確認します。$ oc get lvmcluster -n openshift-storage
出力例
NAME AGE my-lvmcluster 65m
-
LVMCluster
CR が存在しない場合は、LVMCluster
CR を作成します。詳細は、「LVMCluster カスタムリソースを作成する方法」を参照してください。 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
-
topolvm-controller
topolvm-node
topolvm-node
Pod がInit
状態のままになっている場合は、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>
などの一般的なエラーメッセージが表示されます。一般的なエラーメッセージの後には、特定のボリューム障害のエラーメッセージが続きます。
以下の表は、ボリューム障害のエラーメッセージを説明しています。
エラーメッセージ | 説明 |
---|---|
| ボリュームがすでに存在するかどうかを確認する際に問題が発生したことを示します。ボリューム検証の失敗は、ネットワーク接続の問題やその他の障害によって発生する可能性があります。 |
| 使用可能な永続ボリューム (PV) が PVC の要件と一致しない場合、ボリュームのバインドに失敗する可能性があります。 |
| このエラーは、ボリュームをノードにマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。 |
| このエラーは、ノードからボリュームをアンマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。 |
|
このエラーは、 |
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。
手順
次のコマンドを実行して、PVC に関連付けられたイベントを検査します。
$ oc describe pvc <pvc_name> 1
- 1
<pvc_name>
を PVC の名前に置き換えます。
- 問題が発生しているホストへの直接接続を確立します。
- ディスクの問題を解決します。
次のステップ
- ディスクの問題を解決した後もボリューム障害メッセージが続く場合や再発する場合は、強制クリーンアップを実行する必要があります。詳細は、「強制クリーンアップの実行」を参照してください。
関連情報
4.12.4.18.5. 強制クリーンアップの実行
トラブルシューティング手順を完了した後もディスクまたはノード関連の問題が解決しない場合は、強制クリーンアップを実行する必要があります。強制クリーンアップは、永続的な問題に対処し、論理ボリュームマネージャー (LVM) ストレージが確実に適切に機能するために使用されます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。 - LVM ストレージを使用して作成されたすべての永続ボリューム要求 (PVC) が削除されている。
- LVM ストレージを使用して作成された PVC を使用している Pod を停止している。
手順
次のコマンドを実行して、
openshift-storage
namespace に切り替えます。$ oc project openshift-storage
以下のコマンドを実行して、
LogicalVolume
カスタムリソース (CR) が存在するか確認します。$ oc get logicalvolume
以下のコマンドを実行して、
LVMVolumeGroup
CR が存在するか確認します。$ oc get lvmvolumegroup
以下のコマンドを実行して、
LVMVolumeGroupNodeStatus
CR を削除します。$ oc delete lvmvolumegroupnodestatus --all
次のコマンドを実行して、
LVMCluster
CR を削除します。$ oc delete lvmcluster --all
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.14 は、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 レジストラーを含むデーモンセットが必要です。
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 外からはアクセスできません。
通常、attach
、detach
、provision
、および 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 のクローン作成 | CSI のサイズ変更 | インラインの一時ボリューム |
---|---|---|---|---|
AliCloud Disk |
✅ |
- |
✅ |
- |
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 |
- |
- |
✅ |
✅ |
OpenStack Cinder |
✅ |
✅ |
✅ |
- |
OpenShift Data Foundation |
✅ |
✅ |
✅ |
- |
OpenStack Manila |
✅ |
- |
- |
- |
Shared Resource |
- |
- |
- |
✅ |
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 にアタッチする必要があります。
CSI ドライバーが上記の表に記載されていない場合は、CSI ストレージベンダーが提供するインストール手順に従って、サポートされている CSI 機能を使用する必要があります。
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
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 セキュリティープロファイルの適用動作を説明しています。
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 セキュリティープロファイルで警告がいつ発生するかを示しています。
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 セキュリティープロファイルに適用される監査アノテーションを示しています。
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 の作成および破棄時にボリューム操作のすべてのフェーズをすべて処理できます。
手順
-
Pod
オブジェクト定義を作成し、これをファイルに保存します。 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 で使用されるボリュームの名前。
直前のステップで保存したオブジェクト定義ファイルを作成します。
$ oc create -f my-csi-app.yaml
5.2.4. 関連情報
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 を削除してから、スナップショットを作成してください。
手順
ボリュームのスナップショットを動的に作成するには、以下を実行します。
以下の 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
オブジェクトを使用することもできます。以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。
$ oc create -f volumesnapshotclass.yaml
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
以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。
$ oc create -f volumesnapshot-dynamic.yaml
スナップショットを手動でプロビジョニングするには、以下を実行します。
上記のようにボリュームスナップショットクラスを定義するだけでなく、
volumeSnapshotContentName
パラメーターの値をスナップショットのソースとして指定します。volumesnapshot-manual.yaml
apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: snapshot-demo spec: source: volumeSnapshotContentName: mycontent 1
- 1
- 事前にプロビジョニングされたスナップショットには、
volumeSnapshotContentName
パラメーターが必要です。
以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。
$ oc create -f volumesnapshot-manual.yaml
検証
スナップショットがクラスターで作成されると、スナップショットに関する追加情報が利用可能になります。
作成したボリュームスナップショットの詳細を表示するには、以下のコマンドを実行します。
$ 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 データを別の低コストの場所に移動する場合があり、これには数分の時間がかかる可能性があります。
ボリュームのスナップショットが作成されたことを確認するには、以下のコマンドを実行します。
$ oc get volumesnapshotcontent
実際のコンテンツへのポインターが表示されます。
boundVolumeSnapshotContentName
フィールドにデータが設定される場合、VolumeSnapshotContent
オブジェクトが存在し、スナップショットが作成されています。-
スナップショットの準備が完了していることを確認するには、
VolumeSnapshot
オブジェクトにreadyToUse: true
があることを確認します。
5.4.6. ボリュームスナップショットの削除
OpenShift Container Platform によるボリュームスナップショットの削除方法を設定できます。
手順
以下の例のように、
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
オブジェクトを削除すると、コンテンツは残ります。スナップショット自体はストレージバックエンドにも保持されます。
以下のコマンドを入力してボリュームスナップショットを削除します。
$ oc delete volumesnapshot <volumesnapshot_name>
出力例
volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted
削除ポリシーが
Retain
に設定されている場合は、以下のコマンドを入力してボリュームスナップショットのコンテンツを削除します。$ oc delete volumesnapshotcontent <volumesnapshotcontent_name>
オプション:
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
に設定された後に、そのリソースを使用して、スナップショットからのデータが事前に設定されている新規ボリュームをプロビジョニングできます。
前提条件
- 実行中の OpenShift Container Platform クラスターにログインしている。
- ボリュームスナップショットをサポートする Container Storage Interface (CSI) ドライバーを使用して作成される永続ボリューム要求 (PVC)。
- ストレージバックエンドをプロビジョニングするストレージクラス。
- ボリュームスナップショットが作成され、使用できる状態である。
手順
以下のように PVC に
VolumeSnapshot
データソースを指定します。pvc-restore.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim-restore spec: storageClassName: csi-hostpath-sc dataSource: name: mysnap 1 kind: VolumeSnapshot 2 apiGroup: snapshot.storage.k8s.io 3 accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
以下のコマンドを実行して PVC を作成します。
$ oc create -f pvc-restore.yaml
以下のコマンドを実行して、復元された PVC が作成されていることを確認します。
$ oc get pvc
myclaim-restore
などの新規 PVC が表示されます。
5.5. CSI ボリュームのクローン作成
ボリュームのクローン作成により、既存の永続ボリュームが複製されます。これは OpenShift Container Platform におけるデータ損失からの保護に役立ちます。この機能は、サポートされている Container Storage Interface (CSI) ドライバーでのみ利用できます。CSI ボリュームクローンをプロビジョニングする前に、永続ボリューム を理解しておく必要があります。
5.5.1. CSI ボリュームのクローン作成の概要
Container Storage Interface (CSI) ボリュームクローンは、特定の時点における既存の永続ボリュームの複製です。
ボリュームのクローン作成はボリュームのスナップショットに似ていますが、より効率的な方法です。たとえば、クラスター管理者は、既存のクラスターボリュームの別のインスタンスを作成してクラスターボリュームを複製できます。
クローン作成により、バックエンドのデバイスでは、新規の空のボリュームが作成されるのではなく、指定したボリュームの複製が作成されます。動的プロビジョニングの後には、標準のボリュームを使用するのと同じように、ボリュームクローンを使用できます。
クローン作成に必要な新しい API オブジェクトはありません。PersistentVolumeClaim
オブジェクトの既存の dataSource
フィールドは、同じ namespace の既存の PersistentVolumeClaim の名前を許可できるように拡張されます。
5.5.1.1. サポートの制限
デフォルトで、OpenShift Container Platform は以下の制限の下で CSI ボリュームのクローン作成をサポートします。
- 宛先永続ボリューム要求 (PVC) はソース PVC と同じ namespace に存在する必要があります。
クローン作成は、別のストレージクラスでサポートされています。
- 宛先ボリュームは、ソースと異なるストレージクラスでも同じにすることができます。
-
デフォルトのストレージクラスを使用し、
spec
でstorageClassName
を省略できます。
- サポートは CSI ドライバーでのみ利用可能です。インツリーおよび FlexVolumes はサポートされません。
- CSI ドライバーは、ボリュームのクローン作成機能を実装していない可能性もあります。詳細は、CSI ドライバーのドキュメントを参照してください。
5.5.2. CSI ボリュームクローンのプロビジョニング
CSI ボリュームクローンのプロビジョニングは、クローン作成された永続ボリューム要求 (PVC) API オブジェクトの作成によってトリガーされます。クローンは、他の永続ボリュームと同じルールに従って、別の PVC の内容を事前に設定します。例外として、同じ namespace の既存 PVC を参照する dataSource
を追加する必要があります。
前提条件
- 実行中の OpenShift Container Platform クラスターにログインしている。
- PVC がボリュームのクローン作成をサポートする CSI ドライバーを使用して作成されている。
- ストレージバックエンドが動的プロビジョニング用に設定されている。静的プロビジョナーのクローン作成のサポートは利用できません。
手順
既存の PVC から PVC のクローンを作成するには、以下を実行します。
以下の YAML によって記述される
PersistentVolumeClaim
オブジェクトを使用してファイルを作成し、保存します。pvc-clone.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-1-clone namespace: mynamespace spec: storageClassName: csi-cloning 1 accessModes: - ReadWriteOnce resources: requests: storage: 5Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
- 1
- ストレージのバックエンドをプロビジョニングするストレージクラスの名前。デフォルトのストレージクラスを使用でき、
storageClassName
は仕様で省略できます。
以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。
$ oc create -f pvc-clone.yaml
新規の PVC
pvc-1-clone
が作成されます。以下のコマンドを実行して、ボリュームクローンが作成され、準備状態にあることを確認します。
$ oc get pvc pvc-1-clone
pvc-1-clone
は、これがBound
であることを示します。これで、新たにクローン作成された PVC を使用して Pod を設定する準備が整いました。
YAML によって記述される
Pod
オブジェクトと共にファイルを作成し、保存します。以下に例を示します。kind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: myfrontend image: dockerfile/nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: pvc-1-clone 1
- 1
- CSI ボリュームのクローン作成の操作時に作成されるクローン作成された PVC。
作成された
Pod
オブジェクトは、元のdataSource
PVC とは別に、クローンされた PVC の使用、クローン、スナップショット、または削除を実行できるようになりました。
5.6. デフォルトストレージクラスの管理
5.6.1. 概要
デフォルトのストレージクラスを管理すると、複数の異なる目的を達成できます。
- 動的プロビジョニングを無効にして静的プロビジョニングを強制します。
- 他の優先ストレージクラスがある場合に、storage operator による最初のデフォルトストレージクラスの作成を阻止します。
- デフォルトのストレージクラスに名前を付け直すか変更します。
これらの目的を達成するには、ClusterCSIDriver
オブジェクトの spec.storageClassState
フィールドの設定を変更します。このフィールドで可能な設定は以下のとおりです。
- Managed: (デフォルト) コンテナーストレージインターフェイス (CSI) オペレーターがデフォルトのストレージクラスをアクティブに管理しているため、クラスター管理者によってデフォルトのストレージクラスに対して行われた手動変更のほとんどは削除され、デフォルトのストレージクラスは継続的に再作成されます。手動で削除しようとしました。
- Unmanaged: デフォルトのストレージクラスを変更できます。CSI Operator はストレージクラスをアクティブに管理しないため、自動的に作成するデフォルトのストレージクラスを調整します。
- Removed: CSI Operator はデフォルトのストレージクラスを削除します。
デフォルトのストレージクラスの管理は、次の Container Storage Interface (CSI) ドライバー operator によってサポートされています。
5.6.2. Web コンソールを使用したデフォルトのストレージクラスの管理
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
- クラスター管理者権限でクラスターにアクセスできる。
手順
Web コンソールを使用してデフォルトのストレージクラスを管理するには、次の手順を実行します。
- Web コンソールにログインします。
- Administration > CustomResourceDefinitions をクリックします。
-
CustomResourceDefinitions ページで、
clustercsidriver
と入力して、ClusterCSIDriver
オブジェクトを見つけます。 - ClusterCSIDriver をクリックし、Instances タブをクリックします。
- 目的のインスタンスの名前をクリックし、YAML タブをクリックします。
spec.storageClassState
フィールドを追加し、値をManaged
、Unmanaged
、またはRemoved
に設定します。例
... spec: driverConfig: driverType: '' logLevel: Normal managementState: Managed observedConfig: null operatorLogLevel: Normal storageClassState: Unmanaged 1 ...
- 1
spec.storageClassState
フィールドが "Unmanaged" に設定されている
- Save をクリックします。
5.6.3. CLI を使用したデフォルトのストレージクラスの管理
前提条件
- クラスター管理者権限でクラスターにアクセスできる。
手順
CLI を使用してストレージクラスを管理するには、次のコマンドを実行します。
oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 1
- 1
- ここで、
${STATE}
は "削除"、"管理"、または "非管理" です。$DRIVERNAME
はプロビジョナー名です。コマンドoc get sc
を実行すると、プロビジョナー名を見つけることができます。
5.6.4. デフォルトのストレージクラスが存在しないか、複数のデフォルトストレージクラスがある
5.6.4.1. 複数のデフォルトのストレージクラス
デフォルト以外のストレージクラスをデフォルトとしてマークし、既存のデフォルトストレージクラスの設定を解除しない場合、またはデフォルトのストレージクラスがすでに存在するときにデフォルトのストレージクラスを作成した場合は、複数のデフォルトストレージクラスが発生する可能性があります。複数のデフォルトストレージクラスが存在する場合、デフォルトストレージクラス (pvc.spec.storageClassName
=nil) を要求するすべての永続ボリューム要求 (PVC) は、そのストレージクラスのデフォルトステータスと管理者に関係なく、最後に作成されたデフォルトストレージクラスを取得します。アラートダッシュボードで、複数のデフォルトストレージクラス MultipleDefaultStorageClasses
があるというアラートを受け取ります。
5.6.4.2. デフォルトのストレージクラスなし
PVC が存在しないデフォルトのストレージクラスの使用を試みる可能性があるシナリオは 2 つあります。
- 管理者がデフォルトのストレージクラスを削除するか、デフォルト以外としてマークした後、ユーザーがデフォルトのストレージクラスを要求する PVC を作成します。
- インストール中に、インストーラーは、まだ作成されていないデフォルトのストレージクラスを要求する PVC を作成します。
前述のシナリオでは、PVC は無期限に保留状態のままになります。
OpenShift Container Platform は、PVC が保留状態にならないように、デフォルトのストレージクラスを遡って PVC に割り当てる機能を提供します。この機能を有効にすると、デフォルトのストレージクラスが存在しないときに作成されたデフォルトのストレージクラスを要求する PVC は、デフォルトのストレージクラスが作成されるか、既存のストレージクラスの 1 つがデフォルトとして宣言されるまで、保留状態のままになります。デフォルトのストレージクラスが作成または宣言されるとすぐに、PVC は新しいデフォルトのストレージクラスを取得します。
Retroactive なデフォルトのストレージクラスの割り当ては、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
5.6.4.2.1. 手順
Retroactive のデフォルトストレージクラスの割り当てを有効にするには、以下を実行します。
機能ゲートを有効にします (ノード → クラスターの操作 → 機能ゲートを使用した機能の有効化 を参照してください)。
重要機能ゲートを使用してテクノロジープレビュー機能をオンにした後にそれらをオフにすることはできません。その結果、クラスターのアップグレードはできなくなります。
次の設定例では、Retroactive なデフォルトのストレージクラスの割り当てと、その他すべてのテクノロジープレビュー機能が有効になります。
apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster spec: featureSet: TechPreviewNoUpgrade 1 ...
- 1
- Retroactive のデフォルトストレージクラスの割り当てを有効にします。
5.6.5. デフォルトストレージクラスの変更
次の手順を使用して、デフォルトのストレージクラスを変更します。
たとえば、gp3
と standard
の 2 つのストレージクラスがあり、デフォルトのストレージクラスを gp3
から standard
に変更する必要がある場合などです。
前提条件
- クラスター管理者権限でクラスターにアクセスできる。
手順
デフォルトのストレージクラスを変更するには、以下を実行します。
ストレージクラスを一覧表示します。
$ oc get storageclass
出力例
NAME TYPE gp3 (default) kubernetes.io/aws-ebs 1 standard kubernetes.io/aws-ebs
- 1
(default)
はデフォルトのストレージクラスを示します。
目的のストレージクラスをデフォルトにします。
目的のストレージクラスに、次のコマンドを実行して
storageclass.kubernetes.io/is-default-class
アノテーションをtrue
に設定します。$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
注記短期間であれば、複数のデフォルトのストレージクラスを使用できます。ただし、最終的には 1 つのデフォルトのストレージクラスのみが存在することを確認する必要があります。
複数のデフォルトストレージクラスが存在する場合、デフォルトストレージクラス (
pvc.spec.storageClassName
=nil) を要求するすべての永続ボリューム要求 (PVC) は、そのストレージクラスのデフォルトステータスと管理者に関係なく、最後に作成されたデフォルトストレージクラスを取得します。アラートダッシュボードで、複数のデフォルトストレージクラスMultipleDefaultStorageClasses
があるというアラートを受け取ります。古いデフォルトストレージクラスからデフォルトのストレージクラス設定を削除します。
古いデフォルトのストレージクラスの場合は、次のコマンドを実行して
storageclass.kubernetes.io/is-default-class
アノテーションの値をfalse
に変更します。$ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
変更内容を確認します。
$ oc get storageclass
出力例
NAME TYPE gp3 kubernetes.io/aws-ebs standard (default) kubernetes.io/aws-ebs
5.7. CSI の自動移行
従来 OpenShift Container Platform に同梱されていた in-tree のストレージドライバーは非推奨となり、同等の Container Storage Interface (CSI) ドライバーに置き換えられます。OpenShift Container Platform は、ツリー内ボリュームプラグインの同等の CSI ドライバーへの自動移行を提供します。
5.7.1. 概要
この機能は、ツリー内ストレージプラグインを使用してプロビジョニングされたボリュームを、対応するコンテナーストレージインターフェイス (CSI) ドライバーに自動的に移行します。
このプロセスはデータ移行を実行しません。OpenShift Container Platform は、メモリー内の永続ボリュームオブジェクトしか変換しません。その結果、変換された永続ボリュームオブジェクトはディスクに保存されず、その内容も変更されません。CSI 自動移行はシームレスに行ってください。この機能により、既存のすべての API オブジェクト (例: PersistentVolume
、PersistentVolumeClaim
、および StorageClass
) を使用する方法が変更されることはありません。
次のツリー内ドライバーから CSI ドライバーが自動的に移行されます。
- Azure Disk
- OpenStack Cinder
- Amazon Web Services (AWS) Elastic Block Storage (EBS)
- Google Compute Engine Persistent Disk (GCP PD)
- Azure File
- VMware vSphere (vSphere の特定の移行動作については、以下の情報を参照してください)
これらのボリュームタイプの CSI 移行は一般提供 (GA) であるとみなされ、手動の介入は必要ありません。
元のツリー内ストレージプラグインがサポートしていない場合、ツリー内永続ボリューム (PV) または永続ボリュームクレーム (PVC) の CSI 自動移行では、スナップショットや拡張などの新しい CSI ドライバー機能は有効になりません。
5.7.2. ストレージクラスへの影響
新規の OpenShift Container Platform 4.13 以降のインストールでは、デフォルトのストレージクラスは CSI ストレージクラスになります。このストレージクラスを使用してプロビジョニングされるすべてのボリュームは CSI 永続ボリューム (PV) です。
4.12 以前から 4.13 にアップグレードされたクラスターの場合、CSI ストレージクラスが作成され、アップグレード前にデフォルトのストレージクラスが設定されていない場合にはそれがデフォルトに設定されます。ごく稀なケースとして、同じ名前のストレージクラスがある場合、既存のストレージクラスは変更されません。既存のインツリーストレージクラスはそのまま残り、既存の in-tree PV で機能するボリューム拡張などの特定の機能で必要になる場合があります。インツリーストレージプラグインを参照するストレージクラスは機能し続けますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。
デフォルトのストレージクラスを変更するには、デフォルトのストレージクラスの変更 を参照してください。
5.7.3. vSphere の自動移行
5.7.3.1. OpenShift Container Platform の新規インストール
OpenShift Container Platform 4.13 以降の新規インストールの場合、自動移行はデフォルトで有効になっています。
5.7.3.2. OpenShift Container Platform 4.13 から 4.14 への更新
vSphere in-tree 永続ボリューム (PV) を使用していて、OpenShift Container Platform 4.13 から 4.14 に更新する場合は、vSphere vCenter および ESXI ホストを 7.0 Update 3L または 8.0 Update 2 に更新します。更新しないと、OpenShift Container Platform の更新がブロックされます。vSphere を更新すると、OpenShift Container Platform の更新が行われ、自動移行がデフォルトで有効になります。
vSphere を更新しない場合は、管理者承認を実行して、OpenShift Container Platform の更新を続行できます。
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-127-vsphere-migration-in-4.14":"true"}}' --type=merge
vSphere 7.0 Update 3L または 8.0 Update 2 に 更新せずに 管理者承認を使用して OpenShift Container Platform 4.14 に更新すると、OpenShift Container Platform 4.14 で CSI 移行が有効 (デフォルト) になっているために既知の問題が発生する可能性があります。管理者承認に進む前に、こちらのナレッジベースの記事 をよくお読みください。
5.7.3.3. OpenShift Container Platform 4.12 から 4.14 への更新
vSphere in-tree 永続ボリューム (PV) を使用していて、OpenShift Container Platform 4.12 から 4.14 に更新する場合は、vSphere vCenter および ESXI ホストを 7.0 Update 3L または 8.0 Update 2 に更新します。更新しないと、OpenShift Container Platform の更新がブロックされます。vSphere を更新すると、OpenShift Container Platform の更新が行われ、自動移行がデフォルトで有効になります。
vSphere を更新しない場合は、次のコマンドを 両方 実行して管理者承認を実行して、OpenShift Container Platform の更新を続行できます。
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-126-vsphere-migration-in-4.14":"true"}}' --type=merge
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-127-vsphere-migration-in-4.14":"true"}}' --type=merge
vSphere 7.0 Update 3L または 8.0 Update 2 に 更新せずに 管理者承認を使用して OpenShift Container Platform 4.14 に更新すると、OpenShift Container Platform 4.14 で CSI 移行が有効 (デフォルト) になっているために既知の問題が発生する可能性があります。管理者承認に進む前に、こちらのナレッジベースの記事 をよくお読みください。
OpenShift Container Platform 4.12 から 4.14 への更新には、Extended Update Support (EUS) から EUS への更新が伴います。このタイプの更新による影響とその実行方法については、以下の 関連情報 セクションで EUS 間の更新 リンクを参照してください。
関連情報
5.8. ノードの非正常なシャットダウン後に CSI ボリュームを切り離す
この機能により、ノードが正常にダウンしなかった場合に、コンテナーストレージインターフェイス (CSI) ドライバーがボリュームを自動的に切り離すことができます。
非正常なノードシャットダウン後の CSI ボリュームの接続解除は、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
5.8.1. 概要
正常なノードシャットダウンは、kubelet のノードシャットダウンマネージャーが今後のノードシャットダウンアクションを検出したときに発生します。非正常なシャットダウンは、kubelet がノードのシャットダウンアクションを検出しない場合に発生します。これは、システムまたはハードウェアの障害が原因で発生する可能性があります。また、shutdown コマンドが Linux 上の kubelet で使用される Inhibitor Locks メカニズムをトリガーしない場合、またはユーザーエラー (たとえば shutdownGracePeriod および shutdownGracePeriodCriticalPods の詳細が正しく設定されていない場合) が原因で、kubelet はノードのシャットダウンアクションを検出できないことがあります。そのノード。
この機能を使用すると、非正常なノードのシャットダウンが発生したときに、ノードに out-of-service
テイントを手動で追加して、ボリュームをノードから自動的に切断できるようにすることができます。
5.8.2. 自動ボリューム切断のためにサービス外テイントを手動で追加する
前提条件
- クラスター管理者権限でクラスターにアクセスできる。
手順
非正常なノードのシャットダウン後にボリュームがノードから自動的に切り離されるようにするには、次の手順を実行します。
- ノードが異常であると検出されたら、ワーカーノードをシャットダウンします。
次のコマンドを実行してステータスを確認し、ノードがシャットダウンされていることを確認します。
oc get node <node name> 1
- 1
- <node name> = 正常にシャットダウンされていないノードの名前
重要ノードが完全にシャットダウンされていない場合は、ノードのテイントを続行しないでください。ノードがまだ稼働していてテイントが適用されると、ファイルシステムの破損が発生する可能性があります。
次のコマンドを実行して、対応するノードオブジェクトをテイントします。
oc adm taint node <node name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 1
- 1
- <node name> = 正常にシャットダウンされていないノードの名前
テイントが適用されると、ボリュームはシャットダウンノードから切り離され、ディスクを別のノードに接続できるようになります。
例
結果の YAML ファイルは次のようになります。
spec: taints: - effect: NoExecute key: node.kubernetes.io/out-of-service value: nodeshutdown
- ノードを再起動します。
- 汚れを取り除きます。
5.9. AliCloud Disk CSI Driver Operator
5.9.1. 概要
OpenShift Container Platform は、Alibaba AliCloud Disk Storage の Container Storage Interface (CSI) ドライバーを使用して、永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 について理解しておくことが推奨されます。
AliCloud Disk ストレージアセットにマウントする CSI でプロビジョニングされた PV を作成するには、OpenShift Container Platform はデフォルトで AliCloud Disk CSI Driver Operator および AliCloud Disk CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
AliCloud Disk CSI Driver Operator は、永続ボリューム要求 (PVC) の作成に使用できるストレージクラス (
alicloud-disk
) を提供します。AliCloud Disk CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。 - AliCloud Disk CSI ドライバー を使用すると、AliCloud Disk PV を作成し、マウントできます。
5.9.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
関連情報
5.10. AWS Elastic Block Store CSI ドライバー Operator
5.10.1. 概要
OpenShift Container Platform は、AWS EBS CSI ドライバー を使用して永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
AWS EBS ストレージアセットにマウントする CSI プロビジョニングされた PV を作成するために、OpenShift Container Platform は、デフォルトで AWS EBS CSI Driver Operator (Red Hat オペレーター) と AWS EBS CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
- AWS EBS CSI Driver Operator は、PVC を作成するために使用できる StorageClass をデフォルトで提供します。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。AWS Elastic Block Store を使用した永続ストレージ で説明されているように、AWS EBS StorageClass を作成するオプションもあります。
- AWS EBS CSI ドライバー を使用すると、AWS EBS PV を作成し、マウントできます。
AWS EBS CSI Operator およびドライバーを OpenShift Container Platform 4.5 クラスターにインストールしている場合、OpenShift Container Platform 4.14 に更新する前に 4.5 Operator およびドライバーをアンインストールする必要があります。
5.10.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
OpenShift Container Platform は、デフォルトで CSI プラグインを使用して Amazon Elastic Block Store (Amazon EBS) ストレージをプロビジョニングします。
OpenShift Container Platform での AWS EBS 永続ボリュームの動的プロビジョニングに関する詳細は、Amazon Elastic Block Store を使用した永続ストレージ を参照してください。
5.10.3. ユーザー管理型の暗号化
ユーザー管理型の暗号化機能を使用すると、インストール時に OpenShift Container Platform ノードのルートボリュームを暗号化するキーを指定でき、すべてのマネージドストレージクラスはこれらのキーを使用してプロビジョニングされたストレージボリュームを暗号化できます。install-config YAML ファイルの platform.<cloud_type>.defaultMachinePlatform
フィールドにカスタムキーを指定する必要があります。
この機能は、次のストレージタイプをサポートします。
- Amazon Web Services (AWS) Elastic Block storage (EBS)
- Microsoft Azure Disk ストレージ
- Google Cloud Platform (GCP) 永続ディスク (PD) ストレージ
ストレージクラスに暗号化キーが定義されていない場合は、ストレージクラスに encrypted: "true"
のみを設定します。AWS EBS CSI ドライバーは、AWS 管理の alias/aws/ebs を使用します。これは、プロビジョニングされたストレージボリュームを暗号化するために、デフォルトで各リージョンで Amazon EBS によって自動的に作成されます。さらに、マネージドストレージクラスはすべて encrypted: "true"
設定になっています。
Amazon EBS のユーザーが管理する暗号化を使用したインストールの詳細は、インストール設定パラメーター を参照してください。
5.11. AWS Elastic File Service CSI Driver Operator
5.11.1. 概要
OpenShift Container Platform は、AWS Elastic File Service (EFS) の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
AWS EFS CSI Driver Operator をインストールすると、OpenShift Container Platform はデフォルトで AWS EFS CSI Operator と AWS EFS CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。これにより、AWS EFS CSI Driver Operator は、AWS EFS アセットにマウントする CSI がプロビジョニングする PV を作成することができます。
-
AWS EFS CSI Driver Operatorをインストールしても、永続ボリューム要求 (PVC) の作成に使用するストレージクラスがデフォルトで作成されません。ただし、AWS EFS
StorageClass
を手動で作成することは可能です。AWS EFS CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。 - AWS EFS CSI ドライバー を使用すると、AWS EFS PV を作成し、マウントできます。
AWS EFS はリージョナルボリュームのみをサポートしており、ゾーンボリュームはサポートしていません。
5.11.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.11.3. AWS EFS CSI Driver Operator の設定
- AWS EFS と AWS Secure Token Service (STS) を使用している場合は、STS の Amazon リソース名 (ARN) ロールを取得します。これは、AWS EFS CSI Driver Operator をインストールするために必要です。
- AWS EFS CSI Driver Operator をインストールします。
- AWS EFS CSI ドライバーをインストールします。
5.11.3.1. Security Token Service の Amazon リソース名ロールの取得
この手順では、AWS Security Token Service (STS) 上の OpenShift Container Platform で AWS EFS CSI Driver Operator を設定するための Amazon リソース名 (ARN) ロールを取得する方法を説明します。
AWS EFS CSI Driver Operator をインストールする前に、この手順を実行してください (AWS EFS CSI Driver Operator のインストール に記載された手順を参照)。
前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
- AWS アカウントの認証情報。
手順
ARN ロールは複数の方法で取得できます。次の手順は、クラスターのインストールと同じ概念と CCO ユーティリティー (ccoctl
) バイナリーツールを使用する 1 つの方法を示しています。
STS を使用して AWS EFS CSI Driver Operator を設定するための ARN ロールを取得するには、以下を実行します。
-
STS でクラスターをインストールするために使用した OpenShift Container Platform リリースイメージから
ccoctl
を展開します。詳細は、「Cloud Credential Operator ユーティリティーの設定」を参照してください。 以下の例に示されているように EFS
CredentialsRequest
YAML ファイルを作成および保存してから、それをcredrequests
ディレクトリーに配置します。例
apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: openshift-aws-efs-csi-driver namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - action: - elasticfilesystem:* effect: Allow resource: '*' secretRef: name: aws-efs-cloud-credentials namespace: openshift-cluster-csi-drivers serviceAccountNames: - aws-efs-csi-driver-operator - aws-efs-csi-driver-controller-sa
ccoctl
ツールを実行して AWS に新規の IAM ロールを生成し、その YAML ファイルをローカルファイルシステムに作成します (<path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml
)。$ ccoctl aws create-iam-roles --name=<name> --region=<aws_region> --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
-
name=<name>
は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。 -
region=<aws_region>
は、クラウドリソースが作成される AWS リージョンです。 -
dir=<path_to_directory_with_list_of_credentials_requests>/credrequests
は、前のステップの EFS CredentialsRequest ファイルが含まれるディレクトリーです。 <aws_account_id>
は AWS アカウント ID です。例
$ ccoctl aws create-iam-roles --name my-aws-efs --credentials-requests-dir credrequests --identity-provider-arn arn:aws:iam::123456789012:oidc-provider/my-aws-efs-oidc.s3.us-east-2.amazonaws.com
出力例
2022/03/21 06:24:44 Role arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud- created 2022/03/21 06:24:44 Saved credentials configuration to: /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml 2022/03/21 06:24:45 Updated Role policy for Role my-aws-efs-openshift-cluster-csi-drivers-aws-efs-cloud-
-
前の手順の 出力例 の最初の行から、ARN ロールをコピーします。ARN ロールは、"Role" と "created" の間にあります。この例では、ARN ロールは "arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud" です。
AWS EFS CSI Driver Operator をインストールするときに、ARN ロールが必要になります。
次のステップ
5.11.3.2. AWS EFS CSI Driver Operator のインストール
AWS EFS CSI Driver Operator (Red Hat Operator) は、デフォルトでは OpenShift Container Platform にインストールされません。以下の手順を使用して、クラスター内で AWS EFS CSI Driver Operator をインストールおよび設定します。
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
Web コンソールから AWS EFS CSI Driver Operator をインストールするには、以下を実行します。
- Web コンソールにログインします。
AWS EFS CSI Operator をインストールします。
- Operators → OperatorHub をクリックします。
- フィルターボックスに AWS EFS CSI と入力して、AWS EFS CSI Operator を探します。
AWS EFS CSI Driver Operator ボタンをクリックします。
重要AWS EFS Operator ではなく AWS EFS CSI Driver Operator を必ず選択してください。AWS EFS Operator はコミュニティー Operator であり、Red Hat ではサポートしていません。
- AWS EFS CSI Driver Operator ページで Install をクリックします。
Install Operator のページで、以下のことを確認してください。
- AWS EFS と AWS Secure Token Service (STS) を使用している場合は、role ARN フィールドに、セキュリティートークンサービスの Amazon リソース名ロールの取得 に記載されている最後の手順からコピーした ARN ロールを入力します。
- All namespaces on the cluster (default) が選択されている。
- Installed Namespace が openshift-cluster-csi-drivers に設定されている。
Install をクリックします。
インストールが終了すると、AWS EFS CSI Operator が Web コンソールの Installed Operators に表示されます。
次のステップ
5.11.3.3. AWS EFS CSI ドライバーのインストール
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
- Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
- Instances タブで Create ClusterCSIDriver をクリックします。
以下の YAML ファイルを使用します。
apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: efs.csi.aws.com spec: managementState: Managed
- Create をクリックします。
以下の条件が "True" に変わるのを待ちます。
- AWSEFSDriverNodeServiceControllerAvailable
- AWSEFSDriverControllerServiceControllerAvailable
5.11.4. AWS EFS ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
AWS EFS CSI Driver Operator (Red Hat Operator) は、インストール後、デフォルトではストレージクラスを作成しません。ただし、AWS EFS ストレージクラスを手動で作成することは可能です。
5.11.4.1. コンソールを使用した AWS EFS ストレージクラスの作成
手順
- OpenShift Container Platform コンソールで、Storage → StorageClasses をクリックします。
- StorageClasses ページで、Create StorageClass をクリックします。
StorageClass ページで、次の手順を実行します。
- ストレージクラスを参照するための名前を入力します。
- オプション: 説明を入力します。
- 回収ポリシーを選択します。
-
Provisioner ドロップダウンリストから
efs.csi.aws.com
を選択します。 - オプション: 選択したプロビジョナーの設定パラメーターを設定します。
- Create をクリックします。
5.11.4.2. CLI を使用した AWS EFS ストレージクラスの作成
手順
StorageClass
オブジェクトを作成します。kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: efs-sc provisioner: efs.csi.aws.com parameters: provisioningMode: efs-ap 1 fileSystemId: fs-a5324911 2 directoryPerms: "700" 3 gidRangeStart: "1000" 4 gidRangeEnd: "2000" 5 basePath: "/dynamic_provisioning" 6
- 1
- 動的プロビジョニングを有効にするには、
provisioningMode
にefs-ap
を指定する必要があります。 - 2
fileSystemId
は、手動で作成した EFS ボリュームの ID にする必要があります。- 3
directoryPerms
は、ボリュームのルートディレクトリーのデフォルトパーミッションです。この場合、ボリュームには所有者のみがアクセスできます。- 4 5
gidRangeStart
とgidRangeEnd
は、AWS アクセスポイントの GID を設定する際に使用する POSIX グループ ID (GID) の範囲を設定します。指定しないと、デフォルトの範囲は 50000 - 7000000 になります。プロビジョニングされた各ボリューム、つまり AWS のアクセスポイントには、この範囲からの固有 GID が割り当てられます。- 6
basePath
は、動的にプロビジョニングされたボリュームを作成する際に使用される EFS ボリューム上のディレクトリーです。この場合は、EFS ボリューム上に “/dynamic_provisioning/<random uuid>” として PV がプロビジョニングされます。PV を使用する Pod には、そのサブディレクトリーのみがマウントされます。
注記クラスター管理者は、それぞれが異なる EFS ボリュームを使用する複数の
StorageClass
オブジェクトを作成することができます。
5.11.5. AWS EFS CSI クロスアカウントのサポート
クロスアカウントのサポートにより、1 つの AWS アカウントに OpenShift Container Platform クラスターを配置し、AWS Elastic File System (EFS) Container Storage Interface (CSI) ドライバーを使用して別の AWS アカウントにファイルシステムをマウントできます。
OpenShift Container Platform クラスターと EFS ファイルシステムの両方が同じリージョンに存在する必要があります。
前提条件
- 管理者権限を持つ OpenShift Container Platform クラスターへのアクセス
- 2 つの有効な AWS アカウント
手順
次の手順は、セットアップ方法を示しています。
- AWS アカウント A の OpenShift Container Platform クラスター
- アカウント B に AWS EFS ファイルシステムをマウントします。
アカウント間で AWS EFS を使用するには:
- AWS アカウント A を使用して OpenShift Container Platform クラスターをインストールし、EFS CSI Driver Operator をインストールします。
AWS アカウント B に EFS ボリュームを作成します。
- たとえば、CIDR (たとえば、“172.20.0.0/16”) と AWS EFS ボリュームのサブネットを使用して、"my-efs-vpc” という名前の Virtual Private Cloud (VPC) を作成します。
- AWS コンソールで、https://console.aws.amazon.com/efs に移動します。
新しいファイルシステムの作成 をクリックします。
- たとえば、"my-filesystem" という名前のファイルシステムを作成します。
- 先ほど作成した VPC ("my-efs-vpc") を選択します。
- 残りの設定はデフォルトを受け入れます。
ボリュームとマウントターゲットが作成されていることを確認します。
- https://console.aws.amazon.com/efs#/file-systems を確認してください。
- ボリュームをクリックし、Network タブで、すべてのマウントターゲットが使用可能になるまで待ちます (約 1 ~ 2 分)。
- Network タブで、セキュリティーグループ ID をコピーします。次のステップで必要になります。
AWS アカウント B の AWS EFS ボリュームへのネットワークアクセスを設定します。
- https://console.aws.amazon.com/ec2/v2/home#SecurityGroups に移動します。
- 前にコピーしたグループ ID をフィルタリングして、AWS EFS ボリュームで使用されているセキュリティーグループを見つけます。
Inbound rules タブで、Edit inbound rules をクリックし、OpenShift Container Platform ノードが AWS EFS ボリュームにアクセスできるようにする (つまり、クラスターからの NFS ポートを使用する) 新しいルールを追加します。
- Type: NFS
- Protocol: TCP
- Port range: 2049
- Source: OpenShift Container Platform クラスターノードのカスタム/IP アドレス範囲 (例: "10.0.0.0/16")
ルールを保存します。
注記マウントの問題が発生した場合は、ポート番号、IP アドレスの範囲を再確認し、AWS EFS ボリュームが予期したセキュリティーグループを使用していることを確認してください。
AWS アカウント A の OpenShift Container Platform クラスター VPC と AWS アカウント B の AWS EFS VPC の間に VPC ピアリングを作成します。
2 つの VPC が異なるネットワーク CIDR を使用していることを確認し、VPC ピアリングを作成した後、各 VPC にルートを追加して 2 つの VPC ネットワークを接続します。
- たとえば、アカウント B に "my-efs-crossaccount-peering-connection" というピアリング接続を作成します。ローカル VPC ID には、EFS にある VPC を使用します。アカウント A の VPC とピアするには、VPC ID として OpenShift Container Platform クラスター VPC ID を使用します。
- AWS アカウント A でピア接続を受け入れます。
AWS アカウント B の各サブネット (EFS ボリュームが使用するサブネット) のルートテーブルを変更します。
- 左側のペインの Virtual private cloud で、下矢印をクリックして利用可能なオプションをデプロイメントします。
- Virtual private cloud で、Route tables" をクリックします。
- Routes タブをクリックします。
- Destination で 10.0.0.0/16 を入力します。
- Target で、作成されたピア接続からピア接続タイプポイントを使用します。
AWS アカウント A の各サブネット (サブネットを使用する OpenShift Container Platform クラスターノード) のルートテーブルを変更します。
- 左側のペインの Virtual private cloud で、下矢印をクリックして利用可能なオプションをデプロイメントします。
- Virtual private cloud で、Route tables" をクリックします。
- Routes タブをクリックします。
- Destination で、アカウント B の VPC の CIDR を入力します。この例では 172.20.0.0/16 です。
- Target で、作成されたピア接続からピア接続タイプポイントを使用します。
AWS アカウント A と信頼関係がある AWS アカウント B に IAM ロール (たとえば、"my-efs-acrossaccount-role") を作成し、"my-efs-acrossaccount-role" を呼び出す権限を持つインライン AWS EFS ポリシーを追加します。ドライバーポリシー。
このロールは、AWS アカウント A の OpenShift Container Platform クラスター上で実行されている CSI ドライバーのコントローラーサービスによって使用され、AWS アカウント B のファイルシステムのマウントターゲットを決定します。
# Trust relationships trusted entity trusted account A configuration on my-efs-acrossaccount-role in account B { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::301721915996:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] } # my-cross-account-assume-policy policy attached to my-efs-acrossaccount-role in account B { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::589722580343:role/my-efs-acrossaccount-role" } } # my-efs-acrossaccount-driver-policy attached to my-efs-acrossaccount-role in account B { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:DescribeSubnets" ], "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "elasticfilesystem:DescribeMountTargets", "elasticfilesystem:DeleteAccessPoint", "elasticfilesystem:ClientMount", "elasticfilesystem:DescribeAccessPoints", "elasticfilesystem:ClientWrite", "elasticfilesystem:ClientRootAccess", "elasticfilesystem:DescribeFileSystems", "elasticfilesystem:CreateAccessPoint" ], "Resource": [ "arn:aws:elasticfilesystem:*:589722580343:access-point/*", "arn:aws:elasticfilesystem:*:589722580343:file-system/*" ] } ] }
AWS アカウント A で、セキュリティートークンサービス (STS) を実行するために必要なアクセス許可を持つインラインポリシーを AWS EFS CSI ドライバーのコントローラーサービスアカウントの IAM ロールにアタッチし、前に作成した IAM ロールでロールを引き受けます。
# my-cross-account-assume-policy policy attached to Openshift cluster efs csi driver user in account A { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::589722580343:role/my-efs-acrossaccount-role" } }
-
AWS アカウント A で、AWS 管理ポリシー "AmazonElasticFileSystemClientFullAccess" を OpenShift Container Platform クラスターマスターロールにアタッチします。ロール名の形式は
<clusterID>-master-role
(例:my-0120ef-czjrl-master-role
) です。 awsRoleArn
をキーとして、前に作成したロールを値として使用して、Kubernetes シークレットを作成します。$ oc -n openshift-cluster-csi-drivers create secret generic my-efs-cross-account --from-literal=awsRoleArn='arn:aws:iam::589722580343:role/my-efs-acrossaccount-role'
ドライバーコントローラーはシークレットからクロスアカウントロール情報を取得する必要があるため、シークレットロールバインディングを AWS EFS CSI ドライバーコントローラー ServiceAccount (SA) に追加する必要があります。
$ oc -n openshift-cluster-csi-drivers create role access-secrets --verb=get,list,watch --resource=secrets $ oc -n openshift-cluster-csi-drivers create rolebinding --role=access-secrets default-to-secrets --serviceaccount=openshift-cluster-csi-drivers:aws-efs-csi-driver-controller-sa
アカウント B のファイルシステム (AWS EFS ボリューム) の
filesystem
ポリシーを作成します。これにより、AWS アカウント A がそのボリュームでマウントを実行できるようになります。This step is not mandatory, but can be safer for AWS EFS volume usage.
# EFS volume filesystem policy in account B { "Version": "2012-10-17", "Id": "efs-policy-wizard-8089bf4a-9787-40f0-958e-bc2363012ace", "Statement": [ { "Sid": "efs-statement-bd285549-cfa2-4f8b-861e-c372399fd238", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "elasticfilesystem:ClientRootAccess", "elasticfilesystem:ClientWrite", "elasticfilesystem:ClientMount" ], "Resource": "arn:aws:elasticfilesystem:us-east-2:589722580343:file-system/fs-091066a9bf9becbd5", "Condition": { "Bool": { "elasticfilesystem:AccessedViaMountTarget": "true" } } }, { "Sid": "efs-statement-03646e39-d80f-4daf-b396-281be1e43bab", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::589722580343:role/my-efs-acrossaccount-role" }, "Action": [ "elasticfilesystem:ClientRootAccess", "elasticfilesystem:ClientWrite", "elasticfilesystem:ClientMount" ], "Resource": "arn:aws:elasticfilesystem:us-east-2:589722580343:file-system/fs-091066a9bf9becbd5" } ] }
次と同様の設定を使用して、AWS EFS ボリュームストレージクラスを作成します。
# The cross account efs volume storageClass kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: efs-cross-account-mount-sc provisioner: efs.csi.aws.com mountOptions: - tls parameters: provisioningMode: efs-ap fileSystemId: fs-00f6c3ae6f06388bb directoryPerms: "700" gidRangeStart: "1000" gidRangeEnd: "2000" basePath: "/account-a-data" csi.storage.k8s.io/provisioner-secret-name: my-efs-cross-account csi.storage.k8s.io/provisioner-secret-namespace: openshift-cluster-csi-drivers volumeBindingMode: Immediate
5.11.6. AWS における EFS ボリュームへのアクセスの作成と設定
この手順では、OpenShift Container Platform で使用できるように、AWS で EFS ボリュームを作成および設定する方法を説明します。
前提条件
- AWS アカウントの認証情報。
手順
AWS で EFS ボリュームへのアクセスを作成および設定するには、以下の手順を実施します。
- AWS のコンソールで、https://console.aws.amazon.com/efs を開きます。
Create file system をクリックします。
- ファイルシステムの名前を入力します。
- Virtual Private Cloud (VPC) には、OpenShift Container Platform の仮想プライベートクラウド (VPC) を選択します。
- その他の選択項目は、デフォルト設定を受け入れます。
ボリュームとマウントターゲットが完全に作成され終わるのを待ちます。
- https://console.aws.amazon.com/efs#/file-systems にアクセスしてください。
- ボリュームをクリックし、Network タブで、すべてのマウントターゲットが利用可能になるまで待ちます (最長で 1 - 2 分間)。
- Network タブでセキュリティーグループ ID をコピーします (次のステップで必要になります)。
- https://console.aws.amazon.com/ec2/v2/home#SecurityGroups にアクセスし、EFS ボリュームで使用されているセキュリティーグループを探します。
Inbound rulesタブでEdit inbound rules をクリックし、OpenShift Container Platform ノードが EFS ボリュームにアクセスできるようにするために、次の設定で新しいルールを追加します。
- Type: NFS
- Protocol: TCP
- Port range: 2049
Source: ノードのカスタム/IP アドレス範囲 (例:"10.0.0.0/16")
このステップで、OpenShift Container Platform がクラスターから NFS ポートを使用できるようになります。
- ルールを保存します。
5.11.7. Amazon Elastic File Storage の動的プロビジョニング
AWS EFS CSI ドライバー は、他の CSI ドライバーとは異なる形式の動的プロビジョニングをサポートします。既存の EFS ボリュームのサブディレクトリーとして新しい PV をプロビジョニングします。PV はお互いに独立しています。しかし、これらはすべて同じ EFS ボリュームを共有しています。ボリュームが削除されると、そのボリュームからプロビジョニングされたすべての PV も削除されます。EFS CSI ドライバーは、そのようなサブディレクトリーごとに AWS アクセスポイントを作成します。AWS AccessPoint の制限により、単一の StorageClass
/EFS ボリュームから動的にプロビジョニングできるのは 1000 PV のみです。
なお、PVC.spec.resources
は EFS では強制されません。
以下の例では、5 GiB の容量を要求しています。しかし、作成された PV は無限であり、どんな量のデータ (ペタバイトのような) も保存することができます。ボリュームに大量のデータを保存してしまうと、壊れたアプリケーション、あるいは不正なアプリケーションにより、多額の費用が発生します。
AWS の EFS ボリュームサイズのモニタリングを使用することを強く推奨します。
前提条件
- Amazon Elastic File Storage (Amazon EFS) ボリュームが作成されている。
- AWS EFS ストレージクラスを作成している。
手順
動的プロビジョニングを有効にするには、以下の手順を実施します。
以前に作成した
StorageClass
を参照して、通常どおり PVC (または StatefulSet や Template) を作成します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test spec: storageClassName: efs-sc accessModes: - ReadWriteMany resources: requests: storage: 5Gi
動的プロビジョニングのセットアップに問題がある場合は、AWS EFS のトラブルシューティング を参照してください。
5.11.8. Amazon Elastic File Storage を使用した静的 PV の作成
動的プロビジョニングを行わずに、Amazon Elastic File Storage (Amazon EFS) ボリュームを単一の PV として使用できます。ボリューム全体が Pod にマウントされます。
前提条件
- Amazon EFS ボリュームが作成されている。
手順
以下の YAML ファイルで PV を作成します。
apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: 1 storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany - ReadWriteOnce persistentVolumeReclaimPolicy: Retain csi: driver: efs.csi.aws.com volumeHandle: fs-ae66151a 2 volumeAttributes: encryptInTransit: "false" 3
- 1
spec.capacity
には意味がなく、CSI ドライバーでは無視されます。PVC へのバインディング時にのみ使用されます。アプリケーションは、ボリュームに任意の量のデータを保存することができます。- 2
volumeHandle
は、AWS で作成した EFS ボリュームと同じ ID である必要があります。独自のアクセスポイントを提供する場合、volumeHandle
は<EFS volume ID>::<access point ID>
とします。たとえば、fs-6e633ada::fsap-081a1d293f0004630
です。- 3
- 必要に応じて、転送中の暗号化を無効にすることができます。デフォルトでは、暗号化が有効になっています。
静的 PV の設定に問題がある場合は、AWS EFS のトラブルシューティング を参照してください。
5.11.9. Amazon Elastic File Storage のセキュリティー
次の情報は、Amazon Elastic File Storage (Amazon EFS) のセキュリティーに重要です。
前述の動的プロビジョニングなどでアクセスポイントを使用する場合、Amazon はファイルの GID をアクセスポイントの GID に自動的に置き換えます。また、EFS では、ファイルシステムの権限を評価する際に、アクセスポイントのユーザー ID、グループ ID、セカンダリーグループ ID を考慮します。EFS は、NFS クライアントの ID を無視します。アクセスポイントの詳細は、https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html を参照してください。
その結果、EFS ボリュームは FSGroup を静かに無視します。OpenShift Container Platform は、ボリューム上のファイルの GID を FSGroup で置き換えることができません。マウントされた EFS アクセスポイントにアクセスできる Pod は、そこにあるすべてのファイルにアクセスできます。
これとは関係ありませんが、転送中の暗号化はデフォルトで有効になっています。詳細は、https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html を参照してください。
5.11.10. Amazon Elastic File Storage のトラブルシューティング
次の情報は、Amazon Elastic File Storage (Amazon EFS) に関する問題のトラブルシューティング方法に関するガイダンスです。
-
AWS EFS Operator と CSI ドライバーは、namespace
openshift-cluster-csi-drivers
で実行されます。 AWS EFS Operator と CSI ドライバーのログ収集を開始するには、以下のコマンドを実行します。
$ oc adm must-gather [must-gather ] OUT Using must-gather plugin-in image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:125f183d13601537ff15b3239df95d47f0a604da2847b561151fedd699f5e3a5 [must-gather ] OUT namespace/openshift-must-gather-xm4wq created [must-gather ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-2bd8x created [must-gather ] OUT pod for plug-in image quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:125f183d13601537ff15b3239df95d47f0a604da2847b561151fedd699f5e3a5 created
AWS EFS Operator のエラーを表示するには、
ClusterCSIDriver
のステータスを表示します。$ oc get clustercsidriver efs.csi.aws.com -o yaml
Pod にボリュームをマウントできない場合 (以下のコマンドの出力に示す):
$ oc describe pod ... Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m13s default-scheduler Successfully assigned default/efs-app to ip-10-0-135-94.ec2.internal Warning FailedMount 13s kubelet MountVolume.SetUp failed for volume "pvc-d7c097e6-67ec-4fae-b968-7e7056796449" : rpc error: code = DeadlineExceeded desc = context deadline exceeded 1 Warning FailedMount 10s kubelet Unable to attach or mount volumes: unmounted volumes=[persistent-storage], unattached volumes=[persistent-storage kube-api-access-9j477]: timed out waiting for the condition
- 1
- ボリュームがマウントされていないことを示す警告メッセージ。
このエラーは、OpenShift Container Platform ノードと Amazon EFS 間のパケットを AWS がドロップすることで頻繁に発生します。
以下が正しいことを確認します。
- AWS のファイアウォールとセキュリティーグループ
- ネットワーク: ポート番号と IP アドレス
5.11.11. AWS EFS CSI Driver Operator のアンインストール
AWS EFS CSI Driver Operator (Red Hat Operator) をアンインストールすると、すべての EFS PV にアクセスできなくなります。
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
Web コンソールから AWS EFS CSI Driver Operator をアンインストールするには、以下を実行します。
- Web コンソールにログインします。
- AWS EFS PV を使用するすべてのアプリケーションを停止します。
すべての AWS EFS PV を削除します。
- Storage → PersistentVolumeClaims をクリックします。
- AWS EFS CSI Driver Operator が使用している各 PVC を選択し、PVC の右端にあるドロップダウンメニューをクリックして、Delete PersistentVolumeClaims をクリックします。
AWS EFS CSI ドライバー をアンインストールします。
注記Operator をアンインストールする前に、まず CSI ドライバーを削除する必要があります。
- Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
- Instances タブの efs.csi.aws.com の左端にあるドロップダウンメニューをクリックし、Delete ClusterCSIDriver をクリックします。
- プロンプトが表示されたら、Delete をクリックします。
AWS EFS CSI Operator をアンインストールします。
- Operators → Installed Operators をクリックします。
- Installed Operatorsページで、スクロールするか、Search by name ボックスに AWS EFS CSI と入力してオペレーターを見つけ、クリックします。
- Installed Operators > Operator details ページの右上にある Actions → Uninstall Operator をクリックします。
Uninstall Operator ウィンドウでプロンプトが表示されたら、Uninstall ボタンをクリックして namespace から Operator を削除します。Operator によってクラスターにデプロイされたアプリケーションは手動でクリーンアップする必要があります。
アンインストールすると、AWS EFS CSI Driver Operator が Web コンソールの Installed Operators セクションにリスト表示されなくなります。
クラスターを破棄 (openshift-install destroy cluster
) する前に、AWS の EFS ボリュームを削除する必要があります。クラスターの VPC を使用する EFS ボリュームがある場合、OpenShift Container Platform クラスターを破棄することはできません。Amazon はこのような VPC の削除を許可していません。
5.11.12. 関連情報
5.12. Azure Disk CSI Driver Operator
5.12.1. 概要
OpenShift Container Platform は、Microsoft Azure Disk Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
Azure Disk ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで Azure Disk CSI Driver Operator および Azure Disk CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
Azure Disk CSI Driver Operator: 永続ボリューム要求 (PVC) の作成に使用できる
managed-csi
というストレージクラスを提供します。Azure Disk CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。 - Azure Disk CSI ドライバー を使用すると、Azure Disk PV を作成し、マウントできます。
5.12.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
OpenShift Container Platform は、Azure Disk インツリーボリュームプラグインを同等の CSI ドライバーに自動的に移行します。詳細は、CSI 自動移行を参照してください。
5.12.3. ストレージアカウントタイプを使用したストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することで、動的にプロビジョニングされた永続ボリュームを取得できます。
ストレージクラスを作成するときに、ストレージアカウントの種類を指定できます。これは、Azure ストレージアカウントの SKU の層に対応します。有効なオプションは、Standard_LRS
、Premium_LRS
、StandardSSD_LRS
、UltraSSD_LRS
、Premium_ZRS
、StandardSSD_ZRS
、および PremiumV2_LRS
です。Azure SKU レベルを見つける方法は、SKU Types を参照してください。
ZRS と PremiumV2_LRS の両方に、いくつかのリージョン制限があります。これらの制限は、ZRS の制限 および Premium_LRS の制限 を参照してください。
前提条件
- 管理者権限を持つ OpenShift Container Platform クラスターへのアクセス
手順
次の手順を使用して、ストレージアカウントの種類でストレージクラスを作成します。
次のような YAML ファイルを使用して、ストレージアカウントの種類を指定するストレージクラスを作成します。
$ oc create -f - << EOF apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class> 1 provisioner: disk.csi.azure.com parameters: skuName: <storage-class-account-type> 2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true EOF
注記PremiumV2_LRS の場合、
storageclass.parameters
でcachingMode: None
を指定します。ストレージクラスを一覧表示して、ストレージクラスが作成されたことを確認します。
$ oc get storageclass
出力例
$ oc get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE azurefile-csi file.csi.azure.com Delete Immediate true 68m managed-csi (default) disk.csi.azure.com Delete WaitForFirstConsumer true 68m sc-prem-zrs disk.csi.azure.com Delete WaitForFirstConsumer true 4m25s 1
- 1
- ストレージアカウントタイプを使用する新しいストレージクラス。
5.12.4. ユーザー管理型の暗号化
ユーザー管理型の暗号化機能を使用すると、インストール時に OpenShift Container Platform ノードのルートボリュームを暗号化するキーを指定でき、すべてのマネージドストレージクラスはこれらのキーを使用してプロビジョニングされたストレージボリュームを暗号化できます。install-config YAML ファイルの platform.<cloud_type>.defaultMachinePlatform
フィールドにカスタムキーを指定する必要があります。
この機能は、次のストレージタイプをサポートします。
- Amazon Web Services (AWS) Elastic Block storage (EBS)
- Microsoft Azure Disk ストレージ
- Google Cloud Platform (GCP) 永続ディスク (PD) ストレージ
OS (ルート) ディスクが暗号化されており、ストレージクラスに暗号化キーが定義されていない場合、Azure Disk CSI ドライバーは、デフォルトで OS ディスク暗号化キーを使用して、プロビジョニングされたストレージボリュームを暗号化します。
Azure のユーザー管理型の暗号化を使用してインストールする方法の詳細は、Azure のユーザー管理型の暗号化を有効にする を参照してください。
5.12.5. PVC を使用して Ultra ディスクと共にマシンをデプロイするマシンセット
Ultra ディスクと共にマシンをデプロイする Azure で実行されるマシンセットを作成できます。Ultra ディスクは、最も要求の厳しいデータワークロードでの使用を目的とした高性能ストレージです。
in-tree プラグインおよび CSI ドライバーの両方が、Ultra ディスクを有効にするための PVC の使用をサポートします。PVC を作成せずに、データディスクとしての Ultra デイスクと共にマシンをデプロイすることもできます。
関連情報
5.12.5.1. マシンセットを使用した Ultra ディスクを持つマシンの作成
マシンセットの YAML ファイルを編集することで、Azure 上に Ultra ディスクと共にマシンをデプロイできます。
前提条件
- 既存の Microsoft Azure クラスターがある。
手順
既存の Azure
MachineSet
カスタムリソース (CR) をコピーし、次のコマンドを実行して編集します。$ oc edit machineset <machine-set-name>
ここで、
<machine-set-name>
は、Ultra ディスクとともにマシンをプロビジョニングするマシンセットです。示された位置に次の行を追加します。
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet spec: template: spec: metadata: labels: disk: ultrassd 1 providerSpec: value: ultraSSDCapability: Enabled 2
次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。
$ oc create -f <machine-set-name>.yaml
以下の 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
以下の 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
以下の 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
検証
次のコマンドを実行して、マシンが作成されていることを確認します。
$ oc get machines
マシンは
Running
状態になっているはずです。実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。
$ 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
5.12.5.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング
このセクションの情報を使用して、発生する可能性のある問題を理解し、回復してください。
5.12.5.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>
5.12.6. 関連情報
5.13. Azure File CSI Driver Operator
5.13.1. 概要
OpenShift Container Platform は、Microsoft Azure File Storage の Container Storage Interface (CSI) ドライバーを使用して、永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
Azure File ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで Azure File CSI Driver Operator および Azure File CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
Azure File CSI Driver Operator: 永続ボリューム要求 (PVC) の作成に使用できる
azurefile-csi
というストレージクラスを提供します。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。 - Azure File CSI ドライバー を使用すると、Azure File PV を作成し、マウントできます。Azure File CSI ドライバーは、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。
Azure File CSI Driver Operator は以下をサポートしません。
- 仮想ハードディスク (VHD)
- Server Message Block (SMB) ファイル共有に対して連邦情報処理標準 (FIPS) モードが有効になっているノードで実行。ただし、Network File System (NFS) は FIPS モードをサポートします。
サポートされる機能の詳細は、サポートされる CSI ドライバーおよび機能 を参照してください。
5.13.2. NFS のサポート
OpenShift Container Platform 4.14 以降では、Network File System (NFS) を備えた Azure File Container Storage Interface (CSI) Driver Operator がサポートされていますが、次の注意事項があります。
コントロールプレーンノードにスケジュールされている Azure File NFS ボリュームを含む Pod を作成すると、マウントが拒否されます。
この問題を回避するには、コントロールプレーンノードがスケジュール可能で、Pod がワーカーノードで実行できる場合は、
nodeSelector
または Affinity を使用してワーカーノードで Pod をスケジュールします。FS グループポリシーの動作:
重要NFS を使用した Azure File CSI は、Pod によって要求された fsGroupChangePolicy を受け入れません。NFS を使用した Azure File CSI は、Pod によって要求されたポリシーに関係なく、デフォルトの OnRootMismatch FS グループポリシーを適用します。
Azure File CSI Operator は、NFS のストレージクラスを自動的に作成しません。手動で作成する必要があります。次のようなファイルを使用します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class-name> 1 provisioner: file.csi.azure.com 2 parameters: protocol: nfs 3 skuName: Premium_LRS # available values: Premium_LRS, Premium_ZRS mountOptions: - nconnect=4
5.13.3. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.14. Azure Stack Hub CSI Driver Operator
5.14.1. 概要
OpenShift Container Platform は、Azure Stack Hub Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。Azure Stack ポートフォリオの一部である Azure Stack Hub を使用すると、オンプレミス環境でアプリケーションを実行し、データセンターで Azure サービスを配信できます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
Azure Stack Hub ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで Azure Stack Hub CSI Driver Operator および Azure Stack Hub CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
Azure Stack Hub CSI Driver Operator は、デフォルトのストレージアカウントタイプとして "Standard_LRS" が設定されたストレージクラス
(managed-csi)
を提供し、永続的ボリューム要求 (PVC) の作成に使用することができます。Azure Stack Hub CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。 - Azure Stack Hub CSI ドライバー を使用すると、Azure Stack Hub PV を作成し、マウントできます。
5.14.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.14.3. 関連情報
5.15. GCP PD CSI Driver Operator
5.15.1. 概要
OpenShift Container Platform は、Google Cloud Platform (GCP) 永続ディスク (PD) ストレージの Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
GCP PD ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform はデフォルトで GCP PD CSI Driver Operator および GCP PD CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
- GCP PD CSI Driver Operator: デフォルトで、Operator は PVC の作成に使用できるストレージクラスを提供します。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。GCE Persistent Disk を使用した永続ストレージ で説明されているように、GCP PD ストレージを作成するオプションもあります。
- GCP PD ドライバー: このドライバーを使用すると、GCP PD PV を作成し、マウントできます。
OpenShift Container Platform では、GCE Persistent Disk in-tree ボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。詳細は、CSI 自動移行を参照してください。
5.15.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.15.3. GCP PD CSI ドライバーストレージクラスパラメーター
Google Cloud Platform (GCP) 永続ディスク (PD) の Container Storage Interface (CSI) ドライバーは CSI の external-provisioner
サイドカーをコントローラーとして使用します。これは、CSI ドライバーでデプロイされる別のヘルパーコンテナーです。サイドカーは、CreateVolume
操作をトリガーして永続ボリューム (PV) を管理します。
GCP PD CSI ドライバーは、csi.storage.k8s.io/fstype
パラメーターキーを使用して動的プロビジョニングをサポートします。以下の表は、OpenShift Container Platform がサポートするすべての GCP PD CSI ストレージクラスパラメーターを説明しています。
パラメーター | 値 | デフォルト | 説明 |
---|---|---|---|
|
|
| 標準の PV または solid-state-drive PV を選択できます。 ドライバーは値を検証しないため、可能なすべての値が受け入れられます。 |
|
|
| zonal またはリージョン PV を選択できます。 |
| 新規ディスクの暗号化に使用するキーの完全修飾リソース識別子。 | 空の文字列 | 顧客管理の暗号鍵 (CMEK) を使用して新規ディスクを暗号化します。 |
5.15.4. カスタムで暗号化された永続ボリュームの作成
PersistentVolumeClaim
オブジェクトの作成時に、OpenShift Container Platform は新規永続ボリューム (PV) をプロビジョニングし、PersistentVolume
オブジェクトを作成します。新規に作成された PV を暗号化することで、Google Cloud Platform (GCP) にカスタム暗号化キーを追加し、クラスター内の PV を保護することができます。
暗号化の場合、作成した新たに割り当てられる PV は、新規または既存の Google Cloud Key Management Service (KMS) キーを使用してクラスターで顧客管理の暗号鍵 (CMEK) を使用します。
前提条件
- 実行中の OpenShift Container Platform クラスターにログインしている。
- Cloud KMS キーリングとキーのバージョンを作成している。
CMEK および Cloud KMS リソースの詳細は、顧客管理の暗号鍵 (CMEK) の使用 を参照してください。
手順
カスタムで暗号化された PV を作成するには、以下の手順を実行します。
Cloud KMS キーを使用してストレージクラスを作成します。以下の例では、暗号化されたボリュームの動的プロビジョニングを有効にします。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-gce-pd-cmek provisioner: pd.csi.storage.gke.io volumeBindingMode: "WaitForFirstConsumer" allowVolumeExpansion: true parameters: type: pd-standard disk-encryption-kms-key: projects/<key-project-id>/locations/<location>/keyRings/<key-ring>/cryptoKeys/<key> 1
- 1
- このフィールドは、新規ディスクの暗号化に使用されるキーのリソース識別子である必要があります。値では、大文字と小文字が区別されます。キー ID の値を指定する方法は、Retrieving a resource's ID および Getting a Cloud KMS resource ID を参照してください。
注記disk-encryption-kms-key
パラメーターは既存のストレージクラスに追加することはできません。ただし、ストレージクラスを削除し、同じ名前および異なるパラメーターセットでこれを再作成できます。これを実行する場合、既存クラスのプロビジョナーはpd.csi.storage.gke.io
である必要があります。oc
コマンドを使用して、ストレージクラスを OpenShift Container Platform クラスターにデプロイします。$ oc describe storageclass csi-gce-pd-cmek
出力例
Name: csi-gce-pd-cmek IsDefaultClass: No Annotations: None Provisioner: pd.csi.storage.gke.io Parameters: disk-encryption-kms-key=projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/key-name,type=pd-standard AllowVolumeExpansion: true MountOptions: none ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: none
直前の手順で作成したストレージクラスオブジェクトの名前に一致する
pvc.yaml
という名前のファイルを作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteOnce storageClassName: csi-gce-pd-cmek resources: requests: storage: 6Gi
注記新規ストレージクラスをデフォルトとしてマークした場合は、
storageClassName
フィールドを省略できます。PVC をクラスターに適用します。
$ oc apply -f pvc.yaml
PVC のステータスを取得し、これが作成され、新規にプロビジョニングされた PV にバインドされていることを確認します。
$ oc get pvc
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE podpvc Bound pvc-e36abf50-84f3-11e8-8538-42010a800002 10Gi RWO csi-gce-pd-cmek 9s
注記ストレージクラスで
volumeBindingMode
フィールドがWaitForFirstConsumer
に設定されている場合、これを検証する前に PVC を使用するために Pod を作成する必要があります。
CMEK で保護される PV が OpenShift Container Platform クラスターで使用できるようになります。
5.15.5. ユーザー管理型の暗号化
ユーザー管理型の暗号化機能を使用すると、インストール時に OpenShift Container Platform ノードのルートボリュームを暗号化するキーを指定でき、すべてのマネージドストレージクラスはこれらのキーを使用してプロビジョニングされたストレージボリュームを暗号化できます。install-config YAML ファイルの platform.<cloud_type>.defaultMachinePlatform
フィールドにカスタムキーを指定する必要があります。
この機能は、次のストレージタイプをサポートします。
- Amazon Web Services (AWS) Elastic Block storage (EBS)
- Microsoft Azure Disk ストレージ
- Google Cloud Platform (GCP) 永続ディスク (PD) ストレージ
GCP PD のユーザー管理型の暗号化を使用したインストールの詳細は、インストール設定パラメーター を参照してください。
5.15.6. 関連情報
5.16. Google Compute Platform Filestore CSI ドライバーオペレーター
5.16.1. 概要
OpenShift Container Platform は、Google Compute Platform (GCP) Filestore Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
GCP Filestore Storage アセットにマウントする CSI プロビジョニング PV を作成するには、GCP Filestore CSI Driver Operator と GCP Filestore CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
- GCP Filestore CSI Driver Operator は、デフォルトではストレージクラスを提供しませんが、必要に応じて作成 できます。GCP Filestore CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにすることで動的なボリュームプロビジョニングをサポートし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくなります。
- GCP Filestore CSI ドライバー を使用すると、GCP Filestore PV を作成してマウントできます。
5.16.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.16.3. GCP Filestore CSI Driver Operator のインストール
デフォルトでは、Google Compute Platform (GCP) Filestore Container Storage Interface (CSI) Driver Operator は OpenShift Container Platform にインストールされません。次の手順を使用して、GCP Filestore CSI Driver Operator をクラスターにインストールします。
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
ウェブコンソールから GCP Filestore CSI Driver Operator をインストールするには:
- Web コンソールにログインします。
次のコマンドを実行して、GCE プロジェクトで Filestore API を有効にします。
$ gcloud services enable file.googleapis.com --project <my_gce_project> 1
- 1
<my_gce_project>
を Google Cloud プロジェクトに置き換えます。
これは、Google Cloud Web コンソールを使用して行うこともできます。
GCP Filestore CSI Operator をインストールします。
- Operators → OperatorHub をクリックします。
- フィルターボックスに GCP Filestore と入力して、GCP Filestore CSI Operator を見つけます。
- GCP Filestore CSI Driver Operator ボタンをクリックします。
- GCP Filestore CSI Driver Operator ページで、Install をクリックします。
Install Operator のページで、以下のことを確認してください。
- All namespaces on the cluster (default) が選択されている。
- Installed Namespace が openshift-cluster-csi-drivers に設定されている。
Install をクリックします。
インストールが終了すると、GCP Filestore CSI Operator が Web コンソールのInstalled Operatorsに表示されます。
GCP Filestore CSI ドライバーをインストールします。
- administration → CustomResourceDefinitions → ClusterCSIDriverをクリックします。
Instances タブで Create ClusterCSIDriver をクリックします。
以下の YAML ファイルを使用します。
apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: filestore.csi.storage.gke.io spec: managementState: Managed
- Create をクリックします。
以下の条件が "true" に変わるのを待ちます。
- GCPFilestoreDriverCredentialsRequestControllerAvailable
- GCPFilestoreDriverNodeServiceControllerAvailable
- GCPFilestoreDriverControllerServiceControllerAvailable
5.16.4. GCP Filestore Storage のストレージクラスの作成
Operator をインストールしたら、Google Compute Platform (GCP) Filestore ボリュームの動的プロビジョニング用のストレージクラスを作成する必要があります。
前提条件
- 実行中の OpenShift Container Platform クラスターにログインしている。
手順
ストレージクラスを作成するには、以下を行います。
次のサンプル YAML ファイルを使用してストレージクラスを作成します。
サンプル YAML ファイル
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: filestore-csi provisioner: filestore.csi.storage.gke.io parameters: network: network-name 1 allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer
- 1
- Filestore インスタンスを作成する GCP Virtual Private Cloud (VPC) ネットワークの名前を指定します。
Filestore インスタンスを作成する VPC ネットワークの名前を指定します。
Filestore インスタンスを作成する VPC ネットワークを指定することを推奨します。VPC ネットワークが指定されていないと、Container Storage Interface (CSI) ドライバーは、プロジェクトのデフォルト VPC ネットワークにインスタンスを作成しようとします。IPI インストールでは、VPC ネットワーク名は通常、クラスター名に接尾辞 "-network" を付けたものです。ただし、UPI インストールでは、VPC ネットワーク名はユーザーが選択した任意の値にすることができます。
次のコマンドを使用して
MachineSets
オブジェクトを調べると、VPC ネットワーク名を確認できます。$ oc -n openshift-machine-api get machinesets -o yaml | grep "network:" - network: gcp-filestore-network (...)
この例では、このクラスターの VPC ネットワーク名は "gcp-filestore-network" です。
5.16.5. クラスターと GCP Filestore の破棄
通常、クラスターを破棄すると、OpenShift Container Platform インストーラーはそのクラスターに属するすべてのクラウドリソースを削除します。ただし、クラスターが破棄されても、Google Compute Platform (GCP) Filestore インスタンスは自動的に削除されないため、クラスターを破棄する前に、Filestore ストレージクラスを使用するすべての永続ボリュームクレーム (PVC) を手動で削除する必要があります。
手順
すべての GCP Filestore PVC を削除するには:
ストレージクラス
filestore-csi
を使用して作成されたすべての PVC を一覧表示します。$ oc get pvc -o json -A | jq -r '.items[] | select(.spec.storageClassName == "filestore-csi")
前のコマンドでリストされたすべての PVC を削除します。
$ oc delete <pvc-name> 1
- 1
- <pvc-name> を、削除する必要がある PVC の名前に置き換えます。
5.16.6. 関連情報
5.17. IBM VPC Block CSI Driver Operator
5.17.1. 概要
OpenShift Container Platform は、IBM® Virtual Private Cloud (VPC) Block Storage の Container Storage Interface (CSI) ドライバーを使用して、永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
IBM® VPC Block ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで IBM® VPC Block CSI Driver Operator および IBM® VPC Block CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
IBM® VPC Block CSI Driver Operator は、永続ボリューム要求 (PVC) の作成に使用できる異なるレイヤー用に、
ibmc-vpc-block-10iops-tier
(デフォルト)、ibmc-vpc-block-5iops-tier
、およびibmc-vpc-block-custom
という 3 つのストレージクラスを提供します。IBM® VPC Block CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにすることで動的なボリュームプロビジョニングをサポートするので、クラスター管理者はストレージを事前にプロビジョニングする必要がありません。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。 - IBM® VPC Block CSI ドライバー を使用すると、IBM® VPC Block PV を作成およびマウントできます。
5.17.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
関連情報
5.18. IBM Power Virtual Server Block CSI Driver Operator
5.18.1. はじめに
IBM Power® Virtual Server ブロック CSI ドライバーは、IBM Power® Virtual Server ブロック CSI ドライバー Operator を通じてインストールされ、オペレーターは library-go に基づいています。OpenShift library-go は、OpenShift Operator を簡単に構築できるようにする関数のコレクションです。CSI ドライバー operator の機能のほとんどは、すでにそこで利用可能です。IBM Power® Virtual Server Block CSI Driver Operator は、cluster-storage-operator によってインストールされます。プラットフォームのタイプが Power Virtual Servers の場合、Cluster-storage-operator は IBM Power® Virtual Server Block CSI Driver Operator をインストールします。
5.18.2. 概要
OpenShift Container Platform は、IBM Power® Virtual Server Block Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
IBM Power Virtual Server Block CSI Driver Operator は、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
CSI Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
IBM Power® Virtual Server Block アセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで IBM Power® Virtual Server Block CSI Driver Operator および IBM Power® Virtual Server Block CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
IBM Power® Virtual Server ブロック CSI Driver Operator は、永続ボリューム要求 (PVC) の作成に使用できる、
ibm-powervs-tier1
(デフォルト) とさまざまな層用のibm-powervs-tier3
という名前の 2 つのストレージクラスを提供します。IBM Power® Virtual Server Block CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにすることで動的なボリュームプロビジョニングをサポートするので、クラスター管理者はストレージを事前にプロビジョニングする必要がありません。 - IBM Power® Virtual Server Block CSI ドライバー を使用すると、IBM Power® Virtual Server ブロック PV を作成およびマウントできます。
5.18.3. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
関連情報
5.19. OpenStack Cinder CSI Driver Operator
5.19.1. 概要
OpenShift Container Platform は、OpenStack Cinder の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
OpenStack Cinder ストレージアセットにマウントする CSI でプロビジョニングされる PV を作成するには、OpenShift Container Platform は openshift-cluster-csi-drivers
namespace に OpenStack Cinder CSI Driver Operator および OpenStack Cinder CSI ドライバーをインストールします。
- OpenStack Cinder CSI Driver Operator は、PVC の作成に使用できる CSI ストレージクラスを提供します。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。
- OpenStack Cinder CSI ドライバー を使用すると、OpenStack Cinder PV を作成し、マウントすることができます。
OpenShift Container Platform では、Cinder インツリーボリュームプラグインと同等の CSI ドライバーに自動的に移行できます。詳細は、CSI 自動移行を参照してください。
5.19.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
OpenShift Container Platform は、デフォルトで CSI プラグインを使用して Cinder ストレージをプロビジョニングします。
5.19.3. OpenStack Cinder CSI をデフォルトのストレージクラスに設定する
OpenStack Cinder CSI ドライバーは、cinder.csi.openstack.org
パラメーターキーを使用して動的プロビジョニングをサポートします。
OpenShift Container Platform で OpenStack Cinder CSI プロビジョニングを有効にするには、デフォルトのインツリーストレージクラスを standard-csi
で上書きすることが推奨されます。または、永続ボリューム要求 (PVC) を作成し、ストレージクラスを "standard-csi" として指定できます。
OpenShift Container Platform では、デフォルトのストレージクラスはインツリー Cinder ドライバーを参照します。ただし、CSI の自動移行が有効な場合に、デフォルトのストレージクラスを使用して作成されたボリュームは実際には CSI ドライバーを使用します。
手順
以下の手順に従ってデフォルトのインツリーストレージクラスを上書きし、standard-csi
ストレージクラスを適用します。
ストレージクラスをリスト表示します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE standard(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h standard-csi kubernetes.io/cinder Delete WaitForFirstConsumer true 46h
以下の例に示されるように、デフォルトストレージクラスについてアノテーション
storageclass.kubernetes.io/is-default-class
の値をfalse
に変更します。$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
アノテーションを追加するか、アノテーションを
storageclass.kubernetes.io/is-default-class=true
として変更することで、別のストレージクラスをデフォルトにします。$ oc patch storageclass standard-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
デフォルトで PVC が CSI ストレージクラスを参照していることを確認します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE standard kubernetes.io/cinder Delete WaitForFirstConsumer true 46h standard-csi(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h
オプション: ストレージクラスを指定することなく新規 PVC を定義できます。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cinder-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
特定のストレージクラスを指定しない PVC は、デフォルトのストレージクラスを使用して自動的にプロビジョニングされます。
オプション: 新規ファイルを設定した後に、クラスター内にこのファイルを作成します。
$ oc create -f cinder-claim.yaml
関連情報
5.20. OpenStack Manila CSI Driver Operator
5.20.1. 概要
OpenShift Container Platform は、OpenStack Manila 共有ファイルシステムサービスの Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
Manila ストレージアセットにマウントされる CSI でプロビジョニングされる PV を作成するには、OpenShift Container Platform は Manila CSI Driver Operator および Manila CSI ドライバーを Manila サービスが有効にされている OpenStack クラスターにデフォルトでインストールします。
-
Manila CSI Driver Operator は、利用可能なすべての Manila 共有タイプの PVC の作成に必要なストレージクラスを作成します。Operator は
openshift-cluster-csi-drivers
namespace にインストールされます。 -
Manila CSI ドライバー を使用すると、Manila PV を作成し、マウントできます。ドライバーは
openshift-manila-csi-driver
namespace にインストールされます。
5.20.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.20.3. Manila CSI Driver Operator の制限事項
次の制限は、Manila Container Storage Interface (CSI) Driver Operator に適用されます。
- NFS のみがサポートされています
- OpenStack Manila は、NFS、CIFS、CEPHFS など、多くのネットワーク接続ストレージプロトコルをサポートしており、これらは OpenStack クラウドで選択的に有効にすることができます。OpenShift Container Platform の Manila CSI Driver Operator は、NFS プロトコルの使用のみをサポートします。基盤となる OpenStack クラウドで NFS が利用可能でなく、有効化されていない場合は、Manila CSI Driver Operator を使用して OpenShift Container Platform のストレージをプロビジョニングすることはできません。
- バックエンドが CephFS-NFS の場合、スナップショットはサポートされません
-
永続ボリューム (PV) のスナップショットを作成し、ボリュームをスナップショットに戻すには、使用している Manila 共有タイプがこれらの機能をサポートしていることを確認する必要があります。Red Hat OpenStack 管理者は、使用するストレージクラスに関連付けられた共有タイプで、スナップショットのサポート (
share type extra-spec snapshot_support
) およびスナップショットからの共有の作成 (share type extra-spec create_share_from_snapshot_support
) を有効にする必要があります。 - FSGroup はサポートされていません
-
Manila CSI は、複数のリーダーおよび複数のライターによるアクセス用の共有ファイルシステムを提供するため、FSGroup の使用をサポートしていません。これは、ReadWriteOnce アクセスモードで作成された永続ボリュームにも当てはまります。したがって、Manila CSI Driver で使用するために手動で作成するストレージクラスでは、
fsType
属性を指定しないことが重要です。
Red Hat OpenStack Platform 16.x および 17.x では、NFS を介した CephFS を使用する Shared File Systems サービス (Manila) は、Manila CSI を介した OpenShift Container Platform への共有の提供を完全にサポートします。ただし、このソリューションは大規模なスケールを意図したものではありません。CephFS NFS Manila-CSI Workload Recommendations for Red Hat OpenStack Platform の重要な推奨事項を確認してください。
5.20.4. Manila CSI ボリュームの動的プロビジョニング
OpenShift Container Platform は利用可能な Manila 共有タイプ別にストレージクラスをインストールします。
作成される YAML ファイルは Manila およびその Container Storage Interface (CSI) プラグインから完全に切り離されます。アプリケーション開発者は、ReadWriteMany (RWX) ストレージを動的にプロビジョニングし、YAML マニフェストを使用してストレージを安全に使用するアプリケーションと共に Pod をデプロイできます。
PVC 定義のストレージクラス参照を除き、AWS、GCP、Azure、および他のプラットフォームで OpenShift Container Platform で使用する同じ Pod および永続ボリューム要求 (PVC) 定義をオンプレミスで使用できます。
Manila サービスはオプションです。サービスが Red Hat OpenStack Platform (RHOSP) で有効にされていない場合には、Manila CSI ドライバーがインストールされず、Manila のストレージクラスが作成されません。
前提条件
- RHOSP は適切な Manila 共有インフラストラクチャーでデプロイされ、OpenShift Container Platform でボリュームを動的にプロビジョニングし、マウントするために使用できます。
手順 (UI)
Web コンソールを使用して Manila CSI ボリュームを動的に作成するには、以下を実行します。
- OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
結果のページで必要なオプションを定義します。
- 適切なストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
アクセスモードを選択し、作成する PVC の読み取りおよび書き込みアクセスを指定します。
重要この PVC を満たす永続ボリューム (PV) をクラスター内の複数ノードの複数 Pod にマウントする必要がある場合には、RWX を使用します。
- ストレージ要求のサイズを定義します。
- Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
手順 (CLI)
コマンドラインインターフェイス (CLI) を使用して Manila CSI ボリュームを動的に作成するには、以下を実行します。
以下の YAML によって記述される
PersistentVolumeClaim
オブジェクトを使用してファイルを作成し、保存します。pvc-manila.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-manila spec: accessModes: 1 - ReadWriteMany resources: requests: storage: 10Gi storageClassName: csi-manila-gold 2
以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。
$ oc create -f pvc-manila.yaml
新規 PVC が作成されます。
ボリュームが作成され、準備状態にあることを確認するには、以下のコマンドを実行します。
$ oc get pvc pvc-manila
pvc-manila
は、これがBound
であることを示します。
新規 PVC を使用して Pod を設定できるようになりました。
関連情報
5.21. Secrets Store CSI ドライバー
5.21.1. 概要
Kubernetes シークレットは Base64 エンコーディングで保存されます。etcd は、これらのシークレットの保存時に暗号化しますが、シークレットの取得時に、シークレットが復号化されてユーザーに表示されます。クラスターでロールベースのアクセス制御が適切に設定されていない場合、API または etcd へのアクセス権を持つユーザーは誰でもシークレットを取得または変更できます。さらに、namespace で Pod を作成する権限を持つ人は誰でも、そのアクセス権を使用して、その namespace 内の任意のシークレットを読み取ることができます。
シークレットを安全に保存および管理するには、プロバイダープラグインを使用して、Azure Key Vault などの外部シークレット管理システムからシークレットをマウントするように OpenShift Container Platform Secrets Store Container Storage Interface (CSI) Driver Operator を設定できます。アプリケーションはシークレットを使用できますが、アプリケーション Pod が破棄されるとシークレットはシステム上に保持されません。
Secrets Store CSI Driver Operator (secrets-store.csi.k8s.io
) を使用すると、OpenShift Container Platform で、エンタープライズグレードの外部シークレットストアに保存されている複数のシークレット、キー、証明書をボリュームとして Pod にマウントできます。Secrets Store CSI Driver Operator は、gRPC を使用してプロバイダーと通信し、指定された外部シークレットストアからマウントコンテンツを取得します。ボリュームがアタッチされると、その中のデータがコンテナーのファイルシステムにマウントされます。シークレットストアボリュームはインラインでマウントされます。
CSI インラインボリュームの詳細は、CSI インライン一時ボリューム を参照してください。
GCP Filestore CSI Driver Operator は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
CSI ドライバーを使用する場合、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
5.21.1.1. シークレットストアプロバイダー
次のシークレットストアプロバイダーは、Secrets Store CSI Driver Operator で使用できます。
- AWS Secrets Manager
- AWS Systems Manager Parameter Store
- Azure Key Vault
5.21.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.21.3. Secrets Store CSI ドライバーのインストール
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
- 管理者としてクラスターにアクセスできる。
手順
Secrets Store CSI ドライバーをインストールするには、以下を実行します。
Secrets Store CSI Driver Operator をインストールします。
- Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
- フィルターボックスに "Secrets Store CSI" と入力し、Secrets Store CSI Driver Operator を見つけます。
- Secrets Store CSI Driver Operator ボタンをクリックします。
- Secrets Store CSI Driver Operator ページで、Install をクリックします。
Install Operator のページで、以下のことを確認してください。
- All namespaces on the cluster (default) が選択されている。
- Installed Namespace が openshift-cluster-csi-drivers に設定されている。
Install をクリックします。
インストールが終了すると、Web コンソールの Installed Operators セクションに GCP Filestore CSI Driver Operator がリストされます。
ドライバーの
ClusterCSIDriver
インスタンス (secrets-store.csi.k8s.io
) を作成します。- Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
Instances タブで Create ClusterCSIDriver をクリックします。
以下の YAML ファイルを使用します。
apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: secrets-store.csi.k8s.io spec: managementState: Managed
- Create をクリックします。
5.21.4. Secrets Store CSI Driver Operator のアンインストール
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
- 管理者としてクラスターにアクセスできる。
手順
Secrets Store CSI Driver Operator をアンインストールするには、以下を実行します。
-
Secrets-store.csi.k8s.io
プロバイダーを使用するすべてのアプリケーション Pod を停止します。 - 選択したシークレットストアのサードパーティープロバイダープラグインをすべて削除します。
Container Storage Interface (CSI) ドライバーと関連するマニフェストを削除します。
- Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
- Instances タブの左端にある secrets-store.csi.k8s.io でドロップダウンメニューをクリックし、Delete ClusterCSIDriver をクリックします。
- プロンプトが表示されたら、Delete をクリックします。
- CSI ドライバー Pod が稼働していないことを確認します。
Secrets Store CSI Driver Operator をアンインストールします。
注記Operator をアンインストールする前に、まず CSI ドライバーを削除する必要があります。
- Operators → Installed Operators をクリックします。
- Installed Operators ページで、スクロールするか、Search by name ボックスに "Secrets Store CSI" と入力して Operator を見つけ、クリックします。
- Installed Operators > Operator details ページの右上に表示される Actions → Uninstall Operator をクリックします。
Uninstall Operator ウィンドウでプロンプトが表示されたら、Uninstall ボタンをクリックして namespace から Operator を削除します。Operator によってクラスターにデプロイされたアプリケーションは手動でクリーンアップする必要があります。
アンインストールすると、Secrets Store CSI Driver Operator は Web コンソールの Installed Operators セクションにリストされなくなります。
5.21.5. 関連情報
5.22. VMware vSphere CSI Driver Operator
5.22.1. 概要
OpenShift Container Platform は、Virtual Machine Disk (VMDK) ボリュームの Container Storage Interface (CSI) VMware vSphere ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
vSphere ストレージアセットにマウントする CSI でプロビジョニングされた永続ボリューム (PV) を作成するには、OpenShift Container Platform は、デフォルトで vSphere CSI Driver Operator および vSphere CSI ドライバーを openshift-cluster-csi-drivers
namespace にインストールします。
-
vSphere CSI Driver Operator: Operator は、永続ボリューム要求 (PVC) の作成に使用できる
thin-csi
というストレージクラスを提供します。vSphere CSI Driver Operator は、ストレージボリュームをオンデマンドで作成できるようにし、クラスター管理者がストレージを事前にプロビジョニングする必要がなくすことで、動的ボリュームのプロビジョニングをサポートします。必要に応じて、このデフォルトのストレージクラスを無効にできます (デフォルトストレージクラスの管理 を参照)。 - vSphere CSI ドライバー: このドライバーを使用すると、vSphere PV を作成し、マウントできます。OpenShift Container Platform 4.14 のドライバーバージョンは 3.0.2 です。vSphere CSI ドライバーは、XFS や Ext4 など、基盤となる Red Hat Core OS リリースでサポートされるすべてのファイルシステムをサポートします。サポートされているファイルシステムの詳細は、利用可能なファイルシステムの概要 を参照してください。
vSphere の場合:
OpenShift Container Platform 4.13 以降の新規インストールの場合、自動移行はデフォルトで有効になっています。OpenShift Container Platform 4.15 以降に更新した場合も、自動移行が可能になります。
CSI 自動移行はシームレスに行ってください。移行をしても、永続ボリューム、永続ボリューム要求、ストレージクラスなどの既存の API オブジェクトを使用する方法は変更されません。移行の詳細は、CSI の自動移行 を参照してください。
- OpenShift Container Platform 4.12 以前から 4.13 にアップグレードする場合、vSphere の自動 CSI 移行は、オプトインした場合にのみ発生します。オプトインしない場合、OpenShift Container Platform はデフォルトでツリー内 (非 CSI) プラグインを使用して vSphere ストレージをプロビジョニングします。移行をオプトインする前に、提示された影響を慎重に確認してください。
5.22.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.22.3. vSphere CSI の制限
次の制限は、vSphere Container Storage Interface (CSI) Driver Operator に適用されます。
-
vSphere CSI Driver は、動的および静的なプロビジョニングをサポートします。ただし、PV 仕様で静的プロビジョニングを使用する場合は、
csi.volumeAttributes
でキーstorage.kubernetes.io/csiProvisionerIdentity
を使用しないでください。このキーは動的にプロビジョニングされた PV を示すためです。 - vSphere クライアントインターフェイスを使用してデータストア間で永続コンテナーボリュームを移行することは、OpenShift Container Platform ではサポートされていません。
5.22.4. vSphere ストレージポリシー
vSphere CSI Driver Operator ストレージクラスは、vSphere のストレージポリシーを使用します。OpenShift Container Platform は、クラウド設定で設定されるデータストアをターゲットにするストレージポリシーを自動的に作成します。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: thin-csi provisioner: csi.vsphere.vmware.com parameters: StoragePolicyName: "$openshift-storage-policy-xxxx" volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: false reclaimPolicy: Delete
5.22.5. ReadWriteMany vSphere ボリュームのサポート
基盤となる vSphere 環境が vSAN ファイルサービスをサポートしている場合、OpenShift Container Platform によってインストールされた vSphere Container Storage Interface (CSI) Driver Operator は ReadWriteMany (RWX) ボリュームのプロビジョニングをサポートします。vSAN ファイルサービスが設定されていない場合、使用可能なアクセスモードは ReadWriteOnce (RWO) のみです。vSAN ファイルサービスが設定されていない場合に RWX を要求すると、ボリュームの作成に失敗し、エラーがログに記録されます。
ご使用の環境で vSAN ファイルサービスを設定する方法の詳細は、vSAN File Service を参照してください。
次の永続ボリューム要求 (PVC) を行うことで、RWX ボリュームを要求できます。
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: resources: requests: storage: 1Gi accessModes: - ReadWriteMany storageClassName: thin-csi
RWX ボリュームタイプの PVC を要求すると、vSAN ファイルサービスによってサポートされる永続ボリューム (PV) がプロビジョニングされます。
5.22.6. VMware vSphere CSI Driver Operator の要件
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
サードパーティーの CSI ドライバーを削除するには、サードパーティーの vSphere CSI ドライバーの削除 を参照してください。
5.22.7. サードパーティー vSphere CSI Driver Operator の削除
OpenShift Container Platform 4.10 以降には、Red Hat がサポートする vSphere Container Storage Interface (CSI) Operator ドライバーの組み込みバージョンが含まれます。コミュニティーまたは別のベンダーが提供する vSphere CSI ドライバーをインストールした場合、OpenShift Container Platform の次のメジャーバージョン (4.13 以降など) への更新がクラスターで無効になる可能性があります。
OpenShift Container Platform 4.12 以降では、クラスターは引き続き完全にサポートされており、4.12.z などの 4.12 の z ストリームリリースの更新はブロックされませんが、OpenShift Container Platform の次のメジャーバージョンに更新する前に、サードパーティーの vSphere CSI Driver ドライバーを削除してこの状態を修正する必要があります。サードパーティーの vSphere CSI ドライバーの削除には、関連する永続ボリューム (PV) オブジェクトの削除が必要ないため、データ喪失は発生しません。
以下の手順は完全ではない可能性があるため、ベンダーまたはコミュニティープロバイダーのアンインストールガイドを参照して、ドライバーおよびコンポーネントを完全に削除してください。
サードパーティーの vSphere CSI Driver をアンインストールするには、以下を実行します。
- サードパーティーの vSphere CSI Driver(VMware vSphere Container Storage プラグイン) の Deployment および Daemonset オブジェクトを削除します。
- サードパーティーの vSphere CSI Driver で以前にインストールされた configmap およびシークレットオブジェクトを削除します。
サードパーティーの vSphere CSI ドライバー
CSIDriver
オブジェクトを削除します。~ $ oc delete CSIDriver csi.vsphere.vmware.com
csidriver.storage.k8s.io "csi.vsphere.vmware.com" deleted
OpenShift Container Platform クラスターからサードパーティーの vSphere CSI Driver を削除した後に、Red Hat の vSphere CSI Driver Operator のインストールが自動的に再開され、OpenShift Container Platform 4.11 以降へのアップグレードをブロックする可能性のある条件は自動的に削除されます。既存の vSphere CSI PV オブジェクトがある場合、それらのライフサイクルは Red Hat の vSphere CSI Driver Operator で管理されるようになります。
5.22.8. vSphere 永続ディスクの暗号化
vSphere 上で実行される OpenShift Container Platform では、仮想マシン (VM) と動的にプロビジョニングされた永続ボリューム (PV) を暗号化できます。
OpenShift Container Platform は、RWX 暗号化 PV をサポートしていません。暗号化されたストレージポリシーを使用するストレージクラスから RWX PV をリクエストすることはできません。
PV を暗号化する前に仮想マシンを暗号化する必要があります。これは、インストール中またはインストール後に実行できます。
仮想マシンの暗号化の詳細は、以下を参照してください。
VM を暗号化した後、vSphere Container Storage Interface (CSI) ドライバーを使用して、動的暗号化ボリュームプロビジョニングをサポートするストレージクラスを設定できます。これは、次の 2 つの方法のいずれかで実行できます。
- データストア URL: このアプローチは柔軟性があまり高くないため、単一のデータストアを使用する必要があります。また、トポロジーを意識したプロビジョニングもサポートしていません。
- タグベースの配置: プロビジョニングされたボリュームを暗号化し、タグベースの配置を使用して特定のデータストアをターゲットにします。
5.22.8.1. データストア URL の使用
手順
データストア URL を使用して暗号化するには、以下を実行します。
暗号化をサポートするデータストア内のデフォルトのストレージポリシーの名前を見つけます。
これは、VM の暗号化に使用されたポリシーと同じです。
このストレージポリシーを使用するストレージクラスを作成します。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: encryption provisioner: csi.vsphere.vmware.com parameters: storagePolicyName: <storage-policy-name> 1 datastoreurl: "ds:///vmfs/volumes/vsan:522e875627d-b090c96b526bb79c/"
- 1
- 暗号化をサポートするデータストア内のデフォルトのストレージポリシーの名前
5.22.8.2. タグベースの配置の使用
手順
タグベースの配置を使用して暗号化するには:
- vCenter で、このストレージクラスで使用できるデータストアにタグを付けるためのカテゴリーを作成します。また、作成されたカテゴリーの関連付け可能なエンティティーとして StoragePod (Datastore クラスター)、Datastore、および Folder が選択されていることを確認します。
- vCenter で、前に作成したカテゴリーを使用するタグを作成します。
- 以前に作成したタグを、ストレージクラスで使用できる各データストアに割り当てます。データストアが OpenShift Container Platform クラスターに参加しているホストと共有されていることを確認してください。
- vCenter で、メインメニューから Policies and Profiles をクリックします。
- Policies and Profiles ページのナビゲーションペインで、VM Storage Policies をクリックします。
- CREATE をクリックします。
- ストレージポリシーの名前を入力します。
- Enable host based rules および Enable tag based placement rules を選択します。
Next タブで:
- Encryption および Default Encryption Properties を選択します。
- 先ほど作成したタグカテゴリーを選択し、選択したタグを選択します。ポリシーが一致するデータストアを選択していることを確認します。
- ストレージポリシーを作成します。
ストレージポリシーを使用するストレージクラスを作成します。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: csi-encrypted provisioner: csi.vsphere.vmware.com reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer parameters: storagePolicyName: <storage-policy-name> 1
- 1
- 暗号化用に作成したストレージポリシーの名前
5.22.9. vSphere CSI トポロジーの概要
OpenShift Container Platform は、異なるゾーンおよびリージョンに OpenShift Container Platform for vSphere をデプロイする機能を提供します。この機能を使用することで、複数のコンピュートクラスターとデータセンターにデプロイできるため、単一障害点を回避するのに役立ちます。
これは、vCenter でゾーンとリージョンのカテゴリーを定義し、これらのゾーンとリージョンのカテゴリーのタグを作成して、コンピューティングクラスターなどのさまざまな障害ドメインにこれらのカテゴリーを割り当てることによって実現されます。適切なカテゴリーを作成し、vCenter オブジェクトにタグを割り当てたら、それらの障害ドメインで Pod のスケジュールを担当する仮想マシン (VM) を作成する追加のマシンセットを作成できます。
次の例では、1 つのリージョンと 2 つのゾーンを持つ 2 つの障害ドメインを定義しています。
計算クラスター | 障害ドメイン | 説明 |
---|---|---|
コンピューティングクラスター: ocp1、データセンター: アトランタ | openshift-region: us-east-1 (タグ)、openshift-zone: us-east-1a (タグ) | これにより、リージョン us-east-1 にゾーン us-east-1a を持つ障害ドメインが定義されます。 |
コンピュータークラスター: ocp2、データセンター: アトランタ | openshift-region: us-east-1 (タグ)、openshift-zone: us-east-1b (タグ) | これにより、us-east-1b と呼ばれる同じリージョン内の別の障害ドメインが定義されます。 |
5.22.9.1. インストール時の vSphere ストレージトポロジーの作成
5.22.9.1.1. 手順
- インストール時にトポロジーを指定します。Configuring regions and zones for a VMware vCenter セクションを参照してください。
追加のアクションは必要ありません。OpenShift Container Platform によって作成されるデフォルトのストレージクラスはトポロジーを認識し、さまざまな障害ドメインでのボリュームのプロビジョニングを許可します。
5.22.9.2. インストール後に vSphere ストレージトポロジーを作成する
5.22.9.2.1. 手順
VMware vCenter vSphere クライアント GUI で、適切なゾーンとリージョンのカテゴリーとタグを定義します。
vSphere では任意の名前でカテゴリーを作成できますが、OpenShift Container Platform では、トポロジーカテゴリーの定義に
openshift-region
名とopenshift-zone
名を使用することを強く推奨します。vSphere のカテゴリーとタグの詳細は、VMware vSphere のドキュメントを参照してください。
- OpenShift Container Platform で、障害ドメインを作成します。Specifying multiple regions and zones for your cluster on vSphere セクションを参照してください。
障害ドメイン全体のデータストアに割り当てるタグを作成します。
OpenShift Container Platform が複数の障害ドメインにまたがる場合、データストアがそれらの障害ドメイン間で共有されない可能性があります。この場合、永続ボリューム (PV) のトポロジーを意識したプロビジョニングが役立ちます。
-
vCenter で、データストアにタグを付けるためのカテゴリーを作成します。例:
openshift-zonal-datastore-cat
。カテゴリーが OpenShift Container Platform クラスターに参加するデータストアのタグ付けに一意に使用される場合、他のカテゴリー名を使用できます。また、作成したカテゴリーの関連付け可能なエンティティーとしてStoragePod
、Datastore
、およびFolder
が選択されていることを確認します。 -
vCenter で、以前に作成したカテゴリーを使用するタグを作成します。この例では、タグ名
openshift-zonal-datastore
を使用しています。 以前に作成したタグ (この例では
openshift-zonal-datastore
) を、動的プロビジョニングと見なされる障害ドメイン内の各データストアに割り当てます。注記データストアのカテゴリーとタグには任意の名前を使用できます。この例で使用されている名前は、推奨事項として提供されています。定義するタグとカテゴリーが、OpenShift Container Platform クラスター内のすべてのホストと共有されるデータストアのみを一意に識別するようにします。
-
vCenter で、データストアにタグを付けるためのカテゴリーを作成します。例:
必要に応じて、各障害ドメイン内のタグベースのデータストアを対象とするストレージポリシーを作成します。
- vCenter で、メインメニューから Policies and Profiles をクリックします。
- Policies and Profiles ページのナビゲーションペインで、VM Storage Policies をクリックします。
- CREATE をクリックします。
- ストレージポリシーの名前を入力します。
ルールについては、Tag Placement rules を選択し、目的のデータストアを対象とするタグとカテゴリーを選択します (この例では、
openshift-zonal-datastore
タグ)。データストアは、ストレージ互換性テーブルにリストされています。
新しいゾーンストレージポリシーを使用する新しいストレージクラスを作成します。
- Storage > StorageClasses をクリックします。
- StorageClasses ページで、Create StorageClass をクリックします。
- Name に新しいストレージクラスの名前を入力します。
- Provisioner で、csi.vsphere.vmware.com を選択します。
- Additional parameters で、StoragePolicyName パラメーターの Value を、前に作成した新しいゾーンストレージポリシーの名前に設定します。
Create をクリックします。
出力例
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: zoned-sc 1 provisioner: csi.vsphere.vmware.com parameters: StoragePolicyName: zoned-storage-policy 2 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer
注記前述の YAML ファイルを編集し、コマンド
oc create -f $FILE
を実行して、ストレージクラスを作成することもできます。
5.22.9.3. インフラトポロジーを使用しない vSphere ストレージトポロジーの作成
OpenShift Container Platform は、トポロジー対応セットアップで障害ドメインを指定するためにインフラストラクチャーオブジェクトを使用することを推奨します。インフラストラクチャーオブジェクトで障害ドメインを指定し、同時に ClusterCSIDriver
オブジェクトでトポロジーカテゴリーを指定することは、サポートされていない操作です。
5.22.9.3.1. 手順
VMware vCenter vSphere クライアント GUI で、適切なゾーンとリージョンのカテゴリーとタグを定義します。
vSphere では任意の名前でカテゴリーを作成できますが、OpenShift Container Platform では、トポロジーを定義するために
openshift-region
およびopenshift-zone
名を使用することを強く推奨します。vSphere のカテゴリーとタグの詳細は、VMware vSphere のドキュメントを参照してください。
Container Storage Interface (CSI) ドライバーがこのトポロジーを検出できるようにするには、
clusterCSIDriver
オブジェクトの YAML ファイルのdriverConfig
セクションを編集します。-
以前に作成した
openshift-zone
およびopenshift-region
カテゴリーを指定します。 driverType
をvSphere
に設定します。~ $ oc edit clustercsidriver csi.vsphere.vmware.com -o yaml
出力例
apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: csi.vsphere.vmware.com spec: logLevel: Normal managementState: Managed observedConfig: null operatorLogLevel: Normal unsupportedConfigOverrides: null driverConfig: driverType: vSphere 1 vSphere: topologyCategories: 2 - openshift-zone - openshift-region
-
以前に作成した
次のコマンドを実行して、
CSINode
オブジェクトにトポロジーキーがあることを確認します。~ $ oc get csinode
出力例
NAME DRIVERS AGE co8-4s88d-infra-2m5vd 1 27m co8-4s88d-master-0 1 70m co8-4s88d-master-1 1 70m co8-4s88d-master-2 1 70m co8-4s88d-worker-j2hmg 1 47m co8-4s88d-worker-mbb46 1 47m co8-4s88d-worker-zlk7d 1 47m
~ $ oc get csinode co8-4s88d-worker-j2hmg -o yaml
出力例
... spec: drivers: - allocatable: count: 59 name: csi-vsphere.vmware.com nodeID: co8-4s88d-worker-j2hmg topologyKeys: 1 - topology.csi.vmware.com/openshift-zone - topology.csi.vmware.com/openshift-region
- 1
- vSphere
openshift-zone
およびopenshift-region
カテゴリーからのトポロジーキー。
注記CSINode
オブジェクトは、更新されたトポロジー情報を受信するのに時間がかかる場合があります。ドライバーが更新された後、CSINode
オブジェクトにはトポロジーキーが含まれている必要があります。障害ドメイン全体のデータストアに割り当てるタグを作成します。
OpenShift Container Platform が複数の障害ドメインにまたがる場合、データストアがそれらの障害ドメイン間で共有されない可能性があります。この場合、永続ボリューム (PV) のトポロジーを意識したプロビジョニングが役立ちます。
-
vCenter で、データストアにタグを付けるためのカテゴリーを作成します。例:
openshift-zonal-datastore-cat
。カテゴリーが OpenShift Container Platform クラスターに参加するデータストアのタグ付けに一意に使用される場合、他のカテゴリー名を使用できます。また、作成したカテゴリーの関連付け可能なエンティティーとしてStoragePod
、Datastore
、およびFolder
が選択されていることを確認します。 -
vCenter で、以前に作成したカテゴリーを使用するタグを作成します。この例では、タグ名
openshift-zonal-datastore
を使用しています。 以前に作成したタグ (この例では
openshift-zonal-datastore
) を、動的プロビジョニングと見なされる障害ドメイン内の各データストアに割り当てます。注記カテゴリーとタグには、好きな名前を使用できます。この例で使用されている名前は、推奨事項として提供されています。定義するタグとカテゴリーが、OpenShift Container Platform クラスター内のすべてのホストと共有されるデータストアのみを一意に識別するようにします。
-
vCenter で、データストアにタグを付けるためのカテゴリーを作成します。例:
各障害ドメインのタグベースのデータストアを対象とするストレージポリシーを作成します。
- vCenter で、メインメニューから Policies and Profiles をクリックします。
- Policies and Profiles ページのナビゲーションペインで、VM Storage Policies をクリックします。
- CREATE をクリックします。
- ストレージポリシーの名前を入力します。
ルールについては、Tag Placement rules を選択し、目的のデータストアを対象とするタグとカテゴリーを選択します (この例では、
openshift-zonal-datastore
タグ)。データストアは、ストレージ互換性テーブルにリストされています。
新しいゾーンストレージポリシーを使用する新しいストレージクラスを作成します。
- Storage > StorageClasses をクリックします。
- StorageClasses ページで、Create StorageClass をクリックします。
- Name に新しいストレージクラスの名前を入力します。
- Provisioner で、csi.vsphere.vmware.com を選択します。
- Additional parameters で、StoragePolicyName パラメーターの Value を、前に作成した新しいゾーンストレージポリシーの名前に設定します。
Create をクリックします。
出力例
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: zoned-sc 1 provisioner: csi.vsphere.vmware.com parameters: StoragePolicyName: zoned-storage-policy 2 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer
注記前述の YAML ファイルを編集し、コマンド
oc create -f $FILE
を実行して、ストレージクラスを作成することもできます。
5.22.9.4. 結果
トポロジー対応ストレージクラスからの永続ボリュームクレーム (PVC) と PV の作成は完全にゾーンであり、Pod のスケジュール方法に応じて、それぞれのゾーンでデータストアを使用する必要があります。
~ $ oc get pv <pv-name> -o yaml
出力例
... nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: topology.csi.vmware.com/openshift-zone 1 operator: In values: - <openshift-zone> -key: topology.csi.vmware.com/openshift-region 2 operator: In values: - <openshift-region> ... peristentVolumeclaimPolicy: Delete storageClassName: <zoned-storage-class-name> 3 volumeMode: Filesystem ...
5.22.10. 関連情報
第6章 汎用的な一時ボリューム
6.1. 概要
汎用一時ボリュームは、永続ボリュームおよび動的プロビジョニングをサポートするすべてのストレージドライバーが提供できる一時ボリュームの一種です。汎用の一時ボリュームは、スクラッチデータ用に Pod ごとのディレクトリー (通常、プロビジョニング後は空) を提供する点で emptyDir
ボリュームと類似しています。
汎用の一時ボリュームは Pod 仕様に準拠して指定され、Pod のライフサイクルに従います。これらは Pod と共に作成され、削除されます。
汎用の一時ボリュームには、以下の特徴があります。
- ストレージは、ローカルまたはネットワーク接続タイプとすることができます。
- ボリュームには、Pod が超過できない固定サイズを指定できます。
- ドライバーおよびパラメーターによっては、ボリュームに特定の初期データが含まれる場合があります。
- ドライバーがサポートしていれば、スナップショットの作成、クローンの作成、サイズ変更、ストレージ容量の追跡など、ボリュームに対する一般的な操作がサポートされます。
汎用の一時ボリュームは、オフラインのスナップショットやサイズ変更をサポートしません。
この制約により、以下の Container Storage Interface (CSI) ドライバーは、以下の汎用一時ボリューム機能をサポートしません。
- Azure Disk CSI ドライバーは、サイズ変更をサポートしません。
- Cinder CSI ドライバーは、スナップショットをサポートしません。
6.2. ライフサイクルおよび永続ボリューム要求
ボリューム要求のパラメーターは Pod のボリュームソース内で許可されます。ラベル、アノテーション、および永続ボリューム要求 (PVC) のフィールドの全セットがサポートされます。このような Pod が作成されると、一時ボリュームコントローラーは (汎用一時ボリュームの作成 の手順に示すテンプレートから) Pod と同じ namespace に実際の PVC オブジェクトを作成し、Pod が削除されると PVC が削除されるようにします。これがトリガーとなり、以下の 2 つの方法のいずれかでボリュームのバインディングおよびプロビジョニングが行われます。
直ちに (ストレージクラスが即時ボリュームバインディングを使用する場合は)
即時バインディングの場合、スケジューラーはボリュームが利用可能になった後にボリュームにアクセスできるノードを強制的に選択させられます。
Pod が一時的にノードにスケジュールされる場合 (
WaitForFirstConsumervolume
バインディングモード)スケジューラーは Pod に適したノードを選択できるため、このボリュームバインディングオプションは、汎用一時ボリュームに推奨されます。
リソースの所有権に関しては、汎用一時ストレージを持つ Pod は、その一時ストレージを提供する PVC の所有者となります。Pod が削除されると、Kubernetes ガベージコレクターによって PVC が削除され、ストレージクラスのデフォルトの再利用ポリシーがボリュームを削除することになっているため、通常はボリュームの削除がトリガーされます。回収ポリシーが保持のストレージクラスを使用して、準一時ローカルストレージを作成できます。Pod が削除されてもストレージは存続するため、この場合は別途ボリュームのクリーンアップが行われるようにする必要があります。これらの PVC は存在しますが、それらは他の PVC と同様に使用できます。特に、それらはボリュームのクローン作成またはスナップショット作成時にデータソースとして参照できます。PVC オブジェクトは、ボリュームの現在のステータスも保持します。
関連情報
6.3. セキュリティー
汎用一時ボリューム機能を有効にすると、Pod を作成できるユーザーが永続ボリューム要求 (PVC) も間接的に作成できるようになります。この機能は、これらのユーザーが PVC を直接作成するパーミッションを持たない場合でも機能します。クラスター管理者はこれを認識している必要があります。これがセキュリティーモデルに適さない場合は、汎用的な一時ボリュームを持つ Pod などのオブジェクトを拒否する容認 Webhook を使用します。
PVC に対する通常の namespace クォータがそのまま適用されるため、この新しいメカニズムを使用できる場合でも新しいメカニズムを使用して他のポリシーを回避できません。
6.4. 永続ボリューム要求の命名
自動的に作成される永続ボリューム要求 (PVC) には、Pod 名とボリューム名を組み合わせ、間にハイフン (-) を挿入した名前が付けられます。この命名規則では、異なる Pod 間および Pod と手動で作成された PVC 間で競合が生じる可能性があります。
たとえば、pod-a
とボリューム scratch
の組み合わせと、pod
とボリューム a-scratch
の組み合わせは、どちらも同じ PVC 名 pod-a-scratch
になります。
このような競合は検出され、Pod 用に作成された場合にのみ、PVC は一時ボリュームに使用されます。このチェックは所有者の関係に基づいています。既存の PVC は上書きまたは変更されませんが、競合は解決されません。適切な PVC がないと、Pod は起動できません。
同じ namespace 内で Pod とボリュームに名前を付ける際には、命名の競合が発生しないように注意してください。
6.5. 汎用一時ボリュームの作成
手順
-
pod
オブジェクト定義を作成し、これをファイルに保存します。 ファイルに汎用一時ボリュームの情報を追加します。
my-example-pod-with-generic-vols.yaml
kind: Pod apiVersion: v1 metadata: name: my-app spec: containers: - name: my-frontend image: busybox:1.28 volumeMounts: - mountPath: "/mnt/storage" name: data command: [ "sleep", "1000000" ] volumes: - name: data 1 ephemeral: volumeClaimTemplate: metadata: labels: type: my-app-ephvol spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "gp2-csi" resources: requests: storage: 1Gi
- 1
- 汎用一時ボリューム要求
第7章 永続ボリュームの拡張
7.1. ボリューム拡張サポートの有効化
永続ボリュームを拡張する前に、StorageClass
オブジェクトでは allowVolumeExpansion
フィールドを true
に設定している必要があります。
手順
StorageClass
オブジェクトを編集し、以下のコマンドを実行してallowVolumeExpansion
属性を追加します。$ oc edit storageclass <storage_class_name> 1
- 1
- ストレージクラスの名前を指定します。
以下の例では、ストレージクラスの設定の下部にこの行を追加する方法を示しています。
apiVersion: storage.k8s.io/v1 kind: StorageClass ... parameters: type: gp2 reclaimPolicy: Delete allowVolumeExpansion: true 1
- 1
- この属性を
true
に設定すると、PVC を作成後に拡張することができます。
7.2. CSI ボリュームの拡張
Container Storage Interface (CSI) を使用して、作成後にストレージボリュームを拡張することができます。
CSI ボリューム拡張は、以下をサポートしません。
- ボリューム拡張時の障害からの復旧
- 縮小
前提条件
- 基礎となる CSI ドライバーがサイズ変更をサポートする。
- 動的プロビジョニングが使用される。
-
制御する側の
StorageClass
オブジェクトにはallowVolumeExpansion
がtrue
に設定されている。詳細は、「ボリューム拡張サポートの有効化」を参照してください。
手順
-
永続ボリューム要求 (PVC) の場合は、
.spec.resources.requests.storage
を必要な新しいサイズに設定します。 -
PVC の
status.conditions
フィールドを監視し、サイズ変更が完了したかどうかを確認します。OpenShift Container Platform は、拡張時にResizing
条件を PVC に追加します。これは、拡張の完了後に削除されます。
7.3. サポートされているドライバーでの FlexVolume の拡張
FlexVolume を使用してバックエンドストレージシステムに接続する場合は、永続ストレージボリュームを作成後に拡張することができます。これは、OpenShift Container Platform で永続ボリューム要求 (PVC) を手動で更新して実行できます。
FlexVolume は、ドライバーが RequiresFSResize
が true
の状態で設定されている場合に拡張を許可します。FlexVolume は、Pod の再起動時に拡張できます。
他のボリュームタイプと同様に、FlexVolume ボリュームは Pod によって使用される場合にも拡張できます。
前提条件
- 基礎となるボリュームドライバーがサイズ変更をサポートする。
-
ドライバーは
RequiresFSResize
機能がtrue
の状態で設定されている。 - 動的プロビジョニングが使用される。
-
制御する側の
StorageClass
オブジェクトにはallowVolumeExpansion
がtrue
に設定されている。
手順
FlexVolume プラグインのサイズ変更を使用するには、以下の方法で
ExpandableVolumePlugin
インターフェイスを実装する必要があります。RequiresFSResize
-
true
の場合、容量を直接更新します。false
の場合、ExpandFS
メソッドを呼び出し、ファイルシステムのサイズ変更を終了します。 ExpandFS
-
true
の場合、ExpandFS
を呼び出し、物理ボリュームの拡張の実行後にファイルシステムのサイズを変更します。ボリュームドライバーは、ファイルシステムのサイズ変更と共に物理ボリュームのサイズ変更も実行できます。
OpenShift Container Platform はコントロールプレーンノードへの FlexVolume プラグインのインストールをサポートしないため、FlexVolume のコントロールプレーンの拡張をサポートしません。
7.4. ローカルボリュームの拡張
ローカルストレージ Operator (LSO) を使用して作成された永続ボリューム (PV) および永続ボリューム要求 (PVC) を手動で拡張できます。
手順
- 基礎となるデバイスを拡張します。これらのデバイスで適切な容量が利用できるようにします。
-
PV の
.spec.capacity
フィールドを編集して、新しいデバイスサイズに一致するように対応する PV オブジェクトを更新します。 -
PVC を PVet にバインドするためのストレージクラスに
allowVolumeExpansion:true
を設定します。 -
PVC に新しいサイズに一致するように
.spec.resources.requests.storage
を設定します。
Kubelet は、ボリューム上の基礎となるファイルシステムを自動的に拡張するはずです。必要に応じて、新しいサイズを反映するように PVC の status フィールドを更新します。
7.5. ファイルシステムを使用した永続ボリューム要求 (PVC) の拡張
ファイルシステムのサイズ変更を必要とするボリュームタイプ (GCE、EBS、および Cinder など) に基づいて PVC を拡張するには 2 つの手順からなるプロセスが必要です。まず、クラウドプロバイダーのボリュームオブジェクトを拡張します。次に、ノードのファイルシステムを拡張します。
ノードでのファイルシステムの拡張は、新規 Pod がボリュームと共に起動する場合にのみ実行されます。
前提条件
-
制御する側の
StorageClass
オブジェクトでは、allowVolumeExpansion
がtrue
に設定されている必要がある。
手順
spec.resources.requests
を編集して PVC を編集し、新規サイズを要求します。たとえば、以下ではebs
PVC を 8 Gi に拡張します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: ebs spec: storageClass: "storageClassWithFlagSet" accessModes: - ReadWriteOnce resources: requests: storage: 8Gi 1
- 1
spec.resources.requests
をさらに大きな量を表す値に更新すると、PVC が拡張されます。
クラウドプロバイダーオブジェクトのサイズ変更が終了すると、PVC は
FileSystemResizePending
に設定されます。以下のコマンドを入力して状態を確認します。$ oc describe pvc <pvc_name>
-
クラウドプロバイダーオブジェクトのサイズ変更が終了すると、
PersistentVolume
オブジェクトはPersistentVolume.Spec.Capacity
に新規に要求されたサイズを反映します。この時点で、PVC から新規 Pod を作成または再作成してファイルシステムのサイズ変更を終了できます。Pod が実行している場合は、新たに要求されたサイズが利用可能になり、FileSystemResizePending
状態が PVC から削除されます。
7.6. ボリューム拡張時の障害からの復旧
基礎となるストレージの拡張に失敗した場合に、OpenShift Container Platform の管理者は永続ボリューム要求 (PVC) の状態を手動で復旧し、サイズ変更要求を取り消します。そうでない場合には、サイズ変更要求がコントローラーによって継続的に再試行されます。
手順
-
Retain
回収ポリシーで要求 (PVC) にバインドされている永続ボリューム (PV) にマークを付けます。これは、PV を編集し、persistentVolumeReclaimPolicy
をRetain
に変更して実行できます。 - PVC を削除します。
-
PV を手動で編集し、PV 仕様から
claimRef
エントリーを削除して、新しく作成された PVC をRetain
とマークされた PV にバインドできるようにします。これで、PV にはAvailable
というマークが付けられます。 - より小さいサイズ、または基礎となるストレージプロバイダーによって割り当て可能なサイズで PVC を再作成します。
-
PVC の
volumeName
フィールドを PV の名前に設定します。これにより、PVC がプロビジョニングされた PV にのみバインドされます。 - PV で回収ポリシーを復元します。
関連情報
-
制御する側の
StorageClass
オブジェクトには、allowVolumeExpansion
がtrue
に設定されています (ボリューム拡張サポートの有効化 を参照)。
第8章 動的プロビジョニング
8.1. 動的プロビジョニングについて
StorageClass
リソースオブジェクトは、要求可能なストレージを記述し、分類するほか、動的にプロビジョニングされるストレージのパラメーターを要求に応じて渡すための手段を提供します。StorageClass
オブジェクトは、さまざまなレベルのストレージとストレージへのアクセスを制御するための管理メカニズムとしても機能します。クラスター管理者 (cluster-admin
) またはストレージ管理者 (storage-admin
) は、ユーザーが基礎となるストレージボリュームソースに関する詳しい知識がなくても要求できる StorageClass
オブジェクトを定義し、作成します。
OpenShift Container Platform の永続ボリュームフレームワークはこの機能を有効にし、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。フレームワークにより、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。
OpenShift Container Platform では、数多くのストレージタイプを永続ボリュームとして使用することができます。これらはすべて管理者によって静的にプロビジョニングされますが、一部のストレージタイプは組み込みプロバイダーとプラグイン API を使用して動的に作成できます。
8.2. 利用可能な動的プロビジョニングプラグイン
OpenShift Container Platform は、以下のプロビジョナープラグインを提供します。これらには、クラスターの設定済みプロバイダーの API を使用して新規ストレージリソースを作成する動的プロビジョニング用の一般的な実装が含まれます。
ストレージタイプ | プロビジョナープラグインの名前 | 注記 |
---|---|---|
Red Hat OpenStack Platform (RHOSP) Cinder |
| |
RHOSP Manila Container Storage Interface (CSI) |
| インストールが完了すると、OpenStack Manila CSI Driver Operator および ManilaDriver は、動的プロビジョニングに必要なすべての利用可能な Manila 共有タイプに必要なストレージクラスを自動的に作成します。 |
Amazon Elastic Block Store (Amazon EBS) |
|
複数クラスターを複数の異なるゾーンで使用する際の動的プロビジョニングの場合、各ノードに |
Azure Disk |
| |
Azure File |
|
|
GCE Persistent Disk (gcePD) |
| マルチゾーン設定では、GCE プロジェクトごとに OpenShift Container Platform クラスターを実行し、現行クラスターのノードが存在しないゾーンで PV が作成されないようにすることが推奨されます。 |
IBM Power® 仮想サーバーブロック |
| インストール後、IBM Power® Virtual Server Block CSI Driver Operator と IBM Power® Virtual Server Block CSI Driver は、動的プロビジョニングに必要なストレージクラスを自動的に作成します。 |
|
選択したプロビジョナープラグインでは、関連するクラウド、ホスト、またはサードパーティープロバイダーを、関連するドキュメントに従って設定する必要もあります。
8.3. ストレージクラスの定義
現時点で、StorageClass
オブジェクトはグローバルスコープオブジェクトであり、cluster-admin
または storage-admin
ユーザーによって作成される必要があります。
Cluster Storage Operator は、使用されるプラットフォームに応じてデフォルトのストレージクラスをインストールする可能性があります。このストレージクラスは Operator によって所有され、制御されます。アノテーションとラベルを定義するほかは、これを削除したり、変更したりすることはできません。異なる動作が必要な場合は、カスタムストレージクラスを定義する必要があります。
以下のセクションでは、StorageClass
オブジェクトの基本的な定義とサポートされている各プラグインタイプの具体的な例を説明します。
8.3.1. 基本 StorageClass オブジェクト定義
以下のリソースは、ストレージクラスを設定するために使用するパラメーターおよびデフォルト値を示しています。この例では、AWS ElasticBlockStore (EBS) オブジェクト定義を使用します。
StorageClass
定義の例
kind: StorageClass 1 apiVersion: storage.k8s.io/v1 2 metadata: name: <storage-class-name> 3 annotations: 4 storageclass.kubernetes.io/is-default-class: 'true' ... provisioner: kubernetes.io/aws-ebs 5 parameters: 6 type: gp3 ...
8.3.2. ストレージクラスのアノテーション
ストレージクラスをクラスター全体のデフォルトとして設定するには、以下のアノテーションをストレージクラスのメタデータに追加します。
storageclass.kubernetes.io/is-default-class: "true"
以下に例を示します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: storageclass.kubernetes.io/is-default-class: "true" ...
これにより、特定のストレージクラスを指定しない永続ボリューム要求 (PVC) がデフォルトのストレージクラスによって自動的にプロビジョニングされるようになります。ただし、クラスターには複数のストレージクラスを設定できますが、それらのうちの 1 つのみをデフォルトのストレージクラスにすることができます。
ベータアノテーションの storageclass.beta.kubernetes.io/is-default-class
は依然として使用可能ですが、今後のリリースで削除される予定です。
ストレージクラスの記述を設定するには、以下のアノテーションをストレーククラスのメタデータに追加します。
kubernetes.io/description: My Storage Class Description
以下に例を示します。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: kubernetes.io/description: My Storage Class Description ...
8.3.3. RHOSP Cinder オブジェクトの定義
cinder-storageclass.yaml
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: <storage-class-name> 1 provisioner: kubernetes.io/cinder parameters: type: fast 2 availability: nova 3 fsType: ext4 4
- 1
- ストレージクラス名永続ボリューム要求は、関連する永続ボリュームをプロビジョニングするためにこのストレージクラスを使用します。
- 2
- Cinder で作成されるボリュームタイプ。デフォルトは空です。
- 3
- アベイラビリティーゾーン。指定しない場合、ボリュームは通常 OpenShift Container Platform クラスターのノードがあるすべてのアクティブゾーンでラウンドロビンされます。
- 4
- 動的にプロビジョニングされたボリュームで作成されるファイルシステム。この値は、動的にプロビジョニングされる永続ボリュームの
fsType
フィールドにコピーされ、ボリュームの初回マウント時にファイルシステムが作成されます。デフォルト値はext4
です。
8.3.4. RHOSP Manila Container Storage Interface (CSI) オブジェクト定義
インストールが完了すると、OpenStack Manila CSI Driver Operator および ManilaDriver は、動的プロビジョニングに必要なすべての利用可能な Manila 共有タイプに必要なストレージクラスを自動的に作成します。
8.3.5. AWS Elastic Block Store (EBS) オブジェクト定義
aws-ebs-storageclass.yaml
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: <storage-class-name> 1 provisioner: kubernetes.io/aws-ebs parameters: type: io1 2 iopsPerGB: "10" 3 encrypted: "true" 4 kmsKeyId: keyvalue 5 fsType: ext4 6
- 1
- (必須) ストレージクラスの名前。永続ボリューム要求は、関連する永続ボリュームをプロビジョニングするためにこのストレージクラスを使用します。
- 2
- 3
- (オプション) io1 ボリュームのみ。1 GiB あたり 1 秒あたりの I/O 処理数。AWS ボリュームプラグインは、この値と要求されたボリュームのサイズを乗算してボリュームの IOPS を算出します。値の上限は、AWS でサポートされる最大値である 20,000 IOPS です。詳細は、AWS のドキュメント を参照してください。
- 4
- (オプション) EBS ボリュームを暗号化するかどうかを示します。有効な値は
true
またはfalse
です。 - 5
- (オプション) ボリュームを暗号化する際に使用するキーの完全な ARN。値を指定しない場合でも
encypted
がtrue
に設定されている場合は、AWS によってキーが生成されます。有効な ARN 値は、AWS のドキュメント を参照してください。 - 6
- (オプション) 動的にプロビジョニングされたボリュームで作成されるファイルシステム。この値は、動的にプロビジョニングされる永続ボリュームの
fsType
フィールドにコピーされ、ボリュームの初回マウント時にファイルシステムが作成されます。デフォルト値はext4
です。
8.3.6. Azure Disk オブジェクト定義
azure-advanced-disk-storageclass.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class-name> 1 provisioner: kubernetes.io/azure-disk volumeBindingMode: WaitForFirstConsumer 2 allowVolumeExpansion: true parameters: kind: Managed 3 storageaccounttype: Premium_LRS 4 reclaimPolicy: Delete
- 1
- ストレージクラス名永続ボリューム要求は、関連する永続ボリュームをプロビジョニングするためにこのストレージクラスを使用します。
- 2
WaitForFirstConsumer
を使用することが強く推奨されます。これにより、Pod を利用可能なゾーンから空きのあるワーカーノードにスケジュールするのに十分なストレージがボリュームプロビジョニングされます。- 3
- 許容値は、
Shared
(デフォルト)、Managed
、およびDedicated
です。重要Red Hat は、ストレージクラスでの
kind: Managed
の使用のみをサポートします。Shared
およびDedicated
の場合、Azure はマネージド外のディスクを作成しますが、OpenShift Container Platform はマシンの OS (root) ディスクの管理ディスクを作成します。ただし、Azure Disk はノードで管理ディスクおよびマネージド外ディスクの両方の使用を許可しないため、Shared
またはDedicated
で作成されたマネージド外ディスクを OpenShift Container Platform ノードに割り当てることはできません。 - 4
- Azure ストレージアカウントの SKU 層。デフォルトは空です。プレミアム VM は
Standard_LRS
ディスクとPremium_LRS
ディスクの両方を割り当て、標準 VM はStandard_LRS
ディスクのみを、マネージド VM はマネージドディスクのみを、アンマネージド VM はアンマネージドディスクのみを割り当てることができます。-
kind
がShared
に設定されている場合は、Azure は、クラスターと同じリソースグループにあるいくつかの共有ストレージアカウントで、アンマネージドディスクをすべて作成します。 -
kind
がManaged
に設定されている場合は、Azure は新しいマネージドディスクを作成します。 kind
がDedicated
に設定されており、storageAccount
が指定されている場合には、Azure は、クラスターと同じリソースグループ内にある新規のアンマネージドディスク用に、指定のストレージアカウントを使用します。これを機能させるには、以下が前提となります。- 指定のストレージアカウントが、同じリージョン内にあること。
- Azure Cloud Provider にストレージアカウントへの書き込み権限があること。
-
kind
がDedicated
に設定されており、storageAccount
が指定されていない場合には、Azure はクラスターと同じリソースグループ内の新規のアンマネージドディスク用に、新しい専用のストレージアカウントを作成します。
-
8.3.7. Azure File のオブジェクト定義
Azure File ストレージクラスはシークレットを使用して Azure ストレージアカウント名と Azure ファイル共有の作成に必要なストレージアカウントキーを保存します。これらのパーミッションは、以下の手順の一部として作成されます。
手順
シークレットの作成および表示を可能にする
ClusterRole
オブジェクトを定義します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: # name: system:azure-cloud-provider name: <persistent-volume-binder-role> 1 rules: - apiGroups: [''] resources: ['secrets'] verbs: ['get','create']
- 1
- シークレットを表示し、作成するためのクラスターロールの名前。
クラスターロールをサービスアカウントに追加します。
$ oc adm policy add-cluster-role-to-user <persistent-volume-binder-role> system:serviceaccount:kube-system:persistent-volume-binder
Azure File
StorageClass
オブジェクトを作成します。kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: <azure-file> 1 provisioner: kubernetes.io/azure-file parameters: location: eastus 2 skuName: Standard_LRS 3 storageAccount: <storage-account> 4 reclaimPolicy: Delete volumeBindingMode: Immediate
- 1
- ストレージクラス名永続ボリューム要求は、関連する永続ボリュームをプロビジョニングするためにこのストレージクラスを使用します。
- 2
eastus
などの Azure ストレージアカウントの場所。デフォルトは空であり、新規 Azure ストレージアカウントが OpenShift Container Platform クラスターの場所に作成されます。- 3
Standard_LRS
などの Azure ストレージアカウントの SKU 層。デフォルトは空です。つまり、新しい Azure ストレージアカウントはStandard_LRS
SKU で作成されます。- 4
- Azure ストレージアカウントの名前。ストレージアカウントが提供されると、
skuName
およびlocation
は無視されます。ストレージアカウントを指定しない場合、ストレージクラスは、定義されたskuName
およびlocation
に一致するアカウントのリソースグループに関連付けられたストレージアカウントを検索します。
8.3.7.1. Azure File を使用する場合の考慮事項
以下のファイルシステム機能は、デフォルトの Azure File ストレージクラスではサポートされません。
- シンボリックリンク
- ハードリンク
- 拡張属性
- スパースファイル
- 名前付きパイプ
また、Azure File がマウントされるディレクトリーの所有者 ID (UID) は、コンテナーのプロセス UID とは異なります。uid
マウントオプションは StorageClass
オブジェクトに指定して、マウントされたディレクトリーに使用する特定のユーザー ID を定義できます。
以下の StorageClass
オブジェクトは、マウントされたディレクトリーのシンボリックリンクを有効にした状態で、ユーザーおよびグループ ID を変更する方法を示しています。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: azure-file mountOptions: - uid=1500 1 - gid=1500 2 - mfsymlinks 3 provisioner: kubernetes.io/azure-file parameters: location: eastus skuName: Standard_LRS reclaimPolicy: Delete volumeBindingMode: Immediate
8.3.8. GCE PersistentDisk (gcePD) オブジェクトの定義
gce-pd-storageclass.yaml
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class-name> 1 provisioner: kubernetes.io/gce-pd parameters: type: pd-standard 2 replication-type: none volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true reclaimPolicy: Delete
8.3.9. VMware vSphere オブジェクトの定義
vsphere-storageclass.yaml
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: <storage-class-name> 1 provisioner: csi.vsphere.vmware.com 2
- 1
- ストレージクラス名永続ボリューム要求は、関連する永続ボリュームをプロビジョニングするためにこのストレージクラスを使用します。
- 2
- OpenShift Container Platform での VMware vSphere CSI の使用の詳細は、Kubernetes のドキュメント を参照してください。
8.4. デフォルトストレージクラスの変更
次の手順を使用して、デフォルトのストレージクラスを変更します。
たとえば、gp3
と standard
の 2 つのストレージクラスがあり、デフォルトのストレージクラスを gp3
から standard
に変更する必要がある場合などです。
前提条件
- クラスター管理者権限でクラスターにアクセスできる。
手順
デフォルトのストレージクラスを変更するには、以下を実行します。
ストレージクラスを一覧表示します。
$ oc get storageclass
出力例
NAME TYPE gp3 (default) kubernetes.io/aws-ebs 1 standard kubernetes.io/aws-ebs
- 1
(default)
はデフォルトのストレージクラスを示します。
目的のストレージクラスをデフォルトにします。
目的のストレージクラスに、次のコマンドを実行して
storageclass.kubernetes.io/is-default-class
アノテーションをtrue
に設定します。$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
注記短期間であれば、複数のデフォルトのストレージクラスを使用できます。ただし、最終的には 1 つのデフォルトのストレージクラスのみが存在することを確認する必要があります。
複数のデフォルトストレージクラスが存在する場合、デフォルトストレージクラス (
pvc.spec.storageClassName
=nil) を要求するすべての永続ボリューム要求 (PVC) は、そのストレージクラスのデフォルトステータスと管理者に関係なく、最後に作成されたデフォルトストレージクラスを取得します。アラートダッシュボードで、複数のデフォルトストレージクラスMultipleDefaultStorageClasses
があるというアラートを受け取ります。古いデフォルトストレージクラスからデフォルトのストレージクラス設定を削除します。
古いデフォルトのストレージクラスの場合は、次のコマンドを実行して
storageclass.kubernetes.io/is-default-class
アノテーションの値をfalse
に変更します。$ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
変更内容を確認します。
$ oc get storageclass
出力例
NAME TYPE gp3 kubernetes.io/aws-ebs standard (default) kubernetes.io/aws-ebs
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.