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 リソースの調整ループでは、次の手順が実行されます。
-
.spec.selectorに一致するすべてのノードをリスト表示します。 - それらのノードで実行されているすべてのカーネルバージョンのセットを構築します。
各カーネルバージョンで以下を実行します。
-
.spec.moduleLoader.container.kernelMappingsを調べて、適切なコンテナーイメージ名を見つけます。カーネルマッピングにbuildまたはsignが定義されていて、コンテナーイメージがまだ存在しない場合は、必要に応じてビルド、署名ジョブ、またはその両方を実行します。 - 前の手順で決定したコンテナーイメージを使用して、モジュールローダーデーモンセットを作成します。
-
.spec.devicePluginが定義されている場合は、.spec.devicePlugin.containerで指定された設定を使用して、デバイスプラグインデーモンセットを作成します。
-
以下で
garbage-collectを実行します。- クラスター内のどのノードでも実行されていないカーネルバージョンをターゲットとする既存のデーモンセットリソース。
- 成功したビルドジョブ。
- 成功した署名ジョブ。
4.4.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
上記の設定では次のようになります。
-
ロードの順序は
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 のdefaultServiceAccountとして実行します。Moduleリソースは、privilegedSCC の使用を手動で有効にしない限り、特権ワークロードを実行できません。
-
openshift-kmm は信頼できる namespace です。
RBAC 権限を設定するときは、ユーザーまたは ServiceAccount がopenshift-kmm namespace で Module リソースを作成すると、KMM がクラスター内のすべてのノードで特権ワークロードを自動的に実行することに注意してください。
ServiceAccount が privileged SCC を使用できるようにして、モジュールローダーまたはデバイスプラグイン Pod を実行できるようにするには、次のコマンドを使用します。
$ oc adm policy add-scc-to-user privileged -z "${serviceAccountName}" [ -n "${namespace}" ]
4.4.3.2. Pod のセキュリティー基準 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift は、使用中のセキュリティーコンテキストに基づいて namespace Pod セキュリティーレベルを自動的に設定する同期メカニズムを実行します。アクションは不要です。