Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

Kernel Module Management (KMM) は、クラスター内の Node および Module リソースを監視して、カーネルモジュールをノードにロードするか、ノードからアンロードするかを決定します。

モジュールのロード対象となるには、ノードに次のものが含まれている必要があります。

  • モジュールの .spec.selector フィールドと一致するラベル。
  • モジュールの .spec.moduleLoader.container.kernelMappings フィールド内の項目の 1 つと一致するカーネルバージョン。
  • モジュールで順序付きアップグレード (ordered_upgrade.md) が設定されている場合、その .spec.moduleLoader.container.version フィールドと一致するラベル。

KMM は、Module リソースで設定されている目的の状態に合わせてノードを調整するときに、必要なアクションを実行するためにターゲットノード上にワーカー Pod を作成します。KMM Operator は Pod の結果を監視し、情報を記録します。Operator はこの情報を使用して、モジュールが正常にロードされたときに Node オブジェクトにラベルを付け、デバイスプラグインを実行します (設定されている場合)。

ワーカー Pod は、次のタスクを実行する KMM worker バイナリーを実行します。

  • Module リソースで設定された kmod イメージをプルします。kmod イメージは、.ko ファイルを含む標準の OCI イメージです。
  • Pod のファイルシステム内のイメージを抽出します。
  • 指定された引数を使用して modprobe を実行し、必要なアクションを実行します。

4.5.1. Module カスタムリソース定義
リンクのコピー

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

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

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

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

  3. 各カーネルバージョンで以下を実行します。

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

  4. 以下に対して garbage-collect を実行します。

    1. どのノードも対象としていない、廃止されたデバイスプラグインの DaemonSets。
    2. 成功したビルド Pod。
    3. 成功した署名 Pod。

4.5.2. カーネルモジュール間のソフト依存関係を設定する
リンクのコピー

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

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

# ...
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: mod_a
        dirName: /opt
        firmwarePath: /firmware
        parameters:
          - param=1
        modulesLoadingOrder:
          - mod_a
          - mod_b
Copy to Clipboard Toggle word wrap

上記の設定では、ワーカー Pod が、kmod イメージから mod_a をロードする前に、まずツリー内の mod_b をアンロードしようとします。ワーカー Pod が終了し、mod_a がアンロードされると、mod_b は再度ロードされません。

注記

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat