从CentOS迁移到CentOS Stream需要注意哪些问题？

从 CentOS Linux 迁移到 CentOS Stream，本质上是从一个“稳定版下游”（Stable Downstream）转向一个“滚动预览版上游”（Rolling Preview）。这不仅仅是换个名字安装系统，而是底层软件生态、更新策略和安全合规逻辑的根本性转变。

很多老运维或者企业架构师在这个问题上容易踩坑，因为两者的定位完全不同。以下是我在实际迁移和架构设计中总结的几个核心注意事项，按优先级排序：

1. 彻底改变对“稳定性”的认知

这是最关键的一点，也是最大的心理落差来源。

• CentOS Linux (7/8)：是 RHEL（Red Hat Enterprise Linux）的二进制兼容克隆。RHEL 发布后，CentOS 才会同步发布对应的版本。这意味着你在 CentOS 上遇到的 Bug，在 RHEL 上已经修复了；你在 CentOS 上跑得很稳的软件，在 RHEL 生产环境里也是经过严格测试的。它的核心价值是“确定性”。
• CentOS Stream：是 RHEL 的上游开发分支。它在 RHEL 下一个大版本正式发行之前，持续接收最新的代码提交。也就是说，你安装的 Stream 版本，比当前的 RHEL 新版本要新，但比即将发布的 RHEL 下一大版本要旧。它处于“半稳定”状态。

注意问题：
如果你的业务强依赖“绝对稳定”、“不可预测的变化”，比如XX核心交易链路、电信级基础设施，请谨慎迁移。Stream 可能会引入新的内核特性或库版本变更，虽然概率低，但理论上存在引入回归 Bug 的风险。对于大多数互联网应用、Web 服务、容器化平台，这种风险通常是可以接受的，甚至能提前获得新功能。

2. 软件包版本与依赖冲突

由于 Stream 是上游，其默认仓库中的软件包版本通常高于同代号的 RHEL。

• GCC/Python/Node.js 等基础工具链：Stream 可能预装更高版本的编译器或运行时环境。如果你的应用编译脚本硬编码了特定路径或版本假设，可能会出错。
• 第三方 RPM 包兼容性：某些商业软件或闭源驱动（如 NVIDIA GPU 驱动、某些数据库XX）可能只签名认证了特定版本的 RHEL/CentOS。Stream 的内核 ABI（Application Binary Interface）可能与这些驱动不兼容，导致模块加载失败。
  • 解决方案：在迁移前，务必检查你的关键依赖软件官方是否支持 CentOS Stream。如果不确定，建议在测试环境中先进行全量回归测试。

3. 迁移路径的选择：原地升级 vs 全新部署

强烈建议：不要尝试通过 yum update 将 CentOS 7 或 CentOS 8 直接原地升级到 CentOS Stream。

• 技术现实：Red Hat 官方并没有提供从传统 CentOS 到 Stream 的直接在线升级通道。这是因为两者包集合、仓库元数据、甚至部分基础组件（如 systemd 单元文件、SELinux 策略）存在差异。强行操作极易导致系统崩溃或进入不可恢复状态。
• 正确做法：
  1. 全新安装：在新服务器上干净安装 CentOS Stream 9（目前主流是 Stream 9，对应 RHEL 9 系列）。
  2. 数据迁移：使用 rsync、LVM 快照复制、或应用层备份恢复的方式迁移数据和配置。
  3. 配置重构：重新编写 Ansible/Puppet/SaltStack 等自动化配置脚本，确保它们适配 Stream 的环境变量和路径。

例外情况：如果你是从 CentOS 8 迁移，且仅涉及小版本迭代，可参考社区提供的转换工具（convert2rhel），但这依然属于高风险操作，需先在非生产环境验证。

4. 安全补丁与支持周期

• 支持周期对齐：CentOS Stream 的支持周期与对应的 RHEL 大版本保持一致。例如，CentOS Stream 9 将与 RHEL 9 同时结束支持（预计 2032 年左右）。这与之前 CentOS 7 长达 10 年的生命周期类似，但需注意中间的大版本跳跃。
• 安全更新频率：由于 Stream 更贴近上游开发，你可能会更早收到安全补丁，但也可能更早暴露未充分测试的安全漏洞。建议启用自动安全更新，并密切关注 Red Hat Security Advisories。

5. 云厂商镜像与基础设施适配

国内主流云厂商（阿里云、腾讯云、华为云、AWS 中国等）已陆续提供 CentOS Stream 的官方镜像。

• 镜像选择：确保使用云厂商提供的官方定制版 CentOS Stream 镜像，而非自行构建。这些镜像通常预装了必要的云辅助工具（cloud-init, virtio 驱动等），并经过厂商自身的兼容性测试。
• 实例类型兼容性：部分老旧的云服务器实例类型可能对新内核的支持不佳。创建实例时，建议选择较新的硬件规格（如通用型 g6/g7 系列），以确保 virtio 驱动和 NUMA 拓扑被正确识别。

6. 开发者与 CI/CD 环境的适配

• Docker/Kubernetes：K8s 官方对 CentOS Stream 的支持良好，但需注意 cgroup v2 的默认启用情况。RHEL 9 / Stream 9 默认使用 cgroup v2，而旧版 K8s 插件可能需要额外配置才能正常工作。
• 语言运行时：如果使用 Node.js、Python、Java 等，确认其官方预编译二进制包是否支持 Stream 的 glibc 版本。通常没问题，但自定义编译的应用需重新链接。

7. 合规与审计要求

• 等保与行业规范：如果你的系统需要通过等级保护测评或XXXX审计，需确认审计机构是否认可 CentOS Stream 作为合规操作系统。目前多数机构仍倾向于推荐 RHEL 或 Ubuntu LTS，但对 Stream 的认可度正在提高。建议提前与合规团队沟通。
• 开源许可证：CentOS Stream 遵循 GPL v2 等开源协议，无额外商业许可费用，这点与传统 CentOS 一致，无需担心版权陷阱。

总结行动清单

1. 评估业务容忍度：能否接受偶尔因上游代码变更导致的微小不稳定？
2. 放弃原地升级：规划全新部署方案。
3. 全面回归测试：在隔离环境中完整部署 Stream，运行所有自动化测试套件。
4. 检查第三方依赖：重点排查闭源驱动、专有数据库客户端、监控 Agent。
5. 更新自动化脚本：确保 Ansible/Packer/Terraform 模板指向 Stream 镜像。
6. 建立监控基线：新增对内核版本、glibc 版本变化的告警。

最后提醒：CentOS Stream 不是“替代品”，而是“演进方向”。对于追求极致稳定的传统 IT 场景，RHEL 或 Oracle Linux 仍是更稳妥的选择；对于敏捷开发的互联网场景，CentOS Stream 是一个合理且免费的上游试验田。