容器镜像加速终极指南gcr.io 卡到 0 进度时3 条命令让下载提速 20 倍【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror周五下午四点半我盯着终端里kubeadm init的输出发呆——进度条在拉取registry.k8s.io的镜像时彻底停住30 分钟只走了 3%。这不是网络抖动是国内访问海外容器镜像仓库的日常。如果你也在被 gcr.io、ghcr.io 这些海外源的下载速度折磨这篇关于 public-image-mirror 容器镜像加速的实战记录能帮你把下载时间从小时级压到分钟级全程不写一行代码。一次把 kubeadm init 卡到怀疑人生的周五那天我本来只想干一件小事给新集群补装一个网络插件。结果kubeadm init走到拉取控制面镜像那一步就再也不动了。我做了所有标准动作换了节点、清了 DNS、ping 了源站、甚至挂了代理。结论很统一——不是配置问题是网络问题。registry.k8s.io、gcr.io、ghcr.io这些托管在境外的镜像仓库从国内直连基本等于随缘下载。同事告诉我他上周拉一个kube-apiserver镜像等了三个小时最后是用 U 盘从别人电脑里拷贝的。我当时的第一反应是这不合理这不是 2024 年该有的体验。三组数字把慢这件事说清楚了在下结论之前我先用自己的网络做了个简单测试结果触目惊心观测指标实测结果我的感受境外仓库平均下载速度30~80 KB/s一个 120MB 的层要半小时跨国链路丢包率约 20%~30%下载一半就断反复重试一次kubeadm init需要的镜像数6 个起步每个上百 MB全部拉完 一下午把账算明白之后紧迫感就上来了如果你要部署的不是一个测试集群而是一个周五晚上必须上线的生产服务呢项目延期、团队加班、凌晨三点还在盯进度条——这些场景都是同一个根因镜像在国内没有一条快车道。我为什么敢把依赖交给一个第一次请求才同步的镜像站转机出现在我翻到这个项目的 README 时。开头第一句只有一行字很多镜像都在国外国内下载很慢需要加速。朴实但正中要害。public-image-mirror 不是把全世界镜像预先拷一遍那流量是天文数字而是用了一套懒加载的思路你请求什么它才去源站同步什么。第一次拉取时触发同步队列之后所有请求直接命中缓存。更重要的是它保证所有 hash(sha256) 都和源站完全一致——它不重新构建镜像只是做了一个站在源站门口的快递柜。为什么这个设计让我放心哈希一致性既然 sha256 与源站逐一对应就不存在第三方镜像和官方版本对不上的问题生产环境敢用。白名单与限流透明哪些镜像可以同步、限流规则如何都是公开信息。项目里的allows.txt维护着 1300 余条白名单规则覆盖 docker.io、gcr.io、ghcr.io、quay.io、registry.k8s.io 等主流仓库。新增镜像不用改代码想支持一个新镜像往白名单里加一行即可。配合hack/目录下的脚本白名单的格式校验、去重、归一化都能自动化。用一句话验证这个判断我先拿hack/verify-allows.sh查了registry.k8s.io/coredns/coredns返回 0在白名单内。好那就动手。5 分钟跑通一次 gcr.io 镜像加速拉取的完整步骤下面这套流程我建议你直接照着敲每一步的预期输出我都标注了。第一步确认目标镜像在白名单内先 clone 仓库如果你想自己维护白名单或跑校验脚本git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror用脚本检查镜像是否受支持./hack/verify-allows.sh allows.txt registry.k8s.io/coredns/coredns echo $?预期输出0echo $?输出0表示命中白名单可以放心走下一步输出1说明不在支持列表要么换镜像要么去提 issue 申请加白。第二步用加前缀或域名替换写出加速地址项目提供两种写法我推荐第一种写法原始地址加速地址适用场景加前缀推荐gcr.io/distroless/static:nonrootm.daocloud.io/gcr.io/distroless/static:nonroot所有仓库通用域名替换gcr.io/distroless/static:nonrootgcr.m.daocloud.io/distroless/static:nonroot需要整体替换镜像源如果你用域名替换法目前支持 11 个常用源站速查表如下源站替换为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第三步拉取并验证结果docker pull m.daocloud.io/gcr.io/distroless/static:nonroot预期输出的解读如果这个镜像此前已被别人请求过你会看到各层瞬间 Download 完成速度接近本地。如果你是第一个吃螃蟹的人第一层会慢一些——那是懒加载在后台向源站同步几秒到几十秒后恢复高速。拉完后建议验证一下镜像确实可用docker run --rm --entrypoint m.daocloud.io/gcr.io/distroless/static:nonroot /whoami能正常输出说明镜像完整、可执行。到这里一次 gcr.io 镜像加速拉取就完成了。生产环境与团队协作的三种镜像加速玩法单条命令拉镜像只是入门。真正体现价值的是把它融入你的基础设施下面三个玩法覆盖了最常见的场景。玩法一Kubernetes 集群一键换源kubeadm kind如果你用 kubeadm 初始化集群直接把imageRepository指向加速源控制面组件全部走缓存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如果团队里已经有一套现成的 YAML 和 Helm Chart不想逐个改镜像名还可以用 README 里提到的 repimage它通过 Webhook 自动改写所有新建 Pod 的 image 指向镜像站一行kubectl create部署完之后所有工作负载自动受益。玩法二Docker 与 Podman 的全局镜像加速配置Docker 用户改/etc/docker/daemon.json重启后所有docker pull自动走加速{ registry-mirrors: [https://docker.m.daocloud.io] }Podman 用户改/etc/containers/registries.conf并且它比 Docker 更灵活——可以为多个海外源分别配置镜像[[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.io玩法三在内网部署一层私有缓存给整个团队提速如果你的团队有几十台开发机同时拉同一个镜像每次各自触发一次同步既不划算也慢。项目自带的内网缓存方案见docs/local-cache/README.md可以解决这个问题用官方 registry 镜像包一层 proxy把m.daocloud.io的公共缓存搬进内网。services: registry: image: m.daocloud.io/docker.io/library/registry:3 restart: unless-stopped ports: - 8888:8888 command: - /etc/docker/registry/config.yml volumes: - cache-data:/var/lib/registry configs: - source: registry-config target: /etc/docker/registry/config.yml configs: registry-config: content: | version: 0.1 storage: delete: enabled: true filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}启动后内网拉镜像的地址变成内网IP:8888/docker.io/library/nginx。第一台机器触发同步之后的机器全部命中本地缓存TTL 设了 2160 小时90 天基本一劳永逸。彩蛋如果你在跑 OllamaREADME 还提供了 DeepSeek 的加速玩法ollama.m.daocloud.io/library/deepseek-r1:1.5b可以直接在容器里拉起模型服务。我在镜像加速路上踩过的 5 个坑坑踩多了就变成了经验。下面这 5 个是新手最容易栽进去的地方。坑 1把latest当成版本号用❌ 错误做法docker pull m.daocloud.io/docker.io/library/nginx:latest然后发现拉下来的镜像和文档对不上。 ✅ 正确做法优先用sha256:固定摘要其次用明确版本号 tag最后才考虑latest。 原因manifest 内存缓存 1 小时可变 tag 更新后要过 1 小时才会同步新内容期间你拿到的是旧数据。坑 2把非 docker.io 的加速域名塞进 docker 的 registry-mirrors❌ 错误做法daemon.json里写registry-mirrors: [https://gcr.m.daocloud.io]。 ✅ 正确做法docker 的 registry-mirrors 只对 docker.io 生效只配docker.m.daocloud.iogcr/ghcr/quay 这些源请用加前缀方式或交给 Podman 的 per-registry 配置。 README 里原话强调过不要把 docker.io 之外的站点配置给 docker 的 registry-mirrors。坑 3遇到 404 就以为服务挂了缓存内容只保留 30 天过期后会需要重新同步。blob 到期被清理的那一刻恰好又撞上 1 分钟的内存缓存窗口就会报 404。 ✅ 正确做法重试一次即可如果长期不用直接在闲时重新触发一次同步。坑 4下午三点赶上线硬拉 2GB 大镜像❌ 错误做法白天高峰期临时拉大镜像在同步队列里排队几十分钟。 ✅ 正确做法把拉取任务放在凌晨 01:00-07:00北京时间的闲时执行或在业务低峰期提前预热让大镜像先进入缓存。坑 5拉镜像之前不查白名单❌ 错误做法拉一个冷门仓库的镜像404 之后开始怀疑人生。 ✅ 正确做法先跑./hack/verify-allows.sh allows.txt 镜像名校验不在白名单就去提 issue 申请这是完全公开的流程。结果与下一步2 小时变 5 分钟之后我还在研究什么用上这套容器镜像加速方案后我自己的量化结果是kubeadm init卡死的控制面镜像从干等 2 小时变成 5 分钟拉完一次 200MB 的 gcr.io 镜像拉取从 40 分钟降到缓存命中后的秒级团队内网缓存上线后新同事入职当天拉环境再也没人抱怨过网络。而这只是开始。项目hack/目录下还有几个脚本correct-image.sh、fmt-image-match.sh、verify-image-match.sh能帮你把镜像名归一化、自动整理白名单格式、在 CI 里校验白名单是否规范——我已经在计划把镜像白名单自动化校验写进团队流水线下一篇准备写写这个。如果你也受够了境外镜像的下载速度建议现在就 clone 试试git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror。遇到不支持的镜像去提 issue 申请加白想改进同步工具直接 PR 到项目的hack/目录。这种纯转发、哈希一致、白名单公开的镜像加速服务值得每个被下载速度折磨过的人拥有。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考