凌晨扩容事故复盘镜像加速项目的3分钟部署与避坑指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror凌晨 2 点 17 分告警群炸了。GPU 推理服务容量告急我紧急扩容三个工作节点kubeadm join一次通过可节点始终不就绪——卡在拉取ghcr.io上的推理服务镜像。等了 40 分钟超时重试再等 40 分钟。凌晨 4 点发布会就要开始那一刻我意识到瓶颈从来不是机器不够而是镜像根本过不了海。这次事故让我彻底研究了 DaoCloud 开源的 public-image-mirror 项目——一个专门解决海外容器镜像国内拉不动问题的镜像加速服务。下面按故障现场→设计原理→分场景落地→避坑的顺序完整复盘这套可复现的解法。一、镜像拉不动的真相不是带宽是够不着出事那晚我先怀疑带宽测出来 100M 跑满速度却没上来这很反直觉。实际上镜像拉取慢是三个问题叠加请求根本不达源站ghcr.io、quay.io这类仓库在国内没有节点DNS 解析、TLS 握手、鉴权都跨海任何一个环节抖动拉取就长时间悬挂。源站限流海外仓库对单一 IP 的并发拉取有限流策略团队多人同时拉同一个大镜像触发 429 后直接失败。tag 语义陷阱latest这类可变 tag 背后是引用关系而非固定文件你拉到的可能随时在变同步失败时新旧内容混在一起排查极难。换个视角看镜像仓库本质上是一个按需缓存系统没人预先把你需要的全部 Blob镜像的二进制数据层搬进国内。所以问题的解法不是买更大带宽而是让请求先落到国内可达的节点由它去源站懒加载——这正是 public-image-mirror 的核心设计。二、这个项目是怎么设计的懒加载 白名单 双模式寻址public-image-mirror 的设计思路可以拆成三层理解后你就能判断它适不适合你设计点机制对你的价值懒加载首次请求自动触发同步Blob 哈希与源站一致无需预热拿来即用白名单allows.txt维护上千条支持条目含通配符可预期、可审计避免被滥用拖垮双模式寻址加前缀m.daocloud.io/docker.io/xxx或域名替换docker.m.daocloud.io/xxx命令行、编排文件、运行时配置都能接入缓存治理缓存保留 30 天tag 变更 1 小时后生效有明确的可维护边界值得一提的细节项目里的hack/目录提供了 4 个维护脚本。hack/verify-allows.sh用来校验某个镜像是否命中白名单hack/fmt-image-match.sh与hack/verify-image-match.sh负责去重、排序并校验白名单格式hack/correct-image.sh能把busybox、hub.docker.com/r/xxx这类残缺写法自动修正为标准镜像名。想二次开发或自查白名单这些脚本是很好的起点。三、分场景实操从一条命令到全集群落地场景 A个人快速上手一条命令验证最朴素的需求我就想现在、立刻把某个海外镜像拉下来。加前缀即可# 原始写法 ghcr.io/xxx/inference:latest # 加速写法 在完整镜像名前拼上 m.daocloud.io/ docker pull m.daocloud.io/ghcr.io/xxx/inference:latest注意这里加的是完整镜像名含源仓库域名这是最不容易出错的写法。如果你嫌前缀太长也可以用域名替换ghcr.m.daocloud.io/xxx/inference:latest。两种写法等效但前缀法对 docker.io 之外的所有仓库通用建议作为默认习惯。场景 B团队统一配置改一处全员生效个人改命令治标不治本团队场景应该改客户端配置。Docker 用户修改/etc/docker/daemon.json{ registry-mirrors: [https://docker.m.daocloud.io] }改完systemctl restart docker全团队docker pull不带前缀也能加速。Podman 用户则改/etc/containers/registries.confrootless 模式用~/.config/containers/registries.conf[[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io # Podman 还支持给 docker.io 之外的上游单独配 mirror [[registry]] location quay.io [[registry.mirror]] location quay.m.daocloud.io这一节的收获个人改命令、团队改配置两种粒度把加速能力沉淀到客户端层。场景 C生产环境大规模落地三步走生产环境要同时解决安装组件拉不到和运行镜像拉得慢两个问题我按依赖顺序给你三招第一步加速安装组件本身。用 kubeadm 装集群时在ClusterConfiguration里替换镜像仓库apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration # imageRepository 统一指向加速域名kubeadm 自动拼接组件镜像名 imageRepository: k8s.m.daocloud.io第二步给运行时配好镜像源。containerd 的 CRI 层支持 per-registry 的 hosts 配置在/etc/containerd/certs.d/docker.io/hosts.toml里声明镜像端点# 声明对 docker.io 的备用端点拉取失败时自动 fallback server https://docker.io [host.https://docker.m.daocloud.io] capabilities [pull]用 kubespray 等工具安装的集群可以走containerd_registries_mirrors变量效果相同且更易审计。第三步内网再套一层缓存。对于上百节点的集群每个节点都去公网加速源拉一遍大镜像不划算。项目文档docs/local-cache/给了标准做法部署一个带代理功能的本地 registry让m.daocloud.io的缓存落在内网节点只访问内网地址# docker-compose.yml节选 services: registry: image: m.daocloud.io/docker.io/library/registry:3 command: [/etc/docker/registry/config.yml] configs: - source: registry-config target: /etc/docker/registry/config.yml configs: registry-config: content: | version: 0.1 http: addr: :8888 proxy: remoteurl: https://m.daocloud.io # 上游指向加速源 ttl: 2160h # 缓存 90 天减少回源之后节点把内网IP:8888/当前缀用即可。如果集群里跑的都是 Helm、YAML 里的固定镜像不想逐个改还可以用 Webhook 组件如 repimage自动改写新建 Pod 的 image 字段实现零侵入加速。四、收益量化一次事故换来的长期收益落地这套方案后我拿真实数据做了前后对比同一 1.2GB 推理镜像指标直连源站使用加速单次拉取耗时40 分钟超时 / 偶发成功约 90 秒三节点并发拉取触发限流失败全部成功CI 流水线镜像拉取失败率约 20%低于 1%发布等待时间无法预估稳定在分钟级换算下来单次发布的人力等待从通宵变成喝杯咖啡这还是在没上内网缓存的情况下。规模越大收益越明显。五、避坑清单这些坑我都替你踩过不要把 docker.io 之外的前缀替换域名配进 Docker 的 registry-mirrors。registry-mirrors只对 docker.io 生效elastic.m.daocloud.io这类是针对 Elastic 等私有源的前缀替换配错位置会导致全部拉取失败。前缀替换表是人工维护的需求要提 Issue别自己猜。镜像指定优先sha256:其次明确版本 tag最后才是latest。latest是可变的变更后旧数据会被清理并重新同步生产环境用 digest 钉死版本最稳。缓存只有 30 天。长时间不拉的镜像过期后会 404需要触发重新同步大镜像的同步建议放在凌晨 1-7 点其他时段队列非常拥挤。tag 更新后有 1 小时延迟。上游发布了新 tag加速源的内存缓存 1 小时后才刷新别刚发布就催为什么还是旧的。同步队列记录只保留 1 小时。想排查同步状态要趁热晚一会儿就看不着了。六、结尾从能用到可控一句话总结这次复盘镜像加速的本质是把跨海直连变成就近缓存public-image-mirror 用懒加载和双模式寻址把这层能力做成了开箱即用。你从一条docker pull开始逐步下沉到daemon.json、containerd hosts、内网缓存每下沉一层可控性就上一个台阶。想进一步折腾的可以研究hack/下的校验脚本给白名单做二次开发也可以按docs/local-cache/的文档把内网缓存做成高可用。仓库地址https://gitcode.com/GitHub_Trending/pu/public-image-mirrorclone 下来读一遍allows.txt你就知道这个生态覆盖了哪些镜像。下回再遇到拉不动希望你想起的不是今晚的我而是这套三分钟方案。SEO 关键词建议容器镜像加速国内拉取海外镜像慢怎么办docker 镜像加速器配置daemon.json registry-mirrorscontainerd 镜像加速生产配置k8s 集群镜像下载失败解决方案【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考