1条命令解决镜像拉取卡死public-image-mirror镜像加速实战救急指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror凌晨 2 点 47 分你盯着终端里那个转了 20 分钟的进度条gcr.io的镜像才拉到 37%。又过了十分钟Docker 直接超时报错Kubernetes 集群里ImagePullBackOff的红字刷了一屏幕。明天早上还要上线。这不是你的网络问题是镜像在国外这个物理事实在跟你作对。镜像加速这件事其实 1 条命令就能解决。今天这篇文章不讲废话直接带你用 public-image-mirror 把 gcr.io、ghcr.io、k8s.gcr.io 这些老大难仓库全部驯服。它到底是个什么神奇仓库先别急着抄命令花 30 秒搞懂原理你后面排错会轻松十倍。public-image-mirror 本质上不是又一个镜像仓库而是源仓库的镜像Mirror。打个比方你平时海淘东西要从美国仓库发货又慢又贵。public-image-mirror 就是设在境内的快递代收点货物其实还是从原产地发但代收点提前帮你备好了货你从代收点取秒取秒走。关键机制有三个懒加载你第一次拉某个镜像时它才去源站搬货搬完缓存下来后面的人再拉就秒下。hash 一致所有镜像的 sha256 摘要和源站完全一致内容 100% 相同不存在被改过的风险。自动同步项目每天检查同步情况tag 更新后约 1 小时就会跟上镜像不过期不担心用旧版。记住这三条后面遇到怎么验证它靠谱为什么缓存了还会慢这种问题你自己就能推出来答案。1 分钟上手一条命令验证奇迹最狠的地方在于加速一个镜像只需要在原始地址前加一个前缀其他什么都不用改。耗时约 1 分钟。# 原始镜像 docker.io/library/nginx # 前面加上 m.daocloud.io/ 前缀其余路径原样保留 docker run -d -P m.daocloud.io/docker.io/library/nginx跑完这条命令如果你能看到一串容器 ID 返回说明加速已经生效。就这么简单——加前缀是项目官方最推荐的方式因为它是纯规则映射任何镜像都能套用不需要人工维护映射表。再送你三个高频场景的极简配置kubeadm 装集群卡在k8s.gcr.io改一行配置apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration # 把默认的 k8s.gcr.io 换成加速源init 不再卡下载 imageRepository: k8s.m.daocloud.ioDocker 全局加速改/etc/docker/daemon.json{ // registry-mirrors 是 Docker 原生支持的镜像加速配置 registry-mirrors: [https://docker.m.daocloud.io] }改完记得systemctl restart docker重启守护进程然后随便docker pull一个镜像感受下速度差。团队用怎么选三套方案摊开算账个人玩玩加前缀就够但团队/企业场景就得权衡了。我把三套主流方案放在一起对比方案怎么用适用场景代价收益A 加前缀地址前加m.daocloud.io/个人、临时救急要手动改地址覆盖面最全任何镜像都能用B 前缀替换docker.io换成docker.m.daocloud.io常用仓库、Docker/Podman 配置仅限官方支持的前缀列表地址更短可配置成全局 registry-mirrorsC 内网缓存自建 registry 做本地代理企业内网、多节点集群要部署维护一套服务首次拉取后内网秒传彻底不依赖外网选型建议很直白想要零成本就用 A想要少改地址就用 B想要公司内网稳定就用 C。说个容易踩的坑B 方案的前缀替换规则是人工维护的只有表里那十几个仓库支持gcr.io、ghcr.io、quay.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 等。如果你需要的仓库不在列表里直接走 A 方案加前缀别硬套 B。另外容器团队可以关注下 repimage 这个配套工具它用 Webhook 自动改写集群里所有新建 Pod 的镜像地址你连 yaml 都不用改一行命令部署# 部署 repimage之后新建的 Pod 会自动走镜像加速 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企业要上 C 方案的话参考项目仓库docs/local-cache目录下的 compose 文件部署一个指向m.daocloud.io的本地代理 registry 即可。怎么证明它真的快了配置完了别急着走花 2 分钟自证效果免得心里没底。# time 记录拉取耗时感受加速前后的差距 time docker pull m.daocloud.io/docker.io/library/alpine:3.20 # 对比直接拉官方源看看慢在哪 time docker pull docker.io/library/alpine:3.20加速源如果走的是缓存命中的路径几十 MB 的镜像通常几秒内就能拉完对比官方源的超时重试体感差距非常明显。再验证内容一致性——加速源承诺 sha256 与源站完全一致可以查证# 查看镜像 digest和官方源比对应当一模一样 docker inspect --format{{index .RepoDigests 0}} m.daocloud.io/docker.io/library/alpine:3.20如果怀疑服务本身出问题还有两个官方状态入口queue.m.daocloud.io/status/看同步队列只保留 1 小时记录status.daocloud.io/status/docker看服务健康度。拉不动的时候先看这两个页面比盲猜快得多。收尾三句话踩坑清单 下一步动作最后把这几天最容易翻车的三个坑给你钉死别用 latest可变 tag 一变缓存里旧数据会失效并触发重新同步。优先用sha256:指定摘要其次用明确版本号最后才考虑 latest。挑时段拉取北京时间凌晨 01-07 点相对空闲其他时段同步队列可能很拥挤冷门镜像首次拉取会偏慢。别把前缀替换站配给 DockerB 方案的映射表是针对各源站的只有 docker.io 相关的才能配进 Docker 的registry-mirrors其他站gcr、quay 等配进去会报错。接下来该你动手了把项目 clone 下来看看白名单# clone 项目查看 allows.txt 确认你的镜像在支持列表里 git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror仓库里的allows.txt就是加速白名单一查便知。项目官方地址就是上面这个 GitCode 仓库。参与贡献有三条路提交 Issue报告同步异常或申请新的前缀替换规则映射表是人工维护的有需求就得提提交 Pull Request改进文档或校验脚本在社区分享你的使用场景和踩坑经验帮后来人少走弯路。镜像加速这事早一分钟配置早一分钟下班。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考