4.5. 内核模块部署
内核模块管理 (KMM) 监控集群中的 Node 和 Module 资源，以确定是否应该从节点上载入内核模块。
要有资格获得模块，节点必须包含以下内容：
-
与模块的
.spec.selector字段匹配的标签。 -
与模块的
.spec.moduleLoader.container.kernelMappings字段中某一项匹配的内核版本。 -
如果在模块中配置了排序升级 (
ordered_upgrade.md)，则标签与.spec.moduleLoader.container.version字段匹配。
当 KMM 将节点与在 Module 资源中配置的所需状态协调时，它会在目标节点上创建 worker pod 以运行必要的操作。KMM Operator 监控 pod 的结果并记录信息。Operator 使用此信息在模块成功加载时标记 Node 对象，并在配置后运行设备插件。
worker pod 运行 KMM worker 二进制文件，它执行以下任务：
-
拉取
Module资源中配置的 kmod 镜像。kmod 镜像是包含.ko文件的标准 OCI 镜像。 - 在 pod 文件系统中提取镜像。
-
使用指定的参数运行
modprobe，以执行必要的操作。
4.5.1. 模块自定义资源定义
Module 自定义资源定义 (CRD) 代表可通过 kmod 镜像在所有或选择集群中载入的内核模块。Module 自定义资源 (CR) 指定一个或多个兼容它的内核版本，以及一个节点选择器。
Module 资源的兼容版本列在 .spec.moduleLoader.container.kernelMappings 下。内核映射可以与 literal 版本匹配，也可以使用 regexp 同时匹配其中的许多版本。
Module 资源的协调循环运行以下命令：
-
列出与
.spec.selector匹配的所有节点。 - 构建在这些节点上运行的所有内核版本。
对于每个内核版本：
-
进入
.spec.moduleLoader.container.kernelMappings，并找到适当的容器镜像名称。如果内核映射定义了build或sign，且容器镜像尚不存在，请根据需要运行构建、签名 pod 或两者。 -
创建 worker pod 以拉取上一步中确定的容器镜像并运行
modprobe。 -
如果定义了
.spec.devicePlugin，请使用.spec.devicePlugin.container中指定的配置创建一个设备插件守护进程集。
-
进入
在以下运行
garbage-collect：-
过时的设备插件
DaemonSet不以任何节点为目标。 - 成功构建 pod。
- 成功签名 pod。
-
过时的设备插件
4.5.2. 在内核模块之间设置软依赖项
有些配置要求以特定顺序加载多个内核模块才能正常工作，即使模块不会直接依赖于通过符号相互依赖。它们称为软依赖项。depmod 通常不知道这些依赖项，它们不会出现在它生成的文件中。例如，如果 mod_a 有一个软依赖项 mod_b，modprobe mod_a 不会加载 mod_b。
您可以使用 modulesLoadingOrder 字段在 Module 自定义资源定义(CRD)中声明软依赖项来解决这些情况。
# ...
spec:
moduleLoader:
container:
modprobe:
moduleName: mod_a
dirName: /opt
firmwarePath: /firmware
parameters:
- param=1
modulesLoadingOrder:
- mod_a
- mod_b
在上面的配置中，worker pod 首先会尝试在从 kmod 镜像加载 mod_a 前卸载 in-tree mod_b。当 worker pod 终止并卸载 mod_a 时，mod_b 不会再次加载。
列表中的第一个值（最后加载）必须与 moduleName 等效。
