4.9. 创建 kmod 镜像
内核模块管理 (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 镜像包含多个内核模块，并且其中一个模块依赖于另一个模块，则这特别有用。
您必须有一个红帽订阅才能下载 kernel-devel 软件包。
流程
运行以下命令，为特定内核版本生成
modules.dep和.map文件：$ depmod -b /opt ${KERNEL_FULL_VERSION}+`.
4.9.1.1. Dockerfile 示例
如果要在 OpenShift Container Platform 上构建镜像，请考虑使用 Driver Tool Kit (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部分提供构建说明。 -
将容器镜像的
Dockerfile复制到dockerfile键下的ConfigMap资源中。 -
确保
ConfigMap位于与Module相同的命名空间中。
KMM 检查 containerImage 字段中指定的镜像名称是否存在。如果存在，则会跳过构建。
否则，KMM 创建一个 Build 资源来构建您的镜像。构建镜像后，KMM 继续进行 Module 协调。请参见以下示例。
# ...
- regexp: '^.+$'
containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
build:
buildArgs: 1
- name: ARG_NAME
value: <some_value>
secrets: 2
- name: <some_kubernetes_secret> 3
baseImageRegistryTLS:
insecure: false 4
insecureSkipTLSVerify: false 5
dockerfileConfigMap: 6
name: <my_kmod_dockerfile>
registryTLS:
insecure: false 7
insecureSkipTLSVerify: false 8- 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 服务器证书验证。
成功构建 pod 会立即收集垃圾回收，除非 Operator 配置中设置了 job.gcDelay 参数。失败的构建 pod 始终会被保留，且必须由管理员手动删除，才能重启构建。
4.9.3. 使用 Driver Toolkit
Driver Toolkit (DTK) 是一个便捷的基础镜像，用于构建构建 kmod loader 镜像。它包含集群中当前运行的 OpenShift 版本的工具和库。
流程
使用 DTK 作为多阶段 Dockerfile 的第一个阶段。
- 构建内核模块。
-
将
.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}
其他资源
