Nydus容器镜像加速实战：从3GB镜像到十秒级冷启动

上个月我们一套 AI 推理服务的镜像从 3GB 涨到了 5.2GB，新集群冷启动一次要等将近两分钟，一半时间花在 pull 镜像上。后来我把这套镜像切到 Nydus，容器从调度到 Ready 的时间压到了十秒级。Nydus 是目前容器镜像加速领域里相当能打的一套方案，核心思路是"按需加载"：不再把整份镜像拉完再启动，而是边跑边取数据。这篇文章从原理讲到实操，把我接入 Nydus 的完整过程、实测数据和踩坑记录都写出来，给正在为容器启动速度头疼的团队做参考。不管你是只用过 Docker、还没碰过 containerd，还是已经在 K8s 里跑了很久业务，都能在这篇文章里找到对你有用的东西。

1. 先聊聊痛点：容器启动的"卡脖子"环节在哪

在说 Nydus 怎么解决问题之前，我建议先花点时间把"容器启动慢"这件事拆开看清楚。因为很多团队折腾了半天加速方案，其实没有先确认瓶颈到底在哪个环节，最后钱花了、架构复杂了，收益却很有限。

1.1 镜像越来越大，而 OCI 镜像的拉取模型还是"先全量后启动"

传统 OCI 镜像是由一层一层的 tar.gz 组成的。Dockerfile 里的每一个 RUN、COPY、ADD 指令，基本都会生成一个只读层，层和层之间用 overlayfs 或者类似机制堆叠起来。这种设计有它的历史优势：复用、增量构建都方便。但它有一个天生的短板——一个容器要启动，必须先把这个镜像的所有层全部 pull 到本地，再全部解压展开。

打个比方，传统镜像的加载方式就像看视频必须等整部片子缓冲完才能播。现在的业务镜像早就不是几十 MB 的静态页面了：一个 Java 服务带上 fat jar 和中间件基础镜像，动辄 1~2GB；Node.js 项目加上 node_modules、Python 项目带上 site-packages，体积瞬间膨胀；AI 推理镜像更夸张，一个模型权重文件就是几 GB。镜像一大，启动链路就不可避免地变慢。这个慢还不是单点的，它同时吃网络带宽、磁盘 IO 和 CPU 解压开销。

我经常看到团队在集群里遇到这样的场景：新扩容的 Pod 状态一直是 ContainerCreating，底下 containerd 在疯狂拉层。问题是如果你在一个用户访问高峰去扩容，新 Pod 迟迟不就绪，流量全压在老 Pod 上，这就是实打实的稳定性风险。

1.2 冷启动与秒级扩容场景下，慢的不只是网络

很多人的第一反应是"那我提高拉镜像的网速不就行了"。实际上，镜像拉取的耗时是由多个因素叠加出来的。

以一份 3GB 的镜像为例，假设内网带宽很充足，下载本身只要 20 秒，但后续逐层解压、写入磁盘、再交给 overlayfs 做 mount，这个过程也非常耗时。tar.gz 的解压是单线程的、顺序的，解压 3GB 数据在本机上可能就要 30 秒以上。也就是说，就算带宽无限大，传统镜像格式的解压开销也在那里挡着你。

更要命的是冷启动场景。Serverless 平台、CI 跑批、K8s 突发扩容，这些场景下每个节点拿到的镜像都是"冷"的，本地既没有缓存，也没有任何可以复用的数据，必须从零开始 pull。这时候启动耗时的公式基本就是：镜像全量传输时间 + 全量解压时间 + 应用初始化时间。前面两项和镜像大小强相关，几乎没法靠调应用规避。

我见过很多团队为了应对这种问题，靠提前把镜像 push 到各个节点的本地目录、或者疯狂提升节点磁盘性能来缓解，但这都是在和镜像格式本身对抗，治标不治本。要真正解决问题，得从"启动必须拉全量"这个机制上动刀。Nydus 就是冲着这一点来的。

2. Nydus 到底改了镜像格式的什么：Rafs 与按需加载

