镜像卡在 gcr.io 出不来？public-image-mirror 容器镜像加速实战指南

镜像卡在 gcr.io 出不来public-image-mirror 容器镜像加速实战指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror上周我在一台新机器上部署 Kubernetes 控制面卡在gcr.io拉镜像这一步整整两个小时重试超时、换网络、手动导出再导入……折腾到怀疑人生。最后同事丢给我一个方案——public-image-mirror一个由 DaoCloud 维护的容器镜像加速项目。它的核心逻辑简单到一句话把国外镜像仓库的地址原样映射到国内可达的m.daocloud.io域名下。我加了个前缀再拉同一个镜像从十几分钟变成十几秒。这篇文章就把整套玩法拆给你从单条命令到内网缓存从 Docker 到 Kubernetes一次讲透。先搞清楚一件事它到底帮你干了什么很多人一听镜像加速就想到自建代理其实 public-image-mirror 的思路完全不一样它只是源镜像仓库Registry的Mirror也就是镜像站的镜像站。所有 hashsha256都和源保持一致采用懒加载机制你拉的时候它才从源同步绝不给你造一个变味的镜像。项目每天检查各仓库的同步情况保证热门镜像基本实时可用。换句话说你不需要信任什么第三方改编版你拿到的还是那个官方镜像只是运输路径变了。这一点对生产环境尤其重要——hash 对得上安全底线就在。选它而不是自建代理的三个理由我知道你可能已经在想那我干脆自己搭个代理不行吗 行但先看完这张对比再决定维度自建代理公共代理源public-image-mirror上手成本要维护服务器和证书配置即用配置即用改动量要改一堆仓库地址加前缀即可加前缀即可稳定性取决于你的带宽看运营商心情每天检查同步白名单透明镜像一致性自己保证不透明sha256 与源一致懒加载三个理由一个比一个实在改动最小只是名称映射不需要改任何代码。你的 Dockerfile、Helm、yaml 全部原样只在地址前加前缀。稳定可靠每天自动检查同步情况还有同步队列queue.m.daocloud.io/status/和服务状态监控页面可以随时查。覆盖面广gcr.io、docker.io、quay.io、ghcr.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 这些高频仓库全在支持列表里。10 秒上手给镜像地址加个前缀先别想复杂了最快的一条命令长这样docker run -d -P m.daocloud.io/docker.io/library/nginx原理一句话在完整镜像地址前面原样加上m.daocloud.io/前缀。docker.io/library/busybox ↓ 加前缀 m.daocloud.io/docker.io/library/busybox完成这一步你就得到了一条从国内直连、几乎不会超时的拉取链路。注意这里要写完整地址包含docker.io/不要自作聪明把它去掉——这正是前缀法最大的优点规则无脑任何镜像都能套不怕记错映射关系。这个方法适合所有场景docker run、docker compose、Kubernetes 的 image 字段甚至 CI 流水线里都能用属于保底方案。想让地址更短试试前缀替换如果嫌m.daocloud.io/docker.io/library/nginx太长项目还为常见仓库准备了前缀替换的玩法把域名直接映射成xxx.m.daocloud.io源站替换为备注docker.elastic.coelastic.m.daocloud.iodocker.iodocker.m.daocloud.iodhi.iodhi.m.daocloud.iogcr.iogcr.m.daocloud.ioghcr.ioghcr.m.daocloud.iok8s.gcr.iok8s-gcr.m.daocloud.io已迁移到 registry.k8s.ioregistry.k8s.iok8s.m.daocloud.iomcr.microsoft.commcr.m.daocloud.ionvcr.ionvcr.m.daocloud.ioquay.ioquay.m.daocloud.ioregistry.ollama.aiollama.m.daocloud.io实验内测中用起来长这样docker.io/library/busybox ↓ 前缀替换 docker.m.daocloud.io/library/busybox一句话说清适用场景图省事、想要短地址就用替换法图保险、不想记规则就用前缀法官方也是更推荐前缀法的。这里有个特别提醒每个源站的内容都不一样⚠️不要把 docker.io 之外的站点配到 Docker 的 registry-mirrors 里那是给 docker.io 专用镜像加速的配错了轻则无效、重则报错。避开这 6 个坑拉取成功率直接拉满这些坑我基本都踩过直接给你避坑清单一条一条对挑时间拉白天高峰很挤把拉取任务放在凌晨北京时间 01–07 点会快很多实测差距明显。⏰用sha256:锁死镜像优先用 digest 固定版本其次用明确的 tag如v1.22.1最后才考虑latest。latest这种可变 tag 更新后旧数据会被响应且后台要重新同步。缓存只有 30 天项目缓存的内容只保留 30 天过期后会重新同步冷门镜像第一次拉偏慢是正常现象。tag 更新有延迟Manifest 内存缓存 1 小时也就是说上游 tag 更新后大约 1 小时才会同步新的别刚发布就去拉然后怀疑人生。偶发 404 别慌Blob 内存缓存只有 1 分钟期间如果 blob 刚好到 30 天期限被删了可能报 404重试一般就好。先确认镜像在白名单里项目用allows.txt维护支持列表动手之前先看一眼你的镜像在不在里面省得白等。进阶Kubernetes 全家桶一次提速到位如果你的痛点是 Kubernetes 拉镜像慢下面这套组合拳按需取用都是可直接抄的配置。kubeadm 安装控制面——改两行imageRepository即可apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.io dns: imageRepository: k8s.m.daocloud.io/corednskind 创建集群——创建时直接指定加速镜像kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1containerd——参考官方 hosts 文档配置 registry host namespace如果你用 kubespray 装的 containerd直接配containerd_registries_mirrors变量一行搞定。Docker daemon——把加速站加进全局镜像源之后所有docker pull自动走加速{ registry-mirrors: [ https://docker.m.daocloud.io ] }Podman——在配置文件里为多个 registry 分别声明 mirror[[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.ioPodman 有个 Docker 给不了的优势它支持给docker.io 之外的 registry 配 mirrorgcr、ghcr、quay、registry.k8s.io 都能配配置方式照葫芦画瓢。企业级玩法把加速站搬进内网团队人多、镜像量大公共站扛不住那就部署一个本地缓存代理让内网所有机器共享缓存。原理很简单用一个带 proxy 模式的 registry把m.daocloud.io当上游。先写一个docker-compose.ymlservices: 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: {}启动它docker compose up -d然后让每台机器把本地仓库加进 insecure-registries{ insecure-registries: [your-registry-ip:your-registry-port] }重启 Docker 后your-registry-ip:your-registry-port/就成了m.daocloud.io/的本地缓存代理。用法和加前缀一模一样docker pull your-registry-ip:your-registry-port/docker.io/library/nginx:latest第一个拉的人走公网后面的全走内网缓存速度直接起飞 。这份配置在项目里有完整文档对应源码路径是docs/local-cache/README.md照着抄就行。偷懒大法Webhook 自动替换所有镜像不想改任何 yaml、helm、Dockerfile那就让劫持发生在 Pod 创建那一刻。用 repimage 这个工具部署一个 Webhook它会自动把集群里所有新建 Pod 的 image 改写成加速地址你的业务清单一个字都不用动kubectl create -f https://files.m.daocloud.io/github.com/wzshiming/repimage/releases/download/latest/repimage.yaml kubectl rollout status deployment/repimage -n kube-system注意上面这个安装地址本身就是走files.m.daocloud.io加速的连部署工具这一步都是快的。它特别适合存量集群——尤其是那些躺着几百个旧 Deployment、一个个改 image 要改到天荒地老的老项目。彩蛋Ollama 和 DeepSeek 模型也能加速最后给搞 AI 的朋友一个彩蛋。装 Ollama 同样可以走加速源CPU 版docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.m.daocloud.io/ollama/ollama有 GPU 就加个参数docker run -d --gpusall -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.m.daocloud.io/ollama/ollama启动之后连模型下载都能加速DeepSeek-R1 实验内测中docker exec -it ollama ollama run ollama.m.daocloud.io/library/deepseek-r1:1.5b写在最后回到开头那个场景同样是部署 Kubernetes 控制面现在我的流程是给镜像地址加前缀 → 直接拉 → 几分钟进集群。这中间差的不只是两小时是每次碰墙之后想砸键盘的怨气。public-image-mirror 给我的感觉就是方案足够简单简单到你不会再想换别的。如果你也被镜像拉取折磨过建议直接上手试一条命令成本几乎为零。用完觉得香欢迎一起把它养得更肥发现常用镜像不在支持列表去仓库的 Issue 区提需求白名单靠社区共建。想动手改代码仓库里的hack/目录就是维护白名单的工具集verify-allows.sh、fmt-image-match.sh、verify-image-match.sh这些脚本改完记得跑一遍校验。需要拉源码的话git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror少踩一个坑就多省一小时。去试试吧。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考