4.9. kmod イメージの作成
Kernel Module Management (KMM) は専用の kmod イメージを使用します。これは .ko ファイルを含む標準 OCI イメージです。.ko ファイルの場所は、<prefix>/lib/modules/[kernel-version]/ というパターンに従っている必要があります。
.ko ファイルを扱うときは、次の点に注意してください。
-
ほとんどの場合、
<prefix>は/optと同じになります。これはModuleCRD のデフォルト値です。 -
kernel-versionは空であってはならず、カーネルモジュールのビルドに使用されたカーネルバージョンと同じである必要があります。
4.9.1. depmod の実行 リンクのコピーリンクがクリップボードにコピーされました!
ビルドプロセスの最後に depmod を実行して、modules.dep ファイルと .map ファイルを生成することを推奨します。これは、kmod イメージに複数のカーネルモジュールが含まれており、モジュールの 1 つが別のモジュールに依存している場合に特に便利です。
kernel-devel パッケージをダウンロードするには、Red Hat Subscription が必要です。
手順
次のコマンドを実行して、特定のカーネルバージョンの
modules.depおよび.mapファイルを生成します。$ depmod -b /opt ${KERNEL_FULL_VERSION}+`.Dockerfile の例
OpenShift Container Platform でイメージをビルドする場合は、Driver Toolkit (DTK) の使用を検討してください。
詳細は、資格のあるビルドの使用 を参照してください。
apiVersion: v1 kind: ConfigMap metadata: name: kmm-ci-dockerfile data: dockerfile: | ARG DTK_AUTO FROM ${DTK_AUTO} as builder ARG KERNEL_FULL_VERSION WORKDIR /usr/src RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"] WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_FULL_VERSION}/build make all FROM registry.redhat.io/ubi9/ubi-minimal ARG KERNEL_FULL_VERSION RUN microdnf install kmod COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ RUN depmod -b /opt ${KERNEL_FULL_VERSION}
4.9.2. クラスターでのビルド リンクのコピーリンクがクリップボードにコピーされました!
KMM はクラスター内に kmod イメージをビルドできます。次のガイドラインに従ってください。
-
カーネルマッピングの build セクションを使用して
build命令を提供します。 -
コンテナーイメージの Dockerfile を、
dockerfileキーの下のConfigMapリソースにコピーします。 -
ConfigMapがModuleと同じ namespace にあることを確認します。
KMM は、containerImage フィールドで指定されたイメージ名が存在するかどうかを確認します。その場合、ビルドはスキップされます。
それ以外の場合、KMM は Build リソースを作成してイメージをビルドします。イメージがビルドされると、KMM はモジュールの調整を Module します。以下の例を参照してください。
# ...
- regexp: '^.+$'
containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
build:
buildArgs:
- name: ARG_NAME
value: <some_value>
secrets:
- name: <some_kubernetes_secret>
baseImageRegistryTLS:
insecure: false
insecureSkipTLSVerify: false
dockerfileConfigMap:
name: <my_kmod_dockerfile>
registryTLS:
insecure: false
insecureSkipTLSVerify: false
- 1
- 任意。
- 2
- 任意。
- 3
/run/secrets/some-kubernetes-secretとしてビルド Pod にマウントされます。- 4
- オプション: このパラメーターは使用しないでください。
trueに設定すると、ビルドはプレーン HTTP を使用して DockerfileFROM命令でイメージをプルできます。 - 5
- オプション: このパラメーターは使用しないでください。
trueに設定すると、プレーン HTTP を使用して DockerfileFROM命令でイメージをプルするときに、ビルドは TLS サーバー証明書の検証をスキップします。 - 6
- 必須。
- 7
- オプション: このパラメーターは使用しないでください。
trueに設定すると、KMM はプレーン HTTP を使用してコンテナーイメージがすでに存在するかどうかを確認できます。 - 8
- オプション: このパラメーターは使用しないでください。
trueに設定すると、コンテナーイメージがすでに存在するかどうかを確認するときに、KMM は TLS サーバー証明書の検証をスキップします。
Operator 設定で job.gcDelay パラメーターが設定されていない限り、成功したビルド Pod にはすぐにガベージコレクションが適用されます。失敗したビルド Pod は常に保存されるため、ビルドを再開するには管理者が手動で削除する必要があります。
4.9.3. Driver Toolkit の使用 リンクのコピーリンクがクリップボードにコピーされました!
Driver Toolkit (DTK) は、ビルド kmod ローダーイメージをビルドするための便利なベースイメージです。これには、クラスターで現在実行されている OpenShift バージョンのツールとライブラリーが含まれています。
手順
マルチステージの Dockerfile の最初のステージとして DTK を使用します。
- カーネルモジュールをビルドします。
-
.koファイルをubi-minimalなどの小さなエンドユーザーイメージにコピーします。 クラスター内ビルドで DTK を利用するには、
DTK_AUTOビルド引数を使用します。この値は、Buildリソースの作成時に KMM によって自動的に設定されます。以下の例を参照してください。ARG DTK_AUTO FROM ${DTK_AUTO} as builder ARG KERNEL_FULL_VERSION WORKDIR /usr/src RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"] WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_FULL_VERSION}/build make all FROM ubi9/ubi-minimal ARG KERNEL_FULL_VERSION RUN microdnf install kmod COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ RUN depmod -b /opt ${KERNEL_FULL_VERSION}