拉取时间：扩容和故障恢复的隐藏瓶颈

一、拉取时间：扩容和故障恢复的隐藏瓶颈

节点首次拉取镜像的耗时，大致等于镜像层大小除以有效带宽，再加上解压和写入磁盘的时间。我们做过一次对比：一个 1.2GB 的 Spring Boot 镜像，在跨可用区、实际带宽约 100MB/s 的链路上，从开始拉取到容器 Ready 花了 30 秒左右；换成 180MB 的 eclipse-temurin:17-jre 加分层 jar 之后，同样的链路降到 6 秒以内。当 HPA 把副本从 3 个扩到 30 个时，多个节点并发拉取还会互相争抢带宽，这个差距会被进一步放大，表现为扩容迟迟不 Ready、滚动更新卡在 ContainerCreating。

实操上，docker image ls 看到的总大小只是起点，真正有用的是 docker history 或 dive 里每层的大小。原则是把变动最频繁的应用层放在最后，基础依赖层前置。这样一来，节点上已缓存底层，发布新版本时实际只需要拉末尾几十 MB。

二、仓库存储与出网流量：账单上直接看得见的数字

镜像瘦身最容易被低估的收益在 registry 侧。假设每个服务每次发布打一个新 tag、单镜像 1GB、保留 100 个历史版本，那就是 100GB；二十个服务就是 2TB 的仓库存储，加上每次跨区拉取的出网流量，成本每月都在增长。瘦到 200MB 之后，同样的保留策略下这部分直接降到原来的五分之一。

• 保留策略要配合瘦身一起做：按 tag 数量加时间双维度清理，不要只留最新一个，回滚会因此失去退路。
• 节点侧用 crictl rmi --prune 或 kubelet 的 imageGCHighThresholdPercent 控制本地镜像占用，我们遇到过 50GB 数据盘被旧镜像占满、触发 DiskPressure 驱逐业务 Pod 的情况。
• 大镜像还会拖慢镜像同步：多集群分发时，一次全量同步从小时级压到分钟级。

三、安全面：CVE 数量和扫描噪音一起下降

镜像里每一个多余的包都是潜在的 CVE 来源。同一个 Go 服务，基础镜像从 ubuntu:20.04 换成 distroless 之后，Trivy 扫出的 HIGH/CRITICAL 从两百多个降到个位数，扫描报告终于有人愿意看了。更关键的是攻击面：容器里没有 bash、没有 curl、没有包管理器，即使应用被拿到执行权限，横向操作的成本也高得多。

代价是排障变难。我们的做法是保留一个带 shell 的 debug tag，不用于生产，需要时用 kubectl debug --image=registry/app:debug 临时挂载到目标 Pod 的进程命名空间里查看。另外注意，瘦身不能顺手把 ca-certificates 和 tzdata 删掉，我们确实踩过 HTTPS 握手失败和日志时间差 8 小时的坑。

四、构建与分发：CI 时间和缓存命中率同步改善

瘦身过程往往顺带把 Dockerfile 结构改对了。多阶段构建里，先在 build 阶段装依赖编译，最终阶段只 COPY --from=builder 产物；Go 项目先拷 go.mod go.sum 跑 go mod download，再拷源码，依赖层就能长期命中缓存。BuildKit 下还可以用 --mount=type=cache,target=/root/.cache/go-build 保留编译缓存，一次全量构建从 4 分钟压到 40 秒左右。

一个常见误区：清理必须和安装写在同一个 RUN 里。apt-get install 之后再单独一层 rm -rf /var/lib/apt/lists/*，镜像不会小，因为上一层的数据仍然在，只是被标记删除了。

五、别走过头：瘦身的边界

最后提醒几个反例。Alpine 的 musl 对部分 glibc 预编译二进制、DNS 解析行为（ndots 与 musl resolver）都有兼容问题，JDK、Node 原生模块尤其容易出问题，换成 debian-slim 往往更省事。剥离调试符号后 core dump 无法回溯，建议只对无状态、日志充分的边缘服务这么做。多架构镜像也要注意 --platform 一致性，否则瘦身带来的启动收益会被 arm 节点上的 qemu 模拟抵消掉。