Module 04 · The Kubernetes Ecosystem: OpenShift, Istio, etc.
OperatorsKubernetes Operators 深度解析
Operator 的定义与作用
Operator 是一种自动化集群任务的机制，它充当自定义控制器（Custom Controller）来扩展 Kubernetes API。
Operator 的功能
- 扩展 API: 充当自定义控制器，扩展 Kubernetes API 功能。
- 运行环境: 运行在 Pod 中，与 API Server 交互。
- 应用管理: 封装、部署和管理 Kubernetes 原生应用程序。
- 自动化决策: 通过持续的实时决策，自动化应用程序的创建、配置和管理。
- 任务自动化: 自动化其他任务，并确保包含所有相关组件。
人类操作员 vs. 软件操作员
| 类型 | 角色 | 目标 |
|---|---|---|
| 人类操作员 (Human Operators) | 了解他们所控制的系统；知道如何部署服务以及如何识别和修复问题。 | 确保系统正常运行。 |
| 软件操作员 (Software Operators) | 试图捕获人类操作员的知识，并自动化相同的流程。 | 实现系统运维的自动化和标准化。 |
Operator 的优势
- 安装升级: 易于实现可重复的安装和升级过程。
- 健康检查: 对系统中的每个组件进行定期的全面系统健康检查。
- 自动更新: 为组件和软件供应商内容提供 OTA（Over-The-Air）更新。
- 知识传播: 收集和传播现场工程师的知识给所有用户。
- 集成: 与
kubectl和oc等 API 和 CLI 工具集成。
Service Broker 与 Operator 对比
| 特性 | Service Broker (服务代理) | Operator (操作器) |
|---|---|---|
| 进程类型 | 短时运行（Short-running）进程。 | 长时运行（Long-running）进程。 |
| 连续操作 | 无法执行连续操作，例如：升级、故障转移或伸缩。 | 可以每天执行升级、故障转移或伸缩等操作。 |
| 定制化 | 仅在安装时进行定制和参数化。 | 持续监控集群的当前状态，随时进行定制和参数化。 |
| 服务位置 | 集群外服务（Off-cluster services）。 | 集群外服务。 |
Operator 模式的基础组件
Operator 模式是基于 CRD 和自定义控制器的组合。
1. 自定义资源定义 (Custom Resource Definitions, CRDs)
- 作用: 存储和检索 Kubernetes API 中的对象。
- 扩展性: 扩展 Kubernetes 功能，超越了 Deployment 和 Pod 等内置资源。
- 灵活性: 使 Kubernetes API 更具模块化和灵活性。
- 可用性: CRD 仅在其安装的集群内可用。
- 访问: 一旦安装，CRD 对象即可使用
kubectl访问，类似于 Pod 和其他资源。
2. 自定义控制器 (Custom Controllers)
- 作用: 用于改变集群状态。
- 工作原理: 协调集群的实际状态与其配置状态。
- 自定义控制器对自定义资源执行相同的协调工作。
- 自定义控制器对自定义资源执行相同的协调工作。
Operator 模式（Operator Pattern）
- 定义: CRDs 与自定义控制器结合使用，创建了一个声明式 API。
- 工作原理: 自定义控制器将 CRD 数据解释为期望状态，并协调集群的实际状态以匹配 CRD 数据 .
Operator Framework 与生态
Operator Framework 是一个开源工具集，涵盖了 Operator 的编码、测试、交付和更新。
| 组件 | 描述 |
|---|---|
| Operator SDK | 帮助作者构建、测试和打包 Operator，无需了解复杂的 Kubernetes API 细节。包括 Helm、Go 和 Ansible 能力。 |
| Operator Lifecycle Manager (OLM) | 控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。 |
| Operator Registry | 存储 CRDs、集群服务版本 (CSVs) 以及用于包和通道的 Operator 元数据。它在集群中运行，为 OLM 提供 Operator 目录数据。 |
| Operator Hub | 一个 Web 控制台，允许集群管理员查找并一键安装 Operator 到其集群中。 |
Operator 成熟度模型 (Maturity Model)
Operator 成熟度模型定义了 Operator 在日常操作活动中的成熟度阶段，范围从基本安装到自动驾驶（Autopilot）。
- 它还展示了 Operator SDK 的 Helm、Go 和 Ansible 功能支持哪些活动。
Operator 示例与应用
Operator 的应用示例包括：
- 应用部署: 不仅限于 Deployment，还包括 Secret、ConfigMap 和存储资源等。
- 应用伸缩: 根据应用类型，在多个副本的帮助下伸缩应用。
- 例行任务自动化: 自动化集群中的例行任务，例如对应用程序状态进行备份和恢复。
- 集成: 与其他系统集成。
详细示例：部署完整应用程序
- 为应用创建自定义资源（CR）。
- 为该 CRD 创建自定义控制器。
- Operator 逻辑确定如何协调实际状态和配置状态。
- 一个 CRD 需要创建 Deployment、Service、Storage 和其他对象。
Operator Hub 上的 Operator 类型
通过 OpenShift Web Console 的 Operator Hub 视图，可以一键安装 Operator。Operator Hub 提供了多种类型的 Operator：
- Red Hat Operators
- 认证 Operators：来自与 Red Hat 合作的独立服务供应商（ISV）。
- 社区 Operators：来自开源社区，但未得到 Red Hat 官方支持。
- 自定义 Operators：由用户自行定义。
📌 应用: 您可以通过 Operator Hub 安装许多 Kubernetes 生态系统中的工具，例如 Istio Service Mesh。
总结
- CRDs 扩展了 Kubernetes API。
- CRDs 与自定义控制器结合，在 Kubernetes 中创建新的声明式 API。
- Operators 使用 CRDs 和自定义控制器来自动化集群任务。
- Operator Framework 涵盖了编码、测试、交付和更新。
- Operator 成熟度模型定义了日常操作活动的成熟度阶段。