搜索

2.3. preflight 验证内核模块管理 (KMM) 模块

download PDF

在应用 KMM 模块的集群中执行升级前,您需要在集群升级和可能的内核升级后验证使用 KMM 安装的内核模块是否可以在节点上安装。preflight 会尝试并行验证集群中载入的每个模块。在启动一个模块的验证前,preflight 并不会等待一个模块的验证过程完成。

2.3.1. 启动验证

preflight 验证通过在集群中创建 PreflightValidationOCP 资源来触发。此 spec 包含两个字段:

releaseImage
必需的字段,为集群升级到的 OpenShift Container Platform 版本提供发行镜像名称。
pushBuiltImage
如果为 true,则构建期间创建的镜像和签名验证将被推送到其存储库。此字段默认为 false

2.3.2. 验证生命周期

preflight 验证会尝试验证集群中载入的每个模块。在验证成功后,preflight 会停止在 Module 资源上运行验证。如果模块验证失败,您可以更改模块定义,并在下一个循环中再次验证模块。

如果要为附加内核运行 Preflight 验证,则应该为该内核创建另一个 PreflightValidationOCP 资源。验证所有模块后,建议删除 PreflightValidationOCP 资源。

2.3.3. 验证状态

PreflightValidationOCP 资源报告集群中尝试或试图在 .status.modules 列表中验证的每个模块的状态和进度。该列表的元素包含以下字段:

lastTransitionTime
Module 资源状态从一个状态转换到另一个状态最后一次的时间。这应该是底层状态改变的时间。如果为未知,则使用 API 字段更改的时间是可以接受的。
name
Module 资源的名称。
namespace
Module 资源的命名空间。
statusReason
有关状态的动词说明。
verificationStage

描述正在执行的验证阶段:

  • image: 镜像存在验证
  • build: 构建进程验证
  • sign: 签发进程验证
verificationStatus

模块验证的状态:

  • true :已验证
  • false :验证失败
  • error: 验证过程错误
  • unknown: 验证尚未启动

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

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

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

2.3.4.1. 镜像验证阶段

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

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

  1. 镜像存在和可访问性。代码会尝试访问为模块中升级的内核定义的镜像,并获取其清单。
  2. 验证在正确的路径中存在模块中定义的内核模块,以备将来 modprobe 执行。如果这个验证成功,这可能意味着内核模块是使用正确的 Linux 标头编译的。正确的路径为 <dirname>/lib/modules/<upgraded_kernel>/

2.3.4.2. 构建验证阶段

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

注意

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

$ RUN depmod -b /opt ${KERNEL_VERSION}

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

注意

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

2.3.4.3. 签名验证阶段

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

如果在 PreflightValidationOCP CR 中定义 PushBuiltImage 标志,则签名验证也将尝试将生成的镜像推送到其 registry。生成的镜像始终是 ModuleContainerImage 字段中定义的镜像。输入镜像是 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 会将生成的 Build/Sign 镜像推送到定义的存储库中。

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
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.