一、镜像回滚概述
1.1 什么是镜像回滚
镜像回滚，说白了就是把容器镜像从当前版本退回到上一个稳定版本。
我经常跟团队说，回滚不是认输，是给自己留条后路。你想想看，线上跑着跑着出问题了，最快速的办法是什么？不是现场修，而是先切回老版本，让业务先恢复。
从技术角度看，镜像回滚就是修改镜像的 tag 引用。比如从 myapp:v2.3.1 切回 myapp:v2.3.0。Kubernetes 里执行一条 kubectl rollout undo，底层就是改了 Deployment 的镜像地址。
核心要点：回滚不是删除新版本，而是让流量重新指向旧版本。
1.2 为什么需要回滚保护
这个问题我问过不少新人。他们的第一反应是：「回滚不就是改个版本号吗？」
嗯，理论上没错。但实际生产中，裸回滚会带来三个大坑：
- 数据兼容性问题——新版本改了数据库 schema，回滚后老代码不认识新字段
- 依赖链断裂——微服务架构里，A 服务回滚了，B 服务还在新版本，接口对不上
- 回滚本身也可能失败——镜像拉不下来、配置不匹配、启动脚本报错
我在项目中遇到过最惨的一次：回滚时没检查数据库迁移脚本，结果老版本启动后疯狂报错，最后只能手动修数据。那次之后，我坚持所有回滚操作必须走保护机制。
警告：没有保护的回滚，本质上是一次新的上线操作。风险一点没少。
1.3 回滚的常见场景
我总结了一下，回滚需求主要来自三类场景：
| 场景 | 典型表现 | 回滚优先级 |
|---|---|---|
| 发布失败 | 新版本启动后进程崩溃、接口 5xx、内存泄漏 | P0 立即回滚 |
| 配置错误 | 环境变量写错、挂载路径不对、密钥失效 | P1 尽快回滚 |
| 安全漏洞 | 镜像里带了 CVE 漏洞、依赖包被投毒 | P0 强制回滚 |
发布失败
这是最常见的。我记得有一次，团队凌晨上线新版本，结果容器启动后 30 秒就 OOM 了。监控告警响成一片。当时我直接执行了回滚命令，30 秒内业务恢复。
为什么会这样？新版本加了缓存模块，但没做内存限制。这种问题在预发环境很难发现，因为流量不够大。
配置错误
配置错误比代码 bug 更隐蔽。代码编译不过你马上能发现，但配置错了可能运行几小时才暴露。
我曾经踩过一个坑：新版本的日志采集配置写错了路径，结果线上跑了 8 小时，所有日志都丢了。回滚后还得手动补日志，那叫一个痛苦。
安全漏洞
安全漏洞的回滚最特殊。它往往不是功能问题，而是合规问题。
举个例子：镜像里用的 base image 爆出了 Log4j 漏洞。这时候不管新版本功能多好，都必须回滚到打了补丁的旧版本。安全团队会直接下发强制回滚指令，没有商量余地。
个人建议：每个镜像都保留最近 3 个版本的 tag，别只留 latest。安全漏洞回滚时，你很可能需要回退到更早的版本。
1.4 回滚保护的核心逻辑
说了这么多，回滚保护到底保护什么？我画了一张图来说明：
从这张图能看出来，回滚保护不是简单地把版本切回去。它中间多了一层检查：数据兼容吗？依赖链完整吗？配置能复用吗？
只有这些检查都通过了，回滚才是安全的。否则，就要阻断回滚，让运维人员人工介入。
一句话总结：回滚保护 = 健康检查 + 兼容性验证 + 安全回退。三者缺一不可。
1.5 我的经验总结
做了这么多年容器化，我总结了几条回滚的硬道理：
- 回滚不是银弹——它只是止损手段，不是修复方案。回滚后该修的 bug 还得修
- 回滚速度决定故障时长——自动化回滚能在 1 分钟内完成，手动回滚可能要 10 分钟
- 回滚保护不是过度设计——我见过太多因为裸回滚导致二次故障的案例
避坑指南：我曾经在回滚时忘记检查 ConfigMap 的版本。新版本的配置格式变了，回滚后老代码解析不了。从那以后，我把配置版本和镜像版本绑定在一起管理。
好了，这一章我们聊了镜像回滚的基本概念。下一章我会深入讲回滚保护机制的具体实现，包括怎么设计健康检查、怎么做兼容性验证。这些都是在生产环境里摸爬滚打总结出来的经验。
可可精品资料库