容器化部署中，镜像拉取速度往往是被忽视的瓶颈。一个几百兆甚至几个 G 的业务镜像，如果在节点上没有任何缓存，冷启动时要从 Registry 完整下载，内网带宽再快也要等上几十秒到几分钟。而镜像预热和缓存优化正是解决这个问题的两把钥匙：预热让镜像提前到达节点，缓存让重复构建和重复拉取几乎零开销。这篇文章就来把这两个话题掰开揉碎讲清楚。
一、先搞懂镜像分层与缓存命中的底层原理
Docker 镜像并不是一个整体文件，而是由多个只读层叠加而成。Dockerfile 中每一条指令（RUN、COPY、ADD 等）通常都会生成一个新层，容器运行时这些只读层之上再挂一个可写层。这种分层结构带来一个关键特性：如果某一层的构建输入没有变化，这一层就可以直接复用缓存，跳过实际执行。
缓存命中的判断规则值得仔细琢磨。对于 RUN、ENV、EXPOSE 这类指令，Docker 只比较指令文本本身是否一致；而对于 COPY 和 ADD，Docker 会对文件内容计算校验和，只要文件内容变了，缓存就会失效。更关键的一点是：一旦某一层缓存失效，它之后的所有层都会重新构建，哪怕后面的指令和输入完全没变。
这就解释了为什么很多人改了一行业务代码，整个镜像都要重新构建——因为 COPY 源码那层失效了，后面的 RUN pip install 也跟着重来。理解这个失效链路，是后面所有优化手段的基础。
二、Dockerfile 层次重排，最大化利用构建缓存
既然缓存失效会向下传播，那么写 Dockerfile 的核心原则就一条：把变化频率低的内容放前面，变化频率高的放后面。典型的反面教材是把 COPY 源码放在安装依赖之前：
# 反例：源码一变，依赖层缓存全部失效 FROM python:3.11-slim WORKDIR /app COPY . /app RUN pip install -r requirements.txt CMD ["python", "app.py"]
正确做法是先单独拷贝依赖清单，安装完依赖后再拷贝源码。这样只要 requirements.txt 不变，依赖层就永远命中缓存，日常开发中构建速度会有数量级的提升：
# 正例：依赖层与源码层解耦 FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "app.py"]
除了排序，还有几个细节值得注意。一是合并 RUN 指令要适度：合并能减少层数和镜像体积，但会把多个步骤绑成一层，任何一个输入变化都导致整层重建，高频迭代的业务镜像不建议过度合并。二是利用 BuildKit 的 --mount=type=cache 把包管理器的下载缓存挂在持久缓存卷上，即使层本身失效，重新安装依赖时也能走本地缓存：
# syntax=docker/dockerfile:1
FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN --mount=type=cache,target=/root/.cache/go-build \
--mount=type=cache,target=/go/pkg/mod \
go build -o /out/app ./cmd/app
对于 CI 场景，BuildKit 还提供了 --cache-from 和 --cache-to 参数，可以把构建缓存推送到 Registry 或者从 Registry 拉取，实现跨机器、跨流水线的缓存共享。不过要注意 type=registry 模式的缓存镜像与普通业务镜像是两个东西，需要在 CI 环境开启 BuildKit 并开启相应的导出器权限。
三、运行时缓存：节点侧的镜像复用策略
构建缓存解决的是“怎么快速造镜像”，运行时缓存解决的是“怎么快速拿到镜像”。Docker 守护进程在拉取镜像时会对每一层做本地存储，同一节点上第二次启动相同镜像几乎瞬间完成，因为所有层都已经在本地了。真正的痛点在于：新扩容的节点是冷的，上面什么都没有。
针对冷节点，第一步是清理无用镜像时保持克制。Docker 默认没有自动清理策略，磁盘吃紧时很多人习惯性执行 docker system prune，这会把线上正在使用的镜像缓存也一并清掉，下次部署又要全量拉取。建议用 docker image prune -a --filter "until=168h" 这种带过滤条件的方式，只清理长时间未使用的镜像，或者干脆用 --filter "label=keep=false" 按标签精确控制。
第二步是利用镜像仓库的代理缓存。自建 Harbor 时可以配置代理缓存仓库，让它作为上游 Docker Hub 或云厂商 Registry 的透明缓存，节点拉取过一次的镜像会被 Harbor 缓存住，后续拉取不再出公网，既快又省流量。对于多机房场景，在核心机房部署主 Registry，边缘机房部署只读镜像副本，配合定时同步任务，能把跨机房拉取变成同机房拉取。
四、镜像预热：让节点在流量到来之前准备好
缓存是被动复用，预热则是主动推送。核心思路是：在调度器把 Pod 调度到某个节点之前，先想办法让该节点具备所需镜像。最简单的落地方式是 DaemonSet 预热，写一个轻量工具跑在每个节点上，定期或者通过监听 API 获取将要部署的镜像列表，然后调用 crictl pull 提前拉取：
#!/bin/bash
# 从配置中心获取待预热镜像列表并逐个拉取
while read -r image; do
if ! crictl images | grep -q "$image"; then
echo "pulling $image"
crictl pull "$image"
fi
done < /etc/preheater/images.txt
更进一步，可以在 CI 流水线的最后加一个“预热阶段”：镜像推送成功后，主动调用预热服务，对当前灰度或即将发布的节点批量触发预拉取，这样发布时滚动更新的每个新 Pod 都能秒级启动，避免出现拉镜像导致的就绪超时。需要注意的是预热要考虑磁盘水位，预热太多大镜像可能把节点磁盘撑爆，反而把正在运行的容器逼到驱逐状态，所以要配合镜像淘汰策略一起用。
对于大规模集群，还可以引入 Dragonfly 这类 P2P 分发系统。它在节点上部署 Peer 组件，镜像分块在节点间互传，Registry 只需服务少量回源请求，千台规模集群拉取同一个镜像时速度不降反升，这在大促、弹性扩容场景下效果尤其明显。
五、验证效果：量化缓存命中率与预热收益
优化不能只靠感觉，建议建立简单的度量手段。构建侧可以对比 BuildKit 输出的缓存命中日志，命中缓存的指令会标注 CACHED 字样，CI 上记录每次构建的总耗时，观察迭代提交后是否稳定在一个较低水平。运行时侧可以观察 kubelet 暴露的镜像拉取耗时指标，或者在预热工具里记录每次 pull 的耗时和是否命中本地缓存。
一个实用的经验值参考：依赖层缓存优化后的常规业务镜像构建，从原来的五六分钟可以降到一分钟左右；配合节点预热后，滚动更新时单个 Pod 从调度到就绪的时间，通常能从分钟级压缩到十秒以内。如果发现预热后仍然有明显的拉取耗时，多半是预热镜像列表和实际调度节点对不上，这时候要检查预热服务是否拿到了最新的调度信息，或者干脆改为 DaemonSet 全节点预热兜底。
总的来说，镜像预热与缓存优化是一条链路工程：Dockerfile 排序决定构建缓存命中率，Registry 与节点缓存决定拉取速度，预热机制决定冷启动体验。三个环节逐个打通，容器化部署的效率才能真正提上来。
Docker镜像预热Docker缓存机制镜像分层优化修改时间：2026-09-16 21:46:50