docker Pulling fs layer 寄义

执行 docker pull 的时候，终端里会刷出一行行 Pulling fs layer，看起来像是卡住了、或者在下载什么神秘东西。其实这是 Docker 拉取镜像过程中的正常输出，本文把它拆解清楚：fs layer 是什么、为什么刷这么多行、以及为什么第二次拉同一个镜像会飞快。

Docker 镜像不是一整块，是很多层

一个 Docker 镜像由一串只读的层（layer）叠加而成，每一层对应镜像构建过程中的一步动作：

• 装一个软件包（RUN apt install ...）；
• 复制一堆文件（COPY）；
• 改一行配置（RUN echo ... > file）。

这种分层设计带来两个直接好处：

• 共享省空间——十个镜像都基于同一个 base 层，那一份层在磁盘上只存一次，不会存十份；
• 增量拉取快——已存在的层不用重复下载。

Pulling fs layer 到底在干嘛

当你从仓库拉一个镜像，Docker 客户端会向 Registry 请求这个镜像的全部层。每开始下载一层，终端就提示一条 Pulling fs layer——这里的 fs 是 filesystem 的缩写，指的就是这个文件系统层。所以这条信息的意思很简单：Docker 正在抓取构成该镜像的某一段文件系统数据。

随后你会看到更细的输出变化：

输出	含义
Pulling fs layer	开始获取这一层
Downloading	正在传输这一层的数据
Verifying Checksum	校验这一层的完整性
Download complete	这一层下载完
Extracting tar	解压这一层到容器存储
Pull complete	这一层全部完成

所有层都 Pull complete 之后，Docker 把它们叠起来，才形成一个能跑的镜像，此时 docker images 里就能查到。

为什么第二次拉特别快

这就是分层带来的缓存红利。Docker 拉层时会先查本地缓存：

• 本地已有这一层 → 直接命中，不下载，只花零点几秒；
• 本地没有 → 才走网络。

所以同一个镜像第二次拉几乎秒完；更妙的是，新构建一个镜像但只改了最后一层，pull 时前面几百兆的公共层全都命中缓存，真正下载的只有那几 KB 的改动。

缓存也是有限度的：层里的文件内容变了或者构建指令顺序变了，它后面的层就全部失效，得重新传。

排查"卡在 Pulling fs layer"的几种情况

• 一直转圈不动。多半是网络到仓库慢或断了，配好镜像加速源（/etc/docker/daemon.json 里的 registry-mirrors）能明显改善；配完记得 systemctl daemon-reload + systemctl restart docker。
• 报 manifest unknown。镜像名或 tag 写错了，仓库里没这个版本，换正确 tag 重试。
• 报 unauthorized。私有仓库要 docker login 登录，或者镜像路径少了仓库前缀。
• 卡在 Extracting tar。磁盘写满或者存储驱动有问题，df -h 看一下空间。

顺便理解这几条相关命令

docker images      看本地已有哪些镜像（含各层累加后的总大小）
docker rmi 镜像名  删除镜像，层没被别的镜像引用时才会真删
docker system df   看 Docker 占了多大空间，分层共享的情况一目了然

想看一个镜像到底由哪几层构成，docker history 镜像名 可以把它每层的构建命令和体积列出来，配合上面的解释看会很直观。

qidao123.com企服评测-应用市场 编辑提示

本文由齐道123 IT 运维社区整理，解释 Docker 拉取镜像时 Pulling fs layer 输出的含义与分层缓存机制。文中命令请在自有或已授权主机上执行；配置镜像加速源意味着经由第三方地址转发，涉及内部镜像资产时请先做合规评估，谨慎使用来源不明的公共加速器。