Docker镜像仓库高可用需从存储、服务、网络三层解耦冗余：存储层用S3/MinIO等对象存储实现持久化；服务层部署多Registry实例+负载均衡，共享后端存储；网络层通过registry-mirror缓存与DNS轮询优化分发。
Docker 镜像仓库要真正扛住生产环境压力，光靠单台 Registry 不够，得从存储、服务、网络三个层面做冗余和解耦。
存储层必须分离且持久化
本地磁盘存镜像风险极高，一坏全丢。推荐用 S3 兼容的对象存储，比如 MinIO（私有部署）或 AWS S3（公有云）。Registry 本身不存数据，只作元数据和转发代理，所有 blob 层都写入对象存储。这样即使 Registry 实例宕机或重建，镜像数据完全不受影响。配置时在 config.yml 中指定 storage backend：
storage:
s3:
region: us-east-1
bucket: my-registry-bucket
accesskey: xxx
secretkey: xxx
endpoint: http://minio.example.com:9000
secure: false # 内网可关 HTTPS多实例 + 负载均衡 + 故障自动切换
至少部署两个 Registry 实例（跨可用区或不同物理机），前面挂 Nginx 或 HAProxy 做四层/七层负载。关键点是：
- 所有实例共享同一后端存储（S3/MinIO），避免数据不一致
- 启用
http.headers.x-forwarded-for和健康检查路径（如/healthz） - 配合
registry-mirror在 CI/CD 构机构建节点本地缓存热门镜像，降低主库并发压力
缓存与镜像分发优化
不是所有节点都直连主 Registry。建议在每个构建集群或边缘机房部署轻量级 Registry Mirror（如 registry:2.8.1 加 mirror 模式），配置上游为你的主仓库地址。它会自动缓存拉取过的镜像层，下次请求直接返回，大幅减少主库 IO 和带宽消耗。
状态无感与自动恢复设计
Registry 本身是无状态服务，所以扩容缩容简单。但要注意两点：
- 认证信息（如 htpasswd 文件）需通过 ConfigMap 或共享存储统一挂载
- TLS 证书、配置文件必须集中管理，避免实例间不一致
基本上就这些。高可用不是堆机器，而是让每个环节都能独立失效而不影响整体可用性。
