镜像加速实战把 gcr.io 拉取从 2 小时压到 6 分钟【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror提到容器镜像加速就绕不开 DaoCloud 开源的public-image-mirror项目——它专门解决镜像在境外、下载龟速的国内开发者老大难问题让你通过一条前缀命令就能把 gcr.io、ghcr.io、docker.io 的拉取速度从 50KB/s 提升到带宽打满。这篇文章会带你完整走一遍为什么会慢 → 有哪些方案 → 怎么上手 → 会踩什么坑的闭环全程可复制。一、凌晨 1 点我还在等一个永远拉不完的镜像先讲个真实场景。上个月我给客户搭一套生产集群kubeadm init 需要从registry.k8s.io拉几个控制面组件镜像。下午 4 点开始进度条每一秒跳 50KB旁边同事已经开始订晚饭。2 小时后docker pull直接超时报错——链路断了一切重来。这不是网络不好的问题。registry.k8s.io、gcr.io、quay.io的存储节点都在境外国内请求要走国际出口带宽跨洋链路丢包率随便到 30%。你本地再快也快不过那条海底光缆。问题不在你的机器而在路上。二、慢的根源藏在这张图里先别急着找加速器理解根因才能选对工具。镜像拉取慢主要卡在三个环节跨国路由绕行请求从国内跳到境外边缘节点再回到国内绕了半个地球TLS 握手重HTTPS 建立连接在跨洋链路上往返延迟极高小文件也能卡出大延迟无国内缓存源站没有国内节点每次拉取都是硬跨境。public-image-mirror 的做法是把这三点一起解决它在国内部署同步集群你在境外仓库和目标仓库之间插了一层用懒加载机制在后台替你完成同步与校验这个项目严格定义自己是源仓库的 Mirror所有 hash(sha256) 都与源保持一致不会出现第三方打包改哈希的脏镜像。缓存保留 30 天过期后自动重新同步——详见 README.md。三、三条路摆在面前我为什么选加前缀给国内环境提速常见做法有三种我对比后选了最后一种方案成本适用范围一致性适合谁自建 Harbor 定时同步高要养机器和脚本自管仓库靠自己维护有专职运维的团队daemon.json 配 registry-mirrors低仅 docker.io 的拉取路径与加速器一致只想省事的个人public-image-mirror 前缀替换零配置gcr/ghcr/quay/k8s 等全系sha256 与源一致任何场景核心差异在于registry-mirrors只作用于 Docker Hub 的隐式路径而 gcr.io、quay.io 这种独立仓库它管不着。public-image-mirror 则把两种姿势都给你加前缀推荐docker.io/library/busybox→m.daocloud.io/docker.io/library/busybox域名替换备用gcr.io/xxx→gcr.m.daocloud.io/xxx支持替换的 Registry 列表在 README.md 里覆盖gcr.io、ghcr.io、registry.k8s.io、quay.io、mcr.microsoft.com、nvcr.io、docker.elastic.co等主流源站。白名单本身由根目录的 allows.txt 管理已收录 1300 镜像条目支持*和**通配。四、上手闭环拉取 → 校验 → 使用一条龙老规矩直接上手。假设我要拉一个 nginxdocker pull m.daocloud.io/docker.io/library/nginx:1.27-alpine预期输出速度取决于你的带宽但不再卡在几十 KB1.27-alpine: Pulling from library/nginx Digest: sha256:8f35ac584d7c348e10aab6e17caf91dc7c4d21f40b2352f02ee7e0c8a04d4c1d Status: Downloaded newer image for m.daocloud.io/docker.io/library/nginx:1.27-alpine拉下来先别急着用验证镜像身份是否在白名单内grep ^docker.io/library/nginx$ allows.txt预期输出docker.io/library/nginx想自动化判断这个镜像支持不支持项目在 hack/verify-allows.sh 里给了现成脚本./hack/verify-allows.sh allows.txt docker.io/library/nginx echo 支持同步 || echo 不在白名单最后跑起来验证可用性docker run --rm m.daocloud.io/docker.io/library/busybox echo mirror ok预期输出mirror ok到这里拉取、校验、使用三步闭环完成。整个流程你只需要记住一个动作在原始镜像前加m.daocloud.io/docker.io/。镜像名不规范时还能用 hack/correct-image.sh 帮你自动补全library/前缀和:latesttag。五、避坑清单这 6 条我踩过建议收藏光会命令不够把这几条经验带走能帮你少熬几个夜拉取放闲时凌晨 1 点到 7 点北京时间同步队列最空闲白天高峰非常拥挤建议把批量拉取排到深夜。优先sha256:其次明确 taglatest这种可变 tag 一变旧数据会失效并触发后台重新同步别给自己挖坑。缓存只保留 30 天过期镜像要重新同步长周期 CI 记得提前预热。队列页面只留 1 小时记录同步队列状态页 只保留一小时内的同步记录查不到就先等一会儿。别把非 docker.io 站点配进 registry-mirrors前缀替换才是全仓库的正道混配容易拉错源。tag 更新有延迟Manifest 内存缓存 1 小时源站更新后最多 1 小时才会同步到加速端想立刻验证新版本就多等等。六、从个人提速到团队基建内网缓存与容器运行时一个人快不算快把整个团队的拉取速度提上来才是真的快。项目提供了两条进阶路径。路径 A内网缓存代理。用 Docker Compose 起一个本地 registry配置proxy.remoteurl: https://m.daocloud.io团队所有机器统一指向它热门镜像只从外网拉一次。完整配置见 docs/local-cache/README.md。路径 B容器运行时加速。Kubernetes 节点改 containerd 配置给docker.io、gcr.io都挂上加速端点kubeadm 集群则直接在初始化配置里把imageRepository换成k8s.m.daocloud.io控制面组件镜像全部走加速通道。这份配置清单和 Podman、Ollama 的加速方法同样收录在 README.md 的最佳实践章节。值得一提项目还能顺手加速 Ollama 模型拉取ollama.m.daocloud.io正处于实验内测阶段跑大模型镜像时同样适用前缀替换的思路。七、尾声下一个要加速的是你自己的镜像吗关于容器镜像加速我最后想说工具再强也代替不了先判断、再加速的思考习惯。public-image-mirror 采用 Apache 2.0 协议开源见 LICENSE白名单机制让贡献变得非常轻量——你在根目录 allows.txt 里发现缺了某个镜像提个 Issue 或 PR 就能让全社区受益。好了现在轮到你把文章里那条docker pull m.daocloud.io/...命令复制到你的终端看看今天到底能不能告别50KB/s 的深夜如果你还知道哪些好用的镜像加速姿势欢迎在评论区分享我们下期聊聊如何自己搭一个私有同步节点。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考