3分钟解决Docker镜像拉取超时DaoCloud镜像加速完整指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorpublic-image-mirrorDaoCloud 公开镜像仓库解决的是一个很具体的问题gcr.io、ghcr.io、quay.io 这类部署在海外的镜像仓库国内直接拉取经常超时或极慢。它的思路很朴素——在镜像地址前加一个前缀让镜像从国内节点同步缓存后给你下载你不需要任何账号和付费配置。为什么国外镜像会拉取超时先说清它的同步机制后面几个坑都跟这个有关懒加载不是把所有镜像提前搬回国内而是你第一次拉取时才从源仓库同步一份到国内节点哈希一致缓存镜像的 sha256 与源仓库保持一致不会被篡改或换内容缓存 30 天过期长期不拉取的镜像过期后需要重新同步所以第一次拉取会明显比第二次慢。理解了首次慢、二次快你就知道很多超时其实只是冷同步而不是服务挂了。选加速方式加前缀 vs 前缀替换两种方式都能用区别在于覆盖范围和适用场景加前缀m.daocloud.io/前缀替换如docker.m.daocloud.io覆盖范围白名单内的所有仓库仅人工配置了映射的源站写法m.daocloud.io/docker.io/library/nginxdocker.m.daocloud.io/library/nginx能否配进 Docker 全局 mirror否可以仅限 docker.io推荐程度✅ 官方推荐有对应映射时可用常用源站的前缀替换映射节选自项目 README源站替换为docker.iodocker.m.daocloud.ioghcr.ioghcr.m.daocloud.iogcr.iogcr.m.daocloud.ioregistry.k8s.iok8s.m.daocloud.ioquay.ioquay.m.daocloud.iomcr.microsoft.commcr.m.daocloud.io⚠️ 注意不要把 docker.io 之外的站点配进 Docker 的registry-mirrors每个源站内容不同混配会导致找不到镜像。3分钟拉取第一张加速镜像加前缀的用法把原来的镜像地址原样保留前面拼上m.daocloud.io/。下面两条命令等价第二条走国内节点# 原地址国内直连可能超时 docker pull docker.io/library/nginx:latest # 加速地址加 m.daocloud.io/ 前缀其余不变 docker pull m.daocloud.io/docker.io/library/nginx:latest拉下来之后直接docker run -d -P启动即可镜像本身和官方完全一致。如果是 K8s 的 YAML把image:字段按同样方式改前缀就行其他什么都不用动。给 Docker 客户端配置全局加速如果你希望所有docker.io镜像自动走加速节点而不用改每一条 pull 命令改一下 daemon 配置即可。编辑/etc/docker/daemon.json加入registry-mirrors只放 docker.io 的加速地址然后重启 Docker 服务生效{ registry-mirrors: [ https://docker.m.daocloud.io ] }sudo systemctl restart docker # 重启使配置生效这个全局配置只对 docker.io 生效。ghcr.io、gcr.io 等其他源站请继续用加前缀的方式或参考 Podman 的 registries.conf 写法Podman 支持为每个源站单独配 mirror比 Docker 灵活。K8s 集群的镜像仓库加速集群场景常见的三个位置改法如下kubeadm 初始化把集群组件的镜像仓库指到加速节点。在 kubeadm 配置里改两个字段apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration dns: imageRepository: k8s.m.daocloud.io/coredns # CoreDNS 组件镜像 imageRepository: k8s.m.daocloud.io # 其余集群组件镜像kind 本地集群创建时直接指定 node 镜像的加速地址kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1存量集群所有 Pod不想逐个改 YAML 的话可以部署 repimage 这类 Webhook 组件自动改写新建 Pod 的 image 地址业务侧零改动。另外企业内网如果对完全不走外网有要求官方提供了本地缓存方案在内网起一个 Registry 作为m.daocloud.io的二级缓存细节见 docs/local-cache/README.md。两个机制白名单与缓存时效拉取失败前先确认这两点1. 镜像是否在白名单内同步范围由仓库根目录的 allows.txt 控制目前收录 1300 余条仓库规则docker.io约 1000 条、ghcr.io约 200 条gcr.io、registry.k8s.io等则是整站放行。想确认某个镜像是否支持clone 下来查一下最快# 把仓库拉到本地然后 grep 白名单支持 * 通配规则 git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror grep docker.io/nginx public-image-mirror/allows.txt不在名单里的镜像会被拒绝同步需要等维护者添加项目设计上加仓库不需要改代码。2. 缓存时效与 tag 选择现象原因首次拉取特别慢冷同步属正常建议把批量拉取放在北京时间凌晨 01-07 点的闲时换了新 tag 后内容没更新Manifest 内存缓存 1 小时tag 更新后最长延迟 1 小时突然 404缓存临 30 天过期被清理时1 分钟内的 Blob 缓存可能导致短暂 404重拉即可所以 tag 选择的优先级是sha256:固定摘要 明确版本号 latest。latest这类可变 tag 变更后后台会重新同步期间拉到的可能是旧数据生产环境建议锁死版本。常见问题排查拉取报 not found / 404先核对镜像名、仓库、tag 是否拼对再确认在 allows.txt 白名单内最后确认不是上面的缓存过期窗口。拉取超时区分冷同步慢和真失败——同一镜像第二次拉取如果秒回说明只是首次同步耗时把大批量任务挪到闲时执行即可。白名单规则看不懂仓库 hack/ 目录下有维护者用的校验脚本如verify-allows.sh可检查某个镜像是否命中白名单规则排障时可参考其匹配逻辑。下一步建议先用加前缀的方式把手头最慢的那几个镜像跑通确认首次慢、二次快符合预期后再按需配置 Docker 全局 mirror 和 K8s 的 imageRepository。生产环境记得把latest换成固定版本号或 sha256 摘要有内网部署需求的可以接着看 本地缓存文档。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考