Nydus 不是一个简单的"下载加速工具"，它直接重构了镜像在磁盘和网络上的组织方式。它背后的核心是一个叫做 Rafs（Registry Acceleration File System）的镜像格式，以及一整套配套的运行时组件。理解了它的格式设计，你就理解了 Nydus 为什么能快。

2.1 一次镜像转换之后，里面是什么结构

把一份普通镜像用 Nydus 的工具链转换之后，镜像内容在 registry 里不再是"一堆 tar.gz 层"，而是变成了两部分：bootstrap 元数据文件和blob 数据块文件。

bootstrap 文件很小，它保存的是完整文件系统的元数据，包括目录结构、文件名、权限、文件大小、以及每个文件的块索引。blob 里装的是真正的内容数据，被切成了一个个大小接近的 chunk（数据块），每个 chunk 有自己的摘要，并且是独立压缩、独立寻址的。这个结构有几个直接的好处：

• 元数据和数据分离：容器启动时，只需要先把很小的 bootstrap 拉下来，就能立刻知道整个文件系统长什么样。不管镜像里的模型文件有 5GB 还是 10GB，bootstrap 可能只有几 MB。
• chunk 可以按需拉取：应用进程读某个文件的哪一段，运行时就去对应的 blob 里取包含那一段的 chunk，不用把整个文件甚至整个镜像都拉下来。
• 天然支持去重：chunk 是内容寻址的。同一个 base 镜像被多个业务镜像复用、同一份代码被打进多个版本镜像时，相同 chunk 在本地只存一份，能省不少磁盘空间。

可以把它理解成把电影从"整段下载后才能看"变成了"边下边播"。但 Nydus 切得比视频流更细，它不是按层、按文件切，而是按文件内部的块切。一个 2GB 的模型文件，可以拆成上万个 chunk，应用读写到哪就加载到哪。

2.2 按需加载的触发链路：FUSE 与读时拉取

Nydus 按需加载的核心机制是 FUSE（Filesystem in Userspace）。容器内的文件系统挂载点背后，是一个用户态的 nydusd 守护进程。整个链路大概是这样的：

1. 容器启动时，containerd 通过 nydus-snapshotter 调用 nydusd，把镜像的 bootstrap 解析出来，挂载成一个 FUSE 文件系统。
2. 应用进程发起 open、read、stat 这类系统调用。
3. VFS 把请求转发给 FUSE，nydusd 收到请求后，先看本地缓存里有没有对应的 chunk。
4. 缓存没命中的话，nydusd 向配置好的后端（registry、对象存储、NAS 等）发起 HTTP 范围请求，只取缺失的那部分数据。
5. 数据拿到后先校验摘要，再写入本地缓存，同时把内容返回给应用进程。

这个过程对应用是透明的。进程根本不感知自己读的文件其实在远端，只觉得"文件系统稍微慢了一点"。而目录列表、文件权限这类纯粹靠元数据的操作，因为 bootstrap 已经在本地了，响应速度跟本地文件系统几乎没区别。

2.3 为什么这套设计比 tar 层解压快

要理解 Nydus 的优势，得对比一下传统镜像读取一个文件时发生了什么。传统方式里，哪怕你只想要 /app/model.bin 中间的 1MB 数据，也得先把包含这个文件的整个 tar.gz 层下载完、解压完，才能在 overlayfs 里拿到文件。这个开销是 O(镜像体积) 的，和你想读多少数据无关。

Nydus 的读取开销则是 O(实际读取数据量) 的。range request 可以精准到某一个 chunk，网络传输、磁盘写入、CPU 解压都只发生在被真正访问的数据上。这种按需分配的特性，让"大镜像"不再等于"慢启动"。

还有一点很关键：传统镜像层是 tar.gz，必须顺序解压，解压过程中没法跳过无关数据；而 Nydus 的 blob 里 chunk 是独立压缩的，nydusd 可以同时发起多个并发 range 请求，把需要的数据并行拉回来。实际效果就是，应用真正访问的"有效数据"在网络上是并行抵达的，延迟自然就下来了。

3. 实操接入：从普通镜像到 Nydus 镜像的完整链路

讲完原理，直接进入正题。下面这部分是我在一套 K8s 集群里把业务镜像切换到 Nydus 的全过程。整个过程涉及三个核心组件：负责把普通镜像转成 Nydus 格式的nydusify、负责在节点上提供 FUSE 挂载的nydusd、以及负责对接 containerd 的nydus-snapshotter。版本以官方 GitHub 发布页的 latest release 为准，我写这篇文章时用的是 0.13 系列。

3.1 环境准备与组件选型

先明确一个前提：Nydus 目前主要跑在 Linux 环境，容器运行时建议使用 containerd。如果你们集群还在用 dockerd，接入会别扭很多，因为 dockerd 对 snapshotter 插件的支持不如 containerd 干净。我的建议是，为了 Nydus 专门把集群迁移到 containerd 不一定值得，但如果你们本来就在 containerd 体系里，接入成本非常低。

节点层面需要确认两件事：内核加载了 fuse 模块，且 /dev/fuse 设备存在。大多数主流发行版默认都有，但如果你用的是精简内核或者容器优化系统，最好提前查一下：

ls -l /dev/fuse cat /proc/filesystems | grep fuse # 如果没有就加载模块 sudo modprobe fuse

接下来安装 nydus-snapshotter。它一般建议以系统服务方式跑在每个节点上，从发布页下载二进制后放到 /usr/local/bin，并创建对应的 systemd service。它本身会负责拉起 nydusd 子进程，所以节点上不需要手动启动 nydusd。

另外，nydusify 是转换工具，只需要在能访问源镜像和目标 registry 的机器上装一个就行，不需要每台节点都装。

3.2 nydusify 镜像转换

转换命令的典型用法是这样：

nydusify convert \ --source docker.io/library/nginx:latest \ --target myregistry.com/library/nginx-nydus:latest \ --backend-type registry \ --backend-config '{"host": "myregistry.com"}'

解释一下关键参数。--source和--target指定转换前后的镜像地址，--backend-type指定 nydusd 运行时从哪拉数据块，通常填registry，意思是从镜像仓库拉取 blob。--backend-config里填仓库地址。如果仓库需要认证，还需要先在你执行命令的机器上配置好 docker login，nydusify 会复用相关凭证。

转换过程会把原镜像的每一层内容重新切块、压缩、生成 bootstrap 和 blob，最后 push 到目标仓库。这里有一个我在实际中反复踩的注意点：转换时一定要指定和原始镜像一致的平台，尤其是多架构镜像。比如：

nydusify convert \ --source docker.io/library/nginx:latest \ --target myregistry.com/library/nginx-nydus:latest \ --platform linux/amd64 \ --backend-type registry \ --backend-config '{"host": "myregistry.com"}'

不指定--platform的话，在某些仓库环境下会拿到错误的架构镜像，转换出来的镜像可能在另一类节点上直接跑不起来。转换完成后，可以用nydusify check命令校验目标镜像的元数据和 chunk 完整性，这一步在接入初期建议每次都跑。

3.3 containerd 挂接 snapshotter 与运行时配置

转换好的 Nydus 镜像要能真正在 containerd 里跑起来，需要把 nydus-snapshotter 挂到 containerd 上。containerd 支持通过 proxy snapshotter 的方式调用外部 snapshotter，在 /etc/containerd/config.toml 里加一段配置：

version = 2 [proxy_plugins] [proxy_plugins.nydus] type = "snapshot" address = "/run/nydus-snapshotter/nydus-snapshotter.sock" [plugins."io.containerd.grpc.v1.cri"] containerd_snapshotter = "nydus"

这里address要和 nydus-snapshotter 启动时监听的 socket 路径保持一致。containerd_snapshotter = "nydus"的意思是让 CRI 默认走 nydus snapshotter。不过我要提醒一句：如果你把默认 snapshotter 全局改成 nydus，那么集群里所有 Pod 的镜像都得是 Nydus 格式，否则普通镜像会被这个 snapshotter 拒绝或者行为异常。

所以我的建议是，生产环境不要急着改全局配置。先保持 containerd 默认的 overlayfs snapshotter，通过给 Pod 打注解的方式，让指定工作负载走 nydus。这样改造风险完全可控，灰度也方便。后面 3.4 会细说。

