Harbor镜像复制规则通过多地预同步实现全球负载均衡，核心是“复制分发镜像+客户端就近拉取”分工：复制规则（如event_based触发、正则过滤）确保镜像抵达各地仓库，负载均衡由DNS/CI/集群配置等入口层完成，二者协同达成高可用与低延迟。
通过Docker镜像仓库的复制规则实现全球负载均衡，核心不是让复制本身承担流量分发，而是用“多地预同步 + 本地就近拉取”替代中心化拉取，从而达成等效的全球负载均衡效果。复制规则负责把镜像主动分发到各地节点，而真正的负载均衡由客户端配置或网络调度完成。
明确复制与负载均衡的分工
复制规则（如 Harbor 的 Replication Policy 或 Skopeo 脚本）只解决“镜像在哪有”的问题，不处理“请求该发给谁”。负载均衡需在请求入口层实现，比如：
- 用户在 CI/CD 中配置不同环境使用不同 registry 地址：dev 集群拉 registry-us-west.example.com，prod 集群拉 registry-ap-southeast.example.com
- 通过 DNS 权重或 GeoDNS 将 registry.example.com 解析到离用户最近的地域节点
- 在集群入口部署 Nginx/HAProxy，根据客户端 IP 地域信息 proxy_pass 到对应 region 的 registry
基于 Harbor 的跨区域复制配置要点
Harbor 是企业级实践中最常用的支持复制的仓库，其策略需围绕“准实时、按需、可控”设计：
- 触发方式选 event_based：镜像 push 到主站后立即触发同步，避免定时轮询带来的延迟
- 资源过滤要精准：用 name 正则（如 ^prod/.*:v[0-9]+\.[0-9]+\.[0-9]+$）只同步生产标签，减少冗余传输
- 目标 registry 必须启用 HTTPS 且证书可信：否则复制任务会失败；建议统一用 Let’s Encrypt 或私有 CA 签发通配符证书
- 为每个目标站点单独建复制策略：例如 “rep-to-tokyo”、“rep-to-frankfurt”，便于独立启停与监控
配合客户端实现就近拉取的关键动作
光有复制还不够，客户端必须知道该连哪个 registry。常见落地方式包括：
- 构建时注入 registry 域名：CI 流水线根据部署目标 region 替换 Dockerfile 中的 FROM 行，或通过 build-arg 传入 REGISTRY_HOST
- Kubernetes 集群预置 imagePullSecrets + 区域感知镜像前缀：在不同 region 的集群中部署不同 ConfigMap，定义 IMAGE_REGISTRY=registry-mumbai.example.com，应用模板中引用该变量
- Docker daemon 配置 mirror（仅限 pull-through 场景）：在边缘节点的 /etc/docker/daemon.json 中添加 "registry-mirrors": ["https://registry-sao-paulo.example.com"]，使所有未指定 registry 的拉取自动走本地镜像站
验证与可观测性不能少
全球同步容易出现“以为同步成功，实际卡在某环节”的情况。必须建立闭环验证机制：
- 每个目标 registry 提供健康检查端点（如 /api/v2.0/health），由 Prometheus 定期抓取
- 同步任务执行后，调用 GET /api/v2.0/projects/{project_name}/repositories/{repo_name}/artifacts?tag={tag} 确认镜像 manifest 已存在
- 在各 region 部署轻量探测 Job，定时执行 docker pull registry-{region}.example.com/busybox:latest 并记录耗时与成功率
