Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

5.3. Kernel Module Management Operator 2.4 发行注记

5.3.1. 新功能及功能增强
复制链接

  • 在这个发行版本中，您现在可以选择配置内核模块管理 (KMM) 模块，使其不加载树外内核驱动程序，并使用 in-tree 驱动程序，并只运行设备插件。如需更多信息，请参阅在设备插件中使用 in-tree 模块。

  • 在本发行版本中，KMM 配置在集群和 KMM Operator 升级和重新部署 KMM 后会保留。

    在早期版本中，集群或 KMM 升级或其他操作，如升级重新部署 KMM 的固件路径等非默认配置，可能会创建需要重新配置 KMM。在这个发行版本中，KMM 配置现在都会保留持久性，无论任何此类操作是什么。

    如需更多信息，请参阅配置内核模块管理 Operator。

  • 改进已添加到 KMM 中，以便 GPU Operator 供应商不需要在其代码中复制 KMM 功能，而是使用 KMM。这个变化大大改进了 Operator 的代码大小、测试和可靠性。
  • 在这个发行版本中，KMM 不再使用 HTTP(S) 直接请求来检查 kmod 镜像是否存在。相反，CRI-O 在内部用来检查镜像。这可减少直接从 HTTP (S)请求访问容器镜像 registry，并手动处理诸如读取 /etc/containers/registries.conf 用于镜像配置的任务、访问 TLS 配置的镜像集群资源、从节点挂载 CA，并在 Hub 和 Spoke 中维护您自己的缓存。
  • KMM 和 KMM-hub Operator 已分配 Red Hat Catalog 中的"Meets 最佳实践"标签。
  • 现在，如果需要，您可以在计算节点上安装 KMM。在以前的版本中，无法在 control-plane 节点上部署工作负载。由于计算节点没有 node-role.kubernetes.io/control-plane 或 node-role.kubernetes.io/master 标签，因此内核模块管理 Operator 可能需要进一步配置。内部代码更改已解决了这个问题。

  • 在本发行版本中，NMC 协调器的 heartbeat 过滤器已更新，以过滤节点上的以下事件：

    • node.spec
    • metadata.labels
    • status.nodeInfo
    • status.conditions[] （仅限NodeReady ）并仍然过滤 heartbeats

5.3.2. 主要的技术变化
复制链接

  • 在本发行版本中，集群中的 preflight 验证资源已被修改。您可以使用 preflight 验证在集群升级和可能的内核升级后验证要在节点上安装内核模块。preflight 验证还会报告它尝试或试图验证的集群中每个模块的状态和进度。如需更多信息，请参阅内核模块管理(KMM)模块的 Preflight 验证。
  • 创建 kmod 镜像时的要求是必须同时包含 .ko 内核模块文件和 cp 二进制文件，这是在镜像加载过程中复制文件所必需的。如需更多信息，请参阅创建 kmod 镜像。
  • 代表 Operator 成熟度等级的 capabilities 字段已从 Basic Install 改为 Seamless upgrade。Basic Install 表示 Operator 没有升级选项。KMM 不是支持无缝升级的情况。

