×

从概念上讲,Operators 将人工操作知识编码到更容易与消费者共享的软件中。

Operators 是简化运行另一段软件的操作复杂性的软件组件。它们就像软件供应商工程团队的扩展,监控 Kubernetes 环境(例如 OpenShift Container Platform),并利用其当前状态实时做出决策。高级 Operators 旨在无缝处理升级,自动响应故障,并且不会采取捷径,例如跳过软件备份过程以节省时间。

更技术地说,Operators 是一种打包、部署和管理 Kubernetes 应用程序的方法。

Kubernetes 应用程序是在 Kubernetes 上部署并使用 Kubernetes API 和kubectloc工具管理的应用程序。为了充分利用 Kubernetes,您需要一组具有凝聚力的 API 来扩展,以便服务和管理在 Kubernetes 上运行的应用程序。可以将 Operators 视为在 Kubernetes 上管理此类应用程序的运行时。

为什么要使用 Operators?

Operators 提供

  • 安装和升级的可重复性。

  • 每个系统组件的持续运行状况检查。

  • OpenShift 组件和 ISV 内容的空中 (OTA) 更新。

  • 一个将现场工程师的知识封装起来并传播给所有用户(而不仅仅是一个或两个用户)的地方。

为什么要在 Kubernetes 上部署?

Kubernetes(以及 OpenShift Container Platform)包含构建复杂分布式系统所需的所有原语——密钥处理、负载均衡、服务发现、自动缩放——这些原语可在本地和云提供商之间运行。

为什么要使用 Kubernetes API 和kubectl工具管理您的应用程序?

这些 API 功能丰富,拥有所有平台的客户端,并可插入集群的访问控制/审核。Operator 使用 Kubernetes 扩展机制,自定义资源定义 (CRD),因此您的自定义对象(例如MongoDB)看起来和行为就像内置的原生 Kubernetes 对象一样。

Operators 与服务代理相比如何?

服务代理是朝着应用程序的编程发现和部署迈出的一步。但是,因为它不是长期运行的进程,所以它无法执行升级、故障转移或缩放等第 2 天操作。定制和可调参数的参数化是在安装时提供的,而 Operator 则不断监控集群的当前状态。集群外服务非常适合服务代理,尽管也存在用于这些服务的 Operators。

Operator 框架

Operator 框架是一系列工具和功能,用于交付上述客户体验。它不仅仅是编写代码;测试、交付和更新 Operators 同样重要。Operator 框架组件包括用于解决这些问题的开源工具

Operator SDK

Operator SDK 帮助 Operator 作者在其专业知识的基础上,启动、构建、测试和打包他们自己的 Operator,而无需了解 Kubernetes API 的复杂性。

Operator 生命周期管理器

Operator 生命周期管理器 (OLM) 控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。它在 OpenShift Container Platform 4.17 中默认部署。

Operator 注册表

Operator 注册表存储集群服务版本 (CSV) 和自定义资源定义 (CRD),用于在集群中创建,并存储关于包和通道的 Operator 元数据。它运行在 Kubernetes 或 OpenShift 集群中,为 OLM 提供 Operator 目录数据。

OperatorHub

OperatorHub 是一个 Web 控制台,供集群管理员发现和选择要安装在其集群上的 Operator。它在 OpenShift Container Platform 中默认部署。

这些工具的设计是可组合的,因此您可以使用任何对您有用的工具。

Operator 成熟度模型

Operator 中封装的管理逻辑的复杂程度可能会有所不同。一般来说,此逻辑高度依赖于 Operator 所代表的服务类型。

但是,可以对大多数 Operator 可能包含的某些功能集,概括 Operator 封装操作的成熟度规模。为此,以下 Operator 成熟度模型定义了通用 Day 2 操作的 Operator 的五个成熟阶段

operator maturity model
图 1. Operator 成熟度模型

上述模型还显示了如何通过 Operator SDK 的 Helm、Go 和 Ansible 功能最好地开发这些功能。