4.4. カーネルモジュールのデプロイ


Module リソースごとに、カーネルモジュール管理 (KMM) は多数の DaemonSet リソースを作成できます。

  • クラスターで実行されている互換性のあるカーネルバージョンごとに 1 つの ModuleLoader DaemonSet
  • 1 つのデバイスプラグイン DaemonSet (設定されている場合)。

モジュールローダーデーモンは、カーネルモジュールをロードするために ModuleLoader イメージを実行するリソースを設定します。モジュールローダーイメージは、.ko ファイルと modprobe および sleep バイナリーの両方を含む OCI イメージです。

モジュールローダー Pod が作成されると、Pod は modprobe を実行して、指定されたモジュールをカーネルに挿入します。その後、終了するまでスリープ状態になります。その場合、ExecPreStop フックは modprobe -r を実行してカーネルモジュールをアンロードします。

モジュール リソースで .spec.devicePlugin 属性が設定されている場合、KMM はクラスター内に デバイスプラグイン デーモンセットを作成します。このデーモンセットは、以下を対象とします。

  • Module リソースの .spec.selector に一致するノード。
  • カーネルモジュールがロードされたノード (モジュールローダー Pod が Ready 状態にある場合)。

4.4.1. Module カスタムリソース定義

Module のカスタムリソース定義 (CRD) は、モジュールローダーイメージを介してクラスター内のすべてのノードまたは選択したノードにロードできるカーネルモジュールを表します。Module カスタムリソース (CR) は、互換性のある 1 つ以上のカーネルバージョンとノードセレクターを指定します。

Module リソースの互換性のあるバージョンは、.spec.moduleLoader.container.kernelMappings の下にリストされています。カーネルマッピングは、literal バージョンと一致するか、regexp を使用してそれらの多くを同時に一致させることができます。

Module リソースの調整ループでは、次の手順が実行されます。

  1. .spec.selector に一致するすべてのノードをリスト表示します。
  2. それらのノードで実行されているすべてのカーネルバージョンのセットを構築します。
  3. 各カーネルバージョンで以下を実行します。

    1. .spec.moduleLoader.container.kernelMappings を調べて、適切なコンテナーイメージ名を見つけます。カーネルマッピングに build または sign が定義されていて、コンテナーイメージがまだ存在しない場合は、必要に応じてビルド、署名ジョブ、またはその両方を実行します。
    2. 前の手順で決定したコンテナーイメージを使用して、モジュールローダーデーモンセットを作成します。
    3. .spec.devicePlugin が定義されている場合は、.spec.devicePlugin.container で指定された設定を使用して、デバイスプラグインデーモンセットを作成します。
  4. 以下で garbage-collect を実行します。

    1. クラスター内のどのノードでも実行されていないカーネルバージョンをターゲットとする既存のデーモンセットリソース。
    2. 成功したビルドジョブ。
    3. 成功した署名ジョブ。

4.4.2. カーネルモジュール間のソフト依存関係を設定する

一部の設定では、複数のカーネルモジュールがシンボルを通じて相互に直接依存していない場合でも、それらのモジュールを特定の順序でロードしなければ適切に動作しません。これはソフト依存関係と呼ばれています。depmod は通常、これらの依存関係を認識せず、生成するファイルには表示されません。たとえば、mod_amod_b に対するソフト依存関係がある場合、modprobe mod_amod_b をロードしません。

このような状況は、modulesLoadingOrder フィールドを使用してモジュールカスタムリソース定義 (CRD) でソフト依存関係を宣言することで解決できます。

# ...
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: mod_a
        dirName: /opt
        firmwarePath: /firmware
        parameters:
          - param=1
        modulesLoadingOrder:
          - mod_a
          - mod_b

上記の設定では次のようになります。

  • ロードの順序は mod_b、次に mod_a です。
  • アンロードの順序は mod_a、次に mod_b です。
注記

リストの最初の値は最後にロードされ、moduleName と等しくなければなりません。

4.4.3. セキュリティーおよびパーミッション

重要

カーネルモジュールのロードは、非常に機密性の高い操作です。それらがロードされると、カーネルモジュールには、ノード上であらゆる種類の操作を実行するためのすべての可能な権限が付与されます。

4.4.3.1. ServiceAccounts および SecurityContextConstraints

Kernel Module Management (KMM) は、カーネルモジュールをノードにロードするための特権ワークロードを作成します。そのワークロードには、privileged SecurityContextConstraint (SCC) リソースの使用を許可された ServiceAccounts が必要です。

そのワークロードの承認モデルは、Module リソースの namespace とその仕様によって異なります。

  • .spec.moduleLoader.serviceAccountName または .spec.devicePlugin.serviceAccountName フィールドが設定されている場合は常に使用されます。
  • これらのフィールドが設定されていない場合:

    • Module リソースが Operator の namespace (デフォルトでは openshift-kmm) に作成される場合、KMM はそのデフォルトの強力な ServiceAccounts を使用してデーモンセットを実行します。
    • Module リソースが他の namespace で作成された場合、KMM はデーモンセットを namespace の default ServiceAccount として実行します。Module リソースは、privileged SCC の使用を手動で有効にしない限り、特権ワークロードを実行できません。
重要

openshift-kmm は信頼できる namespace です。

RBAC 権限を設定するときは、ユーザーまたは ServiceAccount がopenshift-kmm namespace で Module リソースを作成すると、KMM がクラスター内のすべてのノードで特権ワークロードを自動的に実行することに注意してください。

ServiceAccountprivileged SCC を使用できるようにして、モジュールローダーまたはデバイスプラグイン Pod を実行できるようにするには、次のコマンドを使用します。

$ oc adm policy add-scc-to-user privileged -z "${serviceAccountName}" [ -n "${namespace}" ]

4.4.3.2. Pod のセキュリティー基準

OpenShift は、使用中のセキュリティーコンテキストに基づいて namespace Pod セキュリティーレベルを自動的に設定する同期メカニズムを実行します。アクションは不要です。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る