2.3. Kernel Module Management (KMM) モジュールのプリフライト検証
KMM モジュールが適用されたクラスターでアップグレードを実行する前に、KMM を使用してインストールされたカーネルモジュールが、クラスターのアップグレード、および場合によってはカーネルのアップグレード後に、ノードにインストールできることを確認する必要があります。プリフライトは、クラスターにロードされたすべての Module を並行して検証しようとします。プリフライトは、ある Module の検証が完了するのを待たずに、別の Module の検証を開始します。
2.3.1. 検証のキックオフ
プリフライト検証は、クラスター内に PreflightValidationOCP リソースを作成することによってトリガーされます。この仕様には、次の 2 つのフィールドが含まれます。
releaseImage- クラスターがアップグレードされる OpenShift Container Platform バージョンのリリースイメージの名前を提供する必須フィールド。
pushBuiltImage-
trueの場合、ビルドおよび署名の検証中に作成されたイメージがリポジトリーにプッシュされます。このフィールドはデフォルトでfalseです。
2.3.2. 検証のライフサイクル
プリフライト検証は、クラスターにロードされたすべてのモジュールの検証を試みます。検証が成功した後、プリフライトは Module リソースでの検証の実行を停止します。モジュールの検証が失敗した場合は、モジュール定義を変更することができ、Preflight は次のループで再度モジュールの検証を試行します。
追加のカーネルにプリフライト検証を実行する場合は、そのカーネル用に別の PreflightValidationOCP リソースを作成する必要があります。すべてのモジュールが検証されたら、PreflightValidationOCP リソースを削除することを推奨します。
2.3.3. 検証のステータス
PreflightValidationOCP リソースは、検証を試行している、または試行したクラスター内の各モジュールのステータスと進行状況を .status.modules リストに報告します。そのリストの要素には次のフィールドが含まれます。
lastTransitionTime-
Moduleリソースのステータスが、別のステータスに移行した最後の時刻。これは、基礎となるステータスが変更されたときになります。不明な場合には、API フィールドが変更された時点を使用することも可能です。 name-
Moduleリソースの名前。 namespace-
Moduleリソースの namespace。 statusReason- ステータスに関する動詞の説明。
verificationStage実行されている検証段階を説明します。
-
image: イメージの存在確認 -
build: ビルドプロセスの検証 -
sign: 署名プロセスの検証
-
verificationStatusモジュール検証のステータス:
-
true: 検証済みです -
false: 検証に失敗しました -
error: 検証プロセス中にエラーが発生しました -
unknown: 検証が開始されていません
-
2.3.4. モジュールごとのプリフライト検証ステージ
プリフライトは、クラスター内に存在するすべての KMM モジュールに次の検証を実行します。
- イメージの検証ステージ
- ビルドの検証ステージ
- 署名の検証ステージ
2.3.4.1. イメージの検証ステージ
イメージの検証は常に、実行されるプリフライト検証の最初のステージです。イメージの検証が成功した場合、その特定のモジュールで他の検証は実行されません。
イメージの検証は、次の 2 つのステージで構成されます。
- イメージの存在とアクセシビリティー。コードは、モジュール内のアップグレードされたカーネル用に定義されたイメージにアクセスし、そのマニフェストを取得しようとします。
-
今後の
modprobeの実行のために、Moduleで定義されたカーネルモジュールが正しいパスに存在することを確認します。この検証が成功した場合は、カーネルモジュールが正しい Linux ヘッダーでコンパイルされた可能性が高いです。正しいパスは<dirname>/lib/modules/<upgraded_kernel>/です。
2.3.4.2. ビルドの検証ステージ
ビルドの検証は、イメージの検証が失敗し、Module にアップグレードされたカーネルに関連する build セクションがある場合のみ、実行されます。ビルドの検証は、ビルドジョブを実行し、それが正常に終了したことを検証しようとします。
次に示すように、depmod を実行する場合は、カーネルバージョンを指定する必要があります。
$ RUN depmod -b /opt ${KERNEL_VERSION}
PushBuiltImage フラグが PreflightValidationOCP カスタムリソース (CR) で定義されている場合は、結果のイメージをリポジトリーにプッシュしようとします。結果のイメージ名は、Module CR の containerImage フィールドの定義から取得されます。
アップグレードされたカーネルに sign セクションが定義されている場合、結果のイメージは Module CR の containerImage フィールドではなく、一時的なイメージ名になります。これは、結果のイメージが Sign フローの製品である必要があるためです。
2.3.4.3. 署名の検証ステージ
署名検証は、イメージ検証が失敗した場合にのみ実行されます。Module リソースにはアップグレードカーネルに関連する sign セクションがあり、Module にアップグレードされたカーネルに関連する build セクションがあった場合は、ビルド検証が正常に終了します。署名検証では、署名ジョブを実行し、それが正常に完了したかどうかを検証します。
PushBuiltImage フラグが PreflightValidationOCP CR で定義されている場合、署名の検証は結果のイメージをレジストリーにプッシュしようとします。結果のイメージは、常に Module の ContainerImage フィールドで定義されたイメージです。入力イメージは、Build ステージの出力、または UnsignedImage フィールドで定義されたイメージのいずれかです。
build セクションが存在する場合、sign セクションの入力イメージは、build セクションの出力イメージになります。したがって、入力イメージを sign セクションで使用できるようにするには、PreflightValidationOCP CR で PushBuiltImage フラグを定義する必要があります。
2.3.5. PreflightValidationOCP リソースの例
このセクションでは、YAML 形式の PreflightValidationOCP リソースの例を示します。
この例では、現在存在するすべてのモジュールを、OpenShift Container Platform リリース 4.11.18 (以下のリリースイメージが指す) に含まれる今後のカーネルバージョンに対して検証します。
quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
.spec.pushBuiltImage が true に設定されているため、KMM はビルド/署名の結果のイメージを定義済みのリポジトリーにプッシュします。
apiVersion: kmm.sigs.x-k8s.io/v1beta2 kind: PreflightValidationOCP metadata: name: preflight spec: releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863 pushBuiltImage: true
