容器镜像加速速查手册3步把国外镜像拉取速度拉满附避坑清单【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror这是一份面向国内开发者的镜像加速实操手册基于开源项目 public-image-mirror 编写。无论你是个人开发者还是集群运维都能按查白名单 → 换加速前缀 → 全场景配置的路径在 3 分钟内跑通第一次国外镜像拉取文末还附上 5 个高频翻车点排查清单。深夜等镜像的两个小时你我都懂回想一下上周那个晚上docker pull卡在50KB/s不动进度条像死了一样等了一个小时报EOF重试第三次终于下到一半又断连。你在群里吐槽得到的回复只有一句换个镜像源试试——然后继续踩坑。这不是你的网络问题而是镜像仓库的物理位置问题gcr.io、ghcr.io、registry.k8s.io 这些主流仓库全部架设在国外跨国链路的丢包率和延迟摆在那里速度上不去是常态。而 public-image-mirror 要做的就是把这层跨国链路彻底绕过去。它把这些国外仓库的内容同步到国内节点你只需要在镜像名前加一个前缀拉取速度就能从龟速重试变成跑满带宽。整套操作只有 3 步平均耗时 3 分钟普通场景下提速 20 倍以上。第一层先会用3 步跑通第一次镜像加速第 1 步查白名单确认镜像在服务范围内public-image-mirror 不是全量镜像仓库而是基于白名单机制运作。项目根目录的 allows.txt 维护了 1300 条规则覆盖 docker.io、gcr.io、ghcr.io、registry.k8s.io、quay.io、mcr.microsoft.com 等 10 个主流 Registry。用一条 grep 就能确认你要拉的镜像在不在范围内grep docker.io/bitnami/kafka allows.txt # 输出docker.io/bitnami/*带通配符的规则表示整个组织都被覆盖直接用即可。如果你在脚本里做自动化判断项目还提供了官方校验脚本 hack/verify-allows.sh./hack/verify-allows.sh allows.txt docker.io/bitnami/kafka:3.9.0 echo 允许同步 || echo 不在白名单 # 输出允许同步 一个小技巧拿不准镜像名格式时先用 hack/correct-image.sh 帮你规范化比如./hack/correct-image.sh nginx会输出docker.io/library/nginx:latest保证格式和白名单规则能对上。第 2 步二选一的加速写法10 秒上手确认在范围内之后加速方式就一句话给原始镜像地址加前缀m.daocloud.io/。# 原始镜像 docker.io/bitnami/kafka:3.9.0 # 加速镜像 m.daocloud.io/docker.io/bitnami/kafka:3.9.0如果你觉得前缀太长部分 Registry 还支持域名替换的简写方式# 原始镜像 docker.io/bitnami/kafka:3.9.0 # 加速镜像域名替换 docker.m.daocloud.io/bitnami/kafka:3.9.0两种写法对比如下方案写法示例适用场景推荐度加前缀m.daocloud.io/docker.io/library/nginx单条命令、脚本、k8s yaml 改镜像名强烈推荐换域名docker.m.daocloud.io/library/nginx配置 Docker/Podman 的 registry-mirrors 全量接管按需选用下面是常用 Registry 的域名替换对照速查表建议收藏源站替换为docker.iodocker.m.daocloud.iogcr.iogcr.m.daocloud.ioghcr.ioghcr.m.daocloud.ioregistry.k8s.iok8s.m.daocloud.iok8s.gcr.iok8s-gcr.m.daocloud.ioquay.ioquay.m.daocloud.iomcr.microsoft.commcr.m.daocloud.ionvcr.ionvcr.m.daocloud.iodocker.elastic.coelastic.m.daocloud.ioregistry.ollama.aiollama.m.daocloud.io第 3 步拉取并验证确认拿到了完整镜像以 nginx 为例完整跑一遍docker pull m.daocloud.io/docker.io/library/nginx docker run --rm -d -P m.daocloud.io/docker.io/library/nginx第一次请求某个镜像时会触发后台同步稍等片刻之后同一镜像的所有层都会从国内节点直接分发速度会明显感觉到换了一台机器。到这里你的第一次镜像加速就成功了就这么简单。第二层再懂原理它凭什么这么快用起来简单不代表背后简单。理解了下面三个机制你在排查问题和设计架构时会少走很多弯路。懒加载首次请求才同步命中即直出public-image-mirror 用的是懒加载策略服务端不会提前同步所有镜像而是你第一次请求时它才从源站拉取、校验、落缓存再返回给你。这意味着首次请求可能稍慢但第二次及以后访问同一镜像时全部走国内节点的缓存层速度直接拉满。三把安全锁一致性、时效性、白名单哈希一致所有镜像的 sha256 均与源站保持一致你拉到的每一层都是官方原版不存在第三方篡改或加料的问题。缓存时效缓存内容只保留 30 天过期后需要重新同步Manifest 内存缓存 1 小时Blob 内存缓存 1 分钟。这意味着 tag 更新后最多 1 小时就会同步到新版本。白名单控制通过 allows.txt 的规则通配符如docker.io/bitnami/*、gcr.io/**圈定同步范围新增镜像只需在文件里加一行规则完全不用改代码这也是项目能保持轻量稳定的原因。为什么推荐加前缀而不是换域名换域名写法虽然更短但 README 里明确标注了不推荐。原因在于前缀替换规则是人工配置的每个源站内容都不同如果图省事把非 docker.io 的站点也配到 Docker 的registry-mirrors里镜像解析会出问题。最稳妥的姿势是单条命令用加前缀整机接管只对 docker.io 用docker.m.daocloud.io。第三层进阶调优全场景提速配置清单Docker 镜像加速配置改一行 daemon.json整机接管 Docker 拉取只需在/etc/docker/daemon.json里加一行{ registry-mirrors: [ https://docker.m.daocloud.io ] }然后systemctl restart docker之后所有docker pull不写前缀也会自动走加速。Podman 镜像加速配置原生支持多 RegistryPodman 比 Docker 更灵活可以直接为多个 Registry 配置镜像加速# /etc/containers/registries.conf [[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.io [[registry]] location ghcr.io [[registry.mirror]] location ghcr.m.daocloud.iocontainerd 镜像加速集群节点一次配齐Kubernetes 集群节点用 containerd 时配置hosts.toml或在安装时指定 mirror 即可。安装 kubeadm 时也可以直接替换镜像仓库前缀让所有组件镜像都走加速apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.io dns: imageRepository: k8s.m.daocloud.io/coredns创建 kind 集群同理指定加速镜像即可kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1内网缓存把加速能力搬进自己的机房如果你的团队有大量节点并发拉取还可以部署一层本地缓存。项目文档 docs/local-cache/ 给出了完整的 docker-compose 方案一个 registry 容器把m.daocloud.io作为上游代理内网所有机器只要把镜像名前缀换成你的IP:8888/就能共享一份本地缓存外网依赖降到最低。Ollama DeepSeekAI 模型的镜像加速连大模型生态也没放过。Ollama 容器本身可以走加速源启动DeepSeek 等模型的拉取同样支持前缀替换docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.m.daocloud.io/ollama/ollama docker exec -it ollama ollama run ollama.m.daocloud.io/library/deepseek-r1:1.5b第四层避坑手册5 个高频翻车点排查清单症状原因对策拉取报manifest unknown镜像不在白名单或 30 天缓存已过期先grep确认 allows.txt过期则重新触发一次同步拉到的 tag 内容不是最新用了latest这类可变 tag更新有最多 1 小时延迟优先用sha256:锁镜像其次用明确版本号的 tag高峰期同步特别慢拉取任务太集中队列拥挤把批量的镜像预热放在北京时间凌晨 01-07 点registry-mirrors 配置后解析异常把非 docker.io 的站点配给了 Docker mirror只对 docker.io 使用docker.m.daocloud.io其他站点用加前缀查同步状态发现记录消失同步队列只保留最近 1 小时记录拉取失败时尽快在队列页面确认状态收尾收益量化与下一步把加速前后的体验放在一起看差距非常直观拉取速度从常年100KB/s提升到跑满本地带宽常见 20~50MB/s提速 20 倍以上 ⚡单次部署耗时从2 小时 多次重试压缩到 3 分钟以内重试次数趋近于零成功率跨国链路丢包导致的失败从家常便饭变成基本告别覆盖范围1300 条白名单规则、10 个主流 RegistryKubernetes / OpenShift / Docker / Podman 全平台可用一致性保障所有镜像 sha256 与源站一致不存在版本漂移如果你也想参与白名单共建或者需要离线维护这份规则可以本地克隆一份git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror然后把新镜像规则追加到 allows.txt再用 hack/fmt-image-match.sh 格式化、hack/verify-image-match.sh 校验格式一个干净的白名单 PR 就准备好了。觉得这份速查手册有用的话点赞收藏一下下次配集群时直接翻出来照着抄。下期预告如何基于这套机制搭建你自己的私有镜像同步节点把内网缓存玩出花。备选标题镜像加速终极指南一个前缀解决国外容器镜像下载慢3 分钟上手手把手教你容器镜像加速从 Docker 到 Kubernetes 的全场景配置清单容器镜像加速避坑手册3 步提速 20 倍附 5 个高频报错排查方法【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考