ArgoCD 镜像拉取慢怎么办三级加速方案与内网缓存避坑指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorArgoCD 镜像加速方案国内集群同步应用时gcr.io 等境外仓库拉取卡顿、超时DaoCloud 开源的 public-image-mirror 加个前缀就能走国内同步节点再配一层内网 registry 缓存外网依赖降到最低。先看现场ArgoCD 拉取慢到底卡在哪最常见的误判是网络不好其实多数时候是路径问题集群要跨公网去境外仓库逐层下载排队、限速、超时轮番上阵Pod 事件里反复刷ImagePullBackOffsync 状态就一直挂在 syncing 不动。ArgoCD 还会把问题放大——一次同步往往涉及多个工作负载任何一个镜像拉不下来整个应用就停摆。重灾区是 gcr.io 这类国内镜像覆盖不到的仓库kubeadm、cert-manager、各类 Operator 的组件镜像基本都住在那儿稍有更新就得重新拉。原理一句话名称映射 定时巡检public-image-mirror 不搬库、不转码做的是地址映射境外仓库在国内同步节点上挂一份别名拉取请求先落到节点节点再按需回源sha256 与源站保持一致缓存 30 天到期后会自动重新同步。另外它是懒加载机制——没被请求过的 tag 不会提前搬运所以你只需要关心用哪个前缀日常维护交给它的定时巡检把它当成一套现成的 K8s 镜像同步方案即可。三档落地方案按侵入程度从轻到重三种方式按要动多少东西排成递进关系改地址 → Webhook → 内网缓存。个人或小团队前两档通常就够规模上来、对外网依赖敏感时再上第三档。档位一改一处镜像地址就能提速这是最轻的一档不引入任何组件只改一行文本回滚也是一次替换。原始地址前加m.daocloud.io/或对下表中的域名做前缀替换两种写法共用同一个同步后端docker.io/library/busybox ↓ 加前缀 m.daocloud.io/docker.io/library/busybox gcr.io/google-samples/hello-app:1.0 ↓ 前缀替换 gcr.m.daocloud.io/google-samples/hello-app:1.0在 ArgoCD 里不用碰 Application 定义本身把 K8s 资源中的containers[].image换成上面任一种写法下一次 sync 即走加速链路kubeadm 场景把imageRepository换成k8s.m.daocloud.io同理。注意前缀替换是人工维护的固定清单清单外的源站请一律用加前缀映射关系按仓库类型整理如下分组源站替换为备注Docker 系docker.iodocker.m.daocloud.io使用最频繁Docker 系docker.elastic.coelastic.m.daocloud.ioDocker 系quay.ioquay.m.daocloud.ioDocker 系dhi.iodhi.m.daocloud.ioGCR / K8s 系gcr.iogcr.m.daocloud.ioGCR / K8s 系k8s.gcr.iok8s-gcr.m.daocloud.io源站已迁往 registry.k8s.ioGCR / K8s 系registry.k8s.iok8s.m.daocloud.io其他ghcr.ioghcr.m.daocloud.io其他mcr.microsoft.commcr.m.daocloud.io其他nvcr.ionvcr.m.daocloud.io其他registry.ollama.aiollama.m.daocloud.io实验内测中补充一句各源站内容互相独立不要把 docker.io 之外的站点塞进 Docker 的registry-mirrors替换表想加新条目则走 Issue。档位二让 Webhook 替你改 Pod 镜像应用一多逐个改image就不现实了。repimage 用 Webhook 在 Pod 创建时自动改写镜像地址yaml 与 Helm chart 保持原样不动部署只有两条命令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要留意作用边界Webhook 只拦新建的 Pod存量容器不会被原地改写需要rollout restart之后才切到加速地址。档位三内网 registry 缓存代理外网只走一次前两档的首次拉取仍会回源。集群规模上来后在内网垫一层缓存最稳本地 registry 代理m.daocloud.io命中缓存直接返回未命中才由它去回源。完整步骤见 docs/local-cache/README.mdcompose 文件的核心内容如下services: registry: image: m.daocloud.io/docker.io/library/registry:3 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: filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}启动后客户端只需在/etc/docker/daemon.json里把内网地址声明为可信仓库再重启 Docker 即可生效{ insecure-registries: [registry-host:port] }此后拉取写法与前缀方案完全一致只是前缀换成内网地址docker pull registry-host:port/docker.io/library/nginx:latest。拉取仍慢的 4 个自查点 配置完还是慢按顺序过一遍这四点挪到闲时白天节点比较拥挤批量拉取任务放到凌晨 1 点到 7 点北京时间执行吞吐会明显更稳。钉死版本优先用sha256:摘要其次选明确版本号的 taglatest这类可变 tag 一旦更新就触发后台重新同步缓存命中率低。验证链路先在节点上手动docker pull一次加速地址把仓库本身慢和节点 DNS、代理、防火墙拦了请求区分开。查队列与状态用同步队列仅保留一小时记录确认你的镜像是否在排队再用服务状态监控看后端整体健康度。下一步查文档再提 Issue白名单、限流、新增源站这类问题先翻项目文档解决不了就到仓库提 Issue。需要本地核对同步清单时git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror拉一份 DaoCloud 维护的 public-image-mirror 源码看看项目更新节奏不慢动手前记得通读一遍 README。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考