harbor 本身不原生支持集群高可用，需通过解耦有状态组件（外部高可用 postgresql、redis sentinel/cluster、对象存储）、无状态 harbor 实例横向扩展及前置负载均衡实现；须禁用内置数据库与本地存储，统一配置外部依赖，结合 prometheus 监控与灾备演练保障 sla。
Harbor 本身不原生支持集群高可用（HA），但可通过外部组件和架构设计实现企业级高可用部署。核心思路是：将 Harbor 的有状态组件（如数据库、Redis、存储）解耦并托管到高可用外部服务，同时对 Harbor 实例做无状态横向扩展，前端通过负载均衡统一接入。
关键组件高可用设计
Harbor 各模块需分别保障可用性：
- 数据库（PostgreSQL）：必须使用外部高可用 PostgreSQL 集群（如 Patroni + etcd + PostgreSQL 流复制），禁止使用 Harbor 内置的 PostgreSQL 容器；主从切换需保证事务一致性，连接字符串指向 VIP 或 DNS 负载均衡地址。
- 缓存（Redis）：采用 Redis Sentinel 或 Redis Cluster 模式，确保故障自动转移；Harbor 配置中指定 Sentinel endpoints 或 Cluster nodes，启用密码认证与 TLS（若启用）。
- 镜像存储：禁用本地文件存储；推荐对接对象存储（如 S3 兼容服务：MinIO 集群、阿里云 OSS、AWS S3），或 NFS 高可用集群（需支持 POSIX 锁且挂载点稳定）；所有 Harbor 实例共享同一存储后端。
- 日志与审计：将日志输出至远程 syslog 或 Loki/Promtail 栈；审计日志建议同步写入外部数据库（如 PostgreSQL），避免单点丢失。
Harbor 实例部署与扩缩容
多个 Harbor 实例应完全无状态运行：
- 所有实例共用同一套外部 DB、Redis 和 Storage，配置文件中
database、redis、storage均指向外部服务； - 关闭内置 Notary（已弃用）和 Clair（建议替换为 Trivy Operator 独立部署）；
- 使用 Helm（harbor/harbor Helm Chart）或 K8s StatefulSet + ConfigMap/Secret 管理部署，便于滚动更新；
- 每个实例需配置唯一
hostname，但对外暴露统一域名（如harbor.example.com），由前置 LB 路由流量。
前端接入与流量分发
用户访问必须经由具备健康检查与会话保持能力的负载均衡器：
- 推荐使用 Nginx Ingress Controller（K8s）或 HAProxy（裸金属），启用 HTTPS 终止，配置 OCSP Stapling 和 HSTS；
- 对 /api/、/service/ 等路径启用基于 Cookie 或 IP 的会话保持（Harbor UI 登录态依赖 session cookie）；
- 配置主动健康检查（如 GET /api/v2.0/ping），5 秒间隔，连续 3 次失败即摘除节点；
- 若需跨地域容灾，可结合 DNS 轮询 + 全局负载均衡（如 F5 GTM、Cloudflare Load Balancing）实现多活调度。
运维与可观测性增强
高可用不止于架构，更依赖持续可观测与快速响应：
- 集成 Prometheus：通过 Harbor Exporter 或直接抓取 Harbor 自带的
/metrics（需开启metric配置），监控 registry 请求延迟、DB 连接数、Redis 内存、镜像同步成功率等； - 告警规则覆盖：PostgreSQL 主从延迟 > 10s、Redis Sentinel failover 触发、Harbor Pod 重启频率突增、存储写入失败率 > 0.1%；
- 定期执行灾难恢复演练：模拟 DB 主节点宕机、对象存储临时不可达、单可用区整体失联等场景，验证 RTO/RPO 是否达标；
- 所有配置变更（如证书更新、DB 连接参数调整）必须经 CI/CD 流水线灰度发布，禁止手工修改生产环境 ConfigMap。
