云原生采用不可变基础设施的根本原因是降低故障概率、加速发布、简化排查。其核心在于用镜像替换替代配置修改，杜绝状态漂移、不可追溯和回滚失效；需固定包版本、启用滚动更新限流、外挂配置；监控日志须适配实例短命特性。
云原生强调不可变基础设施，根本原因不是为了追求“技术洁癖”，而是因为可变服务器在持续交付场景下会系统性放大故障概率、拖慢发布节奏、并让问题排查变成考古现场。
为什么改配置比换镜像更容易出事？
运维人员 SSH 登进生产节点执行 sed -i 改配置、yum install 装补丁、甚至手动 systemctl restart 服务，这些操作看似快捷，实则埋下三类隐患：
- 状态漂移：同一份部署脚本在不同时间运行，因环境残留（临时文件、旧进程、未清理的 crontab）导致结果不一致
- 不可追溯：没有版本锚点，无法回答“这个节点当前运行的是哪次 CI 构建的产物？”
- 回滚失效：紧急回退时发现旧版配置已被覆盖，或依赖的二进制文件被升级覆盖，只能靠备份恢复——而备份往往过期或缺失
而用新镜像替换旧实例，等于把“变更”压缩成一个原子动作：构建 → 推送 → 拉取 → 启动 → 切流 → 销毁。中间任何环节失败，都不污染线上状态。
Docker 镜像 + Kubernetes Deployment 是最轻量的落地组合
不需要重写整套流程，只需守住两个关键控制点：
-
Dockerfile中禁止使用RUN apt-get update && apt-get install -y xxx这类非确定性指令；应固定包版本，如apt-get install -y curl=7.68.0-1ubuntu2.20 - Kubernetes 的
Deployment必须设置spec.strategy.type: RollingUpdate并启用maxSurge/maxUnavailable限流，避免滚动更新期间因新旧镜像不兼容引发雪崩 - 所有配置通过
ConfigMap或Secret挂载，禁止在镜像内硬编码或启动时动态拉取远程配置（这等于偷偷引入可变性）
这样做的效果是：哪怕开发提交了错误的代码，只要镜像没推到仓库，集群里就永远不会运行它；一旦推送，所有环境都运行完全一致的副本。
监控和日志必须适配“实例短命”特性
传统基于主机名或 IP 的监控告警会失效，因为 Pod IP 每次重建都变，Node 也可能被自动替换。正确做法是：
- 指标打标必须包含
pod_name、namespace、deployment、container_image等维度，而不是instance - 日志采集工具（如 Fluent Bit）要配置
label_selector，按app.kubernetes.io/name等标签聚合，而非依赖文件路径或主机名 - 不要在容器内写本地日志文件再定时
rsync到中心存储——容器销毁后日志就丢了；必须走 stdout/stderr 直采
否则你会遇到：报警显示 “某 Pod CPU 100%”，但进去一看 Pod 已销毁，连进程栈都看不到。
真正难的不是技术实现，而是组织习惯——当运维不再有“登录服务器救火”的权限，开发也不再能“先上线再改配置”，所有人就必须把验证左移到构建阶段。镜像构建失败、健康检查超时、滚动更新卡住……这些本该在 CI 流水线里暴露的问题，一旦放行到生产，代价就是不可逆的状态污染。
