2.3. Kernel Module Management (KMM) モジュールのプリフライト検証


KMM モジュールが適用されたクラスターでアップグレードを実行する前に、KMM を使用してインストールされたカーネルモジュールが、クラスターのアップグレード、および場合によってはカーネルのアップグレード後に、ノードにインストールできることを確認する必要があります。プリフライトは、クラスターにロードされたすべての Module を並行して検証しようとします。プリフライトは、ある Module の検証が完了するのを待たずに、別の Module の検証を開始します。

2.3.1. 検証のキックオフ

プリフライト検証は、クラスター内に PreflightValidationOCP リソースを作成することによってトリガーされます。このリソースには次のフィールドが含まれています。

dtkImage

クラスターの特定の OpenShift Container Platform バージョン用にリリースされた DTK コンテナーイメージ。この値が設定されていない場合、DTK_AUTO 機能は使用できません。

クラスターで次のいずれかのコマンドを実行すると、イメージを取得できます。

# For x86_64 image:
$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.0-x86_64 --image-for=driver-toolkit
Copy to Clipboard Toggle word wrap
# For ARM64 image:
$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.0-aarch64 --image-for=driver-toolkit
Copy to Clipboard Toggle word wrap
kernelVersion

クラスターがアップグレードされるカーネルのバージョンを提供する必須フィールド。

クラスターで次のコマンドを実行すると、バージョンを取得できます。

$ podman run -it --rm $(oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.0-x86_64 --image-for=driver-toolkit) cat /etc/driver-toolkit-release.json
Copy to Clipboard Toggle word wrap
pushBuiltImage
true の場合、ビルドおよび署名の検証中に作成されたイメージがリポジトリーにプッシュされます。このフィールドはデフォルトで false です。

2.3.2. 検証のライフサイクル

プリフライト検証は、クラスターにロードされたすべてのモジュールの検証を試みます。検証が成功した後、プリフライトは Module リソースでの検証の実行を停止します。モジュールの検証が失敗した場合は、モジュール定義を変更することができ、Preflight は次のループで再度モジュールの検証を試行します。

追加のカーネルにプリフライト検証を実行する場合は、そのカーネル用に別の PreflightValidationOCP リソースを作成する必要があります。すべてのモジュールが検証されたら、PreflightValidationOCP リソースを削除することを推奨します。

2.3.3. 検証のステータス

PreflightValidationOCP リソースは、検証を試行している、または試行したクラスター内の各モジュールのステータスと進行状況を .status.modules リストに報告します。そのリストの要素には次のフィールドが含まれます。

name
Module リソースの名前。
namespace
Module リソースの namespace。
statusReason
ステータスに関する言葉による説明。
verificationStage

実行されている検証段階を説明します。

  • Image: イメージの存在確認
  • Done: 検証の完了
verificationStatus

モジュール検証のステータス:

  • Success: 検証済み
  • Failure: 検証が失敗する
  • InProgress: 検証が進行中

2.3.4. イメージの検証ステージ

イメージの検証は常に、実行されるプリフライト検証の最初のステージです。イメージの検証が成功した場合、その特定のモジュールで他の検証は実行されません。Operator はコンテナーランタイムを使用して、モジュール内の更新されたカーネルのイメージの存在とアクセシビリティーを確認します。

イメージの検証が失敗し、モジュール内にアップグレードされたカーネルに関連する build/sign セクションがある場合、コントローラーはイメージのビルドまたは署名を試みます。PreflightValidationOCP リソースで PushBuiltImage フラグが定義されている場合、コントローラーは結果のイメージをリポジトリーにプッシュしようとします。結果のイメージ名は、Module CR の containerImage フィールドの定義から取得されます。

注記

build セクションが存在する場合、sign セクションの入力イメージは build セクションによって出力イメージとして使用されます。したがって、入力イメージを sign セクションで使用できるようにするには、PreflightValidationOCP CR で PushBuiltImage フラグを定義する必要があります。

2.3.5. PreflightValidationOCP リソースの例

次の例は、YAML 形式の PreflightValidationOCP リソースを示しています。

この例では、現在存在するすべてのモジュールを、今後の 5.14.0-570.19.1.el9_6.x86_64 カーネルに対して検証します。.spec.pushBuiltImagetrue に設定されているため、KMM はビルド/署名の結果のイメージを定義済みのリポジトリーにプッシュします。

apiVersion: kmm.sigs.x-k8s.io/v1beta2
kind: PreflightValidationOCP
metadata:
  name: preflight
spec:
  kernelVersion: 5.14.0-570.19.1.el9_6.x86_64
  dtkImage: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:fe0322730440f1cbe6fffaaa8cac131b56574bec8abe3ec5b462e17557fecb32
  pushBuiltImage: true
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat