什么是 Kubernetes Operator？

• Kubernetes Operator 是一种封装、部署和管理 Kubernetes 应用的方法。 
• Kubernetes 应用既部署在 Kubernetes 上，也可使用 Kubernetes API（应用编程接口）和 kubectl 工具进行管理。
• Kubernetes Operator 使用可自动化运营任务的持续协调循环来管理应用。
• Operator 框架是一个开源项目，提供开发人员和运行时 Kubernetes 工具。
• Kubernetes Operator 模式的出现，源于 Kubernetes 缺乏安全处理复杂的有状态系统（例如数据库和消息队列）所需的内部逻辑。
• 红帽 OpenShift Operator 可以通过定义和实施任意资源以及与资源相关的自定义逻辑，来自动化与原生 OpenShift 资源相关的自定义工作流。

什么是 Kubernetes Operator？

Kubernetes Operator页面当前以 English 显示（暂无 zh 选项） 是一种打包、部署和管理 Kubernetes 应用的方法。Kubernetes 应用既部署在 Kubernetes 上，也可使用 Kubernetes API（应用编程接口）和 kubectl 工具进行管理。

Kubernetes Operator 是一种特定于应用的控制器，可扩展 Kubernetes API 的功能，来代表 Kubernetes 用户创建、配置和管理复杂应用的实例。

它基于基本 Kubernetes 资源和控制器概念构建，但又涵盖了特定于域或应用的知识，用于实现其所管理软件的整个生命周期的自动化。 

在 Kubernetes 中，控制平面的控制器实施控制循环，反复将集群的预期状态与实际状态进行比较。如果集群的实际状态与预期状态不匹配，则控制器会采取措施解决问题。 

Operator 是一种自定义 Kubernetes 控制器，它使用自定义资源（CR）来管理应用及其组件。高级配置和设置由用户通过 CR 提供。Kubernetes Operator 根据 Operator 逻辑中嵌入的最佳实践，将高级指令转换为低级操作。

自定义资源是 Kubernetes 中的 API 扩展机制。自定义资源定义（CRD）定义了一个 CR，并列出 Operator 用户可用的所有配置。 

Kubernetes Operator 监视 CR 类型，并执行特定于应用的操作，使该资源的当前状态与预期状态匹配。

Kubernetes Operator 通过自定义资源定义引入新的对象类型。Kubernetes API 可以像处理内置对象一样处理自定义资源定义，包括通过 kubectl 进行交互，以及纳入基于角色的访问权限控制（RBAC）策略。

Kubernetes Operator 会在应用程序运行期间持续对其进行监控，并能随着时间的推移自动备份数据、从故障中恢复以及升级应用。 

Kubernetes Operator 执行的操作几乎可以包括任何内容：扩展复杂的应用、应用版本升级，甚至在具有专用硬件的计算集群中管理节点的内核模块。

获取 Kubernetes Operator 电子书

Kubernetes Operator 使用持续协调循环来管理应用，将通常需要人类工程师执行的运营任务自动化。它们是标准 Kubernetes 资源与软件复杂的内部运营需求之间，特定于应用的桥梁。

Kubernetes 可以管理和扩展无状态应用（例如 Web 应用、移动后端和 API 服务），而无需额外了解这些应用的运行机制。Kubernetes 具有多项内置功能，旨在轻松处理这些任务。

但是，有状态应用（例如数据库和监控系统）需要额外的特定领域知识，而 Kubernetes 并不具备这些知识。它需要这些知识来扩展、升级和重新配置这些应用。

Kubernetes Operator 将这些特定领域知识编码到 Kubernetes 扩展中，以便管理和自动化应用的生命周期。

通过消除繁琐的手动应用管理任务，Kubernetes Operator 使这些流程标准化并具备可扩展性和可重复性。

对于应用开发人员而言，借助 Operator，能够更轻松地部署和运行应用所依赖的基础服务。 

对于基础架构工程师和供应商而言，Operator 提供了一种在 Kubernetes 集群上分发软件的一致方式，并通过识别和修复应用问题来减轻支持负担。 

除了 Kubernetes 中提供的基本自动化功能外，Operator 还允许您编写代码以实现任务自动化。对于采用 DevOps 或站点可靠性工程（SRE）方法的团队而言，Operator 旨在将 SRE 实践融入 Kubernetes。 

Operator 模式的作用是捕捉运维人员管理服务时的意图。运维人员需要全面了解应用或服务的运作方式、部署方式以及如何解决可能出现的任何问题。

通常情况下，由站点可靠性工程师或运维团队负责编写用于管理应用的软件，但 Operator 旨在将人类运维知识编码到软件中，从而管理和部署 Kubernetes 工作负载，同时消除手动任务。 

Operator 最好由精通安装、运行和升级特定应用的业务逻辑的人员来构建。

创建 Operator 通常从实现应用安装和自助服务置备的自动化开始，然后是更复杂的自动化能力。

还有一个 Kubernetes Operator 软件开发套件（SDK），可帮助您开发自己的 Operator。SDK 提供了用于构建、测试和打包 Operator 的工具，并提供了使用 Helm Charts、Ansible Playbook 或 Golang 创建 Operator 的选项

Operator 框架是一个开源项目，提供开发人员和运行时 Kubernetes 工具，使您能够加速 Operator 的开发。

Operator 框架包括：

• Operator SDK：使开发人员能够根据自己的专业知识构建 Operator，而无需了解 Kubernetes API 的复杂性。
• Operator 生命周期管理：监督 Kubernetes 集群中运行的所有 Operator 的安装、更新和生命周期管理。
• Operator Metering：为提供专业服务的 Operator 启用使用情况报告。

使用 Operator 模式背后的原因和动机是什么？

Kubernetes Operator 模式的出现，源于标准 Kubernetes 中的一个关键限制——它缺乏安全处理数据库、消息队列等复杂有状态系统所需的内部逻辑。传统上，要管理这些系统，需要人类站点可靠性工程师（SRE）手动执行 Playbook 来进行备份、版本升级和多节点故障转移。

Operator 通过将人类运营知识直接编码到软件中来应对这一挑战。通过将自定义资源与自动化协调循环相结合，Operator 将手动运维检查清单转变为持续的、具有自我修复能力的自动化流程。这为工程团队带来了巨大的好处：它消除了手动配置偏移，实现了无风险的滚动升级，并允许企业组织使用完全相同的标准化声明式 YAML 清单，在任意云平台上部署复杂、高度可用的软件。

红帽® OpenShift® Operator 是红帽 OpenShift 的一种扩展机制。他们可以通过定义和实施任意资源以及与这些资源相关的自定义逻辑，自动执行与原生 OpenShift 资源相关的自定义工作流。红帽在这篇博客文章中对此进行了深入探讨。 

红帽® OpenShift® 是一个企业就绪型 Kubernetes 容器平台，具有全堆栈自动化运维功能，可用于管理混合云和多云部署。

红帽 OpenShift 使用 Kubernetes Operator 自主运行整个平台，同时通过 Kubernetes 对象以原生方式公开配置，从而实现快速安装和频繁而可靠的更新。 

红帽 OpenShift 内置嵌入式 OperatorHub，这是汇集软件供应商与开源项目提供的认证 Operator 的资源仓库。在 OperatorHub 中，您可以浏览和安装 Operator 库，这些 Operator 已经过验证，可与红帽 OpenShift 配合使用，并且经过打包，可轻松进行生命周期管理。

免费试用红帽 OpenShift