4.19. 第 0 天到第 2 天 kmod 安装

您可以在第 0 天到第 2 天的操作中，在没有内核模块管理 (KMM) 的情况下安装一些内核模块 (kmods)。这有助于将 kmods 转换为 KMM。

使用以下条件来确定合适的 kmod 安装。

第 0 天

在集群中节点变为 Ready 所需的最基本 kmod。这些类型的 kmod 示例包括：

第 1 天

集群中的节点变为 Ready 不需要的 kmods，但当节点为 Ready 时无法卸载。

此类 kmod 的一个示例是，树外 (OOT) 网络驱动程序，它取代了一个过时的树内驱动程序来充分利用 NIC，NetworkManager 依赖于它。当节点为 Ready 时，因为是 NetworkManager 的依赖项而无法卸载驱动程序。

第 2 天

kmods 可以动态加载到内核或从其中删除，而无需干扰集群基础架构，例如连接性。

这些类型的 kmod 示例包括：

当集群中安装第 0 天 kmod 时，通过 Machine Config Operator (MCO) 和 OpenShift Container Platform 升级应用层不会触发节点升级。

只有在向它添加新的功能时才需要重新编译驱动程序，因为节点的操作系统将保持不变。

当驱动程序允许时，您可以在无需重启的情况下，使用 KMM 管理 kmod 的第 0 天到第 2 天的生命周期。

注意

但如果升级需要重新引导节点（例如，当需要重建 initramfs 文件时）这将无法实现。

使用以下选项之一进行生命周期管理。

在您要升级 kmods 时使用此方法。在这种情况下，将 kmod 视为树内驱动程序，并在集群中创建一个带有 inTreeRemoval 字段的 Module 用来卸载驱动程序的旧版本。

请注意以下将 kmod 视为树状驱动程序的特征：

您可以使用有特定顺序的升级(ordered_upgrade.md) 在集群中创建一个版本化的 Module 来代表没有效果的 kmods，因为 kmods 已被加载。

请注意使用有特定顺序的升级特性：

没有集群停机时间。因为您可以控制升级的过程，以及同时升级的节点数量，所以可以实现在没有停机时间的情况下完成升级。
如果卸载驱动程序会导致丢失与节点的连接，则这个方法将无法正常工作，因为 KMM 创建两个不同的 worker pod，一个用于卸载，另一个用于加载。这些 pod 不会被调度。