运维大侃侃：Centos替代后遗症，你可能会踩坑！

引言

随着CentOS逐步停服，RockyLinux、Ubuntu、Anolis等发行版成为企业运维的主流替代选择。然而在实际使用过程中我们通常会忽略一些细节，导致各类“替代后遗症”频发——小到服务异常重启，大到系统访问受限，进而引发生产环境故障。
坑点1：Rocky Linux 9误升级OpenSSL版本！

现象
RockyLinux 9.3安装Git会导致OpenSSL被依赖升级，导致sshd无法启动！

原因
yum安装其他组件，自动update openssl。
临时解决方案
rpm命令将openssl降级到3.0.7，可参考以下命令：
rpm -Uvh –oldpackage openssl-3.0.7-24.el9.x86_64.rpm openssl-libs-3.0.7-24.el9.x86_64.rpm –nodeps
经验

1. yum install看下依赖是否包含openssl包，再-y决定是否安装；
2. yum/dnf versionlock add git ，使用yum/dnf命令锁定特定软件包的版本;
3. 对git安装使用本地源，其他使用外部源；
   坑点2：Ubuntu22连环坑！

现象
Ubuntu apt每日升级和清理活动，因等待超时导致一系列systemd服务重启（包括网卡），进而引起keepalived发生切换告警。
原因
Ubuntu默认定义了4个systemd unit执行更新任务。
apt-daily.timer触发器，默认每天触发两次，分别为6点和18点。
apt-daily-upgrade.timer触发器，默认每天在6点触发一次。
apt-daily.service，oneshot类型服务，负责每日检查系统更新并下载更新包。
apt-daily-upgrade.service，oneshot类型服务，负责安装更新并清理本地缓存的更新包。
解决方案
关闭apt自动升级

停止自动升级服务和定时器

systemctl stop apt-daily.timer
systemctl stop apt-daily-upgrade.timer
systemctl stop apt-daily.service
systemctl stop apt-daily-upgrade.service

关闭自动升级服务和定时器的开机自启

systemctl disable apt-daily.service
systemctl disable apt-daily.timer
systemctl disable apt-daily-upgrade.service
systemctl disable apt-daily-upgrade.timer
坑点3：Anolis8祸起萧墙！

现象
Anolis8 大量访问阿里云镜像源，触发阿里云安全规则封禁返回403。
根因
从日志查询看在无安装操作系统相关组件情况下，然而实际yum元数据更新发起大批量请求，最终确认Anolis8中元数据更新由dnf-makecache.timer定时器、dnf-makecache.service服务控制，开机后10分钟执行，执行完成后1小时+随机延迟1小时，大约在2小时左右每更新一次。
解决方案
停用dnf-makecache.timer和dnf-makecache.service，每次安装时自动执行元数据缓存，此时会比较耗时。
systemctl stop dnf-makecache.service
systemctl disable dnf-makecache.service
systemctl stop dnf-makecache.timer
systemctl disable dnf-makecache.timer
宣导：Ingress Nginx退役!

退役时间线
2026年3月前：维持“最大努力维护”，仅保障基础功能运转。
2026年3月后：全面停止维护，不再发布新版本、修复漏洞及处理安全隐患；GitHub仓库将设为只读模式，仅保留参考功能。
现有部署影响
已部署的Ingress NGINX可继续运行，Helm图表、容器镜像等安装制品仍保持可用，不会因退役直接中断服务。
退役原因
技术债务问题
早期为追求灵活性设计的功能（如通过 “snippets” 注解添加任意NGINX配置指令），随云原生软件安全标准提升，已成为严重安全隐患，且技术债务难以修复。
维护资源匮乏
尽管用户使用率高，但长期仅1-2名维护者利用业余时间开发，人力严重不足；去年维护者曾计划联合Gateway API社区开发替代控制器 “InGate”，但未吸引足够支持，InGate项目也未成熟，最终一同退役。
应对建议
立即启动迁移
官方强烈建议所有用户迁移至替代方案，优先推荐Gateway API（Ingress 的现代替代者）；若需继续使用Ingress，可参考Kubernetes文档中列出的其他 Ingress控制器(https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/，部分云厂商也提供专属替代方案。
检查自身使用情况
拥有集群管理员权限的用户，可通过执行命令kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx，确认是否部署了Ingress NGINX。
总结

CentOS替代之路往往存在很多“暗礁”，这些坑点的本质是缺乏经验积累，因此特地梳理部分坑点与应对方法，能让我们少走弯路，让CentOS替代过程更平稳。