5.3. Kernel Module Management Operator 2.4 のリリースノート
5.3.1. 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
- このリリースでは、ツリー外カーネルドライバーをロードせず、代わりにツリー内ドライバーを使用してデバイスプラグインのみを実行するように Kernel Module Management (KMM) モジュールを設定するオプションが追加されました。詳細は、デバイスプラグインでのツリー内モジュールの使用 を参照してください。
このリリースでは、クラスターと KMM Operator のアップグレード後および KMM の再デプロイ後も KMM 設定が保持されるようになりました。
以前のリリースでは、クラスターまたは KMM のアップグレードや、デフォルト以外の設定 (KMM を再デプロイするファームウェアパスなど) のアップグレードなどの操作によって、KMM の再設定が必要になることがありました。このリリースでは、このような操作に関係なく、KMM 設定が永続的に維持されるようになりました。
詳細は、Kernel Module Management Operator の設定 を参照してください。
- KMM に改良が加えられたため、GPU Operator のベンダーがコード内で KMM の機能を再現する必要がなくなり、KMM をそのまま使用できるようになりました。この変更により、Operator のコードサイズ、テスト、信頼性が大幅に向上します。
-
このリリースでは、KMM が kmod イメージが存在するかどうかを確認するために HTTP(S) 直接リクエストを使用しなくなりました。イメージの確認には、代わりに CRI-O が内部的に使用されます。これにより、HTTP(S) リクエストからコンテナーイメージレジストリーに直接アクセスして、手動のタスク (ミラーリング設定のための
/etc/containers/registries.conf
の読み取り、TLS 設定のためのイメージクラスターリソースへのアクセス、ノードからの CA のマウント、ハブアンドスポークでの独自のキャッシュの管理など) を処理する必要性が軽減されます。
- KMM および KMM-Hub Operator に、Red Hat Catalog で "Meets Best Practices" (ベストプラクティスに準拠) というラベルが割り当てられました。
-
必要に応じて、コンピュートノードに KMM をインストールできるようになりました。以前は、コントロールプレーンノードにワークロードをデプロイすることはできませんでした。コンピュートノードには
node-role.kubernetes.io/control-plane
またはnode-role.kubernetes.io/master
ラベルがないため、Kernel Module Management Operator に追加の設定が必要になることがありました。この問題は内部コードの変更により解決されました。
このリリースでは、NMC リコンサイラーのハートビートフィルターが更新され、ノード上の次のイベントがフィルタリングされるようになりました。
-
node.spec
-
metadata.labels
-
status.nodeInfo
-
status.conditions[]
(NodeReady
のみ) およびハートビートのフィルタリング
-
5.3.2. 主な技術上の変更点 リンクのコピーリンクがクリップボードにコピーされました!
- このリリースでは、クラスター内のプリフライト検証リソースが変更されました。プリフライト検証を使用すると、クラスターのアップグレードおよび場合によってはカーネルのアップグレード後にノードにインストールされるカーネルモジュールを検証できます。プリフライト検証では、検証を試行している、または試行したクラスター内の各モジュールのステータスと進行状況も報告されます。詳細は、Kernel Module Management (KMM) モジュールのプリフライト検証 を参照してください。
-
kmod イメージを作成する際には、
.ko
カーネルモジュールファイルとcp
バイナリーの両方を含める必要があります。これは、イメージのロードプロセス中にファイルをコピーするために必要です。詳細は、kmod イメージの作成 を参照してください。
-
Operator の成熟度レベルを示す
capabilities
フィールドが、Basic Install
からSeamless upgrades
に変更されました。Basic Install
は、Operator にアップグレードオプションがないことを示します。シームレスなアップグレードがサポートされている KMM は、これには該当しません。
5.3.3. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
Webhook デプロイメントの名前が
webhook-server
からwebhook
に変更されました。-
原因:
controller-gen
を使用してファイルを生成すると、設定不可能なwebhook-service
という名前のサービスが生成されていました。また、Operator Lifecycle Manager (OLM) を使用して KMM をデプロイすると、OLM は-service
という名前の Webhook 用のサービスをデプロイします。 -
結果: 同じデプロイメントに対して 2 つのサービスが生成されていました。1 つは
controller-gen
によって生成され、バンドルマニフェストに追加されるもの、もう 1 つは OLM によって作成されるものです。 -
修正: デプロイメントの名前を
webhook
にすることで、OLM がクラスター内でwebhook-service
という名前の既存のサービスを検出するようにします。 - 結果: 2 つ目のサービスが作成されなくなりました。
-
原因:
imageRepoSecret
オブジェクトを DTK と組み合わせてイメージストリームとして使用するとauthorization required
エラーが発生します。-
原因: Kernel Module Management (KMM) Operator で、KMM モジュールに
imageRepoSecret
オブジェクトを設定し、ビルドの結果のコンテナーイメージをクラスターの内部レジストリーに保存するように定義されている場合、ビルドは最終イメージをプッシュできず、authorization required
エラーが生成されます。 - 結果: KMM Operator は期待どおりに動作しません。
-
修正:
imageRepoSecret
オブジェクトがユーザー定義のオブジェクトである場合、このオブジェクトはビルドプロセスによってプルシークレットとプッシュシークレットの両方として使用されます。クラスターの内部レジストリーの使用をサポートするには、そのレジストリーの認可トークンをimageRepoSecret
オブジェクトに追加する必要があります。トークンは、KMM モジュールの namespace の "build" サービスアカウントから取得できます。 - 結果: KMM Operator は期待どおりに動作します。期待どおりに動作します。
-
原因: Kernel Module Management (KMM) Operator で、KMM モジュールに
イメージを作成または削除しても、MCM モジュールを作成しても、スポークにモジュールがロードされません。
-
原因: ハブアンドスポーク環境で、レジストリー内にイメージを作成または削除するとき、あるいは
ManagedClusterModule
(MCM) を作成するときに、スポーククラスター上のモジュールがロードされません。 - 結果: スポーク上のモジュールが作成されません。
- 修正: ハブアンドスポーク環境からキャッシュパッケージとイメージ変換を削除します。
- 結果: MCM オブジェクトが再び作成されるときに、スポーク上のモジュールが作成されます。
-
原因: ハブアンドスポーク環境で、レジストリー内にイメージを作成または削除するとき、あるいは
クラスター内ビルドの実行中に、KMM がプライベートレジストリーからイメージをプルできません。
- 原因: Kernel Module Management (KMM) Operator が、クラスター内ビルドの実行中にプライベートレジストリーからイメージをプルできません。
- 結果: ビルドプロセスで使用されるプライベートレジストリー内のイメージをプルできません。
-
修正:
imageRepoSecret
オブジェクト設定もビルドプロセスで使用されるようになりました。指定されたimageRepoSecret
オブジェクトに、使用されているすべてのレジストリーが含まれている必要があります。 - 結果: クラスター内ビルドを実行するときにプライベートレジストリーを使用できるようになりました。
プルできないコンテナーイメージを含むモジュールを削除すると、KMM のワーカー Pod が孤立します。
- 原因: プルできないコンテナーイメージを含むモジュールを削除すると、Kernel Module Management (KMM) Operator のワーカー Pod が孤立します。
- 結果: 障害のあるワーカー Pod がクラスター上に残り、ガベージとして収集されません。
- 修正: KMM が、モジュールの削除時に、孤立した障害のある Pod をガベージとして収集するようになりました。
- 結果: モジュールが正常に削除され、関連付けられている孤立した障害のある Pod もすべて削除されます。
ノードセレクターが一致しない場合でも、KMM Operator が MIC の作成を試みます。
- 原因: Kernel Module Management (KMM) Operator が、ノードセレクターが実際のノードと一致しない場合でも 'ModuleImagesConfig' (MIC) リソースの作成を試行し、失敗します。
- 結果: KMM Operator は、どのノードも対象としていないモジュールを調整するときにエラーを報告します。
-
修正: MIC リソースの
Images
フィールドが任意になりました。 - 結果: KMM Operator は、イメージがない場合でも MIC リソースを正常に作成できるようになりました。
ノードの再起動シーケンスが速すぎる場合、KMM がカーネルモジュールをリロードしません。
- 原因: ノードの再起動シーケンスが速すぎる場合、Kernel Module Management (KMM) Operator がカーネルモジュールをリロードしません。再起動は、ステータス条件のタイムスタンプが Node Machine Configuration (NMC) ステータスのタイムスタンプよりも新しいかどうかに基づいて決定されます。
- 結果: 猶予期間よりも短い時間で再起動が迅速に行われると、ノードの状態が変化しません。ノードが再起動した後、KMM がカーネルモジュールを再度ロードしません。
-
修正: NMC は、条件の状態を利用する代わりに、
Status.NodeInfo.BootID
フィールドを利用できます。このフィールドは、サーバーノードの/proc/sys/kernel/random/boot_id
ファイルに基づいて kubelet によって設定されるため、再起動のたびに更新されます。 - 結果: タイムスタンプの精度が向上するため、Kernel Module Management (KMM) Operator がノードの再起動シーケンス後にカーネルモジュールを再ロードできるようになります。
Node Machine Configuration (NMC) コントローラーのノードハートビートイベントの除外。
- 原因: NMC コントローラーには、ノードのハートビートのイベントが大量に送信されます。ノードのハートビートは、ノードがまだ接続されていて機能していることを Kubernetes API サーバーに知らせるものです。
- 結果: クラスターにモジュールが適用されておらず、その結果 NMC が適用されていない状況でも、大量のイベントにより継続的な調整が発生します。
- 修正: NMC コントローラーが、ノードのハートビートを調整ループからフィルタリングするようになりました。
- 結果: NMC コントローラーは実際のイベントのみを取得し、ノードのハートビートを除外します。
NMC.spec
またはモジュールに toleration がない場合でも、NMC ステータスに toleration 値が含まれます。-
原因:
NMC.spec
またはモジュールに toleration がない場合でも、Node Machine Configuration (NMC) ステータスに toleration 値が含まれます。 - 結果: Kernel Module Management 固有の toleration 以外の toleration がステータスに表示される場合があります。
- 修正: NMC ステータスが、ワーカー Pod ではなく専用のアノテーションから toleration を取得するようになりました。
- 結果: NMC ステータスにはモジュールの toleration のみが含まれます。
-
原因:
KMM Operator バージョン 2.4 が正常に起動せず、
\modulebuildsignconfigs\
リソースをリスト表示できません。- 原因: Red Hat Konflux を使用して Kernel Module Management (KMM) Operator がインストールされた場合、ログファイルにエラーが含まれているため、Operator は正常に起動しません。
- 結果: KMM Operator は期待どおりに動作しません。
-
修正:
\modulebuildsignconfigs\
およびmoduleimagesconfig
リソースをリスト表示するようにクラスターサービスバージョン (CSV) ファイルが更新されました。 - 結果: KMM Operator は期待どおりに動作します。
Red Hat Konflux のビルドで、Operator のログにバージョンと git コミット ID が記録されません。
- 原因: Communications Platform as a Service (CPaas) を使用して Kernel Module Management (KMM) Operator をビルドした場合、ビルドのログファイルに Operator バージョンと git コミット ID が記録されていました。しかし、Red Hat Konflux を使用すると、これらの詳細がログファイルに記録されません。
- 結果: ログファイルから重要な情報が欠落しています。
- 修正: この問題を解決するために、Konflux にいくつかの変更が導入されました。
- 結果: KMM Operator のビルドで、ログファイルに Operator バージョンと git コミット ID が記録されるようになりました。
taint されたノードが再起動された後に KMM Operator がモジュールをロードしません。
- 原因: ノードの再起動シーケンスが速すぎる場合、Kernel Module Management (KMM) Operator がカーネルモジュールをリロードしません。再起動は、ステータス条件のタイムスタンプが Node Machine Configuration (NMC) ステータスのタイムスタンプよりも新しいかどうかに基づいて決定されます。
- 結果: 猶予期間よりも短い時間で再起動が迅速に行われると、ノードの状態が変化しません。ノードが再起動した後、KMM がカーネルモジュールを再度ロードしません。
-
修正: NMC は、条件の状態を利用する代わりに、
Status.NodeInfo.BootID
フィールドを利用できます。このフィールドは、サーバーノードの /proc/sys/kernel/random/boot_id ファイルに基づいて kubelet によって設定されるため、再起動のたびに更新されます。 - 結果: タイムスタンプの精度が向上するため、Kernel Module Management (KMM) Operator がノードの再起動シーケンス後にカーネルモジュールを再ロードできるようになります。
クラスター内ビルドを使用するモジュールの再デプロイが、
ImagePullBackOff
ポリシーにより失敗します。- 原因: Kernel Module Management (KMM) Operator で、プラー Pod とワーカー Pod のイメージプルポリシーが異なります。
- 結果: イメージが実際には存在しないにもかかわらず、存在するものとみなされる場合があります。
- 修正: プル Pod のイメージプルポリシーを、KMM モジュールで定義されたプルポリシーと同じものにします。このポリシーは、ワーカー Pod で使用されるポリシーと同じであるためです。
- 結果: MIC が、ワーカー Pod がイメージにアクセスするのと同じ方法で、そのイメージの状態を表すようになりました。
MIC コントローラーがプル Pod を 1 つではなく 2 つ作成します。
-
原因: Kernel Module Management (KMM) Operator で、
ModuleImagesConfig
(MIC) コントローラーが同じイメージに対して複数のプル Pod を作成する場合があります。 - 結果: リソースが適切に、または意図したとおりに使用されません。
-
修正:
CreateOrPatch
MIC API は、ImageSpecs
のスライスを入力として受け取ります。この入力は、ターゲットノードを調べて、そのイメージをスライスに追加することで作成されます。そのため、重複するImageSpecs
がフィルターで除外されるようになりました。 - 結果: KMM Operator は期待どおりに動作します。
-
原因: Kernel Module Management (KMM) Operator で、
ドキュメント内の
job.dcDelay
の例で、0
ではなく0s
を指定する必要があります。-
原因: Kernel Module Management (KMM) Operator のデフォルトの
job.gcDelay
期間フィールドは0s
ですが、ドキュメントでは値が0
と記載されています。 -
結果:
60s
または1m
ではなく60
というカスタム値を入力すると、入力型が間違っているためにエラーが発生する可能性があります。 -
修正: ドキュメント内の
job.gcDelay
フィールドがデフォルト値の0s
に更新されました。 - 結果: ユーザーが混乱する可能性が低くなりました。
-
原因: Kernel Module Management (KMM) Operator のデフォルトの
MIC および MBSC CRD がないため、KMM Operator ハブ環境が機能しません。
-
原因: Kernel Module Management (KMM) Operator ハブ環境は、
api-hub/
ディレクトリーだけに基づいてカスタムリソース定義 (CRD) ファイルを生成します。そのため、ModuleImagesConfig
(MIC) リソースや Managed Kubernetes Service (MBSC) など、KMM Operator Hub 環境に必要な一部の CRD が生成されません。 - 結果: KMM Operator ハブ環境がクラスター内に存在しない CRD を調整するコントローラーを起動しようとするため、ハブ環境は機能しません。
-
修正: この修正により、すべての CRD ファイルが
config/crd-hub/bases
ディレクトリーに生成されるようになりました。ただし、クラスターには実際に必要なリソースのみが適用されます。 - 結果: KMM Operator ハブ環境は期待どおりに動作します。
-
原因: Kernel Module Management (KMM) Operator ハブ環境は、
リソースにファイナライザーが設定されていない場合、KMM OperatorHub 環境でビルドを実行できません。
-
原因: Kernel Module Management (KMM) Operator が、
ManagedClusterModule
コントローラーのビルドに失敗したというエラーを表示します。これは、KMM OperatorHub 環境のModuleImagesConfig
(MIC) リソースファイナライザーとロールベースアクションコントロール (RBAC) 権限が欠落していることが原因です。 - 結果: KMM OperatorHub 環境でイメージをビルドできません。
- 修正: RBAC 権限が更新されたことで、MIC リソースのファイナライザーを更新し、適切なルールを作成できるようになりました。
-
結果: KMM OperatorHub 環境は、
ManagedClusterModule
コントローラーを使用してエラーなしでイメージをビルドします。
-
原因: Kernel Module Management (KMM) Operator が、
kernelVersion: tesdt
を持つPreflightValidationOCP
カスタムリソースにより、KMM Operator でパニックが発生します。-
原因:
kernelVersion
フラグをtesdt
に設定してPreflightValidationOCP
カスタムリソース (CR) を作成すると、Kernel Module Management (KMM) Operator によってパニックランタイムエラーが生成されます。 - 結果: 無効なカーネルバージョンを入力すると、KMM Operator でパニックが発生します。
-
修正: 特定のイベント発生時に、あるアプリケーションから別のアプリケーションにリアルタイムデータを自動的に送信する方法として、Webhook が
PreflightValidationOCP
CR に追加されました。 -
結果: 無効なカーネルバージョンを含む
PreflightValidationOCP
CR はクラスターに適用できなくなりました。これにより、Operator がパニックランタイムエラーを生成するのを防ぐことができます。
-
原因:
クラスターの
kernelVersion
フラグとは異なる kernelVersion フラグを含むPreFflightValidationOCP
カスタムリソースが機能しません。-
原因: クラスターの
kernelVersion
フラグとは異なる kernelVersion フラグを使用してPreflightValidationOCP
カスタムリソース (CR) を作成することはできません。 - 結果: Kernel Module Management (KMM) Operator が、新しいカーネルバージョン用の Driver Toolkit (DTK) 入力イメージを検出できません。
-
修正:
PreflightValidationOCP
CR を使用し、CR でdtkImage
フィールドを明示的に設定する必要があります。 -
結果:
kernelVersion
フィールドとdtkImage
フィールドを使用すると、ターゲットの OpenShift Container Platform バージョン用のインストールされるモジュールをビルドできます。
-
原因: クラスターの
KMM Operator バージョン 2.4 のドキュメントが、
PreflightValidationOCP
の情報で更新されました。-
原因: 以前は、
PreflightValidationOCP
CR を作成するときに、release-image を指定する必要がありました。これは現在変更されており、kernelVersion
をdtkImage
フィールドに設定する必要があります。 - 結果: ドキュメントが古くなっていたため、更新が必要でした。
- 修正: ドキュメントがサポート状況に関する新しい情報で更新されました。
- 結果: KMM のプリフライト機能が期待どおりにドキュメント化されました。
-
原因: 以前は、
5.3.4. 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
モジュールが
Unloaded
の場合、ModuleUnloaded
イベントが表示されません。-
原因: モジュールが
Loaded
状態のとき (ModuleLoad
イベントの作成を使用)、またはUnloaded
状態のとき (ModuleUnloaded イベントの作成を使用)、イベントが表示されない場合があります。これは、カーネルモジュールを連続してロードおよびアンロードした場合に発生します。 -
結果:
ModuleLoad
イベントとModuleUnloaded
イベントが OpenShift Container Platform に表示されない可能性があります。 - 修正: モジュールを扱う際の注意を喚起するために、この動作が発生する可能性に関する警告メカニズムを導入します。
- 結果: まだ提供されていません。
-
原因: モジュールが