上周跟几个做基础架构的老朋友喝酒，有个哥们拍桌子说，刚花了三个月把两百多套老系统迁到K8s，本来以为能省点运维成本，结果上周凌晨三点被叫起来——某个业务镜像拉不下来，整个支付链路堵了俩小时。
说白了，他们迁的时候光顾着把程序塞到容器里跑，压根没管镜像那摊子事。容器化迁移中的镜像治理从来不是迁完再做的收尾活，是从打包第一行镜像指令开始就得抠的核心环节。
没人提前算过的镜像隐性成本
很多团队迁容器的时候，第一反应是把原来服务器上跑的环境整个打个包。Java应用带一整个JDK，Python项目把虚拟环境全塞进去，连测试用的SDK都没删。镜像动不动就几个G。
拉镜像慢。
启动慢。
占节点存储。
这些都是明面上的账。真正麻烦的是没人挨个查过镜像里装了啥。有个团队迁完俩月做安全扫描，发现近三成镜像里藏着好几年前的开源组件漏洞，连当年爆出来的Log4j老问题都没补。这时候再回头改？几百个镜像挨个重新打包、测试、发版，光排期就排了俩月。
很多人觉得镜像不就是个压缩包，多大点事。不对。镜像不是给开发本地跑着玩的。你迁到生产环境，几百个业务共用一套镜像仓库，每个镜像的每一层都要占存储、占带宽，每次拉取都要校验哈希。你图省事把所有依赖全打进去，最后平摊到每个节点的资源成本，比你原来在虚拟机上跑还高。
镜像仓库不是存文件的网盘
之前碰到过一个团队，迁移的时候随便找了个开源的镜像仓库搭起来，权限开得特别大。开发随便推镜像，标签乱写，今天推个v1，明天推个v1，后天又把测试版的东西打个latest标签推上去。
线上跑的服务突然崩了。
想回滚？翻了半天仓库，根本找不到对应版本的镜像在哪。
这就是典型的把镜像仓库当网盘用。你存个文件乱命名就算了，生产环境的镜像，每一个标签都要对应确定的代码版本、构建参数、安全扫描结果。没有这些元数据，你迁得再快，最后出了问题连追溯的依据都没有。
说真的，这事我见过不下五次。每次出事团队都拍大腿，说早知道就把标签规则定严点。早知道值几个钱？定个规范半天的事，非要等线上炸了才想起来补。
很多人觉得做镜像治理就要上一堆昂贵的商业平台。其实真没那么玄。你哪怕一开始就把标签规则定死，禁止随便推latest，每次推镜像的时候自动跑一遍漏洞扫描，有高危漏洞的直接拦在仓库外面，能解决八成的问题。
迁移阶段最容易被忽略的取舍
容器化迁移不是把所有系统一次性全塞到K8s里就完事。你做镜像治理的时候，总得做取舍。
比如，要不要把所有基础镜像统一替换成经过安全加固的最小版本？
要做的话，所有业务团队都要重新适配构建脚本，可能要耽误一两周的迁移进度。不做的话，后面跑起来，每个月都要花大量时间处理镜像漏洞告警，节点上的资源也浪费。
我见过最拧巴的团队，为了赶迁移进度，跟业务团队说”先跑起来再说，治理的事后面慢慢补”。结果迁完半年，镜像仓库里堆了上千个没人用的废弃镜像，占了几十T的存储，每次清理都要挨个找业务团队确认，谁也说不清哪个镜像还在用。
这就是代价。
你省了前期一周的适配时间，后面要花几个月甚至半年的时间擦屁股。
镜像治理从来不是运维团队单方面的事。你要求开发构建镜像的时候少装没用的依赖，得给他们提供现成的基础镜像模板，不能光提要求不给工具。你推漏洞扫描的拦截规则，得提前跟业务团队对齐哪些漏洞是可以延后修复的，不能一上来就把所有镜像都拦了，耽误人家发版。
别信那些说”容器化迁移一步到位”的鬼话。你迁的过程中，每打一个镜像，每推一个版本，每做一次权限配置，都是在给后面的运维埋坑或者铺路。
之前有个团队做得特别聪明。迁移一开始就拉了个小群，把开发、测试、运维的人凑到一起，先花了三天时间把基础镜像的模板定好，把镜像标签的规则捋顺，把仓库的权限分好层。后面的迁移速度反而比那些上来就闷头打包的团队快得多。因为大家不用反复改镜像，不用出了问题半夜爬起来找镜像版本，也不用天天补之前挖的漏洞坑。
很多人做容器化迁移，算的都是能省多少虚拟机成本，能提多少部署效率。很少有人算镜像这块的账。
毕竟镜像看不见摸不着。
等你看见的时候，往往就是出大事的时候。