什么是 Operators？- 理解 Operators | Operators | OpenShift Dedicated

为什么要使用操作员？
操作员框架
操作员成熟度模型

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

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

从更技术的角度来看，操作员是打包、部署和管理 Kubernetes 应用程序的一种方法。

Kubernetes 应用程序是在 Kubernetes 上部署并使用 Kubernetes API 和kubectl 或oc 工具进行管理的应用程序。为了充分利用 Kubernetes，您需要一套能够扩展的内聚 API 来服务和管理在 Kubernetes 上运行的应用程序。可以将操作员视为在 Kubernetes 上管理此类应用程序的运行时。

为什么要使用操作员？

操作员提供

安装和升级的可重复性。
每个系统组件的持续运行状况检查。
OpenShift 组件和 ISV 内容的无线 (OTA) 更新。
一个将现场工程师的知识封装起来并传播给所有用户（而不仅仅是一两个用户）的地方。

为什么要在 Kubernetes 上部署？: Kubernetes（以及 OpenShift Dedicated）包含构建复杂分布式系统所需的所有原语——密钥处理、负载均衡、服务发现、自动缩放——这些原语可在本地和云提供商之间工作。
为什么要使用 Kubernetes API 和kubectl 工具来管理您的应用程序？: 这些 API 功能丰富，拥有适用于所有平台的客户端，并且可以插入集群的访问控制/审核。操作员使用 Kubernetes 扩展机制（自定义资源定义 (CRD)），因此您的自定义对象（例如MongoDB）看起来和行为都像内置的本机 Kubernetes 对象。
操作员与服务代理相比如何？: 服务代理是朝着应用程序的程序化发现和部署迈出的一步。但是，因为它不是长期运行的进程，所以它无法执行升级、故障转移或缩放等第 2 天操作。定制和可调参数的参数化是在安装时提供的，而操作员则不断监视集群的当前状态。集群外服务非常适合服务代理，尽管也存在用于这些服务的操作员。

操作员框架

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

操作员 SDK: 操作员 SDK 帮助操作员作者根据其专业知识启动、构建、测试和打包他们自己的操作员，而无需了解 Kubernetes API 的复杂性。
操作员生命周期管理器: 操作员生命周期管理器 (OLM) 控制集群中操作员的安装、升级和基于角色的访问控制 (RBAC)。它在 OpenShift Dedicated 中默认部署。
操作员注册表: 操作符注册表存储集群服务版本 (CSV) 和自定义资源定义 (CRD)，以便在集群中创建，并存储关于包和通道的操作符元数据。它运行在 Kubernetes 或 OpenShift 集群中，为 OLM 提供此操作符目录数据。
OperatorHub: OperatorHub 是一个 Web 控制台，供集群管理员发现和选择要在其集群上安装的操作符。它在 OpenShift Dedicated 中默认部署。

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

操作符成熟度模型

封装在操作符中的管理逻辑的复杂程度可能会有所不同。通常，此逻辑高度依赖于操作符所代表的服务类型。

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

图 1. 操作符成熟度模型

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