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 は期待どおりに動作します。期待どおりに動作します。
  • イメージを作成または削除しても、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 は期待どおりに動作します。
  • ドキュメント内の job.dcDelay の例で、0 ではなく 0s を指定する必要があります。

    • 原因: Kernel Module Management (KMM) Operator のデフォルトの job.gcDelay 期間フィールドは 0s ですが、ドキュメントでは値が 0 と記載されています。
    • 結果: 60s または 1m ではなく 60 というカスタム値を入力すると、入力型が間違っているためにエラーが発生する可能性があります。
    • 修正: ドキュメント内の job.gcDelay フィールドがデフォルト値の 0s に更新されました。
    • 結果: ユーザーが混乱する可能性が低くなりました。
  • 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 ハブ環境は期待どおりに動作します。
  • リソースにファイナライザーが設定されていない場合、KMM OperatorHub 環境でビルドを実行できません。

    • 原因: Kernel Module Management (KMM) Operator が、ManagedClusterModule コントローラーのビルドに失敗したというエラーを表示します。これは、KMM OperatorHub 環境の ModuleImagesConfig (MIC) リソースファイナライザーとロールベースアクションコントロール (RBAC) 権限が欠落していることが原因です。
    • 結果: KMM OperatorHub 環境でイメージをビルドできません。
    • 修正: RBAC 権限が更新されたことで、MIC リソースのファイナライザーを更新し、適切なルールを作成できるようになりました。
    • 結果: KMM OperatorHub 環境は、ManagedClusterModule コントローラーを使用してエラーなしでイメージをビルドします。
  • 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 を指定する必要がありました。これは現在変更されており、kernelVersiondtkImage フィールドに設定する必要があります。
    • 結果: ドキュメントが古くなっていたため、更新が必要でした。
    • 修正: ドキュメントがサポート状況に関する新しい情報で更新されました。
    • 結果: KMM のプリフライト機能が期待どおりにドキュメント化されました。

5.3.4. 既知の問題

  • モジュールが Unloaded の場合、ModuleUnloaded イベントが表示されません。

    • 原因: モジュールが Loaded 状態のとき (ModuleLoad イベントの作成を使用)、または Unloaded 状態のとき (ModuleUnloaded イベントの作成を使用)、イベントが表示されない場合があります。これは、カーネルモジュールを連続してロードおよびアンロードした場合に発生します。
    • 結果: ModuleLoad イベントと ModuleUnloaded イベントが OpenShift Container Platform に表示されない可能性があります。
    • 修正: モジュールを扱う際の注意を喚起するために、この動作が発生する可能性に関する警告メカニズムを導入します。
    • 結果: まだ提供されていません。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat