我的服务镜像一路膨胀到三四个 GB、平时不觉得、直到一次大促要紧急扩容,新 Pod 卡在拉镜像上好几分钟才起得来、扩容根本来不及救火,还把节点磁盘塞得告警,排查很久才搞懂我把一堆编译工具、构建缓存、整套基础系统全打进了最终镜像、交付物的体积本身就是一笔我一直没正眼看的成本的深度复盘

这次踩的坑,坑在一个我长期忽视的维度:交付物的"体积/重量"。功能对不对、跑得快不快我天天盯,可"这个镜像有多大"我从来没当回事——直到它在最需要快的时刻,用几分钟的拉取时间狠狠拖了我一把。

故障现场:扩容时新 Pod 卡在拉镜像,半天起不来

我的服务镜像不知不觉就长到了三四个 GB。平时滚动更新慢一点我也没在意,可一次大促流量暴涨、需要紧急扩容时,问题集中爆发:

• 新 Pod 迟迟起不来:扩容时新调度到节点的 Pod,卡在 ContainerCreating / Pulling 状态好几分钟,镜像没拉完容器就起不来,等它终于就绪,高峰都快过去了,扩容根本来不及救火。
• 没缓存的节点更惨:调度到本地没有这个镜像的新节点时,要从镜像仓库完整拉取三四个 GB,网络稍一波动就更慢、甚至拉取超时失败重试。
• 节点磁盘告警:几个大镜像 + 各版本一堆,把节点磁盘吃得告急,触发磁盘压力、甚至驱逐。
• CI 也慢、仓库也胀:每次构建推送都要传这三四个 GB,CI 慢、镜像仓库存储也蹭蹭涨。

"扩容拉镜像卡几分钟、大镜像拖慢一切"——这几条合起来,把矛头指向一个我从没认真算过的东西:镜像的体积。我一直只关心镜像里的程序跑得对不对、快不快,却从没关心过这个镜像本身有多大,以及这个"大"会在分发、启动、存储的每个环节带来多少拖累。我得去搞清楚,我的镜像怎么就胖成了三四个 GB。

第一件事:搞懂镜像里塞满了运行时根本不需要的东西

带着"镜像为什么这么大"去扒我的 Dockerfile,我才看清:我把一大堆只有"构建"时才需要、"运行"时根本用不到的东西,全都打进了最终镜像。一个镜像之所以臃肿,通常是这几类"乘客"堆出来的:

• 臃肿的基础镜像:从一个完整的操作系统镜像(如完整版 ubuntu/centos)起步,带着一整套绝大多数用不上的系统工具和库,光基础层就几百 MB 到上 GB。
• 编译/构建工具链:为了编译代码装的编译器、构建工具、SDK、各种 dev 依赖包——这些是构建时用的,程序运行时根本不需要,却全留在了镜像里。
• 构建中间产物和缓存:源码、依赖下载缓存(如 maven/npm/pip 的缓存)、中间编译产物,统统没清理。
• 层层叠加、删了也还在:Docker 镜像是分层的,在后面的层里 rm 掉前面层装的东西,前面那层的体积依然留在镜像里(只是被覆盖),删了等于没删,反而更大。

关键的认知是:"构建一个程序需要什么"和"运行一个程序需要什么",是两套差别巨大的东西。构建需要编译器、构建工具、源码、全套 dev 依赖;而运行,往往只需要编译产物(或解释器)+ 少量运行时依赖。我犯的错,就是把这两套东西混在了一起、全打进了同一个最终镜像——于是镜像里 90% 的体积,是运行时永远不会用到的构建期"乘客",它们白白让镜像胖了几个 GB,在每次分发、启动时被反复拖着走。我把胖镜像的构成看清楚:

# 我原来的 Dockerfile:构建和运行混在一起, 啥都打进去
FROM ubuntu:22.04                 # 完整系统, 几百 MB 起步
RUN apt-get update && apt-get install -y \
    openjdk-17-jdk maven git ...  # 编译工具链, 运行时根本不用!
COPY . /app                       # 源码全进去
WORKDIR /app
RUN mvn package                   # 构建产生一堆缓存和中间产物, 都留着
CMD ["java", "-jar", "target/app.jar"]
# 结果:基础系统 + JDK + Maven + 源码 + .m2 缓存 + 编译产物 = 三四个 GB
# 而真正运行只需要: 一个 JRE + app.jar(几十 MB)

真相大白:不是我的程序大,而是我把"构建程序需要的一切"和"运行程序需要的一点点"混装在了一个镜像里,让交付物背上了一身运行时毫无用处的赘肉;而这身赘肉,在扩容这种最需要镜像轻快的时刻,变成了致命的拖累。解法的核心,就是把构建和运行分开,让最终镜像只装运行真正需要的东西。

第二件事:正解——多阶段构建 + 精简基础镜像,只把运行所需打进去

根因是"构建期的东西混进了运行镜像",那正解的核心就一句话:用多阶段构建(multi-stage build)把"构建"和"运行"彻底分开——在构建阶段编译,最终镜像只从构建阶段拷贝出产物,再配一个精简的基础镜像。

# === 构建阶段(builder): 带全套编译工具链, 这一阶段的体积不进最终镜像 ===
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline       # 依赖单独一层, 利于缓存
COPY src ./src
RUN mvn package -DskipTests          # 编译, 产出 target/app.jar

# === 运行阶段: 只要一个精简 JRE + 编译产物, 构建工具一概不带 ===
FROM eclipse-temurin:17-jre-alpine   # 精简基础镜像(alpine), 只带 JRE
WORKDIR /app
COPY --from=builder /build/target/app.jar app.jar   # 只拷产物!
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
# 最终镜像 = 精简 JRE + app.jar, 几十到一两百 MB, 而非三四个 GB

这套做法的精髓是几个层次:第一,多阶段构建——builder 阶段那一身编译工具、源码、缓存,统统不会进入最终镜像,最终镜像只通过 COPY --from=builder 把编译产物拿过来。第二,选精简基础镜像——运行阶段用 alpine、slim 或 distroless 这类极小的基础镜像,而不是完整操作系统,基础层从几百 MB 砍到几 MB~几十 MB。第三,层和清理要讲究——把 apt install + 清理 合并在同一个 RUN 里(分开写删了也留痕)、用 .dockerignore 排除不必要的文件、按变化频率排层(不常变的依赖放前面)提高缓存命中。

核心就一条:最终镜像里只放"运行时真正需要的东西",构建期的一切赘肉都挡在构建阶段、绝不带进交付物。镜像瘦下来,拉取、启动、扩容、存储,每个环节都跟着快。

第三件事:同一类"交付物/载体太重,在每个环节都拖后腿"的坑,我后来又撞见好几个

这次踩坑让我对"体积/重量"这个维度彻底敏感了:很多被我们交付、分发、加载的东西,它的"体积"本身就是一笔成本——而且这笔成本不是只付一次,而是在它被传输、加载、存储、启动的每一个环节都要付一遍;东西越重,每个环节越慢。这种坑不止 Docker 镜像:

• 前端打包体积过大:JS bundle 几 MB,用户每次首屏都要下载解析,白屏久、流量费高——该 tree-shaking、按需加载、拆包。
• 依赖装了一大堆没用的:为一个小功能引入一个重量级库,把整个应用/镜像撑大,还拖慢安装和启动。
• API 返回字段过多过大:接口一股脑返回所有字段、嵌套一大坨,每次传输都浪费带宽、客户端解析也慢——该按需返回。
• 日志/数据冗余膨胀:打了一堆无用日志、存了一堆冗余数据,占满磁盘、拖慢检索和备份。
• 启动加载一大堆用不上的东西:启动时初始化、加载了大量当前场景用不到的模块,拖慢冷启动。

它们的内核是同一个:任何要被传输、加载、存储、启动的东西,它的体积都是一笔反复支付的成本——传输时占带宽和时间、加载时占内存和解析、存储时占空间、启动时拖慢就绪;体积越大,这些成本在每个环节都越高,而且往往在最关键的时刻(扩容、首屏、故障恢复)暴露得最狠。我们习惯于只关心"它对不对、它做了什么",却很少主动去问"它有多大、这份大有没有必要"。所以,对任何交付物/载体,都要把"精简体积"当成一项主动的设计目标:只装必要的、剔除无用的赘肉,让它尽可能轻。我把这套判断画成了一张图(见后文)。

第四件事:混装镜像 vs 多阶段精简镜像——一张对照表

这次事故逼我把"构建运行混装"和"多阶段精简"摆成一张表,以后写 Dockerfile 前先对照:

看清这张表,做法就明确了:用多阶段构建把编译工具链挡在构建阶段、最终镜像只 COPY 产物 + 配精简基础镜像(alpine/slim/distroless),让交付物只装运行真正需要的东西。同样一个程序,混装是三四个 GB,精简后可能就几十 MB,差的就是那一身没必要的赘肉。

第五件事:我曾经对镜像体积想当然的几个误区

这场"扩容拉镜像卡死"的事故,把我对镜像体积的一堆想当然照得清清楚楚:

这些误区的根子是同一个:我把注意力全放在了"镜像里的程序"上——它对不对、跑得快不快,却完全没把"镜像这个交付物本身有多大"当成一个值得关心的问题;在我的认知里,体积是个无关紧要的副产物,而不是一笔需要主动管理的成本。正因为"体积"从来不在我的视野里,我才会一路把编译工具、源码、缓存往里塞而毫无察觉,直到它在扩容时用几分钟的拉取时间给我上了一课。只关心交付物"做什么、对不对",而从不关心它"有多大、重不重",把体积当成无所谓的副产物而非一等成本,是这类"太重而处处拖累"问题的共同根源。

第六件事:写 Dockerfile、排查"扩容慢/拉镜像久"时,我现在的自检习惯

现在每当我写 Dockerfile、或排查"扩容拉镜像慢、节点磁盘紧",我都会先盯住"镜像有多大、里面有没有运行时用不上的东西"。先看清臃肿镜像为什么处处拖累:

然后用这张自检图把镜像瘦下来:

配套地,我会用工具量一量镜像到底胖在哪,别凭感觉:

# 1. 看镜像总体积和各版本占用
docker images myapp
# 2. 用 dive 逐层分析每层装了什么、有多少是浪费(wasted space)
dive myapp:latest
# 3. 看最终镜像里有没有不该有的东西(编译器/源码/缓存)
docker run --rm myapp:latest sh -c "which mvn gcc; ls -la /build 2>/dev/null"
#    -> 运行镜像里若还能找到 mvn/gcc/源码, 说明构建期东西漏进来了
# 4. 对比优化前后: 多阶段 + alpine 后再 docker images 看体积降了多少

而 .dockerignore 这个最容易被忽略、却能挡掉一大堆无用文件的东西,我也固定配上:

# .dockerignore: 别把这些没用的东西 COPY 进构建上下文/镜像
.git
target/
node_modules/
*.log
*.md
.idea/
Dockerfile
# 否则 COPY . 会把一大堆开发垃圾也打进去, 既撑大又泄露

这套习惯的精髓,是"分清构建需要 vs 运行需要、多阶段构建只 COPY 产物、用精简基础镜像、合并清理层配 .dockerignore、用 dive 量体积别凭感觉"。它让我从"能跑就行不管多大",变成了"把镜像当成要反复分发的交付物、主动给它减重"——核心始终是:构建一个程序所需要的东西(编译器、构建工具、SDK、源码、全套 dev 依赖、构建缓存)和运行一个程序所需要的东西(编译产物或解释器加少量运行时依赖)是两套差别巨大的东西,如果把它们混在一起全打进同一个最终镜像、再加上从一个完整操作系统镜像起步,镜像就会臃肿到几个 GB、而其中运行时真正用得到的可能只有几十 MB,且 Docker 镜像是分层的在后面的层里删掉前面层装的东西前面那层的体积依然留在镜像里(删了等于没删反而更大);镜像体积过大不是一个无关紧要的副产物而是一笔在分发传输启动存储每个环节都要反复支付的成本——拉取和扩容时要完整传输几个 GB 卡几分钟(在大促扩容或故障恢复这种最需要镜像轻快的时刻暴露得最狠)、占满节点磁盘触发磁盘压力甚至驱逐、CI 构建推送慢镜像仓库存储胀、还因带一堆用不上的工具扩大了攻击面;正解是用多阶段构建 multi-stage build 把构建和运行彻底分开——在 builder 阶段带全套编译工具链编译产出,最终镜像只通过 COPY --from=builder 把编译产物拿过来、那一身编译工具源码缓存统统不进最终镜像,运行阶段用 alpine slim 或 distroless 这类精简基础镜像而非完整操作系统把基础层从几百 MB 砍到几 MB 到几十 MB,并把 apt 安装与清理合并在同一个 RUN 层(分开写删了也留痕)、用 .dockerignore 排除 .git target node_modules 等无用文件、按变化频率排层把不常变的依赖放前面提高缓存命中,用 docker images 和 dive 等工具量一量镜像到底胖在哪而不是凭感觉;更一般地任何要被传输加载存储启动的交付物或载体(Docker 镜像、前端 bundle、依赖、API 响应、日志数据、启动加载的模块)其体积本身就是一笔会在每个环节反复支付的成本、体积越大每个环节越慢且往往在最关键的时刻暴露得最狠,而我们习惯只关心它对不对做了什么却很少主动问它有多大这份大有没有必要,所以要把精简体积当成一项主动的设计目标只装必要的剔除无用的赘肉让交付物尽可能轻。

我立下的几条规矩

这场"扩容拉镜像卡死"的事故,换来了我做容器化时,刻进骨子里的几条铁律:

1. 构建需要的和运行需要的是两套东西,别混装进一个镜像。
2. 用多阶段构建:builder 阶段编译,最终镜像只 COPY 产物。
3. 运行阶段用精简基础镜像(alpine/slim/distroless)。
4. 分层里 rm 删不掉前面层的体积,清理要和安装合并同一 RUN。
5. 配 .dockerignore,别把 .git/源码/缓存/开发垃圾打进去。
6. 用 dive/docker images 量体积,别凭感觉觉得"还行"。
7. 体积是一等成本:交付物越轻,分发启动扩容每环节越快。

附:一段从臃肿到精简的 Dockerfile 对照清单

最后留一段我自己给镜像减重时照着改的 Dockerfile 对照清单:

# ❌ 臃肿:构建运行混装, 完整系统 + 工具链 + 源码 + 缓存 = 几个 GB
# FROM ubuntu:22.04
# RUN apt-get update && apt-get install -y openjdk-17-jdk maven
# COPY . /app
# RUN cd /app && mvn package
# CMD ["java","-jar","/app/target/app.jar"]

# ✅ 精简:多阶段 + alpine 精简基础镜像, 最终只产物 + JRE
# --- 构建阶段(不进最终镜像)---
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline          # 依赖单独一层利于缓存
COPY src ./src
RUN mvn package -DskipTests

# --- 运行阶段(最终镜像)---
FROM eclipse-temurin:17-jre-alpine     # 精简 JRE, 几十 MB
WORKDIR /app
COPY --from=builder /build/target/app.jar app.jar   # 只拷产物
ENTRYPOINT ["java","-jar","app.jar"]

# 验证减重效果与排查残留
docker build -t myapp:slim .
docker images myapp                 # 对比优化前后体积(几 GB -> 几十~一两百 MB)
dive myapp:slim                     # 逐层看 wasted space, 揪出还在浪费的层
# 确认最终镜像里没有构建期残留:
docker run --rm myapp:slim sh -c "which mvn 2>/dev/null || echo '无 mvn 干净'"
# 配 .dockerignore: .git target node_modules *.log 等别打进去

这段清单的核心就一句:多阶段构建把工具链挡在 builder 阶段、最终镜像只 COPY 产物 + 精简基础镜像,再用 dive/docker images 量一量、确认没有构建期残留。把"一锅炖几个 GB"换成"只装运行必需的几十 MB",扩容拉镜像那几分钟的卡顿就一起消失了。

写在最后

回头看,这场由"镜像臃肿到几个 GB"引发的"扩容拉镜像卡死"事故,真正教给我的,远不止"用多阶段构建"这一个技巧。它让我对"我们交付出去的东西,除了'它能做什么'这个我们紧盯的维度,还有一个长期被我们漠视、却同样实打实的维度——'它有多重';而'重',会在它被传输、被加载、被启动的每一程里,默默地、反复地拖慢它",有了一次刻骨的体会。我栽跟头,是因为我把全部注意力都给了"镜像里的程序对不对、跑得快不快",却从来没把"这个镜像本身有多大"当成一个问题;在我的脑子里,体积是构建顺带产出的、无所谓的副产物——能跑就行,大点怕什么;于是我一路把编译器、构建工具、源码、缓存往里塞,镜像在我毫无察觉中胖到了几个 GB;平时它只是让滚动更新慢一点点,我连这点慢都懒得追究;直到大促那天,流量压上来、我急着扩容救火,这个臃肿的镜像却用几分钟的拉取时间把"快速扩容"这件救命的事生生拖垮——我才痛感到,那一身我从没在意的赘肉,会在最要命的时刻,变成压垮骆驼的重量。这让我领悟到一个关于"功能与重量"的深刻认知:我们造的、交付的每一样东西,都同时有两个属性:一是它的"功能"(它能做什么、做得对不对),二是它的"重量/体积"(它有多大、要被搬运多少);我们的注意力天然被"功能"吸引——因为功能是目的、是看得见的价值,而重量是沉默的、隐性的、似乎不影响对错的;可重量从不沉默太久:任何东西只要需要被移动、加载、复制、启动,它的重量就会被反复地支付——传一次付一次、起一次付一次、存一份付一份;功能的价值是一次性兑现的,而重量的代价是随使用次数不断累加的;更残酷的是,重量的代价往往不在平时显形,而在峰值、在紧急、在规模骤增的时刻集中爆发——平时多搬几斤无所谓,千钧一发要冲刺时,这几斤就成了致命的累赘;所以,真正成熟的工程,不只追求"功能完备",还时时为重量负责:主动地问"这东西有多重?这份重量里有多少是必要的、多少是可以卸掉的赘肉?",并把"轻"当成一个和"对"同等重要的、需要主动设计和守护的品质。这给了我一种面对"一切'要交付、要分发、要加载某样东西'之事"时的自觉:每当我产出一个要被反复搬运的东西(镜像、包、bundle、响应、数据),我都会在盯着"它对不对"之余,多问一句"它有多大?这份大有必要吗?我能不能给它减重"——把体积当成一等成本、主动剔除赘肉、让交付物只带运行真正必要的东西;"为重量负责、让交付物尽可能轻",是做好容器化、也是交付一切高效系统的关键。认清构建和运行要分离、多阶段构建+精简基础镜像、体积是一等成本——这,是我用一次"大促扩容时镜像拉了几分钟救火不及"的事故,换来的、关于 DevOps、也关于如何为交付物的重量负责的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次写 Dockerfile 时,把它拆成 builder 和运行两个阶段、把基础镜像换成 alpine,顺手 docker images 看一眼体积降了多少,那我对着那个卡在 Pulling 上迟迟起不来的 Pod 急出的那身汗,就值了。

—— 别看了 · 2026