5.3. Shared Resource CSI Driver Operator
クラスター管理者は、OpenShift Container Platform で Shared Resource CSI Driver を使用して、Secret
または ConfigMap
オブジェクトの内容が含まれるインライン一時ボリュームをプロビジョニングできます。これにより、ボリュームマウントを公開する Pod および他の Kubernetes タイプ、ならびに OpenShift Container Platform Builds は、クラスター内の namespace 全体でそれらのオブジェクトの内容を安全に使用できます。そのために、現在、SharedSecret
カスタムリソース (Secret
オブジェクト用) および SharedConfigMap
カスタムリソース ConfigMap
オブジェクト用) という 2 種類の共有リソースがあります。
Shared Resource CSI Driver は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Shared Resource CSI Driver を有効にするには、フィーチャーゲートを使用して機能を有効化 する必要があります。
5.3.1. CSI について
ストレージベンダーはこれまで Kubernetes の一部としてストレージドライバーを提供してきました。Container Storage Interface (CSI) の実装では、サードパーティーのプロバイダーは、コア Kubernetes コードを変更せずに標準のインターフェイスを使用してストレージプラグインを提供できます。
CSI Operator は、インツリーボリュームプラグインでは不可能なボリュームスナップショットなどのストレージオプションを OpenShift Container Platform ユーザーに付与します。
5.3.2. namespace 間でのシークレットの共有
クラスター内の namespace 間でシークレットを共有するには、共有する Secret
オブジェクトの SharedSecret
カスタムリソース (CR) インスタンスを作成します。
前提条件
次のアクションを実行するためのパーミッションがある。
-
cluster スコープレベルで
sharedsecrets.sharedresource.openshift.io
カスタムリソース定義 (CRD) のインスタンスを作成する。 - クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
-
ロールおよびロールバインディングを管理し、Pod で指定されたサービスアカウントが、使用する
SharedSecret
CR インスタンスを参照する Container Storage Interface (CSI) ボリュームをマウントできるかどうかを制御する。 - 共有する Secret が含まれる namespace にアクセスする。
手順
クラスター内の namespace 間で共有する
Secret
オブジェクトのSharedSecret
CR インスタンスを作成します。$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedSecret metadata: name: my-share spec: secretRef: name: <name of secret> namespace: <namespace of secret> EOF
5.3.3. Pod での SharedSecret インスタンスの使用
Pod から SharedSecret
カスタムリソース (CR) インスタンスにアクセスするには、その SharedSecret
CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。
前提条件
-
クラスター内の namespace 間で共有する Secret の
SharedSecret
CR インスタンスを作成している。 次のアクションを実行するためのパーミッションがある。
- ビルド設定を作成し、ビルドを開始します。
-
oc get sharedsecrets
コマンドを入力し、空でないリストを取得して、使用可能なSharedSecret
CR インスタンスを見つけます。 -
namespace で利用可能な
builder
サービスアカウントが指定のSharedSecret
CR インスタンスを使用できるかどうかを判別します。つまり、oc adm policy who-can use <identifier of specific SharedSecret>
実行して、namespace のbuilder
サービスアカウントが一覧に表示されるかどうかを確認できます。
このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedSecret
CR インスタンスを検出し、サービスアカウントを有効にして SharedSecret
CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。
手順
YAML コンテンツと共に
oc apply
を使用して、その Pod でSharedSecret
CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。注記現在、
kubectl
とoc
には、use
動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …
を使用して、SharedSecret
CR インスタンスの使用に必要なロールを作成することはできません。$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedsecrets resourceNames: - my-share verbs: - use EOF
oc
コマンドを使用して、ロールに関連付けられたRoleBinding
を作成します。$ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
Pod から
SharedSecret
CR インスタンスにアクセスします。$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedSecret: my-share EOF
5.3.4. namespace 間での設定マップの共有
クラスター内の namespace 間で設定マップを共有するには、その設定マップの SharedConfigMap
カスタムリソース (CR) インスタンスを作成します。
前提条件
次のアクションを実行するためのパーミッションがある。
-
cluster スコープレベルで
sharedconfigmaps.sharedresource.openshift.io
カスタムリソース定義 (CRD) のインスタンスを作成する。 - クラスター内の namespace 全体でロールおよびロールバインディングを管理し、これらのインスタンスを取得、リスト表示、監視できるユーザーを制御する。
- クラスター内の namespace 全体でロールおよびロールバインディングを管理し、Container Storage Interface (CSI) ボリュームをマウントする Pod のどのサービスアカウントが、それらのインスタンスを使用できるかを制御する。
- 共有する Secret が含まれる namespace にアクセスする。
手順
クラスター内の namespace 間で共有する設定マップの
SharedConfigMap
CR インスタンスを作成します。$ oc apply -f - <<EOF apiVersion: sharedresource.openshift.io/v1alpha1 kind: SharedConfigMap metadata: name: my-share spec: configMapRef: name: <name of configmap> namespace: <namespace of configmap> EOF
5.3.5. Pod での SharedConfigMap インスタンスの使用
次のステップ
Pod から SharedConfigMap
カスタムリソース (CR) インスタンスにアクセスするには、その SharedConfigMap
CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。
前提条件
-
クラスター内の namespace 間で共有する設定マップの
SharedConfigMap
CR インスタンスを作成している。 次のアクションを実行するためのパーミッションがある。
- ビルド設定を作成し、ビルドを開始します。
-
oc get sharedconfigmaps
コマンドを入力し、空でないリストを取得して、使用可能なSharedConfigMap
CR インスタンスを検出します。 -
namespace で利用可能な
builder
サービスアカウントが指定のSharedSecret
CR インスタンスを使用できるかどうかを判別します。つまり、oc adm policy who-can use <identifier of specific SharedSecret>
実行して、namespace のbuilder
サービスアカウントが一覧に表示されるかどうかを確認できます。
このリストの最後の 2 つの前提条件のいずれも満たされない場合は、SharedConfigMap
CR インスタンスを検出し、サービスアカウントを有効にして SharedConfigMap
CR インスタンスを使用できるように、必要なロールベースアクセス制御 (RBAC) を作成するか、誰かに依頼して作成します。
手順
YAML コンテンツと共に
oc apply
を使用して、その Pod でSharedConfigMap
CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。注記現在、
kubectl
とoc
には、use
動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …
を使用して、SharedConfigMap
CR インスタンスの使用に必要なロールを作成することはできません。$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: shared-resource-my-share namespace: my-namespace rules: - apiGroups: - sharedresource.openshift.io resources: - sharedconfigmaps resourceNames: - my-share verbs: - use EOF
oc
コマンドを使用して、ロールに関連付けられたRoleBinding
を作成します。oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
Pod から
SharedConfigMap
CR インスタンスにアクセスします。$ oc apply -f - <<EOF kind: Pod apiVersion: v1 metadata: name: my-app namespace: my-namespace spec: serviceAccountName: default # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume volumes: - name: my-csi-volume csi: readOnly: true driver: csi.sharedresource.openshift.io volumeAttributes: sharedConfigMap: my-share EOF
5.3.6. Shared Resource CSI Driver に対するその他のサポート制限
Shared Resource CSI Driver には、以下の重要な制限があります。
- ドライバーは、Container Storage Interface (CSI) のインライン一時ボリュームの制限の対象となります。
-
readOnly
フィールドの値はtrue
である必要があります。そうでない場合には、Pod 起動時のボリュームのプロビジョニング時に、ドライバーはエラーを kubelet に返します。この制限は、関連するボリュームへの SELinux ラベルの適用に関して、アップストリームの Kubernetes CSI Driver で提案されたベストプラクティスに対応するためのものです。 -
ドライバーは、
tmpfs
ボリュームしかサポートしないため、FSType
フィールドを無視します。 -
ドライバーは
NodePublishSecretRef
フィールドを無視します。代わりに、ドライバーはuse
動詞でSubjectAccessReviews
を使用して、Pod がSharedSecret
またはSharedConfigMap
カスタムリソース (CR) インスタンスが含まれるボリュームを取得できるかどうかを評価します。
5.3.7. 共有リソース Pod ボリュームの VolumeAttributes に関する追加情報
以下の属性は、さまざまな形で共有リソース Pod ボリュームに影響を及ぼします。
-
volumeAttributes
プロパティーのrefreshResource
属性。 -
Shared Resource CSI Driver 設定の
refreshResources
属性。 -
volumeAttributes
プロパティーのsharedSecret
およびsharedConfigMap
属性。
5.3.7.1. refreshResource
属性
Shared Resource CSI Driver は、ボリュームの volumeAttributes
プロパティーの refreshResource
属性を尊重します。この属性は、Pod 起動の一環としてボリュームが初回にプロビジョニングされた 後 に、基礎となる Secret
または ConfigMap
オブジェクトの内容に対する更新がボリュームにコピーされるかどうかを制御します。refreshResource
のデフォルト値は true
です。これは、コンテンツが更新されることを意味します。
Shared Resource CSI Driver 設定により、共有 SharedSecret
および SharedConfigMap
カスタムリソース (CR) インスタンス両方の更新が無効にされている場合、volumeAttribute
プロパティーの refreshResource
属性は影響を及ぼしません。この属性の目的は、更新が一般的に許可されている場合に、特定のボリュームマウントの更新を無効にすることです。
5.3.7.2. refreshResources
属性
グローバルスイッチを使用して、共有リソースの更新を有効または無効にできます。このスイッチは Shared Resource CSI Driver の csi-driver-shared-resource-config
設定マップの refreshResources
属性で、openshift-cluster-csi-drivers
namespace で確認できます。この refreshResources
属性を false
に設定する場合、ボリュームに保存されている Secret
または ConfigMap
オブジェクト関連のコンテンツは、ボリュームの初回プロビジョニング後に更新されません。
この Shared Resource CSI Driver 設定を使用して更新を無効にすると、ボリュームの volumeAttributes
プロパティーの refreshResource
属性に関係なく、Shared Resource CSI Driver を使用するすべてのクラスターのボリュームマウントが影響を受けます。
5.3.7.3. Pod の共有リソースボリュームをプロビジョニングする前の volumeAttributes の検証
1 つのボリュームの volumeAttributes
で、sharedSecret
または sharedConfigMap
属性いずれかの値を、SharedSecret
または SharedConfigMap
CS インスタンスの値に設定する必要があります。設定しないと、Pod の起動時にボリュームがプロビジョニングされる際に、検証でそのボリュームの volumeAttributes
がチェックされ、以下の条件下では kubelet にエラーが返されます。
-
sharedSecret
およびsharedConfigMap
属性の両方に値が指定されている。 -
sharedSecret
およびsharedConfigMap
属性の両方に値が指定されていない。 -
sharedSecret
またはsharedConfigMap
属性の値が、クラスター内のSharedSecret
またはSharedConfigMap
CR インスタンスの名前に対応していない。
5.3.8. 共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーション
共有リソース、Insights Operator、および OpenShift Container Platform Builds 間のインテグレーションにより、Red Hat サブスクリプション (RHEL エンタイトルメント) を OpenShift Container Platform Builds で簡単に使用できます。
従来、OpenShift Container Platform 4.9.x 以前では、認証情報を手動でインポートし、ビルドを実行している各プロジェクトまたは namespace にコピーしていました。
OpenShift Container Platform 4.10 以降では、OpenShift Container Platform Builds では、共有リソースおよび Insights Operator によって提供される単純なコンテンツアクセス機能を参照して、Red Hat サブスクリプション (RHEL エンタイトルメント) を使用できるようになりました。
-
シンプルなコンテンツアクセス機能は、サブスクリプションの認証情報を、既知の
Secret
オブジェクトにインポートします。以下の「関連情報」セクションのリンクを参照してください。 -
クラスター管理者は、その
Secret
オブジェクトに関するSharedSecret
カスタムリソース (CR) インスタンスを作成し、特定のプロジェクトまたは namespace にパーミッションを付与します。特に、クラスター管理者は、そのSharedSecret
CR インスタンスを使用するための、builder
サービスアカウントパーミッションを付与します。 -
それらのプロジェクトまたは namespace 内で実行されるビルドは、
SharedSecret
CR インスタンスおよびそのエンタイトルメントが適用された RHEL コンテンツを参照する CSI Volume をマウントできます。