上周在南京机房蹲到一个刚迁移完核心业务的运维团队，整个团队三天没合眼，不是因为业务挂了，是镜像仓库的磁盘写满了。
几百个G的镜像堆在那，一半是测试的时候打了忘删的，一半是同一个服务反复打出来的，连基础系统层都没复用。
没人想过这茬。
大家默认容器化就是把应用打个包丢去K8s，镜像？那不是打包的时候自动生成的东西吗。容器化迁移中的镜像治理，从来都不是迁移完之后才要考虑的事。
别把镜像当一次性安装包
说白了，很多团队对镜像的认知，还停留在当年打jar包、打RPM的阶段。打出来的包只要能跑就行，扔在服务器上没人管。容器时代这逻辑直接撞墙。
镜像的层是共享的，如果你每次打镜像都从ubuntu基础镜像开始装依赖，那哪怕你改了一行代码，拉镜像的时候还是要把几个G的基础层全拉一遍，节点扩容的时候能等到你怀疑人生。
上个月碰过一个做电商的团队，大促前扩容订单服务，12个节点同时拉镜像，仓库带宽直接打满，整个扩容流程卡了四十多分钟，差点错过预热窗口。
他们那会才想起来，自己的镜像里塞了全套的编译工具、测试依赖，连没用到的字体库都没删。
麻烦在于，镜像不是虚拟机的快照，你塞进去的每一寸没用的东西，最后都会变成仓库的存储成本、拉取的带宽成本、节点的磁盘成本。
很多人算迁移成本的时候，只算服务器的钱，从来没算过镜像仓库的钱，算过节点拉镜像的时间成本。有的团队算下来，一年花在镜像仓库上的存储和带宽费用，够给运维团队发半年奖金。
治理不是删镜像 是先理清楚谁在生产镜像
别一上来就搞什么镜像治理平台，先去翻仓库的日志，看看谁在往里面推东西。
我见过最离谱的情况，开发把自己本地调试好的镜像直接推到生产仓库，版本号写的是latest，连个tag都没有。运维早上起来发版，拉到的镜像里还带着开发本地的.ssh文件夹。
这事没那么玄。
你不需要什么复杂的流程，先把推镜像的权限收住就行。
肯定有人跳出来说，我开发要快速迭代，收了权限会不会拖慢效率？那就给测试仓库开宽松权限，生产仓库必须过CI扫描，必须有明确的版本tag，必须走审批。
刚开始肯定有人骂，说以前十分钟能搞定的事现在要走半小时流程。但你要算，一次因为乱推镜像导致的生产故障，损失的是多少个半小时？
很多人说镜像治理就是给镜像瘦身，把没用的层删掉。是，但不全是。
你得先搞清楚，哪些镜像是正在用的，哪些是半年前打了之后从来没拉过的。有的仓库里存了上千个镜像，80%都是历史版本，连对应的代码仓库都已经归档了，占了快几个T的空间。
没人敢删，怕哪次要回滚的时候找不到。那就给这些镜像打个归档标签，挪到冷存储里，平时不占热仓库的带宽和磁盘，真要回滚的时候再拉出来，成本能降七成。
镜像治理的核心不是把所有镜像都管得死死的，是把不同优先级的镜像放到不同的存储层级里。
迁移前的治理 比迁移后的补救省一半钱
很多团队的顺序搞反了。先把业务全迁到K8s，跑了半年，仓库炸了，才想起来要做镜像治理。
那时候你要处理的是已经跑在生产里的几千个镜像，每个都不能随便动，要兼容，要回滚，要做扫描，工作量是迁移前的三倍都不止。
去年碰到一个做金融的客户，一开始觉得镜像治理是小事，迁移的时候直接把虚拟机里的环境全打了镜像，迁完跑了三个月，仓库存了12T的镜像，每个月的存储成本十几万，还要应付合规的漏洞扫描，每个镜像都要扫，扫出来的漏洞要修，要重新打镜像，整个运维团队一半的精力都耗在这上面。
要是迁移前花两周时间，把基础镜像统一做一遍瘦身，把公共依赖抽成公共的基础层，把没用的包全删掉，后面的工作量能少一大半。
说实话，别相信什么“一键治理”的工具。工具是帮你提效的，不是帮你做决策的。你得先搞清楚自己的业务需要什么，哪些镜像要留，哪些要删，哪些要做扫描，哪些可以放到冷存储。
不过话说回来，这事没什么捷径，就是蹲在仓库旁边翻日志，翻个一周，你就知道问题出在哪了。别一上来就买几十万的治理平台，很多时候你写个脚本，把超过半年没拉过的镜像列出来，挨个问对应的负责人要不要留，就能清掉60%的无用镜像。
前几天碰到那个被仓库磁盘搞崩溃的运维团队，他们现在迁移前第一件事，就是先给所有要迁的服务打个镜像，算一下大小，看看有没有可以复用的公共层。上次去他们机房，仓库的磁盘使用率从98%降到了22%，扩容的时候拉镜像的时间从四十分钟降到了两分钟。
没人再把镜像当随便扔的安装包了。