配置改完后重启 containerd，用ctr手动验证一下 snapshotter 是否通了：

sudo ctr plugins ls | grep nydus sudo ctr images pull myregistry.com/library/nginx-nydus:latest --snapshotter nydus sudo ctr run --snapshotter nydus myregistry.com/library/nginx-nydus:latest test-container

如果容器能起来，说明 snapshotter 链路已经正常。在这个阶段先用 ctr 验证比直接上 K8s 排错要快得多。

3.4 Kubernetes 集群中的接入姿势

K8s 接入 Nydus 有两种常见姿势。第一种是给工作负载加注解：

apiVersion: apps/v1 kind: Deployment metadata: name: nydus-demo spec: template: metadata: annotations: containerd.io/snapshotter: nydus spec: containers: - name: app image: myregistry.com/library/nginx-nydus:latest

这个注解是 containerd CRI 通过 Pod 注解识别 snapshotter 的标准做法，需要 containerd 1.7 或更高版本支持。老版本可能不认这个注解，那时候可以退而求其次，用 RuntimeClass 把工作负载路由到使用 nydus snapshotter 的运行时配置上。

第二种做法是维持 containerd 默认 snapshotter 为 nydus，但只在一个独立的节点池或者独立的集群里启用。这种做法适用于"整个集群所有镜像都切换成 Nydus 格式"的场景，管理上最简单，但要求团队对镜像格式切换有充分的把控力。我个人的偏好是注解方案，因为它可以精细到单个 Deployment，出现问题回滚也快。

还有一点，K8s 集群如果在防火墙后面访问私有仓库，记得保证节点上的 nydusd 有访问 registry 的网络权限。它拉 chunk 是节点直接发起的请求，不走 kubelet 那套镜像拉取凭证机制。私有仓库需要认证时，要把 registry 的认证信息配置到 nydus-snapshotter 的配置里，否则容器一读文件就是权限错误，表现非常隐蔽。

4. 实测对比：一场典型的大镜像冷启动测试

理论说了半天，不如数据来得直接。我把这套方案在我们自己的测试环境里做了几轮对比测试，下面把测试方法和结果都贴出来，方便你照着做一次验证。

4.1 测试环境与镜像样本

测试用的 K8s 节点是 4 核 8GB 的虚拟机，系统盘为 SSD，内网访问私有仓库，仓库和节点之间的带宽约 1Gbps。我特意挑了三类有代表性的镜像：

每个镜像分别准备了普通版本和 Nydus 版本。测试方法是：先清空节点上的所有镜像缓存和 nydusd 本地缓存，保证从"冷"状态开始，然后创建单副本 Deployment，记录从 Pod 创建到 Ready 的总耗时。

4.2 拉取与启动耗时对比

结果如下表。这里的"原始镜像冷启动"走的是默认 overlayfs snapshotter，全程包含 pull + 解压 + 挂载 + 启动应用；"Nydus 冷启动"是只拉 bootstrap 和少量元数据，然后应用边运行边拉数据块；"Nydus 热启动"是本地缓存已有大部分 chunk 的情况。

三组数据对比非常明显。镜像越大，Nydus 的收益越夸张。5.2GB 的 AI 镜像，冷启动从 260 秒降到了 39 秒，节省了 85% 的时间。如果这几天持续有流量在跑，热启动状态下的收益更大，只有 8 秒左右。

4.3 数据的正确解读姿势

这里我要泼一盆冷水：启动时间缩短不等于整体请求性能就一定不受影响。Nydus 做的是把"拉取成本"从启动阶段转移到了运行阶段的前几次文件读取上。所以看 Nydus 的效果不能只盯容器 Ready 时间，还要观测容器就绪后的首次请求链路。

我踩过一个很真实的坑：AI 推理服务启动是快了，但前几个推理请求因为需要现场去仓库拉模型权重文件，单次响应时间涨到了十几秒，直接把客户端超时打爆。这不是 Nydus 有 bug，而是"延迟转移"带来的必然现象。解决办法后面第 5 节会说，核心思路是预热或者合理控制 prefetch 策略。

