- 作者 | Maxime Hurtrel
- 译者 | 李大白
最近，我们的容器平台团队使我们的“私人托管注册表”服务普遍可用。在这篇博文中，我们将解释为什么 OVHcloud 选择将这项服务基于 Harbor 项目，为其构建了一个 Kubernetes Operator，并在 CNCF goharbor 项目下开源。
需要到S.MART进行注册
在我们的托管 Kubernetes 服务发布之后，我们收到了许多关于完全托管的私有容器镜像仓库的请求。
用于托管镜像的容器镜像仓库部署起来可能听起来很简单，但我们的用户提到生产级注册表（registry）解决方案是软件交付供应链的关键部分，实际上很难维护。
我们的客户要求企业级解决方案，通过设计来提供先进的基于角色的访问控制和安全性，因为对公开可用镜像中的漏洞的担忧增加并且对内容信任的要求成为必要。
用户经常称赞 Docker Hub 等服务的用户界面，但同时要求提供具有高可用性和 SLA 支持的服务。
开源和企业级功能集的完美结合
在调查了前景以及微调我们的功能集和定价模型之后，我们寻找了最好的现有技术来支持它，并登陆了CNCF 孵化项目 Harbor（由 VMWare 捐赠给 CNCF）。除了 Harbour 是少数几个达到 CNCF 孵化状态的项目之一，从而印证了社区的坚定承诺之外，它也成为了几个商业企业容器化解决方案的关键部分。我们还赞赏 Harbor 采取的方法，即不重复造轮子，而是将同类最佳技术用于漏洞扫描、内容信任和许多其他组件等组件。它利用 CNCF 强大的开源项目网络并确保出色的用户体验质量水平。
现在是时候采用这种 10k-GitHub-stars 技术并使其适应我们的具体案例了：为我们的用户管理数以万计的注册中心，每个注册中心都有特定数量的容器镜像和使用模式。
当然，高可用性（客户的软件集成和部署依赖于这项服务）以及数据持久性对我们来说是必须的。
此外，Kubernetes 确保无状态服务 HA 和对象存储（基于 Openstack Swift 并与 S3 API 兼容）是检查这些要求的明显选择。
解决云提供商规模的运营挑战
在几周内，我们在公测中开放了该服务，迅速吸引了数百名活跃用户。但是随着流量的激增，我们自然而然地遇到了第一个瓶颈和性能挑战。
我们联系了 Harbor 用户组和团队，他们亲切地向我们指出了潜在的解决方案，在对 Harbor 处理数据库连接的方式进行了一些小而关键的更改后，我们的问题得到了解决。这加强了我们的信念，即 Harbour 社区是强大的，并致力于项目的健康和用户的需求。
随着我们的服务蓬勃发展，没有真正的工具可以轻松适应 Harbor 实例的生命周期。我们对 Kubernetes 生态系统的承诺使 Kubernetes 的 Harbor 运营商的概念成为一种有趣的方法。
我们与 Harbour 维护人员进行了讨论，他们热烈欢迎我们开发它的想法，并将其作为Harbor Kubernetes Operator 官方开源。OVHcloud 非常自豪地在 Apache 2 许可证下的goharbor GitHub 项目中提供该项目。这个项目是我们对开源的坚定承诺以及我们愿意为我们喜爱的项目贡献我们的努力的另一个例子。
一个多才多艺的Operator，旨在适应任何环境的Harbor部署
熟悉 Harbor 项目的读者可能想知道，这个Operator为当前的部署目录（包括项目维护的 Helm Chart 版本）带来了什么价值。
Operator 设计模式正在迅速流行并模仿以应用程序为中心的控制器，该控制器扩展了 Kubernetes 以管理更复杂、有状态的应用程序。简而言之，它解决了与 Helm 不同的用例。虽然 Helm Chart 提供了一个一体化安装程序，它还可以从开源 Docker 镜像部署 Harbor 的不同依赖项（数据库、缓存等），但像我们这样的其他企业、服务运营商和云提供商将希望pick-and-choose这些组件背后的服务或技术。
我们还旨在扩展当前的 v0.5 运营商来管理 Harbor 的整个生命周期，从部署到删除，包括扩展、更新、升级和备份管理。
这将帮助生产用户达到他们的目标 SLO，例如从托管解决方案或他们已经维护的现有数据库集群中受益。
我们设计了 Operator（利用 OperatorSDK 框架），以便 Harbor 可选模块（Helm Chart 存储、漏洞扫描器等）和依赖项（注册表存储后端、关系和非关系数据库等）都可以轻松匹配您的特定用例。
OVHcloud 托管私有注册表服务背后的简化架构图
