本文发表时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

使用 OperatorHub.io 自动化集群上的操作

作者：Diane Mueller (Red Hat) |

开发人员和 Kubernetes 管理员面临的重要挑战之一是缺乏快速找到可用于 Kubernetes 的、已准备好进行操作的通用服务的能力。通常，特定服务的 Operator 的存在（该模式于 2016 年引入并获得了发展势头）是该服务在 Kubernetes 上是否已准备好运行的良好信号。然而，迄今为止，还没有一个 Operator 注册表来简化此类服务的发现。

为了帮助解决这一挑战，今天 Red Hat 与 AWS、Google Cloud 和 Microsoft 合作推出了 OperatorHub.io。OperatorHub.io 使开发人员和 Kubernetes 管理员能够查找和安装经过精选的、由 Operator 支持的服务，这些服务具有基本的文档、社区或供应商的积极维护、基本测试以及针对 Kubernetes 上优化的生命周期管理进行打包。

目前在 OperatorHub.io 中的 Operator 只是一个开始。我们邀请 Kubernetes 社区加入我们，通过在 OperatorHub.io 上开发、打包和发布 Operator 来建立一个充满活力的 Operator 社区。

OperatorHub.io 提供什么？

OperatorHub.io 旨在满足 Kubernetes 开发人员和用户的需求。对于前者，它提供了一个通用注册表，他们可以在其中发布他们的 Operator，并附带描述、相关详细信息（如版本、镜像、代码仓库），并将其轻松打包以进行安装。他们还可以在发布新版本时更新已发布的 Operator。

用户可以在中央位置发现和下载 Operator，该位置的内容已根据先前提及的标准进行筛选，并扫描了已知漏洞。此外，开发人员可以使用他们引入的 CustomResources 的规范示例来指导其 Operator 的用户与应用程序进行交互。

什么是 Operator？

Operator 最初由 CoreOS 于 2016 年引入，并已被 Red Hat 和 Kubernetes 社区用作打包、部署和管理 Kubernetes 原生应用程序的一种方式。Kubernetes 原生应用程序是一个既部署在 Kubernetes 上，又使用 Kubernetes API 和众所周知的工具（如 kubectl）进行管理的应用程序。

Operator 被实现为自定义控制器，该控制器监视某些 Kubernetes 资源的出现、修改或删除。这些通常是 Operator “拥有”的 CustomResourceDefinitions。在这些对象的 spec 属性中，用户声明应用程序或操作的所需状态。Operator 的协调循环将拾取这些属性并执行必要的操作以实现所需状态。例如，创建高可用性 etcd 集群的意图可以通过创建 EtcdCluster 类型的新资源来表达

apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
  name: "my-etcd-cluster"
spec:
  size: 3
  version: "3.3.12"

作为结果，EtcdOperator 将负责创建运行 v3.3.12 版本的 3 节点 etcd 集群。类似地，可以定义 EtcdBackup 类型的对象来表达将 etcd 数据库的持久备份创建到 S3 存储桶的意图。

如何创建和运行 Operator？

一种入门方式是使用 Operator Framework，这是一个开源工具包，提供 SDK、生命周期管理、计量和监控功能。它使开发人员能够构建、测试和打包 Operator。Operator 可以用多种编程和自动化语言实现，包括 Go、Helm 和 Ansible，这三种语言都由 SDK 直接支持。

如果您有兴趣创建自己的 Operator，我们建议您查看 Operator Framework 以入门。

Operator 在 能力范围 中各不相同，从基本功能到具有应用程序的特定操作逻辑，以自动化高级场景（如备份、还原或调整）。除了基本安装之外，高级 Operator 旨在更无缝地处理升级并自动对故障做出反应。目前，OperatorHub.io 上的 Operator 涵盖了成熟度范围，但我们预计它们会随着时间的推移继续成熟。

虽然 OperatorHub.io 上的 Operator 不需要使用 SDK 实现，但它们通过 Operator Lifecycle Manager (OLM) 打包以进行部署。该格式主要由称为 [ClusterServiceVersion](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/building-your-csv.md) 的 YAML 清单组成，该清单提供有关 Operator 拥有或需要的 CustomResourceDefinitions、它需要的 RBAC 定义、镜像存储位置等信息。此文件通常附带定义 Operator 自己 CRD 的其他 YAML 文件。当用户请求安装 Operator 时，OLM 会处理此信息以提供依赖项解析和自动化。

在 OperatorHub.io 上列出 Operator 意味着什么？

要被列出，Operator 必须成功显示集群生命周期功能，打包为可通过 OLM 维护的 CSV，并为其预期用户提供可接受的文档。

目前在 OperatorHub.io 上列出的一些 Operator 示例包括：Amazon Web Services Operator、Couchbase Autonomous Operator、CrunchyData 的 PostgreSQL、etcd Operator、Kubernetes 的 Jaeger Operator、Kubernetes Federation Operator、MongoDB Enterprise Operator、Percona MySQL Operator、PlanetScale 的 Vitess Operator、Prometheus Operator 和 Redis Operator。

想将您的 Operator 添加到 OperatorHub.io 吗？请按照以下步骤操作

如果您有现有的 Operator，请使用 community-operators 存储库的分支，按照 贡献指南 进行操作。每个贡献都包含 CSV、所有 CustomResourceDefinitions、访问控制规则以及安装和运行 Operator 所需的容器镜像的引用，以及其他信息，如其功能描述和支持的 Kubernetes 版本。完整的示例（包括 Operator 的多个版本）可以在 EtcdOperator 中找到。

在您自己的集群上测试您的 Operator 后，请按照 此目录结构 将所有 YAML 文件提交到 community 存储库的 PR。Operator 的后续版本可以通过相同的方式发布。最初，这将进行手动审查，但自动化正在进行中。由维护人员合并后，它将与文档和便捷的安装方法一起显示在 OperatorHub.io 上。

想了解更多信息吗？