TL;DR 通过 Harbor Operator 简化 Harbor 的安装和 Day 2 运维操作。点击此处了解更多。

Harbor 自三年多前发布以来，用户采用率一直很高，并且在过去几个季度中，生产部署的数量不断增加。这种稳步增长揭示了我们可以在几个方面进行改进，特别是需要 Harbor 的 Operator 版本，以便更好地管理注册表的多个实例。

“Operator” 这个术语已经流传多年，如果最近 KubeCon 活动中的讨论有任何迹象表明，它似乎正在被广泛接受。但是，尽管对于 Operator 的作用有不同的看法（Operator 是一组 CRD、一个框架？、一种设计模式？、一种管理工具？），但有一点是肯定的：它的诞生源于对管理更复杂、有状态的应用程序的需求，而当前的方法已显得不足。Harbor 的长期用户可能会想知道 Operator 版本与当前 Harbor 的 Helm Chart 部署有何关系。答案是，虽然 Helm 带来了模板化，并允许为不同的工作负载部署自定义 YAML，但 Operator 的设计旨在通过更好的自动化来促进 Day 2 运维管理任务。

Operator 方法之所以受欢迎，是因为它使第三方开发人员能够使用自定义控制器和自定义资源定义 (CRD) 来扩展 Kubernetes 控制平面，从而实现真正的声明式 API。这使开发人员能够比使用默认控制器的内置 Kubernetes 对象更好地控制资源。使用 Operator 版本，控制器有效地连接到消息队列，从而允许持续地向指定的期望状态进行协调。

当欧洲领先的公共云厂商之一 OVHcloud 联系我们，分享他们在 Harbor Operator 方面的独立工作时，我们感到非常兴奋！OVHcloud 随后在 goharbor 项目下发布了这项工作，作为 Harbor Operator v0.5，希望它能覆盖尽可能多的受众。点击此处了解如何部署 Operator 并进行测试。具体来说，当前版本将允许您

• 将 Harbor 部署为自定义资源，并将 Notary、Chartmuseum 和 Clair 视为可选组件
• 支持通过使用 ConfigMaps 和 secrets 进行配置
• 销毁 Harbor 实例并自动清理

您还可以阅读 OVHcloud 为何选择 Harbor 作为其注册表即服务 (registry-as-a-service)，以及他们为创建 Harbor Operator 的第一个版本所做的工作，请点击此处。作为一家托管服务提供商，需要一个专门的私有注册表来从管理数百个 Harbor 实例扩展到数万个，为 Harbor 构建 Operator 是 OVHcloud 能够从一些现有组件中挑选并选择以满足其需求的最佳方式。

通过 Operator，我们希望解决社区要求的一些遗留问题，包括备份和恢复、零接触原地升级以及面向企业级部署的开箱即用的 HA（高可用性）。通过利用 OVHcloud 已完成的工作，以及 Redis 和 PostgreSQL 现有 Operator 的工作，我们计划构建一个 Harbor 集群 Operator，它将包含一个包含 HA 的一体化安装体验。您将能够使用此 Operator 只需单击一下即可配置、扩展、升级、备份和停用您的 Harbor 集群。

我们也很高兴地宣布，来自 OVHcloud 的 Pierre Peronet 和 Jeremie Monsinjon 将作为维护者加入 Harbor 项目，专注于 Harbor Operator 和任何相关的 Day 2 运维体验。请在此处关注我们的进展，如有任何问题或建议，请告知我们。

与 Harbor 社区协作！

加入 Harbor 社区会议和邮件列表
在 Twitter 上关注 @project_harbor 获取更新
在 CNCF Slack 的 #harbor 频道上与我们聊天
在 GitHub 上与我们协作： github.com/goharbor/harbor

Alex Xu
Harbor 贡献者
VMware 产品经理
github.com/xaleeks