Harbor高可用需解耦有状态组件（外部PostgreSQL集群、Redis Cluster、对象存储）、无状态实例横向扩展及前置负载均衡；禁用内置数据库与本地存储，统一配置外部依赖，并通过Prometheus监控与灾备演练保障SLA。
容器镜像仓库要真正支撑生产环境，光能跑起来远远不够——高可用（HA）是底线要求。它不是“锦上添花”，而是避免一次Registry宕机导致整个CI/CD流水线卡死、线上服务无法滚动更新的关键保障。
核心组件必须解耦与独立部署
Harbor不是单体应用，强行把所有服务塞进一台机器，既是性能瓶颈，也是单点风险源。高可用的前提是服务分层、职责清晰、可独立伸缩：
- Core、Jobservice、Portal、Registry应作为无状态服务分别部署，通过负载均衡对外提供统一入口
- PostgreSQL必须启用主从复制或集群模式（如Patroni），禁止单实例；元数据丢失等于仓库“失忆”
- Redis建议采用Redis Cluster（至少3节点），而非Sentinel+单主，避免缓存雪崩和连接倾斜
- Registry存储后端禁用本地磁盘，改用支持ReadWriteMany的共享存储：MinIO集群、Ceph RBD、或云厂商对象存储（S3兼容）
流量入口与服务发现需冗余设计
用户和Kubernetes集群访问仓库，不能只依赖一个IP或一个Ingress Controller：
- 前端用NGINX或HAProxy做七层负载均衡，开启HTTP/2、调大buffer和超时参数（read/write/idle timeout建议≥300s）
- 在Kubernetes中，用Ingress + 多副本Ingress Controller（如Nginx Ingress多个Pod），或直接使用Service类型为LoadBalancer并绑定多可用区
- 客户端配置镜像仓库地址时，应指向VIP或DNS域名，而非具体节点IP，确保故障时自动切换
数据一致性与故障自愈机制不可省略
高可用不只是“多开几个Pod”，更要保证数据不丢、状态可控、故障可恢复：
- Registry推送过程必须开启
storage.maintenance.uploadpurging: false，防止上传中断时清理未完成分片 - 开启定期垃圾回收（GC），但避开业务高峰；建议配置
dry_run: true先验证，再正式执行 - JobService任务失败需有重试+告警（如通过Prometheus+Alertmanager监控
harbor_job_status指标） - 所有配置文件（harbor.yml）、证书、密钥必须纳入GitOps管理，配合Argo CD等工具实现配置即代码与自动回滚
跨地域与多活场景下的复制策略
单一数据中心的HA只是基础；对全球化团队或灾备要求高的场景，需叠加镜像复制能力：
- 利用Harbor内置的Replication功能，在不同区域部署独立Harbor集群，配置双向或单向复制策略
- 复制任务建议按项目（Project）粒度划分，避免全量同步拖垮带宽；启用过滤器（Filter）只同步特定标签（如
^v[0-9]+\.[0-9]+\.[0-9]+$） - 复制链路必须走内网或专线，公网传输需启用TLS双向认证，并限制源IP白名单
- 复制状态需可视化监控，例如通过Harbor API拉取
/api/v2.0/replication/executions并聚合成功率与延迟
