每个 OpenShift 管理员都知道其中的利弊权衡。全新的红帽企业 Linux CoreOS 具备您想要的功能：更强的硬件支持、更新的加密策略以及内核改进。但是，采用它向来就意味着全面采用。硬件认证不会自动迁移。内部验证管道还需要再耗费一个季度。变更咨询委员会要求提供回滚计划，但该升级历来无法实现平稳回滚。
结果就是，团队为了避免操作系统迁移而推迟平台升级，从而错过了他们实际需要的功能。操作系统升级就像是从悬崖上一跃而下，而非沿着缓坡循序渐进。
借助红帽企业 Linux 10，我们将改变这一状况。
为此，我们在红帽 OpenShift 4.22 中引入了红帽企业 Linux CoreOS 10 技术预览版；在未来的红帽 OpenShift 的版本中，集群将能够同时运行不同的红帽企业 Linux CoreOS 流。红帽企业 Linux CoreOS 9 和红帽企业 Linux CoreOS 10 节点可在同一集群中共存，这是一种受支持的过渡运行模式，这样一来，升级带来的干扰程度不会高于升级任何其他红帽 OpenShift 次要版本。迁移将按照您的节奏进行，一次迁移一个 MachineConfigPool。
我们来探讨一下多操作系统流支持对集群的影响、红帽企业 Linux CoreOS 10 目前提供的功能，以及该平台的未来发展方向。
多操作系统流：工作原理
全新推出 OSStreams，这是一项集群级 API 资源，可让 Machine Config Operator 管理同一集群中的多个红帽企业 Linux CoreOS 版本。
如果进行全新安装，系统将默认安装红帽企业 Linux CoreOS 10。如果环境有相关需求，可以按照有文档记录的路径安装红帽企业 Linux CoreOS 9。也许是您的硬件认证与红帽企业 Linux 9 绑定，又或是您的内部验证周期尚未完成对红帽企业 Linux 10 的验证。无论哪种情况，这都是受支持的可选方案，而非临时应对措施。
如果从红帽 OpenShift 4.22 进行升级，您的节点将保留在红帽企业 Linux CoreOS 9 上。升级第 1 天不会强制迁移操作系统。您可以先升级平台，同时保留已经过验证的节点操作系统。当您准备好将节点迁移到红帽企业 Linux CoreOS 10 时，可以按照自己的计划进行迁移。
迁移按照一次一个 MachineConfigPool 的方式进行。创建一个自定义 MachineConfigPool，哪怕只向其中添加一个节点，将其指向红帽企业 Linux CoreOS 10 流，然后验证工作负载。如果一切正常，则继续。如果出现问题，节点将回退。这与 MachineConfigPool 在每次配置更改时所采用的“排空/封锁/重启”循环相同。没有新的回滚机制，也没有新的风险模型。
红帽企业 Linux CoreOS 9 节点将与红帽企业 Linux CoreOS 10 一同继续获得支持。这为您提供了充足的时间，您可以从容迁移到红帽企业 Linux CoreOS 10，而无需被迫在短时间内完成迁移。
操作系统升级变成了迁移。不再像是从悬崖上一跃而下，也无需安排周末割接。升级循序渐进、经过验证、可回滚。
为什么值得迁移到红帽企业 Linux CoreOS 10
红帽企业 Linux CoreOS 10 继承了红帽企业 Linux 10 内核，这意味着为 GPU、NIC、NVMe 和 CXL 设备提供更新的硬件支持。如果您正在运行或计划运行较新的服务器硬件，那红帽企业 Linux CoreOS 10 就是驱动支持率先落地的版本。调度程序和内存管理方面的改进意味着延迟表现更优，并且在内存压力下可以实现更高效的页面回收，这对于高密度、高利用率的节点至关重要。
红帽企业 Linux CoreOS 10 基于红帽企业 Linux 10 的相同基础构建而成，该基础支持密封镜像模式，这项技术使用 Composer 和 fs-verity 实现持续的加密完整性验证。它不局限于启动时验证，每次文件读取都经过加密验证。支持客户控制的签名密钥，构建从固件到文件系统的信任链。它还支持红帽企业 Linux 的后量子密码学技术，企业可在内部开始测试经 NIST 批准的抗量子算法，以此开始保护数据，并为满足未来的监管要求做好准备。
开始规划迁移
红帽企业 Linux CoreOS 10 现已在红帽 OpenShift 4.22 中推出技术预览版。
当您准备好测试红帽企业 Linux CoreOS 10 时：在测试集群上，创建一个包含单个节点的自定义 MachineConfigPool。将其指向红帽企业 Linux CoreOS 10 流。针对该节点运行验证工作负载。这在设计上就是低风险的：一个节点，一个池，完全可回滚。
确认没问题之后：功能正式发布并且对测试结果感到满意后，按池逐个扩展。最后迁移生产关键型工作负载。
如果使用集群内分层：MachineOSConfig 以 MCP 为范围，因此在将池迁移到红帽企业 Linux CoreOS 10 时，务必要确保您的 MachineOSConfig 能够兼容对操作系统版本敏感的构建步骤。在扩大迁移范围之前，先针对红帽企业 Linux CoreOS 9 和红帽企业 Linux CoreOS 10 基础镜像测试您的分层镜像。
延长过渡时间表。红帽企业 Linux CoreOS 9 将继续享有全面支持。当红帽企业 Linux CoreOS 10 带来的价值超过特定环境的验证成本时，您就可以进行迁移。有些团队会第一时间采用，也有团队选择下个季度再行动。两种选择都是可行的。
借助多操作系统流支持，您可以按照自己的节奏灵活地实现操作系统现代化。迁移到红帽企业 Linux CoreOS 10 确实是值得的。是升级平台，还是继续让节点在稳定可靠的环境中运行，您不必再二选一。
升级不再像是从悬崖上一跃而下，而是沿着缓坡循序渐进。 立即开始体验红帽企业 Linux CoreOS 10（已在红帽 OpenShift 4.22 中作为技术预览版推出）
关于作者
Mark joined Red Hat in 2014 and is part of the RHEL and OpenShift product management teams. Before that, he had experience as: a sysadmin, a support tech for multiple Linux distros, a consulting architect and an engineering partnership manager. He loves discussing image-based operating systems, edge scenarios, and container engines. Outside of work, Mark enjoys going to see punk rock and other weird music shows in tiny clubs.
