ストレージ
OpenShift Dedicated クラスターのストレージの設定
概要
第1章 OpenShift Dedicated ストレージの概要
OpenShift Dedicated は、オンプレミスプロバイダーとクラウドプロバイダーの両方で、複数のタイプのストレージをサポートします。OpenShift Dedicated クラスターでは、永続データと非永続データのコンテナーストレージを管理できます。
1.1. OpenShift Dedicated ストレージの一般用語集
この用語集では、ストレージコンテンツで使用される一般的な用語を定義します。
- アクセスモード
ボリュームアクセスモードは、ボリューム機能を表します。アクセスモードを使用して、永続ボリューム要求 (PVC) と永続ボリューム (PV) を一致させることができます。次に、アクセスモードの例を示します。
- ReadWriteOnce (RWO)
- ReadOnlyMany (ROX)
- ReadWriteMany (RWX)
- ReadWriteOncePod (RWOP)
- config map
-
config map は、設定データを Pod に注入する方法を提供します。タイプ
ConfigMap
のボリューム内の config map に格納されたデータを参照できます。Pod で実行しているアプリケーションは、このデータを使用できます。 - Container Storage Interface (CSI)
- 異なるコンテナーオーケストレーション (CO) システム間でコンテナーストレージを管理するための API 仕様。
- 動的プロビジョニング
- このフレームワークを使用すると、ストレージボリュームをオンデマンドで作成できるため、クラスター管理者が永続ストレージを事前にプロビジョニングする必要がなくなります。
- 一時ストレージ
- Pod とコンテナーは、その操作のために一時的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。
- fsGroup
- fsGroup は、Pod のファイルシステムグループ ID を定義します。
- hostPath
- OpenShift Container Platform クラスター内の hostPath ボリュームは、ファイルまたはディレクトリーをホストノードのファイルシステムから Pod にマウントします。
- KMS キー
- Key Management Service (KMS) は、さまざまなサービスで必要なレベルのデータ暗号化を実現するのに役立ちます。KMS キーを使用して、データの暗号化、復号化、および再暗号化を行うことができます。
- ローカルボリューム
- ローカルボリュームは、ディスク、パーティション、ディレクトリーなどのマウントされたローカルストレージデバイスを表します。
- OpenShift Data Foundation
- インハウスまたはハイブリッドクラウドのいずれの場合でもファイル、ブロック、およびオブジェクトストレージをサポートし、OpenShift Container Platform のすべてに対応する非依存永続ストレージのプロバイダーです。
- 永続ストレージ
- Pod とコンテナーは、その操作のために永続的なストレージを必要とする場合があります。OpenShift Dedicated は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、基盤となるストレージインフラストラクチャーに関する特定の知識がなくても、PVC を使用して PV リソースを要求できます。
- 永続ボリューム (PV)
- OpenShift Dedicated は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、基盤となるストレージインフラストラクチャーに関する特定の知識がなくても、PVC を使用して PV リソースを要求できます。
- 永続ボリューム要求 (PVC)
- PVC を使用して、PersistentVolume を Pod にマウントできます。クラウド環境の詳細を知らなくてもストレージにアクセスできます。
- Pod
- OpenShift Dedicated クラスターで実行されている、ボリュームや IP アドレスなどの共有リソースを持つ 1 つ以上のコンテナー。Pod は、定義、デプロイ、および管理される最小のコンピュート単位です。
- 回収ポリシー
-
解放後のボリュームの処理方法をクラスターに指示するポリシー。ボリュームの回収ポリシーは、
Retain
、Recycle
またはDelete
のいずれかにすることができます。 - ロールベースアクセス制御 (RBAC)
- ロールベースのアクセス制御 (RBAC) は、組織内の個々のユーザーのロールに基づいて、コンピューターまたはネットワークリソースへのアクセスを規制する方法です。
- ステートレスアプリケーション
- ステートレスアプリケーションは、あるセッションで生成されたクライアントデータを、そのクライアントとの次のセッションで使用するために保存しないアプリケーションプログラムです。
- ステートフルアプリケーション
-
ステートフルアプリケーションは、データを永続ディスクストレージに保存するアプリケーションプログラムです。サーバー、クライアント、およびアプリケーションは、永続ディスクストレージを使用できます。OpenShift Dedicated で
Statefulset
オブジェクトを使用して一連の Pod のデプロイメントとスケーリングを管理し、これらの Pod の順序と一意性を保証できます。 - 静的プロビジョニング
- クラスター管理者は、多数の PV を作成します。PV にはストレージの詳細が含まれます。PV は Kubernetes API に存在し、消費することができます。
- ストレージ
- OpenShift Dedicated は、オンプレミスプロバイダーとクラウドプロバイダーの両方で、多くのタイプのストレージをサポートします。OpenShift Dedicated クラスターでは、永続データと非永続データのコンテナーストレージを管理できます。
- ストレージクラス
- ストレージクラスは、管理者が提供するストレージのクラスを説明する方法を提供します。さまざまなクラスが、サービスレベルの品質、バックアップポリシー、クラスター管理者によって決定された任意のポリシーにマップされる場合があります。
1.2. ストレージタイプ
OpenShift Dedicated ストレージは、一時ストレージと永続ストレージという 2 つのカテゴリーに大きく分類されます。
1.2.1. 一時ストレージ
Pod およびコンテナーは性質上、一時的または遷移的であり、ステートレスアプリケーション用に設計されています。一時ストレージを使用すると、管理者および開発者は一部の操作についてローカルストレージをより適切に管理できるようになります。一時ストレージの概要、タイプ、および管理の詳細は、一時ストレージについて を参照してください。
1.2.2. 永続ストレージ
コンテナーにデプロイされるステートフルアプリケーションには永続ストレージが必要です。OpenShift Dedicated は、永続ボリューム (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 Dedicated による他の使用に加えて、ノードで実行されているすべての Pod 間で共有されます。一時ストレージフレームワークにより、Pod は短期的なローカルストレージのニーズを指定できます。また、OpenShift Dedicated が必要に応じて Pod をスケジュールし、ローカルストレージの過剰な使用からノードを保護することもできます。
一時ストレージフレームワークを使用すると、管理者および開発者はローカルストレージをより適切に管理できますが、I/O スループットやレイテンシーに直接影響はありません。
2.2. 一時ストレージのタイプ
一時ローカルストレージは常に、プライマリーパーティションで利用できるようになっています。プライマリーパーティションを作成する基本的な方法には、root、ランタイムの 2 つがあります。
Root
このパーティションでは、kubelet の root ディレクトリー /var/lib/kubelet/
(デフォルト) と /var/log/
ディレクトリーを保持します。このパーティションは、ユーザーの Pod、OS、Kubernetes システムのデーモン間で共有できます。Pod は、EmptyDir
ボリューム、コンテナーログ、イメージ階層、コンテナーの書き込み可能な階層を使用して、このパーティションを使用できます。Kubelet はこのパーティションの共有アクセスおよび分離を管理します。このパーティションは一時的なもので、アプリケーションは、このパーティションからディスク IOPS などのパフォーマンス SLA は期待できません。
ランタイム
これは、ランタイムがオーバーレイファイルシステムに使用可能なオプションのパーティションです。OpenShift Dedicated は、このパーティションへの分離とともに、共有アクセスを識別して提供しようとします。コンテナーイメージ階層と書き込み可能な階層は、ここに保存されます。ランタイムパーティションが存在すると、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 Dedicated は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、永続ボリューム要求 (PVC) を使用すると、基礎となるストレージインフラストラクチャーに関する特定の知識がなくても PV リソースを要求できます。
PVC はプロジェクトに固有のもので、開発者が PV を使用する手段として作成し、使用します。PV リソース自体のスコープはいずれの単一プロジェクトにも設定されず、それらは OpenShift Dedicated クラスター全体で共有でき、すべてのプロジェクトから要求できます。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 つ以上の動的プロビジョナーを設定します。
3.2.2. 要求のバインド
PVC の作成時に、ストレージの特定容量の要求、必要なアクセスモードの指定のほか、ストレージクラスを作成してストレージの記述や分類を行います。マスターのコントロールループは新規 PVC の有無を監視し、新規 PVC を適切な PV にバインドします。適切な PV がない場合は、ストレージクラスのプロビジョナーが PV を作成します。
すべての PV のサイズが PVC サイズを超える可能性があります。これは、特に、手動でプロビジョニングされる PV の場合に当てはまります。超過を最小限にするために、OpenShift Dedicated は他のすべての条件に一致する最小の 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. 永続ボリュームの解放
ボリュームの処理が終了したら、API から PVC オブジェクトを削除できます。これにより、リソースを回収できるようになります。ボリュームは要求の削除時に解放 (リリース) されたものとみなされますが、別の要求で利用できる状態にはなりません。以前の要求側に関連するデータはボリューム上に残るため、ポリシーに基づいて処理される必要があります。
3.2.5. 永続ボリュームの回収ポリシー
永続ボリュームの回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法を指示します。ボリュームの回収ポリシーは、Retain
、Recycle
または Delete
のいずれかにすることができます。
-
Retain
回収ポリシーは、サポートするボリュームプラグインのリソースの手動による回収を許可します。 -
Recycle
回収ポリシーは、ボリュームがその要求からリリースされると、バインドされていない永続ボリュームのプールにボリュームをリサイクルします。
Recycle
回収ポリシーは OpenShift Dedicated 4 では非推奨となっています。動的プロビジョニングは、同等またはそれ以上の機能で推奨されます。
-
Delete
回収ポリシーは、OpenShift Dedicated のPersistentVolume
オブジェクトと、Amazon Elastic Block Store (Amazon EBS) または VMware vSphere などの外部インフラストラクチャーの関連するストレージアセットの両方を削除します。
動的にプロビジョニングされたボリュームは常に削除されます。
3.2.6. 永続ボリュームの手動回収
永続ボリューム要求 (PVC) が削除されても、永続ボリューム (PV) は依然として存在し、"released" (リリース済み) とみなされます。ただし、PV は、直前の要求側のデータがボリューム上に残るため、別の要求には利用できません。
手順
クラスター管理者として PV を手動で回収するには、以下を実行します。
PV を削除します。
$ oc delete pv <pv-name>
PV が削除された後も、AWS EBS や GCE PD ボリュームなどの外部インフラストラクチャー内の関連するストレージアセットは引き続き存在します。
- 関連するストレージアセットのデータをクリーンアップします。
- 関連するストレージアセットを削除します。または、同じストレージアセットを再利用するには、ストレージアセットの定義で新規 PV を作成します。
回収される PV が別の PVC で使用できるようになります。
3.2.7. 永続ボリュームの回収ポリシーの変更
永続ボリュームの回収ポリシーを変更するには、以下を実行します。
クラスターの永続ボリュームをリスト表示します。
$ 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: ...
以下のコマンドを実行して、PV にバインドされている PVC の名前を表示できます。
$ oc get pv <pv-name> -o jsonpath='{.spec.claimRef.name}'
3.3.1. PV の種類
OpenShift Dedicated は、以下の永続ボリュームプラグインをサポートします。
- AWS Elastic Block Store (EBS)
- GCP 永続ディスク
- GCP ファイルストア
3.3.2. Capacity
通常、永続ボリューム (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 つのサイズが一致するまでそれぞれを (サイズの順序で) 繰り返し処理します。
ボリュームアクセスモードは、ボリューム機能を表します。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。
以下の表では、アクセスモードをまとめています。
アクセスモード | CLI の省略形 | 説明 |
---|---|---|
ReadWriteOnce |
| ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
ReadWriteOncePod [1] |
| ボリュームは、1 つのノード上の 1 つの Pod によって読み取り/書き込みとしてマウントできます。 |
- RWOP は SELinux マウント機能を使用します。この機能はドライバーに依存しており、ODF、AWS EBS、Azure Disk、GCP PD、IBM Cloud Block Storage ボリューム、Cinder、vSphere ではデフォルトで有効になっています。サードパーティーのドライバーについては、ストレージベンダーにお問い合わせください。
ボリュームプラグイン | ReadWriteOnce [1] | ReadWriteOncePod | ReadOnlyMany | ReadWriteMany |
---|---|---|---|---|
AWS EBS [2] |
✅ |
✅ |
|
|
AWS EFS |
✅ |
✅ |
✅ |
✅ |
GCP Persistent Disk |
✅ |
✅ |
|
|
GCP Filestore |
✅ |
✅ |
✅ |
✅ |
LVM Storage |
✅ |
✅ |
|
|
- ReadWriteOnce (RWO) ボリュームは複数のノードにマウントできません。ノードに障害が発生すると、システムは、すでに障害が発生しているノードに割り当てられているため、割り当てられた RWO ボリュームを新規ノードにマウントすることはできません。複数割り当てのエラーメッセージが表示される場合には、シャットダウンまたはクラッシュしたノードで Pod を強制的に削除し、動的永続ボリュームの割り当て時などの重要なワークロードでのデータ損失を回避します。
- AWS EBS に依存する Pod の再作成デプロイメントストラテジーを使用します。
- raw ブロックボリュームのみが、ファイバーチャネルおよび iSCSI の ReadWriteMany (RWX) アクセスモードをサポートします。詳細は、「ブロックボリュームのサポート」を参照してください。
3.3.4. フェーズ
ボリュームは以下のフェーズのいずれかにあります。
フェーズ | 説明 |
---|---|
Available | まだ要求にバインドされていない空きリソースです。 |
Bound | ボリュームが要求にバインドされています。 |
Released | 要求が削除されていますが、リソースがまだクラスターにより回収されていません。 |
Failed | ボリュームが自動回収に失敗しています。 |
3.3.4.1. 最後のフェーズの移行時間
LastPhaseTransitionTime
フィールドには、永続ボリューム (PV) が別のフェーズ (pv.Status.Phase
) に移行するたびに更新されるタイムスタンプが含まれます。PV の最後のフェーズ移行の時間を確認するには、次のコマンドを実行します。
$ oc get pv <pv-name> -o json | jq '.status.lastPhaseTransitionTime' 1
- 1
- 最後のフェーズの移行を確認する PV の名前を指定します。
3.3.4.2. マウントオプション
属性 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)
- GCE Persistent Disk
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 Dedicated は raw ブロックボリュームを静的にプロビジョニングできます。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込むアプリケーションや、独自のストレージサービスを実装するアプリケーションにはパフォーマンス上の利点があります。
raw ブロックボリュームは、PV および PVC 仕様で volumeMode: Block
を指定してプロビジョニングされます。
raw ブロックボリュームを使用する Pod は、特権付きコンテナーを許可するように設定する必要があります。
以下の表は、ブロックボリュームをサポートするボリュームプラグインを表示しています。
ボリュームプラグイン | 手動のプロビジョニング | 動的なプロビジョニング | フルサポート |
---|---|---|---|
Amazon Elastic Block Store (Amazon EBS) | ✅ | ✅ | ✅ |
Amazon Elastic File Storage (Amazon EFS) | |||
GCP | ✅ | ✅ | ✅ |
LVM Storage | ✅ | ✅ | ✅ |
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 Dedicated が各ボリュームのコンテンツの所有権と権限を再帰的に変更して、そのボリュームがマウントされたときに Pod の securityContext
で指定された fsGroup
に一致させるために発生する可能性があります。大規模なボリュームでは、所有者とパーミッションの確認と変更には時間がかかり、Pod の起動が遅くなる場合があります。securityContext
内の fsGroupChangePolicy
フィールドを使用して、OpenShift Dedicated がボリュームの所有権と権限をチェックおよび管理する方法を制御できます。
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 Dedicated クラスターは、Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する 4 つのストレージクラスで事前構築されています。これらのストレージクラスはすぐに使用でき、Kubernetes と AWS にある程度精通していることを前提としています。
以下は、事前構築済みの 4 つのストレージクラスです。
名前 | プロビジョナー |
---|---|
gp2 | kubernetes.io/aws-ebs |
gp2-csi | ebs.csi.aws.com |
gp3 (デフォルト) | kubernetes.io/aws-ebs |
gp3-csi | ebs.csi.aws.com |
gp3 ストレージクラスがデフォルトとして設定されています。ただし、任意のストレージクラスをデフォルトのストレージクラスとして選択できます。
Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。Amazon EBS ボリュームを動的にプロビジョニングできます。永続ボリュームは、単一のプロジェクトまたは namespace にバインドされていません。OpenShift Dedicated クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。KMS キーを定義して、AWS のコンテナー永続ボリュームを暗号化できます。デフォルトでは、OpenShift Dedicated バージョン 4.10 以降を使用して新しく作成されたクラスターは、gp3 ストレージと AWS EBS CSI ドライバー を使用します。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
4.1.1. EBS ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
4.1.2. 永続ボリューム要求の作成
前提条件
ストレージは、OpenShift Dedicated でボリュームとしてマウントする前に、基盤となるインフラストラクチャーに存在する必要があります。
手順
- OpenShift Dedicated コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
4.1.3. ボリュームのフォーマット
OpenShift Dedicated はボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType
パラメーターで指定されたファイルシステムがボリュームに含まれていることを確認します。デバイスが指定されたファイルシステムでフォーマットされていないと、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。
この検証により、フォーマットされていない AWS ボリュームを永続ボリュームとして使用できるようになります。これは、OpenShift Dedicated が最初に使用する前にフォーマットするためです。
4.1.4. ノード上の EBS ボリュームの最大数
デフォルトでは、OpenShift Dedicated は、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 ドライバー Operator を参照してください。
4.2. GCE Persistent Disk を使用した永続ストレージ
OpenShift Dedicated は、GCE Persistent Disk ボリューム (gcePD) をサポートします。GCE を使用して、永続ストレージを備えた OpenShift Dedicated クラスターをプロビジョニングできます。これには、Kubernetes と GCE についてある程度の理解があることが前提となります。
Kubernetes 永続ボリュームフレームワークは、管理者がクラスターのプロビジョニングを永続ストレージを使用して実行できるようにし、ユーザーが基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようにします。
GCE Persistent Disk ボリュームは動的にプロビジョニングできます。
永続ボリュームは、単一のプロジェクトまたは namespace にバインドされていません。OpenShift Dedicated クラスター全体で共有できます。永続ボリューム要求はプロジェクトまたは namespace に固有のもので、ユーザーによって要求されます。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
関連情報
4.2.1. GCE ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
4.2.2. 永続ボリューム要求の作成
前提条件
ストレージは、OpenShift Dedicated でボリュームとしてマウントする前に、基盤となるインフラストラクチャーに存在する必要があります。
手順
- OpenShift Dedicated コンソールで、Storage → Persistent Volume Claims をクリックします。
- 永続ボリューム要求の概要で、Create Persistent Volume Claim をクリックします。
表示されるページで必要なオプションを定義します。
- ドロップダウンメニューから以前に作成したストレージクラスを選択します。
- ストレージ要求の一意の名前を入力します。
- アクセスモードを選択します。この選択により、ストレージクレームの読み取りおよび書き込みアクセスが決定されます。
- ストレージ要求のサイズを定義します。
- Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。
4.2.3. ボリュームのフォーマット
OpenShift Dedicated はボリュームをマウントしてコンテナーに渡す前に、永続ボリューム定義の fsType
パラメーターで指定されたファイルシステムがボリュームに含まれていることを確認します。デバイスが指定されたファイルシステムでフォーマットされていないと、デバイスのデータはすべて消去され、デバイスはそのファイルシステムで自動的にフォーマットされます。
この検証により、フォーマットされていない GCE ボリュームを永続ボリュームとして使用できるようになります。これは、OpenShift Dedicated がそれらを最初に使用する前にフォーマットするためです。
第5章 Container Storage Interface (CSI) の使用
5.1. CSI ボリュームの設定
Container Storage Interface (CSI) により、OpenShift Dedicated は、CSI インターフェイス を永続ストレージとして実装するストレージバックエンドからストレージを消費できます。
OpenShift Dedicated 4 は、CSI 仕様 のバージョン 1.6.0 をサポートします。
5.1.1. CSI アーキテクチャー
CSI ドライバーは通常、コンテナーイメージとして提供されます。これらのコンテナーは、それらが実行される OpenShift Dedicated を認識しません。OpenShift Dedicated で CSI 互換のストレージバックエンドを使用するには、クラスター管理者が、OpenShift Dedicated とストレージドライバーの間のブリッジとして機能する複数のコンポーネントをデプロイする必要があります。
次の図は、OpenShift Dedicated クラスターの Pod で実行されるコンポーネントの概要を示しています。

異なるストレージバックエンドに対して複数の CSI ドライバーを実行できます。各ドライバーには、独自の外部コントローラーのデプロイメントおよびドライバーと CSI レジストラーを含むデーモンセットが必要です。
5.1.1.1. 外部の CSI コントローラー
外部の CSI コントローラーは、5 つのコンテナーを含む 1 つまたは複数の Pod を配置するデプロイメントです。
-
スナップショットコンテナーは、
VolumeSnapshot
オブジェクトおよびVolumeSnapshotContent
オブジェクトを監視し、VolumeSnapshotContent
オブジェクトの作成および削除を担当します。 -
リサイザーコンテナーは、
PersistentVolumeClaim
オブジェクトでより多くのストレージを要求した場合に、PersistentVolumeClaim
の更新を監視し、CSI エンドポイントに対してControllerExpandVolume
操作をトリガーするサイドカーコンテナーです。 -
外部の CSI アタッチャーコンテナーは、OpenShift Dedicated からの
attach
およびdetach
呼び出しを、CSI ドライバーへのそれぞれのControllerPublish
およびControllerUnpublish
呼び出しに変換します。 -
OpenShift Dedicated からの
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 Dedicated 接続 API を実装するために実行する必要があります。
5.1.1.2. CSI ドライバーのデーモンセット
CSI ドライバーデーモンセットは、OpenShift Dedicated が CSI ドライバーによって提供されるストレージをノードにマウントし、それをユーザーワークロード (Pod) で永続ボリューム (PV) として使用できるようにするすべてのノードで Pod を実行します。CSI ドライバーがインストールされた Pod には、以下のコンテナーが含まれます。
-
ノード上で実行中の
openshift-node
サービスに CSI ドライバーを登録する CSI ドライバーレジストラー。このノードで実行中のopenshift-node
プロセスは、ノードで利用可能な UNIX Domain Socket を使用して CSI ドライバーに直接接続します。 - CSI ドライバー
ノードにデプロイされた CSI ドライバーには、ストレージバックエンドへの認証情報をできる限り少なく指定する必要があります。OpenShift Dedicated は、NodePublish
/NodeUnpublish
および NodeStage
/NodeUnstage
などの CSI 呼び出しのノードプラグインセットが実装されている場合のみを使用します。
5.1.2. OpenShift Dedicated でサポートされる CSI ドライバー
OpenShift Dedicated は、デフォルトで特定の CSI ドライバーをインストールし、in-tree ボリュームプラグインでは不可能なストレージオプションをユーザーに提供します。
これらのサポートされているストレージアセットにマウントする CSI プロビジョニングされた永続ボリュームを作成するために、OpenShift Dedicated は、必要な CSI ドライバー Operator、CSI ドライバー、および必要なストレージクラスをデフォルトでインストールします。Operator およびドライバーのデフォルト namespace の詳細は、特定の CSI ドライバー 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 Dedicated でサポートされる CSI ドライバーと、ボリュームのスナップショットやサイズ変更などの CSI 機能がサポートされているかを説明します。
CSI ドライバーが以下の表に記載されていない場合は、CSI ストレージベンダーが提供するインストール手順に従って、サポートされている CSI 機能を使用する必要があります。
CSI ドライバー | CSI ボリュームスナップショット | CSI ボリュームグループスナップショット [1] | CSI のクローン作成 | CSI のサイズ変更 | インラインの一時ボリューム |
---|---|---|---|---|---|
AWS EBS |
✅ |
|
|
✅ |
|
AWS EFS |
|
|
|
|
|
Google Compute Platform (GCP) persistent disk (PD) |
✅ |
|
✅[2] |
✅ |
|
GCP Filestore |
✅ |
|
|
✅ |
|
LVM Storage |
✅ |
|
✅ |
✅ |
|
5.1.3. 動的プロビジョニング
永続ストレージの動的プロビジョニングは、CSI ドライバーおよび基礎となるストレージバックエンドの機能により異なります。CSI ドライバーのプロバイダーは、OpenShift Dedicated でストレージクラスを作成する方法と、設定に使用できるパラメーターを文書化する必要があります。
作成されたストレージクラスは、動的プロビジョニングを有効にするために設定できます。
手順
デフォルトのストレージクラスを作成します。これにより、特殊なストレージクラスを必要としないすべての 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.2. デフォルトストレージクラスの管理
5.2.1. 概要
デフォルトのストレージクラスを管理すると、複数の異なる目的を達成できます。
- 動的プロビジョニングを無効にして静的プロビジョニングを強制します。
- 他の優先ストレージクラスがある場合に、storage operator による最初のデフォルトストレージクラスの作成を阻止します。
- デフォルトのストレージクラスに名前を付け直すか変更します。
これらの目的を達成するには、ClusterCSIDriver
オブジェクトの spec.storageClassState
フィールドの設定を変更します。このフィールドで可能な設定は以下のとおりです。
- Managed: (デフォルト) コンテナーストレージインターフェイス (CSI) オペレーターがデフォルトのストレージクラスをアクティブに管理しているため、クラスター管理者によってデフォルトのストレージクラスに対して行われた手動変更のほとんどは削除され、デフォルトのストレージクラスは継続的に再作成されます。手動で削除しようとしました。
- Unmanaged: デフォルトのストレージクラスを変更できます。CSI Operator はストレージクラスをアクティブに管理しないため、自動的に作成するデフォルトのストレージクラスを調整します。
- Removed: CSI Operator はデフォルトのストレージクラスを削除します。
5.2.2. Web コンソールを使用したデフォルトのストレージクラスの管理
前提条件
- OpenShift Dedicated 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.2.3. CLI を使用したデフォルトのストレージクラスの管理
前提条件
- クラスター管理者権限でクラスターにアクセスできる。
手順
CLI を使用してストレージクラスを管理するには、次のコマンドを実行します。
oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 1
- 1
- ここで、
${STATE}
は "削除"、"管理"、または "非管理" です。$DRIVERNAME
はプロビジョナー名です。コマンドoc get sc
を実行すると、プロビジョナー名を見つけることができます。
5.2.4. デフォルトのストレージクラスが存在しないか、複数のデフォルトストレージクラスがある
5.2.4.1. 複数のデフォルトのストレージクラス
デフォルト以外のストレージクラスをデフォルトとしてマークし、既存のデフォルトストレージクラスの設定を解除しない場合、またはデフォルトのストレージクラスがすでに存在するときにデフォルトのストレージクラスを作成した場合は、複数のデフォルトストレージクラスが発生する可能性があります。複数のデフォルトストレージクラスが存在する場合、デフォルトストレージクラス (pvc.spec.storageClassName
=nil) を要求するすべての永続ボリューム要求 (PVC) は、そのストレージクラスのデフォルトステータスと管理者に関係なく、最後に作成されたデフォルトストレージクラスを取得します。アラートダッシュボードで、複数のデフォルトストレージクラス MultipleDefaultStorageClasses
があるというアラートを受け取ります。
5.2.4.2. デフォルトのストレージクラスなし
PVC が存在しないデフォルトのストレージクラスの使用を試みる可能性があるシナリオは 2 つあります。
- 管理者がデフォルトのストレージクラスを削除するか、デフォルト以外としてマークした後、ユーザーがデフォルトのストレージクラスを要求する PVC を作成します。
- インストール時に、インストーラーは、まだ作成されていないデフォルトのストレージクラスを要求する PVC を作成します。
前述のシナリオでは、PVC は無期限に保留状態のままになります。この状況を解決するには、デフォルトのストレージクラスを作成するか、既存のストレージクラスの 1 つをデフォルトとして宣言します。デフォルトのストレージクラスが作成または宣言されるとすぐに、PVC は新しいデフォルトのストレージクラスを取得します。可能であれば、最終的に PVC は通常どおり静的または動的にプロビジョニングされた PV にバインドされ、保留状態から抜け出します。
5.2.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.3. AWS Elastic Block Store CSI Driver Operator
5.3.1. 概要
OpenShift Dedicated は AWS EBS CSI ドライバー を使用して永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
PV を作成して、AWS EBS ストレージアセットにマウントするために、OpenShift Dedicated は AWS EBS CSI Driver Operator (Red Hat Operator) と 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 を作成し、マウントできます。
5.3.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Dedicated ユーザーに付与します。
OpenShift Dedicated は、デフォルトで CSI プラグインを使用して Amazon Elastic Block Store (Amazon EBS) ストレージをプロビジョニングします。
OpenShift Dedicated で Amazon EBS 永続ボリュームを動的にプロビジョニングする方法は、AWS Elastic Block Store を使用した永続ストレージ を参照してください。
5.4. AWS Elastic File Service CSI Driver Operator
この手順は、AWS EFS CSI Driver Operator (Red Hat Operator) に固有であり、OpenShift Dedicated 4.10 以降のバージョンにのみ適用されます。
5.4.1. 概要
OpenShift Dedicated は、AWS Elastic File Service (EFS) の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。
CSI Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
AWS EFS CSI ドライバー Operator をインストールすると、OpenShift Dedicated はデフォルトで 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.4.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Dedicated ユーザーに付与します。
5.4.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.4.3.1. Security Token Service の Amazon リソース名ロールの取得
この手順では、AWS Security Token Service (STS) 上の OpenShift Dedicated で AWS EFS CSI Driver Operator を設定するための Amazon リソース名 (ARN) ロールを取得する方法を説明します。
AWS EFS CSI Driver Operator をインストールする前に、この手順を実行してください (AWS EFS CSI Driver Operator のインストール に記載された手順を参照)。
前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
- AWS アカウントの認証情報。
手順
以下の内容を含む IAM ポリシー JSON ファイルを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticfilesystem:DescribeAccessPoints", "elasticfilesystem:DescribeFileSystems", "elasticfilesystem:DescribeMountTargets", "ec2:DescribeAvailabilityZones", "elasticfilesystem:TagResource" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "elasticfilesystem:CreateAccessPoint" ], "Resource": "*", "Condition": { "StringLike": { "aws:RequestTag/efs.csi.aws.com/cluster": "true" } } }, { "Effect": "Allow", "Action": "elasticfilesystem:DeleteAccessPoint", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/efs.csi.aws.com/cluster": "true" } } } ] }
以下の内容で IAM 信頼 JSON ファイルを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<your_aws_account_ID>:oidc-provider/<openshift_oidc_provider>" 1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<openshift_oidc_provider>:sub": [ 2 "system:serviceaccount:openshift-cluster-csi-drivers:aws-efs-csi-driver-operator", "system:serviceaccount:openshift-cluster-csi-drivers:aws-efs-csi-driver-controller-sa" ] } } } ] }
- 1
- AWS アカウント ID および OpenShift OIDC プロバイダーエンドポイントを指定します。
次のコマンドを実行して AWS アカウント ID を取得します。
$ aws sts get-caller-identity --query Account --output text
次のコマンドを実行して、OpenShift OIDC エンドポイントを取得します。
$ openshift_oidc_provider=`oc get authentication.config.openshift.io cluster \ -o json | jq -r .spec.serviceAccountIssuer | sed -e "s/^https:\/\///"`; \ echo $openshift_oidc_provider
- 2
- OpenShift OIDC エンドポイントを再度指定します。
IAM ロールを作成します。
ROLE_ARN=$(aws iam create-role \ --role-name "<your_cluster_name>-aws-efs-csi-operator" \ --assume-role-policy-document file://<your_trust_file_name>.json \ --query "Role.Arn" --output text); echo $ROLE_ARN
ロール ARN をコピーします。AWS EFS CSI ドライバー Operator をインストールするときに必要になります。
IAM ポリシーを作成します。
POLICY_ARN=$(aws iam create-policy \ --policy-name "<your_cluster_name>-aws-efs-csi" \ --policy-document file://<your_policy_file_name>.json \ --query 'Policy.Arn' --output text); echo $POLICY_ARN
IAM ポリシーを IAM ロールに割り当てます。
$ aws iam attach-role-policy \ --role-name "<your_cluster_name>-aws-efs-csi-operator" \ --policy-arn $POLICY_ARN
次のステップ
5.4.3.2. AWS EFS CSI Driver Operator のインストール
AWS EFS CSI Driver Operator (Red Hat Operator) は、デフォルトでは OpenShift Dedicated にインストールされません。以下の手順を使用して、クラスター内で AWS EFS CSI Driver Operator をインストールおよび設定します。
前提条件
- OpenShift Dedicated 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.4.3.3. AWS EFS CSI ドライバーのインストール
AWS EFS CSI Driver Operator (Red Hat Operator) をインストールした後、AWS EFS CSI ドライバー をインストールします。
前提条件
- OpenShift Dedicated 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.4.4. AWS EFS ストレージクラスの作成
ストレージクラスを使用すると、ストレージのレベルや使用状況を区別し、記述することができます。ストレージクラスを定義することにより、ユーザーは動的にプロビジョニングされた永続ボリュームを取得できます。
AWS EFS CSI Driver Operator (Red Hat Operator) は、インストール後、デフォルトではストレージクラスを作成しません。ただし、AWS EFS ストレージクラスを手動で作成することは可能です。
5.4.4.1. コンソールを使用した AWS EFS ストレージクラスの作成
手順
- OpenShift Dedicated コンソールで、Storage → StorageClasses をクリックします。
- StorageClasses ページで、Create StorageClass をクリックします。
StorageClass ページで、次の手順を実行します。
- ストレージクラスを参照するための名前を入力します。
- オプション: 説明を入力します。
- 回収ポリシーを選択します。
-
Provisioner ドロップダウンリストから
efs.csi.aws.com
を選択します。 - オプション: 選択したプロビジョナーの設定パラメーターを設定します。
- Create をクリックします。
5.4.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.4.5. AWS における EFS ボリュームへのアクセスの作成と設定
この手順では、OpenShift Dedicated で使用できるように、AWS で EFS ボリュームを作成および設定する方法を説明します。
前提条件
- AWS アカウントの認証情報。
手順
AWS で EFS ボリュームへのアクセスを作成および設定するには、以下の手順を実施します。
- AWS のコンソールで、https://console.aws.amazon.com/efs を開きます。
Create file system をクリックします。
- ファイルシステムの名前を入力します。
- Virtual Private Cloud (VPC) には、OpenShift Dedicated の仮想プライベートクラウド (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 Dedicated ノードが EFS ボリュームにアクセスできるようにします。
- Type: NFS
- Protocol: TCP
- Port range: 2049
Source: ノードのカスタム/IP アドレス範囲 (例:"10.0.0.0/16")
この手順で、OpenShift Dedicated がクラスターから NFS ポートを使用できるようになります。
- ルールを保存します。
5.4.6. 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.4.7. 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.4.8. 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 Dedicated は、ボリューム上のファイルの GID を FSGroup で置き換えることができません。マウントされた EFS アクセスポイントにアクセスできる Pod は、そこにあるすべてのファイルにアクセスできます。
これとは関係ありませんが、転送中の暗号化はデフォルトで有効になっています。詳細は、https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html を参照してください。
5.4.9. AWS EFS ストレージ CSI 使用状況メトリクス
5.4.9.1. 使用状況メトリクスの概要
Amazon Web Services (AWS) Elastic File Service (EFS) Container Storage Interface (CSI) 使用状況メトリクスを使用すると、動的または静的にプロビジョニングされた EFS ボリュームによって使用されているスペースの量を監視できます。
メトリクスを有効にするとパフォーマンスが低下する可能性があるため、この機能はデフォルトで無効になっています。
AWS EFS 使用状況メトリクス機能は、ボリューム内のファイルを再帰的にウォークスルーし、AWS EFS CSI ドライバーのボリュームメトリクスを収集します。この作業によりパフォーマンスが低下する可能性があるため、管理者はこの機能を明示的に有効にする必要があります。
5.4.9.2. Web コンソールを使用した使用状況メトリクスの有効化
Web コンソールを使用して Amazon Web Services (AWS) Elastic File Service (EFS) Container Storage Interface (CSI) の使用状況メトリクスを有効にするには、次の手順を実行します。
- Administration > CustomResourceDefinitions をクリックします。
-
CustomResourceDefinitions ページの Name ドロップダウンボックスの横に、
clustercsidriver
と入力します。 - CRD ClusterCSIDriver をクリックします。
- YAML タブをクリックします。
spec.aws.efsVolumeMetrics.state
の下で、値をRecursiveWalk
に設定します。RecursiveWalk
は、AWS EFS CSI ドライバーのボリュームメトリクス収集が、ボリューム内のファイルを再帰的にウォークスルーすることによって実行されることを示します。ClusterCSIDriver efs.csi.aws.com YAML ファイルの例
spec: driverConfig: driverType: AWS aws: efsVolumeMetrics: state: RecursiveWalk recursiveWalk: refreshPeriodMinutes: 100 fsRateLimit: 10
オプション: 再帰ウォークの動作を定義するために、次のフィールドを設定することもできます。
-
refreshPeriodMinutes
: ボリュームメトリクスの更新頻度を分単位で指定します。このフィールドを空白のままにすると、適切なデフォルトが選択されますが、これは時間の経過とともに変更される可能性があります。現在のデフォルトは 240 分です。有効な範囲は 1 - 43,200 分です。 -
fsRateLimit
: ファイルシステムごとに、goroutine でボリュームメトリクスを処理するためのレート制限を定義します。このフィールドを空白のままにすると、適切なデフォルトが選択されますが、これは時間の経過とともに変更される可能性があります。現在のデフォルトは 5 つの goroutine です。有効な範囲は 1 - 100 の goroutine です。
-
- Save をクリックします。
AWS EFS CSI 使用状況メトリクスを 無効化 するには、前述の手順を使用しますが、spec.aws.efsVolumeMetrics.state
の値を RecursiveWalk
から Disabled
に変更します。
5.4.9.3. CLI を使用した使用状況メトリクスの有効化
CLI を使用して Amazon Web Services (AWS) Elastic File Service (EFS) Container Storage Interface (CSI) 使用状況メトリクスを有効にするには、次の手順を実行します。
次のコマンドを実行して ClusterCSIDriver を編集します。
$ oc edit clustercsidriver efs.csi.aws.com
spec.aws.efsVolumeMetrics.state
の下で、値をRecursiveWalk
に設定します。RecursiveWalk
は、AWS EFS CSI ドライバーのボリュームメトリクス収集が、ボリューム内のファイルを再帰的にウォークスルーすることによって実行されることを示します。ClusterCSIDriver efs.csi.aws.com YAML ファイルの例
spec: driverConfig: driverType: AWS aws: efsVolumeMetrics: state: RecursiveWalk recursiveWalk: refreshPeriodMinutes: 100 fsRateLimit: 10
オプション: 再帰ウォークの動作を定義するために、次のフィールドを設定することもできます。
-
refreshPeriodMinutes
: ボリュームメトリクスの更新頻度を分単位で指定します。このフィールドを空白のままにすると、適切なデフォルトが選択されますが、これは時間の経過とともに変更される可能性があります。現在のデフォルトは 240 分です。有効な範囲は 1 - 43,200 分です。 -
fsRateLimit
: ファイルシステムごとに、goroutine でボリュームメトリクスを処理するためのレート制限を定義します。このフィールドを空白のままにすると、適切なデフォルトが選択されますが、これは時間の経過とともに変更される可能性があります。現在のデフォルトは 5 つの goroutine です。有効な範囲は 1 - 100 の goroutine です。
-
-
efs.csi.aws.com
オブジェクトへの変更を保存します。
AWS EFS CSI 使用状況メトリクスを 無効化 するには、前述の手順を使用しますが、spec.aws.efsVolumeMetrics.state
の値を RecursiveWalk
から Disabled
に変更します。
5.4.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 Dedicated ノードと Amazon EFS 間のパケットを AWS がドロップすることで頻繁に発生します。
以下が正しいことを確認します。
- AWS のファイアウォールとセキュリティーグループ
- ネットワーク: ポート番号と IP アドレス
5.4.11. AWS EFS CSI Driver Operator のアンインストール
AWS EFS CSI Driver Operator (Red Hat Operator) をアンインストールすると、すべての EFS PV にアクセスできなくなります。
前提条件
- OpenShift Dedicated 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 Dedicated クラスターを破棄できません。Amazon はこのような VPC の削除を許可していません。
5.4.12. 関連情報
5.5. GCP PD CSI Driver Operator
5.5.1. 概要
OpenShift Dedicated は、Google Cloud Platform (GCP) 永続ディスク (PD) ストレージ用の Container Storage Interface (CSI) ドライバーを使用して、永続ボリューム (PV) をプロビジョニングできます。
Container Storage Interface (CSI) Operator およびドライバーを使用する場合は、永続ストレージ および CSI ボリュームの設定 を理解しておくことが推奨されます。
GCP PD ストレージアセットにマウントする CSI プロビジョニングされた永続ボリューム (PV) を作成するために、OpenShift Dedicated はデフォルトで GCP PD CSI ドライバー 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 を作成し、マウントできます。
GCP PD CSI ドライバーは、ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプをサポートします。C3 インスタンスタイプと N4 マシンシリーズは、hyperdisk–balanced ディスクをサポートします。
5.5.2. ベアメタルおよび N4 マシンシリーズ用の C3 インスタンスタイプ
5.5.2.1. C3 および N4 インスタンスタイプの制限
ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプに対する GCP PD CSI ドライバーのサポートには、次の制限があります。
- ストレージプールを使用する場合、ボリュームのクローン作成はサポートされません。
- クローン作成またはサイズ変更を行うには、hyperdisk-balanced ディスクのサイズは 6Gi 以上である必要があります。
デフォルトストレージクラスは standard-csi です。
重要ストレージクラスを手動で作成する必要があります。
ストレージクラスの作成については、hyperdisk–balanced ディスクの設定 セクションのステップ 2 を参照してください。
- N2 や N4 など、異なるストレージタイプを使用する仮想マシン (VM) が混在するクラスターはサポートされていません。これは、ハイパーディスク分散ディスクがほとんどのレガシー VM で使用できないためです。同様に、N4/C3 仮想マシンでは、通常の永続ディスクは使用できません。
- c3-standard-2、c3-standard-4、n4-standard-2、および n4-standard-4 ノードを持つ GCP クラスターは、アタッチ可能な最大ディスク番号 (16) を誤って超過する可能性があります (JIRA リンク)。
5.5.2.2. ハイパーディスクバランスディスクのストレージプールの概要
ハイパーディスクストレージプールは、大規模なストレージ用に Compute Engine で使用できます。ハイパーディスクストレージプールは、購入した容量、スループット、および IOPS のコレクションであり、必要に応じてアプリケーションにプロビジョニングできます。ハイパーディスクストレージプールを使用すると、プールにディスクを作成して管理し、複数のワークロードでディスクを使用できます。ディスクをまとめて管理することで、期待される容量とパフォーマンスの向上を実現しながらコストを節約できます。ハイパーディスクストレージプールに必要なストレージのみを使用することで、数百のディスクの管理から単一のストレージプールの管理に至るまでに、容量の予測や管理の複雑さを軽減できます。
ストレージプールを設定するには、hyperdisk–balanced ディスクの設定 を参照してください。
5.5.2.3. hyperdisk–balanced ディスクの設定
前提条件
- 管理者権限でクラスターにアクセスできる。
手順
hyperdisk-balanced ディスクを設定するには、以下を実行します。
次のサンプル YAML ファイルを使用して、ハイパーディスク固有のストレージクラスを使用する永続ボリューム要求 (PVC) を作成します。
PVC YAML ファイルの例
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: storageClassName: hyperdisk-sc 1 accessModes: - ReadWriteOnce resources: requests: storage: 2048Gi 2
作成した PVC を使用するデプロイメントを作成します。デプロイメントを使用すると、Pod が再起動して再スケジュールされた後でも、アプリケーションが永続ストレージにアクセスできるようになります。
- デプロイメントを作成する前に、指定されたマシンシリーズのノードプールが稼働していることを確認します。稼働していない場合は、Pod はスケジュールに失敗します。
以下の YAML ファイルの例を使用してデプロイメントを作成します。
デプロイメント YAML ファイルの例
apiVersion: apps/v1 kind: Deployment metadata: name: postgres spec: selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: nodeSelector: cloud.google.com/machine-family: n4 1 containers: - name: postgres image: postgres:14-alpine args: [ "sleep", "3600" ] volumeMounts: - name: sdk-volume mountPath: /usr/share/data/ volumes: - name: sdk-volume persistentVolumeClaim: claimName: my-pvc 2
以下のコマンドを実行して、デプロイメントが正常に作成されたことを確認します。
$ oc get deployment
出力例
NAME READY UP-TO-DATE AVAILABLE AGE postgres 0/1 1 0 42s
ハイパーディスクインスタンスがプロビジョニングを完了し、READY ステータスが表示されるまで数分かかる場合があります。
次のコマンドを実行して、PVC
my-pvc
が永続ボリューム (PV) に正常にバインドされていることを確認します。$ oc get pvc my-pvc
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE my-pvc Bound pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 2Ti RWO hyperdisk-sc <unset> 2m24s
hyperdisk-balanced ディスクの想定の設定を確認します。
$ gcloud compute disks list
出力例
NAME LOCATION LOCATION_SCOPE SIZE_GB TYPE STATUS instance-20240914-173145-boot us-central1-a zone 150 pd-standard READY instance-20240914-173145-data-workspace us-central1-a zone 100 pd-balanced READY c4a-rhel-vm us-central1-a zone 50 hyperdisk-balanced READY 1
- 1
- Hyperdisk-balanced ディスク。
ストレージプールを使用している場合は、次のコマンドを実行して、ボリュームがストレージクラスと PVC で指定されたとおりにプロビジョニングされていることを確認します。
$ gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
出力例
NAME STATUS PROVISIONED_IOPS PROVISIONED_THROUGHPUT SIZE_GB pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 READY 3000 140 2048
5.5.3. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Dedicated ユーザーに付与します。
5.5.4. 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 Dedicated でサポートされているすべての GCP PD CSI ストレージクラスパラメーターを説明します。
パラメーター | 値 | デフォルト | 説明 |
---|---|---|---|
|
|
| 標準の PV または solid-state-drive PV を選択できます。 ドライバーは値を検証しないため、可能なすべての値が受け入れられます。 |
|
|
| zonal またはリージョン PV を選択できます。 |
| 新規ディスクの暗号化に使用するキーの完全修飾リソース識別子。 | 空の文字列 | 顧客管理の暗号鍵 (CMEK) を使用して新規ディスクを暗号化します。 |
5.5.5. カスタムで暗号化された永続ボリュームの作成
PersistentVolumeClaim
オブジェクトを作成すると、OpenShift Dedicated は新しい永続ボリューム (PV) をプロビジョニングし、PersistentVolume
オブジェクトを作成します。新規に作成された PV を暗号化することで、Google Cloud Platform (GCP) にカスタム暗号化キーを追加し、クラスター内の PV を保護することができます。
暗号化の場合、作成した新たに割り当てられる PV は、新規または既存の Google Cloud Key Management Service (KMS) キーを使用してクラスターで顧客管理の暗号鍵 (CMEK) を使用します。
前提条件
- 実行中の OpenShift Dedicated クラスターにログインしている。
- 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 Dedicated クラスターにデプロイします。$ 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 Dedicated クラスターで使用できるようになりました。
5.5.6. 関連情報
5.6. Google Compute Platform Filestore CSI ドライバーオペレーター
5.6.1. 概要
OpenShift Dedicated は、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 を作成してマウントできます。
OpenShift Dedicated GCP Filestore は Workload Identity をサポートします。これにより、ユーザーはサービスアカウントキーの代わりにフェデレーションアイデンティティーを使用して Google Cloud リソースにアクセスできます。GCP Workload Identity はインストール中にグローバルに有効にしてから、GCP Filestore CSI Driver Operator 用に設定する必要があります。詳細は、GCP Filestore CSI Driver Operator のインストール を参照してください。
5.6.2. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、in-tree ボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Dedicated ユーザーに付与します。
5.6.3. GCP Filestore CSI Driver Operator のインストール
5.6.3.1. Workload Identity を使用して GCP Filestore CSI Driver Operator をインストールする準備
GCP Workload Identity を Google Compute Platform Filestore と共に使用する予定の場合は、GCP Filestore Container Storage Interface (CSI) Driver Operator のインストール中に使用する特定のパラメーターを取得する必要があります。
前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
手順
Workload Identity を使用して GCP Filestore CSI ドライバー Operator をインストールする準備をします。
プロジェクト番号を取得します。
以下のコマンドを実行してプロジェクト ID を取得します。
$ export PROJECT_ID=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.gcp.projectID}')
以下のコマンドを実行し、プロジェクト ID を使用してプロジェクト番号を取得します。
$ gcloud projects describe $PROJECT_ID --format="value(projectNumber)"
ID プール ID とプロバイダー ID を検索します。
クラスターのインストール中に、これらのリソースの名前は、
--name parameter
を使用して Cloud Credential Operator ユーティリティー (ccoctl
) に渡されます。「Cloud Credential Operator ユーティリティーを使用した GCP リソースの作成」を参照してください。GCP Filestore Operator の Workload Identity リソースを作成します。
次のサンプルファイルを使用して
CredentialsRequest
ファイルを作成します。Credentials Request YAML ファイルの例
apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: openshift-gcp-filestore-csi-driver-operator namespace: openshift-cloud-credential-operator annotations: include.release.openshift.io/self-managed-high-availability: "true" include.release.openshift.io/single-node-developer: "true" spec: serviceAccountNames: - gcp-filestore-csi-driver-operator - gcp-filestore-csi-driver-controller-sa secretRef: name: gcp-filestore-cloud-credentials namespace: openshift-cluster-csi-drivers providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/file.editor - roles/resourcemanager.tagUser skipServiceCheck: true
次のコマンドを実行し、
CredentialsRequest
ファイルを使用して GCP サービスアカウントを作成します。$ ./ccoctl gcp create-service-accounts --name=<filestore-service-account> \1 --workload-identity-pool=<workload-identity-pool> \2 --workload-identity-provider=<workload-identity-provider> \3 --project=<project-id> \4 --credentials-requests-dir=/tmp/credreq 5
出力例
2025/02/10 17:47:39 Credentials loaded from gcloud CLI defaults 2025/02/10 17:47:42 IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator created 2025/02/10 17:47:44 Unable to add predefined roles to IAM service account, retrying... 2025/02/10 17:47:59 Updated policy bindings for IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator 2025/02/10 17:47:59 Saved credentials configuration to: /tmp/install-dir/ 1 openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml
- 1
- 現在のディレクトリー。
次のコマンドを実行して、新しく作成されたサービスアカウントのサービスアカウントメールを見つけます。
$ cat /tmp/install-dir/manifests/openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml | yq '.data["service_account.json"]' | base64 -d | jq '.service_account_impersonation_url'
出力例
https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com:generateAccessToken
この出力例では、サービスアカウントのメールは
filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com
です。
結果
これで、GCP Filestore CSI Driver Operator をインストールするために必要な次のパラメーターが揃いました。
- プロジェクト番号 - ステップ 1.b
- プール ID - ステップ 2
- プロバイダー ID - ステップ 2
- サービスアカウントのメール - ステップ 3.c
5.6.3.2. GCP Filestore CSI Driver Operator のインストール
デフォルトでは、Google Compute Platform (GCP) の Filestore Container Storage Interface (CSI) Driver Operator は OpenShift Dedicated にインストールされません。次の手順を使用して、GCP Filestore CSI Driver Operator をクラスターにインストールします。
前提条件
- OpenShift Dedicated Web コンソールへアクセスできる。
- GCP ワークロード ID を使用する場合は、特定の GCP Workload Identity パラメーターがある。前述のセクション Workload Identity を使用して GCP Filestore CSI Driver Operator をインストールする準備 を参照してください。
手順
ウェブコンソールから GCP Filestore CSI Driver Operator をインストールするには、以下を行います。
- OpenShift Cluster Manager にログインします。
- クラスターを選択します。
- Open console をクリックし、認証情報を使用してログインします。
次のコマンドを実行して、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 に設定されている。
GCP Workload Identity を使用する場合は、セクション ワークロードアイデンティティーを使用した GCP Filestore CSI ドライバー Operator のインストールの準備 の手順で取得した次のフィールドの値を入力します。
- GCP Project Number
- GCP Pool ID
- GCP Provider ID
- GCP Service Account Email
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.6.4. GCP Filestore Storage のストレージクラスの作成
Operator をインストールしたら、Google Compute Platform (GCP) Filestore ボリュームの動的プロビジョニング用のストレージクラスを作成する必要があります。
前提条件
- 実行中の OpenShift Dedicated クラスターにログインしている。
手順
ストレージクラスを作成するには、以下を行います。
次のサンプル YAML ファイルを使用してストレージクラスを作成します。
サンプル YAML ファイル
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: filestore-csi provisioner: filestore.csi.storage.gke.io parameters: connect-mode: DIRECT_PEERING 1 network: network-name 2 allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer
Filestore インスタンスを作成する VPC ネットワークの名前を指定します。
Filestore インスタンスを作成する VPC ネットワークを指定することを推奨します。VPC ネットワークが指定されていないと、Container Storage Interface (CSI) ドライバーは、プロジェクトのデフォルト VPC ネットワークにインスタンスを作成しようとします。
IPI インストールでは、VPC ネットワーク名は通常、クラスター名に接尾辞 "-network" を付けたものです。ただし、UPI インストールでは、VPC ネットワーク名はユーザーが選択した任意の値にすることができます。
共有 VPC (
connect-mode
=PRIVATE_SERVICE_ACCESS
) の場合、ネットワークは完全な VPC 名である必要があります。たとえばproject/shared-vpc-name/global/networks/gcp-filestore-network
です。次のコマンドを使用して
MachineSets
オブジェクトを調べると、VPC ネットワーク名を確認できます。$ oc -n openshift-machine-api get machinesets -o yaml | grep "network:" - network: gcp-filestore-network (...)
この例では、このクラスターの VPC ネットワーク名は "gcp-filestore-network" です。
5.6.5. クラスターと GCP Filestore の破棄
通常、クラスターを破棄すると、OpenShift Dedicated インストーラーはそのクラスターに属するすべてのクラウドリソースを削除します。ただし、Google Compute Platform (GCP) Filestore リソースの特殊な性質により、自動クリーンアッププロセスでは、すべてのリソースが削除されない場合がまれに発生します。
したがって、Red Hat では、アンインストールプロセスによってクラスター所有のすべての Filestore リソースが削除済みであることを確認するよう推奨しています。
手順
すべての GCP Filestore PVC が削除済みであるこを確認するには、以下を実行します。
- GUI または CLI を使用して Google Cloud アカウントにアクセスします。
kubernetes-io-cluster-${CLUSTER_ID}=owned
ラベルを持つリソースを検索します。クラスター ID は削除されたクラスターに固有であるため、そのクラスター ID を持つリソースは残っていないはずです。
- 万が一リソースが残っている場合は、削除してください。
5.6.6. 関連情報
第6章 汎用的な一時ボリューム
6.1. 概要
汎用一時ボリュームは、永続ボリュームおよび動的プロビジョニングをサポートするすべてのストレージドライバーが提供できる一時ボリュームの一種です。汎用の一時ボリュームは、スクラッチデータ用に Pod ごとのディレクトリー (通常、プロビジョニング後は空) を提供する点で emptyDir
ボリュームと類似しています。
汎用の一時ボリュームは Pod 仕様に準拠して指定され、Pod のライフサイクルに従います。これらは Pod と共に作成され、削除されます。
汎用の一時ボリュームには、以下の特徴があります。
- ストレージは、ローカルまたはネットワーク接続タイプとすることができます。
- ボリュームには、Pod が超過できない固定サイズを指定できます。
- ドライバーおよびパラメーターによっては、ボリュームに特定の初期データが含まれる場合があります。
- ドライバーがサポートしていれば、スナップショットの作成、クローンの作成、サイズ変更、ストレージ容量の追跡など、ボリュームに対する一般的な操作がサポートされます。
汎用の一時ボリュームは、オフラインのスナップショットやサイズ変更をサポートしません。
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
リソースオブジェクトは、要求可能なストレージを記述し、分類するほか、動的にプロビジョニングされるストレージのパラメーターを要求に応じて渡すための手段を提供します。StorageClass
オブジェクトは、さまざまなレベルのストレージとストレージへのアクセスを制御するための管理メカニズムとしても機能します。クラスター管理者 (cluster-admin
) またはストレージ管理者 (storage-admin
) は、ユーザーが基礎となるストレージボリュームソースに関する詳しい知識がなくても要求できる StorageClass
オブジェクトを定義し、作成します。
OpenShift Dedicated 永続ボリュームフレームワークは、この機能を有効にし、管理者が永続ストレージを使用してクラスターをプロビジョニングできるようにします。フレームワークにより、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。
OpenShift Dedicated では、多くのストレージタイプが永続ボリュームとして使用できます。これらはすべて管理者によって静的にプロビジョニングされますが、一部のストレージタイプは組み込みプロバイダーとプラグイン API を使用して動的に作成できます。
7.2. 利用可能な動的プロビジョニングプラグイン
OpenShift Dedicated は、以下のプロビジョナープラグインを提供します。これらのプラグインには、クラスターの設定済みプロバイダーの API を使用して新しいストレージリソースを作成する動的プロビジョニングの汎用実装があります。
ストレージタイプ | プロビジョナープラグインの名前 | 注記 |
---|---|---|
Amazon Elastic Block Store (Amazon EBS) |
|
複数クラスターを複数の異なるゾーンで使用する際の動的プロビジョニングの場合は、各ノードに |
GCE Persistent Disk (gcePD) |
| マルチゾーン設定では、GCE プロジェクトごとに 1 つの OpenShift Dedicated クラスターを実行して、現在のクラスターにノードが存在しないゾーンに PV が作成されないようにすることを推奨します。 |
IBM Power® 仮想サーバーブロック |
| インストール後、IBM Power® Virtual Server Block CSI Driver Operator と IBM Power® Virtual Server Block CSI Driver は、動的プロビジョニングに必要なストレージクラスを自動的に作成します。 |
選択したプロビジョナープラグインでは、関連するクラウド、ホスト、またはサードパーティープロバイダーを、関連するドキュメントに従って設定する必要もあります。
7.3. ストレージクラスの定義
現時点で、StorageClass
オブジェクトはグローバルスコープオブジェクトであり、cluster-admin
または storage-admin
ユーザーによって作成される必要があります。
Cluster Storage Operator は、使用されるプラットフォームに応じてデフォルトのストレージクラスをインストールする可能性があります。このストレージクラスは Operator によって所有され、制御されます。アノテーションとラベルを定義するほかは、これを削除したり、変更したりすることはできません。異なる動作が必要な場合は、カスタムストレージクラスを定義する必要があります。
以下のセクションでは、StorageClass
オブジェクトの基本的な定義とサポートされている各プラグインタイプの具体的な例を説明します。
7.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 ...
7.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 ...
7.3.3. 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
です。
7.3.4. 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-ssd 2 replication-type: none volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true reclaimPolicy: Delete
7.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.