Harbor系列-03-企业化部署的提升
概述
一般在使用 Harbor 上，大部分场景就是部署一个 Harbor 然后就上线了，运维一定时间之后，就会遇到各种问题，下面就这些问题，针对通过 Helm 部署在 Kubernetes 集群的的 Harbor，简单介绍一下场景和建议。
事件中心接入事件
Harbor 部署在 Kubernetes 中，那么所有的组件包括数据库，Redis，Registry 这些组件都是以 Pod 的方式运行的，下面是组件的清单:
|
|
既然这么多组件，那么随便挂一个 Pod 或者重启有问题，都需要即时可以发现的，所以这里的建议是将 Kubernetes 的事件，尤其是告警级别的事件采集出来，通过公司内部的告警通道发送到负责人，这样才能及时发现 Harbor 的问题，迅速做出反应。
LDAP支持
Harbor 提供的 UI 的访问能力，在公司内的用户肯定不会少，针对开发或者其他角色的人员，不能每来一个人申请，就手动创建一个账户，即使通过接口来创建，后续也会面临很多关于用户方面的维护问题，因此这里建议公司内的 Harbor 可以通过接入 LDAP，并且同步接入公司的 OA 等人员、架构的信息。
基础镜像预热
Harbor 虽然是部署在 Kubernetes 上，理论上已经提供了相当不错的高可用的能力了，但是为了防止 Harbor 意外崩溃，导致无法拉取一些关键镜像，比如说 Harbor 崩溃了，但是 Harbor 部署的时候需要从 Harbor 拉取镜像这样的「鸡生蛋，蛋生鸡」的问题，因此一些业务、组件重要的基础镜像，需要有一个机制来预热到 Kubernetes 中的工作节点。
公网镜像同步
这里主要是指一些国内无法拉取的镜像的场景，不如 gcr.io 这些镜像仓库，需要一些机制来同步到公司内部，这里不管是通过代理还是其他方法，都是需要考虑实现的，否则公司内部在拉取这些镜像的时候就会非常麻烦，影响开发迭代的速度。
项目功能对接和启用
Harbor 中的镜像仓库是有项目概念的，需要利用好，项目内还会针对用户可以提供一些细粒度的权限管理的机制。
仓库密码管理
针对一些项目维度的镜像，可以通过分发一些机器人账号密码来提供给 Kubernetes 集群使用，这里面可以通过写一个后台的服务，给业务或者用户来去获取。