ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

如何加速 Kafka 镜像拉取:用 public-image-mirror 分钟级拉完 Docker 镜像的完整指南

如何加速 Kafka 镜像拉取:用 public-image-mirror 分钟级拉完 Docker 镜像的完整指南 如何加速 Kafka 镜像拉取用 public-image-mirror 分钟级拉完 Docker 镜像的完整指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorApache Kafka 的官方镜像放在海外源站国内经常 Docker 镜像拉取慢。public-image-mirror 是 DaoCloud 维护的公开容器镜像同步服务在镜像名前加一个加速前缀就能把 Kafka 镜像加速到分钟级完成不用改任何部署文件。拉取慢是什么体验 周四晚上准备演示环境docker pull 拉一个 Kafka 镜像跑了四十分钟速度始终在个位数的 KB/s 打转最后直接超时中断。整条流水线卡在这一步后面的集成测试和发布计划全部顺延。有时候只能等到深夜再试或者换一条网络线路。集群场景更糟某个节点反复拉不到镜像Pod 一直停在 ImagePullBackOff扩出来的机器等于白扩。慢的根源很直接很多公开镜像存放在海外 registry比如 gcr.io跨境链路上丢包、限速都常见。这个镜像同步服务能做什么public-image-mirror 的定位是源仓库的镜像它和源站最关键的约定是所有镜像的哈希sha256与源站一致。所以你拉到的内容不会变成同名不同版这一点和那些内容不可信、哈希对不上的中转站不一样。它采用懒加载你的请求打到服务上缓存命中就直接返回未命中就触发一次同步任务从源站取回内容再写入缓存。因果链很清楚首次拉取要等同步完成所以偏慢之后命中缓存就快了。缓存本身也讲周期内容只保留 30 天Manifest 内存缓存 1 小时tag 更新后大约一小时才会同步新内容。这和自己改 registry 地址的差别在维护成本。自建转发节点每接一个新镜像都要搭节点、维护链路、人工核对哈希。用这个服务你只需要在镜像名前加前缀。支持范围写在 allows.txt 里一千三百多条白名单规则服务每天检查同步情况扩范围靠增白名单条目全程不改代码。下图把一次拉取的路径画出来三步拉通 Kafka 镜像第一步 查白名单确认镜像在列一条 grep 确认目标仓库在白名单里grep wurstmeister allows.txt输出 docker.io/wurstmeister/kafka 即在列。allows.txt 里还有一条通配规则 docker.io/*所以 docker.io 下大多数公开镜像都能直接走前缀方式。第二步 给镜像名加上加速前缀这一步不用敲命令把镜像名按下面格式改写即可原镜像docker.io/wurstmeister/kafka:3.9.0加速写法m.daocloud.io/docker.io/wurstmeister/kafka:3.9.0另一种写法是前缀替换把 docker.io 换成 docker.m.daocloud.io。README 更推荐加前缀因为 gcr.io、quay.io 这类源站没有对应的替换域名前缀方式对 11 个源站通用。第三步 拉取并验证版本拉完用容器内自带的工具核对版本号docker pull m.daocloud.io/docker.io/wurstmeister/kafka:3.9.0 docker run --rm m.daocloud.io/docker.io/wurstmeister/kafka:3.9.0 kafka-topics.sh --version第二条输出 3.9.0 即验证通过。如果首次拉取偏慢稍等再试那是后台同步还在进行。进阶玩法与常见坑配一次 让整台机器默认走加速源 ⚙️逐条改镜像名容易漏你可以在 Docker 客户端配全局镜像把下面内容写进 /etc/docker/daemon.json 后重启 Docker{ registry-mirrors: [ https://docker.m.daocloud.io ] }配置只对 docker.io 生效不要拿它加速 gcr.io 这类别的源站README 特意提醒过这一点。Kubernetes 集群可以按 README 的写法改每个节点的 containerdPodman 的 registries.conf 则支持一次给 gcr.io、ghcr.io 等多个源站配镜像。内网场景还可以再套一层本地缓存部署文档在 docs/local-cache/。大镜像提前拉一遍预热 因为首次请求会触发同步任务大镜像第一次拉最慢。正式部署前先把镜像拉一遍上线时它已经在缓存里。同步队列状态页能看到最近的同步动态记录只保留 1 小时。README 也建议把拉取任务放在北京时间凌晨 1 点到 7 点的闲时窗口其他时段比较拥挤。三个高频误区误区现象背后的机制registry-mirrors 能加速所有源站配完 docker.io 后 gcr.io 的镜像照样慢每个源站独立配置docker 的 registry-mirrors 只认 docker.io其他源站要换成对应前缀或替换域名latest 标签总是最新拉到的还是旧内容Manifest 内存缓存 1 小时tag 更新后新内容有同步延迟建议用 sha256 摘要或固定版本号缓存一次有效一个月没拉的镜像再拉又慢了缓存内容只保留 30 天过期后需要重新同步参与项目新增镜像或新的前缀替换规则提 issue前缀规则是人工配置的靠用户反馈扩充。改进校验脚本向 hack/ 提 PR里面就是白名单校验、规则格式化这类同步维护脚本。提需求前先自测在仓库根目录运行bash hack/verify-allows.sh allows.txt docker.io/wurstmeister/kafka返回 0 表示白名单已覆盖。把前缀加到镜像名上Kafka 镜像拉取慢这件事就有了标准解法。同步、校验和缓存过期都交给服务本身协议是 Apache-2.0 开源许可。支持的源站列表与每种场景的完整配置见 README.md。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进