harbor高可用集群关键在于共享后端存储、postgresql与redis高可用、多实例负载均衡。需使用s3/nfs/ceph统一镜像存储，patroni管理postgresql主从，redis sentinel保障缓存可靠，3节点以上statefulset部署并统一external_url，前端通过ingress或haproxy实现健康检查与会话保持。
部署 Harbor 多节点集群实现高可用，关键在于打破单点依赖，让核心服务可横向扩展、有状态组件具备容灾能力。不靠“主从切换”这种被动兜底，而是从架构设计上让多个 Harbor 实例真正协同工作——数据统一、请求分发、故障自动绕过。
共享后端存储：镜像数据一致性的基础
多个 Harbor 实例必须读写同一份镜像数据，否则就会出现 A 节点上传了镜像但 B 节点查不到的情况。这就要求使用外部共享存储，而非各节点本地磁盘。
- NFS：适合测试或中小规模，需确保 NFS 服务本身高可用（如双机热备 + keepalived），并配置 sync、no_root_squash 等参数保障读写一致性
- 对象存储（S3 兼容）：生产环境首选，如 AWS S3、阿里云 OSS、QingStor。Harbor 原生支持，天然具备多副本、跨区冗余能力，无需额外维护存储集群
- Ceph / MinIO：自建对象存储方案，适合对数据主权和网络延迟有强要求的场景，需单独部署并验证 S3 接口兼容性
配置时，在 harbor.yml 中明确指定 storage_service 段，禁用本地文件系统（filesystem）。
数据库与缓存：元数据和会话的可靠中枢
Harbor 的项目、用户、权限、扫描记录等都存在数据库里；登录态、任务队列、临时锁依赖 Redis。这两者一旦单点宕机，整个集群就“失智”。
-
PostgreSQL 集群：至少部署一主两从，启用流复制 + 同步提交（
synchronous_commit = on），配合 HAProxy 或 Patroni 实现自动主库选举 - Redis 高可用：推荐哨兵（Sentinel）模式或 Redis Cluster。避免单实例 Redis，否则 JobService 任务可能丢失、Web 登录会话中断
-
连接地址统一抽象：Harbor 配置中数据库
host和 Redishost应指向负载均衡 VIP（如haproxy-pg、haproxy-redis），而非具体节点 IP
多实例部署与流量分发
Core、Registry、JobService 这些无状态服务可以水平扩容。每个节点运行完整 Harbor 组件栈，但只负责处理分发过来的请求。
- 节点数量建议：生产环境至少 3 个 Harbor 实例，避免偶数节点在脑裂时无法仲裁
- 统一入口：前端必须配置反向代理（Nginx / HAProxy），做 SSL 卸载、健康检查、会话保持（基于 cookie 或 IP hash）
-
关键配置对齐：所有节点共用同一份
harbor.yml（除hostname外），尤其注意external_url必须一致，否则 Web 页面跳转和 Docker CLI 认证会出错 -
JobService 协调：启用
jobservice的分布式锁机制（默认基于 Redis），避免多个节点重复执行垃圾回收或镜像复制
验证与运维要点
部署完成不等于高可用落地，必须通过真实故障模拟来验证闭环能力。
- 主动停机测试：逐个停止某个 Harbor 节点容器或主机，观察前端访问是否无感切换，镜像 push/pull 是否持续成功
-
数据一致性校验：在不同节点执行
curl -u admin:xxx https://harbor.example.com/api/v2.0/projects，确认返回结果完全一致 - 存储层隔离检查：手动在 NFS 或 S3 中删除一个镜像的 manifest 文件，观察 Harbor 是否报错而非静默失败，验证异常处理健壮性
-
日志聚合与告警：集中收集各节点的
core.log和registry.log，对 “failed to connect to redis”、“database is not available” 类错误设置即时告警
