2026年4月实测：我把公司K8s集群的Docker镜像拉取速度提升了20倍

上周公司新上了一批AI训练节点，拉PyTorch镜像差点把整个下午搭进去。实测了5种方案后，最终用了一个大多数人没注意到的加速方案，分享给大家。

起因：一次翻车的K8s集群部署

上周三，公司要给AI训练环境扩容，新加了一批GPU节点。按照流程，K8s集群初始化需要拉取几十个基础镜像——PyTorch、CUDA、NVIDIA Runtime、Prometheus、Grafana……

第一台节点拉了一个多小时才完成，其中有3个大镜像反复超时重试。按照这个速度，8台节点全部初始化完估计要到第二天了。

更尴尬的是，CI/CD流水线也受影响。每次构建都要重新拉镜像，构建时间从之前的3分钟飙升到20多分钟。开发群里开始有人抱怨"流水线又卡了"。

我意识到问题出在镜像拉取上，开始系统性地排查和优化。

2026年4月，境内Docker镜像拉取到底有多难？

我先测了直连Docker Hub的速度：

time docker pull pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel
# 直连结果：3.8GB，耗时约32分钟，平均速度约2MB/s
# 中途出现2次超时重试

这个速度对于8台节点×30+个镜像的集群部署来说，完全不可接受。

然后我去找目前还能用的境内镜像源。之前收藏夹里的地址，逐一测试：

结论很残酷：收藏夹里的老面孔基本都不行了。现在4月份还在更新的镜像加速文章，评论区里大家也都在问"这个还能用多久"。

实测3种加速方案

方案一：多源轮换配置

在daemon.json里配置多个源，Docker会自动尝试下一个：

{
   
  "registry-mirrors": [
    "https://源A",
    "https://源B",
    "https://源C"
  ]
}

结果：理论上行得通，但实际上目前可用的源太少了，轮换意义不大。而且某个源响应慢但没挂的时候，Docker会等它超时才切换下一个，反而更慢。

方案二：离线导入（save/load）

在有网的机器上先拉好，然后：

docker save pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel | gzip > pytorch.tar.gz
scp pytorch.tar.gz user@target-machine:/tmp/
docker load < pytorch.tar.gz

结果：适合一次性部署，但不适合日常使用。每次有新版本都要手动操作，维护成本太高。

方案三：第三方加速服务 docker.1ms.run

最后试了一个之前没怎么关注的方案——docker.1ms.run。配置很简单：

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<'EOF'
{
  "registry-mirrors": ["https://docker.1ms.run"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

实测速度对比：

# 同一台机器，同一个镜像
# 直连 Docker Hub
time docker pull pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel
# 结果：3.8GB，32分钟，平均2MB/s

# 通过 docker.1ms.run 加速
time docker pull pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel
# 结果：3.8GB，1分48秒，平均35MB/s

速度提升约18倍。 同样的镜像，从32分钟缩短到不到2分钟。

再测几个常用的：

最让我惊喜的是pytorch/pytorch:latest——直连直接超时失败了，但走加速通道4分钟就搞定了。

K8s集群部署加速配置

确认方案可行后，我在所有K8s节点上统一配置了加速。Containerd的配置如下：

sudo vi /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
  endpoint = ["https://docker.1ms.run"]

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
  endpoint = ["https://gcr.1ms.run"]

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."ghcr.io"]
  endpoint = ["https://ghcr.1ms.run"]

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"]
  endpoint = ["https://quay.1ms.run"]

sudo systemctl restart containerd

配置完之后，重新部署集群：

部署时间对比：

• 8台节点 × 30+镜像，直连预计需要8-10小时
• 配置加速后，实际用时 47分钟
• CI/CD构建时间从20分钟降回到 3分半

这个优化效果比我预期的好很多。

一键部署脚本

如果要批量部署多台机器，可以直接用一键脚本：

sudo bash -c "$(curl -sSL https://n3.ink/helper)"

脚本会自动检测Docker/containerd环境，修改配置并重启服务。我用它给8台节点统一配置，一条命令搞定。

关于费用

这个方案的基础服务是免费的，个人开发者日常使用完全够。对于我这种公司场景，大量拉取大镜像，付费套餐也不贵

镜像搜索

顺便提一下，它的镜像搜索功能也挺好用。直接访问 1ms.run 就能搜，比去Docker Hub网页端搜快多了（国内直连Docker Hub网页也经常超时）。

总结

说实话，2026年了还在为Docker镜像拉取速度头疼，挺无奈的。但既然短期内改变不了网络环境，找到一个稳定高效的加速方案就是最务实的做法。

我这次的经验总结：

1. 收藏夹里的老镜像源基本都挂了，别再浪费时间一个个试
2. 自建代理成本高、不稳定，除非你有高带宽海外服务器
3. 选一个靠谱的加速服务配好就行，把时间花在业务上
4. K8s/CI/CD场景一定要配加速，集群部署时间差距巨大

配置速查：

希望这篇文章能帮到正在被镜像拉取速度折磨的朋友。如果你有更好的方案，欢迎评论区交流。