资讯动态

ArgoCD 镜像加速怎么选:public-image-mirror 上手指南

发布时间:2026/9/11 14:59:53 来源:尧图企业网站定制
ArgoCD 镜像加速怎么选public-image-mirror 上手指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorArgoCD 的 Application 刚同步完Pod 却卡在 ImagePullBackOff 十分钟——问题往往不在配置写错而在镜像放在 gcr.io 这类国外仓库国内直连拉不动。public-image-mirror 就是为这个痛点做的镜像服务它给 gcr.io、ghcr.io、docker.io 等公开镜像仓库做懒加载镜像原始地址加个前缀就能从国内节点拉取。它是什么先把定位说清楚public-image-mirror 是 Registry 的 Mirror不是重新打包的镜像——每一层的 sha256 都和源仓库一致内容按需拉取懒加载缓存保留 30 天过期后要重新同步。Manifest 有 1 小时内存缓存所以latest这类可变 tag 变更一小时后才响应新数据。服务维护了一份 1327 行的白名单 allows.txt只有名单内的镜像会被加速想用名单外的需要到项目仓库提 Issue。限流与同步机制的更多细节见 README.mdhack/ 目录里还有校验地址映射规则的脚本可以顺便看看项目是怎么保证映射不出错的。先验证再动手 改配置之前先花 30 秒确认链路在你这边是通的。固定版本号拉一个 nginx顺手计时time docker pull m.daocloud.io/docker.io/library/nginx:1.25拉得快说明加速路径可用再把方案推进到 ArgoCD 里。拉得慢或报 404先别动 ArgoCD回到 避坑清单 逐项排查。镜像地址怎么写写法其实只有两种加前缀、镜像前缀替换。选哪种看你的使用场景。增加前缀默认选择在原始地址前加m.daocloud.io/后面原样保留。白名单里的任意仓库都能用包括不在替换表里的仓库不用背映射docker.io/library/busybox→m.daocloud.io/docker.io/library/busybox官方 README 明确推荐这种写法。地址长一点但规则只有一条谁都能改对。前缀替换对照表对下面 11 个常用源站可以直接替换域名地址更短。注意这张表是人工配置的不在表里的源站没有对应替换域名源站替换为备注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.iok8s.gcr.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实验内测中一句话决策拿不准就加前缀源站在表里、且要写几十条镜像地址替换起来更干净。接进 ArgoCD把镜像接进 ArgoCD 有两条路取舍很直接。直接改 Application 里的 image 字段应用少、镜像数量固定时手动改就够了不引入任何新组件containers: - name: app image: m.daocloud.io/gcr.io/google-samples/hello-app:1.0代价是每个新应用都要再改一遍地址。部署 Webhook 批量替换应用多或者不想动一行 yaml / helm 模板时部署 repimage 组件它用 mutating webhook 自动改写所有新建 Pod 的镜像地址应用仓库完全不用碰。先从 repimage 项目的 releases 页下载最新的 repimage.yaml然后kubectl create -f repimage.yaml -n kube-system kubectl rollout status deployment/repimage -n kube-system推荐做法3 个以内的应用手动改第 4 个应用出现时就上 webhook从此地址变更只在一个地方维护。进阶自建缓存代理团队镜像清单相对固定时值得在内网再垫一层缓存本地 registry:3 走代理先回源 m.daocloud.io之后同镜像的拉取全部命中内网基本不用等。完整 docker-compose.yml 在 docs/local-cache/README.md这里只列关键配置项image: m.daocloud.io/docker.io/library/registry:3 ports: - 8888:8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160hproxy.remoteurl指向加速入口ttl: 2160h即本地缓存 90 天有效docker compose up -d启动后在/etc/docker/daemon.json里把insecure-registries: [your-registry-ip:8888]加上并重启 docker之后拉取只需把前缀换成内网地址其余不变docker pull your-registry-ip:8888/docker.io/library/nginx:1.25避坑清单⚠️ 上线前逐条过一遍能省掉大部分排查时间大批量拉取排在凌晨 01-07 点北京时间闲时其他时段非常拥挤镜像优先用sha256:固定其次明确版本号 tag少用latest——可变 tag 变更后要重新同步期间会响应旧数据tag 变更后有 1 小时 Manifest 缓存窗口拉到的可能还是旧内容缓存内容只保留 30 天过期未拉取需要重新同步刚过期那一分钟遇到 404 直接重试确认镜像在 allows.txt 白名单内不在就提 Issue同步队列只保留 1 小时的记录想查某次拉取为何没同步趁早看Docker 的registry-mirrors只能配 docker.m.daocloud.io别把其他站点的替换域名塞进去只做少量镜像加前缀这一步就能收尾应用多了再叠上 webhook 和内网缓存把“等拉镜像”从日常流程里摘出去。需要看源码或者想给白名单补一个镜像直接 clone 仓库git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror遇到限流、白名单或同步方面的问题直接到项目仓库提 Issue 讨论觉得白名单该加条目、脚本可以更好用提交 PR 是最快的推动方式——这个项目的迭代节奏基本就靠社区提 Issue 和 PR 撑着。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价