前段时间搭 AKS 集群交付方案最头疼的环节不是 Kubernetes 本身而是镜像拉取。节点扩容时要同时从 Docker Hub 拉几十个镜像匿名限流一撞上就批量失败有的节点反复 ImagePullBackOff 停了十几分钟才恢复。从那一刻起我就把镜像供给链路当成正经基础设施来看生产环境不能依赖 Docker Hub 的免费额度必须有一套自动化的同步机制把 Docker Hub 上的镜像持续搬到 Azure Container Registry。后来选了 GitHub Actions 加 image-syncer 这套组合搭完之后基本不用再管每六小时自动同步一次日常主力镜像的增量同步通常几十秒就能跑完。这篇文章把完整方案从头写下来从选型逻辑、架构设计到 workflow 编写、踩坑记录都在里面适合已经有一份常用镜像清单、想给集群建立稳定镜像底座的人参考。1. 为什么要把 Docker Hub 镜像搬到 ACR限流、稳定性与可审计1.1 这不是没苦硬吃Docker Hub 的限流是真实的很多人觉得从 Docker Hub 直接拉镜像没什么问题开发环境确实如此一天拉不了几次。但到了生产集群就完全不一样了。Docker Hub 从 2020 年底开始对免费用户实施限流匿名访问每 6 小时大约 100 次拉取登录用户每 6 小时大约 200 次拉取。这个数量级对生产集群来说非常容易触顶。Kubernetes 节点扩容时每个节点要拉取节点监控、日志采集、网络插件、业务 Pod 等一堆镜像如果一个节点上有几十个 Pod一次扩容可能就把节点可用的拉取额度打光。限流触发后拉取请求会收到 429kubelet 会反复重试Pod 长时间停留在 ImagePullBackOff业务直接受影响。当时我遇到的情况是集群里新增了一批节点十几个节点同时拉镜像Docker Hub 开始大量返回 429。运行中的 Pod 没受太大影响但新调度的 Pod 全部起不来弹性伸缩形同虚设。查监控发现 kubelet 日志里全是toomanyrequests: You have reached your pull rate limit。那一刻我就确定生产集群的镜像来源绝对不能直接挂在 Docker Hub 的免费配额上。1.2 ACR 作为生产仓库能给到什么Azure Container RegistryACR在东八区这边访问速度和稳定性都不错但更关键的是它提供的是一整套仓库管理能力私有仓库镜像默认不公开只有被授权的主体才能拉取避免了镜像内容泄露。RBAC 权限控制可以用服务主体Service Principal给 CI/CD 一个最小权限账号只允许推拉指定 ACR不暴露全局凭据。地理复制Standard 或 Premium SKU 支持多区域复制镜像推送到一个区域后自动复制到其他区域多地域部署时拉取延迟更低。生命周期管理可以对仓库设置保留策略自动清理旧 tag避免仓库无限膨胀。审计与集成ACR 的操作日志能被 Azure Monitor 收集配合 SIEM 可以做拉取审计和 AKS、App Service、Container Apps 等服务的集成也更顺滑。如果你只是想解决拉取慢这一个问题ACR 的 connected registry 或 pull-through cache 确实可以按需从 Docker Hub 缓存镜像。但按需缓存不是离线快照Docker Hub 限流、镜像下架、某个 tag 被覆盖重推都会继续影响你。对生产环境来说我更推荐主动同步把镜像固化进自己的仓库而不是依赖上游的实时可用性。1.3 同步解决的不只是加速是供应链快照镜像同步有一个容易被忽略的价值它给生产环境建立了一份经过认可的镜像快照。latest这种 tag 表示的是变动指针今天拉到的nginx:latest和三个月后拉到的是两个不同的镜像。如果生产环境直接引latest你永远不知道代码实际跑在哪个版本上出了问题也难以回滚。通过 image-syncer 把镜像同步到 ACR 时可以在镜像清单里锁定具体 tag甚至可以在 ACR 侧开启不可变更 tag 策略让已经被引用的镜像版本不可覆盖。另外把仓库清单放进 Git 也等于做了供应链审计。每次同步哪些镜像、从哪个地址来、目标仓库是什么都有历史记录。对于需要过合规审计的团队这一条非常值钱。2. 工具选型博弈为什么偏偏是 image-syncer2.1 常见的临时方案为什么撑不住在确定 image-syncer 之前我先试过几种看起来也行的方案结果都在细节上崩了。最简单的方案是写个 shell 循环docker pull再docker tag、docker push。这个方案的问题是依赖 Docker daemonGitHub