概述 通过 Helm Charts 部署的 Harbor，其中里面的 PostgreSQL 以及 Redis 通过调整参数，使用外部的高可用数据库，可以为 Harbor 提供更稳定的服务，虽然这些数据库的运维和操作

概述 在某些场景下，可能会存在中心、下游镜像仓库这样的概念，中心仓库和下游客户仓库的关系图大概可以理解成下面的示意图: 接口调用逻辑 涉及到的接口

概述 一般在使用 Harbor 上，大部分场景就是部署一个 Harbor 然后就上线了，运维一定时间之后，就会遇到各种问题，下面就这些问题，针对通过 Helm 部署在 Kubernetes 集群的的 Ha

概述 为什么会有这样的需求呢，主要还是作为平台的提供方，免不了要做一些组件的升级、维护之类的操作，那么怎么去通知用户呢？最好的办法就是在 Harbor 的前

概述 Harbor 的指标主要分成五部分，分为是 Info, Core, General, JobService 和 Registry。 指标 下图是 Harbor 官方给的 Grafana 的 Dashboard，截止目前已经有17个月没有更新过了

概述 目前随着 Kubernetes 在各个企业的流行，用 Helm Chart 把 Harbor 部署到 Kubernetes 集群上已经变成非常稳定和常规的做法了，但是如果需要同步其他公网仓库的镜像的话，这样就会有网