2. Kubernetes Operator 概念解析

在进入多集群自动化部署之前，必须先理解 Operator 的本质。Operator 不是一段简单的脚本，而是一种将运维知识编码为软件的 Kubernetes 原生扩展模式。本节从模式定义、与 Controller 的关系、开发工具链和生命周期四个维度拆解 Operator 的核心概念。

2.1 Operator 模式定义

Operator 模式由 CoreOS 在 2016 年提出，其核心思想是：利用 Kubernetes 的自定义资源（CRD）和控制器（Controller），将特定应用或组件的整个生命周期管理逻辑封装为一个可自动运行的程序。这个程序被称为 Operator。

Operator 模式包含三个核心要素：

  • 自定义资源定义（CRD）：扩展 Kubernetes API，定义应用特有的配置模型（如 RedisCluster、MySQLCluster）。
  • 自定义控制器（Controller）：监听 CRD 实例的变化，执行调谐循环（Reconciliation Loop），确保实际状态与期望状态一致。
  • 运维知识编码：将备份、扩缩容、升级、故障恢复等人工运维操作，以代码形式固化在控制器中。
关键理解：Operator = CRD（数据模型）+ Controller（控制逻辑）+ 运维领域知识。三者缺一不可。
Operator 模式核心结构 Kubernetes API Server CRD / 自定义资源 Operator Controller + 运维逻辑 被管理应用 Pod / Service / PVC Watch CR 调谐控制 状态上报 / 事件 模式要点 1. CRD 定义了“期望状态”的数据结构（如副本数、版本、存储配置）。 2. Controller 通过 Watch 机制监听 CR 变化，驱动实际资源向期望状态收敛。 3. 运维知识（备份、故障恢复）被编码为控制器的调谐逻辑，实现自动化。

2.2 Operator 与 Controller 的关系

很多初学者混淆 Operator 和 Controller。实际上，Operator 是 Controller 的一种特殊形式，但二者在抽象层次和职责范围上有明显区别。

对比维度 Kubernetes Controller Operator
管理对象 内置资源（Deployment、Service、Job 等） 自定义资源（CRD 实例）
逻辑复杂度 通用、简单（如确保副本数） 领域特定、复杂（含备份、升级、故障恢复）
运维知识 无领域知识 深度编码领域运维知识
扩展方式 内置，无需额外安装 通过 CRD + 自定义控制器扩展
典型例子 kube-controller-manager 中的 ReplicaSetController etcd-operator、prometheus-operator
记忆口诀：所有 Operator 都是 Controller，但不是所有 Controller 都是 Operator。Operator = Controller + 领域运维知识。
Operator 与 Controller 的层次关系 Kubernetes 控制器体系 内置 Controller ReplicaSetController DeploymentController DaemonSetController JobController ... 管理内置资源，无领域知识 Operator（自定义 Controller） etcd-operator prometheus-operator redis-operator mysql-operator ... 管理 CRD 实例，含领域运维知识 扩展

2.3 Operator SDK 简介

手动编写 Operator 涉及大量样板代码：CRD 定义、控制器框架、调谐循环、RBAC 配置等。Operator SDK 是 Red Hat 主导的开源工具，旨在简化 Operator 的开发、测试和打包流程。目前主流版本基于 controller-runtime 库，支持 Go、Ansible、Helm 三种语言/方式。

SDK 类型 适用场景 优势 劣势
Go 类型 复杂业务逻辑、高性能要求 完全控制调谐逻辑，类型安全 开发周期长，需要 Go 语言基础
Ansible 类型 已有 Ansible Playbook 的运维团队 快速将现有自动化迁移为 Operator 调谐性能受限，调试较困难
Helm 类型 已有 Helm Chart 的简单应用 开发最快，适合无状态应用 无法处理复杂状态和故障恢复
课程选择：本课程后续实战全部使用 Go 类型 Operator SDK，因为多集群自动化部署需要精细控制调谐逻辑和集群间通信，Go 类型提供最大的灵活性和性能。

Operator SDK 的核心工作流程：

  1. 初始化项目：operator-sdk init --domain=example.com --repo=github.com/example/my-operator
  2. 创建 API：operator-sdk create api --group=cache --version=v1alpha1 --kind=MyApp --resource=true --controller=true
  3. 定义 CRD 结构：在 api/ 目录下编辑 Spec 和 Status 字段。
  4. 实现调谐逻辑：在 controllers/ 目录下编写 Reconcile 方法。
  5. 测试：使用 make test 运行单元测试，make install 部署 CRD 到集群。
  6. 构建与部署：make docker-build docker-push IMG=myregistry/my-operator:latest，然后 make deploy。
版本注意：Operator SDK 在 v1.x 之后将脚手架功能迁移到了 kubebuilder 项目。如果你使用最新版本，建议直接使用 kubebuilder init 命令，其底层依赖与 Operator SDK 一致。本课程示例兼容两种工具链。

2.4 Operator 生命周期管理

Operator 本身也是一个运行在 Kubernetes 上的应用，其生命周期包括安装、升级、扩缩容、健康检查、日志收集、卸载等环节。OLM（Operator Lifecycle Manager）是 Kubernetes 社区推荐的 Operator 生命周期管理框架。

OLM 引入几个关键概念：

概念 说明 类比
CatalogSource Operator 的元数据仓库，类似应用商店 apt 源 / yum 源
Subscription 定义用户订阅某个 Operator 及其更新频道 订阅杂志
OperatorGroup 指定 Operator 的目标命名空间范围 权限范围
ClusterServiceVersion (CSV) 描述 Operator 的版本、依赖、部署方式 RPM 包的 spec
InstallPlan 自动生成的安装/升级计划 apt install 的执行计划

Operator 的典型生命周期流程：

  1. 发现：用户通过 kubectl get catalogsource 查看可用 Operator。
  2. 订阅：创建 Subscription 资源，指定要安装的 Operator 和更新频道（stable、alpha 等）。
  3. 安装：OLM 自动解析依赖，生成 InstallPlan，用户批准后执行安装。
  4. 运行：Operator 以 Deployment 形式运行在集群中，开始管理 CRD 实例。
  5. 升级：当 CatalogSource 中有新版本时，Subscription 自动触发升级流程。
  6. 卸载：删除 Subscription 和 CSV，OLM 清理 Operator 及其相关资源。
多集群场景提示：在多集群架构中，每个集群可以独立部署 OLM 和 Operator，也可以通过中心集群统一推送 Subscription 到多个成员集群。本课程第 4 章将详细讲解多集群 Operator 的部署策略。

对于不依赖 OLM 的简单场景，也可以直接通过 kubectl apply 部署 Operator 的 YAML 清单（包含 Deployment、ServiceAccount、RBAC、CRD 等）。这种方式更轻量，但缺少自动升级和依赖管理能力。本课程后续实战将同时覆盖裸部署和OLM 部署两种方式，以适应不同规模的多集群环境。

← 上一章 📖 返回目录 下一章 →