运维 Harbor 镜像仓库的法宝：Operator

题图摄于北京奥林匹克公园



不知不觉，Harbor 开源项目发布后我们已经走过了 4 个年头，Github 上的星星数超过1万1千，参与贡献代码的开发者有170多位。随着 Harbor 功能的完善，用户对 Harbor 的认可度很高，在生产系统中的部署也越来越多，我们也从用户反馈中了解到需要改进的地方。比较多用户的呼声是需要 Harbor 的Operator，以便更好地管理多个 Harbor 镜像仓库实例。



Operator 是 Kubernetes 上运维服务的一种模式，经历了数年的发展，社区中被频繁地关注和谈及，基本上得到了用户的接受。对于 Operator 的作用有不同的理解，有人认为是一组 CRD，亦或是个开发框架；也有人认为是设计模式和管理工具。但有一点可以确定：它源自管理复杂、有状态的应用的需要，而此前的方法还有不尽人意之处。



长期使用 Harbor 的用户可能会对 Operator 有疑问，它与当前 Harbor 的 Helm Chart 部署相比，到底适合怎样的场景？简单地说，Helm 是模板化工具，允许定制不同应用的部署 YAML，而 Operator 的设计目的是通过更好的自动化来简化日常的管理事务。



Operator 受欢迎的原因之一，是因为它使开发人员能够使用自定义控制器 （Controller） 和自定义资源定义（Custom Resource Definition，CRD）来扩展 Kubernetes 控制平面，从而实现真正的声明式 API。这赋予了开发人员比用默认控制器更大的自由度，可管理除 Kubernetes 内置对象之外的其它资源。在 Harbor 的 Operator 中，控制器被有效地挂接到消息传递队列中，允许不断地保持在特定的状态。



欧洲领先的公有云厂商 OVHcloud 在 Harbor Operator 方面的取得不少进展，他们的成果让 Harbor 项目开发人员非常兴奋！OVHcloud 把他们的成果贡献给了 Harbor 项目，成为 Harbor Operator v0.5，希望它能发扬光大，让更多的用户使用。V0.5版本主要功能：



• Harbor 作为自定义资源部署，将 Notary、Chartmuseum 和 Clair 作为可选组件

• 支持使用 ConfigMap 和 secret 来配置

• 可自动清除 Harbor 实例



OVHcloud 作为公有云服务提供商，给用户提供私有镜像仓库的解决方案，需要管理数百甚至数万个 Harbor 实例，为 Harbor 构建一个 Operator 可能是 OVHcloud 的最佳选择，能够从现有组件中挑选满足其需求的部分来使用。



通过 Operator 我们希望解决社区要解决的一些遗留问题，包括备份和恢复、零接触式就地升级和开箱即用的企业级 HA 部署。在 OVHcloud 已经完成功能的基础上，加上 Redis 和 PostgreSQL Operator，Harbor 项目维护者计划构建一个 Harbor 集群的 Operator，它将包含 HA 的完整安装体验。用户将能够使用该 Operator 来创建、扩展、升级、备份和下线 Harbor集群。



Harbor 社区越来越壮大，来自 OVHcloud 的 Pierre Peronet 和 Jeremie Monsinjon 将成为 Harbor 项目的维护者，专注于 Harbor Operator 和相关的功能。感兴趣的用户请关注我们的进展，也欢迎反馈问题或建议。



（本文根据 Harbor 项目产品经理徐天行的英文博客翻译和改编。）



Harbor社区联系方式

双周例会，周三晚9点（中英文）：goharbor.community/MEETING_SCHEDULE.md

Email组：

harbor_dev at lists.cncf.io ， harbor_users at lists.cncf.io

微信公众号：HarborChina (官方公众号)

GitHub： Github.com/goharbor

要想了解更多云原生和人工智能等技术原理，请立即长按以下二维码，关注本公众号亨利笔记，以免错过更新。