15.4. 每个模块的 preflight 验证阶段

preflight 在集群中的每个 KMM 模块上运行以下验证：

  1. 镜像验证阶段
  2. 构建验证阶段
  3. 签名验证阶段

15.4.1. 镜像验证阶段

镜像验证始终是要执行的 preflight 验证的第一个阶段。如果镜像验证成功，则不会在该特定模块上运行其他验证。

镜像验证由两个阶段组成：

  1. 镜像存在和可访问性。代码会尝试访问为模块中升级的内核定义的镜像，并获取其清单。
  2. 验证在正确的路径中存在模块中定义的内核模块，以备将来 modprobe 执行。正确的路径为 <dirname>/lib/modules/<upgraded_kernel>/。

如果这个验证成功，这可能意味着内核模块是使用正确的 Linux 标头编译的。

15.4.2. 构建验证阶段

只有在镜像验证失败，且在与升级的内核相关的模块 中有一个 build 部分时，才会执行构建验证。构建验证尝试运行构建作业，并验证它是否已成功完成。

注意

在运行 depmod 时必须指定内核版本，如下所示： 

$ RUN depmod -b /opt ${KERNEL_VERSION}

如果在 PreflightValidationOCP 自定义资源(CR) 中定义 PushBuiltImage 标志，它将尝试将生成的镜像推送到其存储库中。生成的镜像名称取自 Module CR 的 containerImage 字段的定义。

注意

如果为升级的内核定义了 sign 部分，则生成的镜像不是 Module CR 的 containerImage 字段，而是临时镜像名称，因为生成的镜像应该是 Sign 流的产品。

15.4.3. 签名验证阶段

只有在镜像验证失败时，才会执行签名验证，模块 中有一个与升级内核相关的 sign 部分，并在与升级的内核相关的模块中存在 build 部分时成功完成构建部分。签名验证将尝试运行签名作业，并验证它是否已成功完成。

如果在 PreflightValidationOCP CR 中定义 PushBuiltImage 标志，则签名验证也将尝试将生成的镜像推送到其 registry。

生成的镜像始终是模块的 containerImage 字段中定义的镜像。输入镜像是 Build 阶段的输出，也可以是 UnsignedImage 字段中定义的镜像。

注意

如果存在 build 部分，则 sign 部分输入镜像是 build 部分的输出镜像。因此，为了使输入镜像可用于 sign 部分，必须在 PreflightValidationOCP CR 中定义 PushBuiltImage 标志。