另外，做对比测试时一定要保证两边都从冷状态出发，否则拿一个已经有本地镜像缓存的"热"环境和 Nydus 冷启动比，数据会严重失真。建议每次测试前清空 containerd 的镜像数据目录，以及 nydusd 的缓存目录，统一口径。

5. 生产环境落地时，我踩过的坑和调优记录

方案本身很成熟，但生产环境从来不缺意外。下面几个坑是我自己踩过的，有些折腾了挺久才定位到原因，写出来希望大家少走弯路。

5.1 FUSE 权限与内核模块的坑

FUSE 依赖 /dev/fuse 设备和内核模块。测试环境一般没问题，但有些云厂商的节点镜像为了安全会禁用一些内核模块，或者 systemd 里对设备访问有限制。如果节点上 /dev/fuse 不存在，nydusd 挂载会直接失败，现象是 Pod 一直 CrashLoopBackOff，报错信息又是底层的 "fuse: device not found" 之类，很容易让人以为是镜像问题。

还有一种情况是 SELinux 或者 AppArmor 策略拦了 nydusd 对某些路径的访问。如果你发现 snapshotter 进程起来了、socket 也在，但容器一挂载就报权限异常，先查节点审计日志，看看是不是被 LSM 策略挡了。处理方式一般是给 nydusd 进程对应的 systemd service 补上合适的 SELinux 规则，或者把缓存目录放到白名单内。

另外一个容易被忽略的点：nydusd 的缓存目录要选对文件系统类型。我一开始图省事把缓存目录放在 tmpfs 上，重启节点缓存全丢不说，内存还差点被打爆。生产环境请把缓存目录放到持久盘上，并且单独规划大小，避免和 containerd 的数据目录抢磁盘。

5.2 冷读延迟与缓存策略调优

这是所有 Nydus 使用者绕不开的话题。按需加载的代价是，容器起来之后第一次访问某些文件时，有一个"网络往返 + 解压"的冷读延迟。对小文件这个延迟可能是几十毫秒，对大块连续读可能非常夸张。

解决思路有两个方向。第一，在业务低峰期做预热，把关键文件先读一遍。Nydus 提供 prefetch 机制，可以在容器启动时预先拉取指定文件或者全量数据。典型配置在 nydusd 的 config 里：

{ "device": { "backend": { "type": "registry", "config": { "host": "myregistry.com" } }, "cache": { "type": "blobcache", "cache_dir": "/var/lib/nydus/cache", "cache_size": 10737418240 } }, "mode": "rafs", "enable_prefetch": true, "prefetch_all": false }

prefetch_all代表容器启动时是否把整个镜像预取完整。如果你追求启动速度的极致，可以开prefetch_all，但这样就退回了"全量拉取"的老路，只是把下载动作从 containerd 换成了 nydusd。对于超大镜像，我的经验是不要全开，而是按业务实际读取路径做定向预热。比如 AI 服务可以写一个 initContainer，容器启动后先 touch 一下模型文件的关键几个区间，把最常访问的 chunk 拉进缓存。

第二个方向是扩大缓存命中率。nydusd 的缓存目录支持设置大小上限，命中率上来了，冷读出现的概率就低了。多副本服务的扩容尽量在已运行过该镜像的节点上调度，依赖 K8s 的节点亲和性，能显著减少冷读。

5.3 和已有容器体系的兼容性问题

Nydus 镜像和普通 OCI 镜像在仓库里是两套不同的 artifacts，dockerd 或者普通 containerd overlayfs snapshotter 是认不了的。如果你的团队还在大量使用 docker CLI 在开发机、CI 里构建和调试镜像，这批 Nydus 镜像对他们来说"不可见"，很容易造成协作混乱。

我的应对方式是建立一套明确的镜像命名规范，比如在 tag 里加-nydus后缀或者在仓库路径里拆一个 nydus 目录，让所有人一眼看出这是专用加速镜像。CI 流水线里也把"普通镜像构建"和"Nydus 镜像转换"做成两个独立阶段，一个失败不会阻断另一个发布流程。