5.3.3. 程序错误修复
复制链接

  • Webhook 部署已从 webhook-server 重命名为 webhook。

    • 原因 ：使用 controller-gen 生成文件生成名为 webhook-service 的服务，该服务不可配置。另外，当使用 Operator Lifecycle Manager (OLM) 部署 KMM 时，OLM 会为名为 -service 的 webhook 部署服务。
    • 结果 ：为同一部署生成了两个服务。由 controller-gen 生成并添加到捆绑包清单中，以及 OLM 创建的其他清单。
    • 修复 ：使 OLM 在集群中查找名为 webhook-service 的现有服务，因为部署名为 webhook。
    • 结果 ： 不再创建第二个服务。

  • 将 imageRepoSecret 对象与 DTK 结合使用会导致 authorization required 错误。

    • 原因 ：在 Kernel Module Management (KMM) Operator 中，当您在 KMM 模块中设置 imageRepoSecret 对象时，构建的生成的容器镜像会被定义为集群内部 registry 中，构建无法推送最终镜像并生成 authorization required 错误。
    • 结果 ：KMM Operator 无法按预期工作。
    • 修复: 当 imageRepoSecret 对象被用户定义的时，它由构建过程用作 pull 和 push secret。要支持使用集群的内部 registry，您必须将该 registry 的授权令牌添加到 imageRepoSecret 对象中。您可以从 KMM 模块命名空间的 "build" 服务帐户获取令牌。
    • 结果 ：KMM Operator 可以正常工作。

  • 创建和删除镜像或创建 MCM 模块不会在 spoke 上加载模块。

    • 原因 ：在 hub 和 spoke 环境中，在 registry 中创建和删除镜像时，或者在创建 ManagedClusterModule (MCM) 时，spoke 集群上的模块不会被加载。
    • 结果 ： 没有创建 spoke 上的模块。
    • 修复: 从 hub 和 spoke 环境中删除缓存软件包和镜像转换。
    • 结果： 在 spoke 上为创建 MCM 对象的第二个时间创建模块。

  • 在进行集群构建时，KMM 无法从私有 registry 中拉取镜像。

    • 原因 ：在进行集群构建时，内核模块管理 (KMM) Operator 无法从私有 registry 中拉取镜像。
    • 结果 ：构建过程中使用的私有 registry 中的镜像无法拉取。
    • 修复: imageRepoSecret 对象配置现在还在构建过程中被使用。指定的 imageRepoSecret 对象必须包含所有正在使用的 registry。
    • 结果：现在，您可以在进行集群构建时使用私有 registry。

  • 当删除带有无法拉取的容器镜像的模块时，KMM worker pod 会孤立。

    • 原因 ：当删除带有无法拉取的容器镜像的模块时，内核模块管理(KMM) Operator worker pod 会孤立。
    • 结果 ： 使 worker pod 保留在集群中，且没有为垃圾收集任何点。
    • 修复: KMM，现在在为垃圾删除模块时收集孤立的故障 pod。
    • 结果：模块被成功删除，所有关联的孤立故障 pod 也会被删除。

  • KMM Operator 会尝试创建 MIC，即使节点选择器不匹配。

    • 原因: 内核模块管理(KMM) Operator 会尝试创建一个 'ModuleImagesConfig'(MIC)资源，即使节点选择器与任何实际节点不匹配且失败。
    • 结果 ：KMM Operator 在协调不以任何节点为目标的模块时报告错误。
    • 修复: MIC 资源中的 Images 字段现在是可选的。
    • 结果： KMM Operator 可以成功创建 MIC 资源，即使其中没有镜像也是如此。

  • 当节点重启序列太快时，KMM 不会重新载入内核模块。

    • 原因: 如果节点重启序列过快，则内核模块管理 (KMM) Operator 不会重新载入内核模块。重启取决于状态条件的时间戳超过 Node Machine Configuration (NMC) 状态的时间戳。
    • 结果：当重启快速发生时，重启的时间比宽限期要短，节点状态不会改变。节点重启后，KMM 不会再次载入内核模块。
    • 修复：依赖条件状态，NMC 依赖于 Status.NodeInfo.BootID 字段。kubelet 根据服务器节点的 /proc/sys/kernel/random/boot_id 文件设置此字段，以便在每次重启后更新该字段。
    • 结果：更准确的时间戳可让内核模块管理(KMM) Operator 在节点重启序列后重新载入内核模块。

  • 过滤节点机器配置(NMC)控制器的节点心跳事件。

    • 原因: NMC 控制器通过来自节点 heartbeat 的事件获取垃圾邮件。节点心跳可让 Kubernetes API 服务器知道该节点仍然已连接并可以正常工作。
    • 结果 ：即使没有模块，垃圾邮件也会造成恒定协调，因此没有 NMC，因此对集群应用任何 NMC。
    • 修复: NMC 控制器现在从其协调循环中过滤节点的 heartbeat。
    • 结果： NMC 控制器只获得实际的事件，并过滤掉节点 heartbeat。

  • NMC 状态包含容限值，即使 NMC.spec 或模块中没有容限。

    • 原因：节点机器配置(NMC)状态包含容限值，即使 NMC.spec 或模块中没有容限。
    • 结果：特定于内核模块管理容限以外的容限可能会出现在状态中。
    • 修复: NMC 状态现在从专用注解而不是从 worker pod 获取容限。
    • 结果：NMC 状态仅包含模块的容限。

  • KMM Operator 版本 2.4 无法正确启动，且无法列出 \modulebuildsignconfigs\ 资源。

    • 原因: 在 Kernel Module Management (KMM) Operator 中，当使用 Red Hat Konflux 安装 Operator 时，它不会正确启动，因为日志文件包含错误。
    • 结果 ：KMM Operator 无法按预期工作。
    • 修复: Cluster Service Version (CSV) 文件已更新，以列出 \modulebuildsignconfigs\ 和 moduleimagesconfig 资源。
    • 结果 ：KMM Operator 可以正常工作。

  • Red Hat Konflux 构建不包括 Operator 日志中的 version 和 git commit ID。

    • 原因：在内核模块管理 (KMM) Operator 上，当 Operator 使用通信平台作为服务 (CPaas) 构建时，构建包含在日志文件中的 Operator 版本和 git 提交 ID。但是，在 Red Hat Konflux 中，这些详细信息不包含在日志文件中。
    • 结果：日志文件中缺少重要信息。
    • 修复 ：在 Konflux 中引入了一些修改来解决这个问题。
    • 结果：KMM Operator 构建现在包含日志文件中的 Operator 版本和 git 提交 ID。

  • KMM Operator 在重启带有污点的节点后不会加载模块。

    • 原因: 如果节点重启序列过快，则内核模块管理 (KMM) Operator 不会重新载入内核模块。重启取决于状态条件的时间戳超过 Node Machine Configuration (NMC) 状态的时间戳。
    • 结果：当重启快速发生时，重启的时间比宽限期要短，节点状态不会改变。节点重启后，KMM 不会再次载入内核模块。
    • 修复：依赖条件状态，NMC 依赖于 Status.NodeInfo.BootID 字段。kubelet 根据服务器节点的 /proc/sys/kernel/random/boot_id 文件设置此字段，以便在每次重启后更新该字段。
    • 结果：更准确的时间戳可让内核模块管理(KMM) Operator 在节点重启序列后重新载入内核模块。

  • 重新部署使用集群构建的模块会失败，并显示 ImagePullBackOff 策略。

    • 原因 ：在 Kernel Module Management (KMM) Operator 中，puller pod 和 worker pod 的镜像拉取策略会有所不同。
    • 结果 ：镜像可以被视为现有的，但实际上并没有考虑它。
    • 修复: 使 pull pod 的镜像拉取策略与 KMM 模块中定义的 pull 策略相同，因为它与 worker Pod 使用的同一策略相同。
    • 结果：MIC 代表镜像的状态，其方式与 worker pod 访问它相同。

  • MIC 控制器在应只创建一个 pull-pods 时创建两个 pull-pods。

    • 原因 ：在内核模块管理(KMM) Operator 中，ModuleImagesConfig (MIC) 控制器可能会为同一镜像创建多个 pull-pods。
    • 结果：资源没有适当或按预期使用。
    • 修复 ： CreateOrPatch MIC API 接收 ImageSpecs 片段，因为通过目标节点创建输入并将其镜像添加到片段中，因此任何重复的 ImageSpecs 现在都会被过滤掉。
    • 结果 ：KMM Operator 可以正常工作。

  • 文档中的 job.dcDelay 示例应指定 0s 而不是 0。

    • 原因: Kernel Module Management (KMM) Operator 默认 job.gcDelay duration 字段为 0s，但文档中被提为 0。
    • 结果：输入自定义值 60 而不是 60s 或 1m 可能会导致错误，因为输入类型错误。
    • 修复: 文档中的 job.gcDelay 字段更新为默认值 0s。
    • 结果：用户不太可能被混淆。

  • 因为缺少 MIC 和 MBSC CRD，KMM Operator Hub 环境无法正常工作。

    • 原因 ：内核模块管理(KMM) Operator hub 环境仅根据 api-hub/ 目录生成自定义资源定义(CRD)文件。因此，这不包含 KMM Operator Hub 环境所需的一些 CRD，如 ModuleImagesConfig (MIC) 资源和受管 Kubernetes Service (MBSC)。
    • 结果 ：KMM Operator hub 环境无法工作，因为它会尝试启动集群中不存在的控制器协调 CRD。
    • 修复: 修复将所有 CRD 文件生成到 config/crd-hub/bases 目录中，但仅将资源应用到实际需要的集群。
    • 结果： KMM Operator hub 环境可以正常工作。

  • 当资源上没有设置最终器时，KMM OperatorHub 环境无法构建。

    • 原因: Kernel Module Management (KMM) Operator 显示一个错误，并显示 ManagedClusterModule 控制器无法构建。这是因为 KMM OperatorHub 环境缺少 ModuleImagesConfig (MIC) 资源终结器和基于角色的访问控制 (RBAC) 权限。
    • 结果 ：KMM OperatorHub 环境无法构建镜像。
    • 修复: RBAC 权限已更新，允许更新 MIC 资源上的终结器，然后创建适当的规则。
    • 结果：KMM OperatorHub 环境构建镜像，而不会与 ManagedClusterModule 控制器出现错误。

  • PreflightValidationOCP 自定义资源，带有 kernelVersion: tesdt 会导致 KMM Operator panic。

    • 原因 ：创建 PreflightValidationOCP 自定义资源 (CR)，其 kernelVersion 标志被设置为 tesdt，从而导致内核模块管理(KMM) Operator 生成 panic 运行时错误。
    • 后果 ：输入无效的内核版本会导致 KMM Operator panic。
    • 修复: webhook - 一个应用程序在发生特定事件时自动向另一个应用程序发送实时数据 - 现在被添加到 PreflightValidationOCP CR 中。
    • 结果： 带有无效内核版本的 PreflightValidationOCP CR 不再应用到集群，因此阻止 Operator 生成 panic 运行时错误。

  • PreFflightValidationOCP 自定义资源带有 kernelVersion 标志，它与其中一个集群不同。

    • 原因 ：创建 PreflightValidationOCP 自定义资源 (CR)，使用与其中一个集群不同的 kernelVersion 标志无法正常工作。
    • 结果 ：内核模块管理(KMM) Operator 无法找到新内核版本的 Driver Toolkit (DTK) 输入镜像。
    • 修复: 您必须使用 PreflightValidationOCP CR，并在 CR 中明确设置 dtkImage 字段。
    • 结果： 使用字段 kernelVersion 和 dtkImage，该功能可以为目标 OpenShift Container Platform 版本构建已安装的模块。

  • KMM Operator 版本 2.4 文档使用 PreflightValidationOCP 信息进行了更新。

    • 原因 ：以前，在创建 PreflightValidationOCP CR 时，您需要提供 release-image。现在，这已更改，您需要设置 kernelVersion 为 dtkImage 字段。
    • 结果 ：文档已过时，需要更新。
    • 修复: 文档使用新的支持详情进行了更新。
    • 结果： KMM preflight 功能如预期进行了记录。

5.3.4. 已知问题
复制链接

  • 当模块为 Unloaded 时，不会显示 ModuleUnloaded 事件。

    • 原因 ：当模块被加载（使用创建 ModuleLoad 事件）或 Unloaded ` (using the create a `ModuleUnloaded 事件）时，事件可能不会出现。当您在快速连续加载和卸载内核模块时会出现这种情况。
    • 结果： ModuleLoad 和 ModuleUnloaded 事件可能不会出现在 OpenShift Container Platform 中。
    • 修复: 引入这个潜在行为的警报机制，并在使用模块时感知。
    • 结果： 尚未可用。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat