关键是以Harbor为主干构建事件驱动、可验证、故障自愈的分发闭环：主中心推送，多地从库事件触发同步+定时补漏，配合registry-proxy地理调度与Skopeo+对象存储兜底，实现一次推送、多地可见、就近拉取、失败可溯。
要在 Docker 生态中实现镜像仓库的跨机房主从同步并支撑多活架构，关键不是简单部署两个 Harbor 实例，而是构建一个事件驱动、可验证、故障自愈的分发闭环。核心在于“一次推送、多地可见、就近拉取、失败可溯”。
用 Harbor 搭建主从复制链路（推荐生产环境）
Harbor 是目前最成熟的企业级方案，原生支持跨机房 Registry-to-Registry 同步：
- 在主中心（如上海机房）部署主 Harbor，所有 CI/CD 流水线只向该实例 push 镜像，不直连从库
- 在从中心（如北京、深圳机房）分别部署从 Harbor 实例，配置独立域名与 TLS 证书（如 harbor-bj.myorg.com）
- 在主 Harbor 的 Web UI 中创建“复制规则”：目标地址填从库 URL，认证方式选短期 Token 或基于 OIDC 的自动刷新凭证，命名空间映射建议加地域前缀（如 prod/app → bj-prod/app）
- 触发模式必须设为“事件驱动”，确保新镜像入库即同步；同时配一条每天凌晨执行的“定时拉取”规则，用于补偿网络抖动导致的漏同步
- 关闭“覆盖已存在镜像”选项，配合不可变 tag（如 v1.5.2-sha256-9f3a）和 OCI Artifact 存储签名，保障内容不可篡改
同步过程加校验与告警闭环
同步完成不等于可用，需验证结果并快速响应异常：
- 每条复制任务在 Harbor UI 中可查看详细日志：包括各层 SHA256、传输耗时、HTTP 状态码（如 201 表示成功，401 表示凭据失效）
- 启用失败重试（默认 3 次），并配置 Webhook 推送至内部 IM 群或告警平台；也可对接邮件服务，失败时自动发送含同步 ID 和错误原因的通知
- 在从 Harbor 上定期运行校验脚本：skopeo inspect docker://harbor-bj.myorg.com/bj-prod/app:v1.5.2，比对 manifest digest 与主库是否一致
运行时实现多活拉取调度（让容器自动选最近源）
同步只是前半程，真正影响业务的是 Pod 启动时能否秒级拉到镜像：
- 在每个 Kubernetes 集群节点上，通过 containerd config.toml 配置 registry mirror，指向本地 registry-proxy（如 https://proxy-bj.myorg.com），所有 pull 请求自动走代理
- 部署轻量 registry-proxy（可用 buildkitd 或 caddy+reverse_proxy），根据请求来源 IP 所属 AZ，返回对应机房的 Harbor 地址（如华北请求返回 harbor-bj.myorg.com，华东返回 harbor-sh.myorg.com）
- 配合 CoreDNS 的 k8s_external 插件做地理 DNS 解析：同一域名 harbor.myorg.com，不同地区集群解析出不同 VIP，实现无侵入式流量分发
补充兜底：Skopeo + 对象存储离线通道
当某机房因防火墙或网络策略无法直连主 Harbor 时，用 Skopeo 构建“离线中转”：
- 编写同步脚本，用 skopeo copy --src-tls-verify=false docker://harbor-sh.myorg.com/prod/app:v1.5.2 docker-archive:/tmp/app-v1.5.2.tar 导出镜像包
- 上传 tar 包至跨机房对象存储（如阿里云 OSS 华北桶 + 跨区域复制到华南桶），各地从本地桶下载并 load 进 registry 存储后端
- 用 systemd timer 替代 cron，设置 After=network-online.target，避免节点启动早于网络就绪导致同步失败