另一个兼容性坑出现在私有仓库。Nydus 的按需拉取依赖 HTTP range 请求，但部分私有仓库实现、尤其是某些旧版本的 Harbor 或者经过特殊网关的仓库，对 range 请求支持不完整，会导致 chunk 下载时偶尔出现 416 错误。遇到这种情况，先检查仓库网关层有没有对 range 请求做拦截，必要时升级仓库服务或者走对象存储后端。

5.4 排查与观测：日志、metrics 与监控

Nydus 这套组件本身可观测性做得不错，前提是你要知道去哪看。nydus-snapshotter 和 nydusd 都有独立的日志，把日志级别调到 debug 能看到每个 chunk 的 fetch 请求和命中情况。

更推荐的是把 nydusd 的 metrics 接进 Prometheus。它能暴露的关键指标包括 chunk 命中率、后端请求延迟、缓存占用、fetch 失败的次数等。我上线后长期盯的一个指标就是 chunk miss 率。如果 miss 率一直在高位，说明业务在频繁读取未被缓存的数据，这时候就需要考虑预热策略或者调度优化。

还有一个排障技巧：用ls -l看 FUSE 挂载点的文件大小永远是对的，因为元数据来自 bootstrap；但du看磁盘占用可能不准，因为内容还没拉下来。遇到"文件能看但不能读"或者"读一半卡住"的问题，优先看 nydusd 日志里的 fetch error，多半是后端仓库访问没通。

6. 什么场景值得上 Nydus，什么场景先观望

Nydus 不是银弹。它在大镜像、冷启动密集的场景下收益巨大，但在某些场景下反而会变成负担。最后这部分我把自己的判断标准写出来，希望你在做技术选型时能少纠结。

6.1 收益最大的几类场景

第一类是 Serverless 和 FaaS 平台。这类平台每个新实例几乎都是冷启动，镜像大小直接决定实例交付时间，Nydus 的按需加载天然适配"秒级扩容"的诉求。

第二类是 AI 推理和模型服务。模型文件动辄几 GB，但推理服务真正启动时只需要加载模型的一小部分，或者至少可以配合预热把加载流程并行化，省掉"先下载完模型再启动"的等待。

第三类是大量使用 CI 跑批的团队。跑批容器每次都在新节点上从零拉镜像，Nydus 能直接把"拉取时间"大幅压缩，特别是频繁发布、镜像迭代快的团队，收益非常稳定。

第四类是镜像体积大、但内部有大量冷数据（很少被访问的文件）的业务。Nydus 能让你不用为这部分永远不读的数据付出启动代价，这是传统镜像做不到的。

6.2 不适合的场景与替代方案思考

如果你的镜像很小，比如 100MB 以内，Nydus 带来的启动加速可能只有几秒，但你需要为此维护一套额外的转换和运维链路，性价比不高。另一个不适合的场景是长生命周期、单副本、很少扩容的普通 Web 服务，这类 Pod 启动一次跑几个月，启动省下的几十秒一次性收益意义有限。

我在生产环境的判断标准其实很简单：先跑一次上面的对比测试，如果冷启动耗时压缩比例不到 50%，就不要引入 Nydus。与其增加一套组件，不如先去解决业务自身启动过慢的问题。

如果你们的核心诉求只是"跨节点分发镜像"，不一定要用 Nydus。Dragonfly 这类 P2P 分发方案针对"大规模扇形分发"做得也很好，甚至 Nydus 和 Dragonfly 可以配合使用：Dragonfly 负责 chunk 的 P2P 传输，Nydus 负责按需加载的格式和运行时。团队如果已经用了 Dragonfly，叠加 Nydus 后加速效果会更明显；如果什么基础都没有，那从 Nydus 单点切入更轻量。

最后再分享一个我自己的习惯：改造完成之后，不要急着把原始镜像删掉。先用新镜像灰度一两个服务，跑完一个发布周期，观察 nydusd 的 chunk miss 率和业务侧的首请求延迟，确认没有异常再逐步铺开。每次发版后我也会持续盯几天指标，再决定要不要调整 prefetch 策略或缓存目录大小。容器启动加速这件事，真正的门槛从来不是装上组件，而是你能不能把这个组件的运行状态看清、管好。