K8s 拉取 gcr 镜像慢到抓狂?3 个实战场景玩转 public-image-mirror 加速

K8s 拉取 gcr 镜像慢到抓狂?3 个实战场景玩转 public-image-mirror 加速 K8s 拉取 gcr 镜像慢到抓狂3 个实战场景玩转 public-image-mirror 加速【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror在国内搞 Kubernetes最让人崩溃的时刻多半是盯着终端里gcr.io/...的镜像进度条慢慢爬。public-image-mirror 是 DaoCloud 开源的容器镜像加速项目核心思路就是给国外镜像仓库搭一座「国内可达的桥」让 gcr、docker、quay 这些站点的镜像也能被快速拉下来。下面不聊虚的直接按三个真实使用场景带你上手。先花 1 分钟搞懂加速到底在加速什么镜像卡顿的根源往往不是网速而是「物理距离」——镜像文件躺在海外的服务器上数据要跨越大洋一路传输。public-image-mirror 相当于在国外仓库和你之间放了一个中转仓它在海外侧把镜像同步好再在国内侧提供访问你请求的每一层数据都能从更近的节点拿到。项目 README 里写得很清楚它本质是源仓库的 Mirror所有镜像的 sha256 校验值都和源保持一致采用懒加载机制第一次拉取时才真正同步数据。另外缓存内容默认只保留 30 天过期需要重新同步tag 更新后约 1 小时才会反映到镜像站。记住这两条后面遇到「404」或「版本不新」就不慌。场景一个人开发者速成篇 如果你的诉求只是「让本机 docker pull 别再卡死」这个场景就够了。打法 A加前缀最省心给原始镜像地址前面加上m.daocloud.io/即可规则简单到不用记任何映射表docker.io/library/busybox ↓ m.daocloud.io/docker.io/library/busybox一条命令就能验证效果docker run -d -P m.daocloud.io/docker.io/library/nginx打法 B前缀替换地址更短嫌前缀法地址太长可以玩「域名替换」把常见源站的域名换成对应的加速域名路径部分原样保留docker.io/library/busybox ↓ docker.m.daocloud.io/library/busybox常用映射如下完整清单以项目 README 为准源站替换为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.ioregistry.k8s.iok8s.m.daocloud.iomcr.microsoft.commcr.m.daocloud.ionvcr.ionvcr.m.daocloud.ioquay.ioquay.m.daocloud.io小提醒前缀替换表是人工维护的需要的源站不在列表里时可以去提 Issue 申请。日常使用仍优先推荐加前缀它不依赖映射表、适用范围最广。另外只有 docker.io 适合配置成 Docker 的registry-mirrorsgcr、quay 这些源站千万别往daemon.json里塞否则不生效。场景二ArgoCD 流水线接入篇 ⚙️ArgoCD 同步任务卡在「拉镜像」这一步很常见下面两种接入方式按需选择。手动改把 image 字段换成加速地址直接在应用清单里替换镜像地址即可。比如把containers: - name: example image: gcr.io/google-samples/hello-app:1.0改成containers: - name: example image: m.daocloud.io/gcr.io/google-samples/hello-app:1.0Application 里的repoURL和path保持原样改完提交ArgoCD 下次同步就会从加速站拉取。自动改Webhook 兜底一个命令解放双手手动改只适合镜像不多的小项目集群里跑着几十上百个工作负载时挨个改不现实。这时可以部署 repimage它作为 Webhook 运行自动拦截所有新建 Pod把 image 地址改写为加速地址你的 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看到 Pod 进入 Running 状态后新创建的 Pod 就都会走加速通道。这套方案对 ArgoCD 同样有效——因为 ArgoCD 最终也是通过 Kubernetes API 创建 Pod改写动作发生在这一层应用侧完全无感。场景三企业内网部署篇 团队一大人人都去公共镜像站拉高峰容易拥挤对外网的依赖也变强。更稳的做法是在内网搭一个本地缓存让它当m.daocloud.io/的「二级代理」。具体步骤准备一台装了 Docker 和 Docker Compose 的机器。参照项目文档 docs/local-cache/README.md写一份docker-compose.yml核心是用 registry 镜像起一个带proxy配置的仓库把remoteurl指向https://m.daocloud.io。启动服务并在/etc/docker/daemon.json里把内网地址加入insecure-registries重启 Docker 生效。用起来和加前缀一模一样——在原始地址前补上你的内网仓库地址即可docker pull your-registry-ip:your-registry-port/docker.io/library/nginx:latest第一次拉取会穿透到公网同步之后团队内再拉同一个镜像就直接命中本地缓存基本秒开还能大幅减轻出口带宽压力。避坑指南让加速体验更顺滑 几个高频问题提前帮你排掉挑时间段北京时间凌晨 01:00–07:00 相对空闲白天高峰很挤批量同步任务尽量放到这个窗口。慎用 latestlatest这类可变 tag 一变镜像站后台就要重新同步。能写sha256:就用 digest其次用明确的版本号。看状态同步队列只保留 1 小时内的记录服务是否健康可以留意status.daocloud.io监控页仓库 README 里都有入口。仍然慢把任务挪到闲时 固定 tag通常立竿见影。写在最后现在就动手也欢迎来共建从本地 docker pull到 ArgoCD 流水线再到企业内网缓存这套方案把「一个人」到「一个团队」的场景都覆盖了。现在就打开终端把第一条命令里的镜像地址加上m.daocloud.io/前缀十秒钟就能感受到差别。遇到问题、找不到想要的源站或者想一起完善代码都可以通过 Issue 反馈、Pull Request 共建也欢迎在社区分享你的使用经验。想先跑起来看效果直接克隆仓库读 READMEgit clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考