2. Kubernetes Operator 基础：Operator 模式原理、CRD 与 Controller 核心概念、Operator 工作流程

在深入诊断 Operator API 延迟之前，必须牢固掌握 Operator 的底层运行机制。Operator 本质上是将运维专家的领域知识编码为软件，通过 Kubernetes 原生机制自动管理复杂有状态应用。本章从模式原理、核心组件和工作流程三个维度建立完整认知。

2.1 Operator 模式原理

Operator 模式的核心思想是“用软件模拟人类运维工程师的决策循环”。传统运维人员通过 kubectl 观察集群状态，对比期望状态（Desired State）与实际状态（Actual State），然后执行操作（扩容、备份、升级）使实际状态趋近期望状态。Operator 将这个闭环自动化。

Operator 模式依赖两个 Kubernetes 核心扩展机制：

• 自定义资源定义（CRD）： 扩展 Kubernetes API，定义新的资源类型（如 RedisCluster、MySQLBackup）。
• 自定义控制器（Controller）： 运行在集群内，持续监视 CRD 实例的变化，执行调和逻辑。

以下表格对比了传统运维模式与 Operator 模式的关键差异：

2.2 CRD 与 Controller 核心概念

2.2.1 自定义资源定义（CRD）

CRD 是 Kubernetes API 的插件机制。通过声明一个 CRD 对象，你可以让 API Server 识别并存储新的资源类型。CRD 本身是一个标准的 Kubernetes 资源，其核心结构如下：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: redisclusters.redis.example.com
spec:
  group: redis.example.com          # API 组
  names:
    kind: RedisCluster              # 资源类型名称
    plural: redisclusters           # 复数形式，用于 URL
    singular: rediscluster
    shortNames: [rc]                # 简写
  scope: Namespaced                # 作用域：Namespaced 或 Cluster
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                version:
                  type: string
            status:
              type: object
              properties:
                readyReplicas:
                  type: integer
                phase:
                  type: string

2.2.2 Controller 核心组件

一个标准的 Kubernetes Controller 由以下核心模块构成：

2.3 Operator 工作流程

一个完整的 Operator 工作流程从用户提交 CRD 实例开始，到资源状态收敛结束。以下是标准流程的步骤分解：

1. 用户提交 CRD 实例： 通过 kubectl apply -f rediscluster.yaml 向 API Server 发送请求。
2. API Server 校验与存储： 校验 CRD schema，将实例写入 etcd，返回成功响应。
3. Informer 感知事件： Controller 中的 Informer 通过 Watch 连接收到 ADDED 事件，将对象存入本地 Indexer 缓存。
4. 事件入队： Informer 将事件对应的命名空间/名称键值对（namespace/name）推入 WorkQueue。
5. Reconcile 触发： Reconciler 从 WorkQueue 取出键值，开始执行调和逻辑。
6. 读取期望状态： 从 Indexer 或直接调用 API 获取 CRD 实例的 spec 字段。
7. 读取实际状态： 查询集群中由该 Operator 管理的子资源（如 Deployment、Service、PVC）的当前状态。
8. 对比与决策： 比较期望状态与实际状态，计算出需要执行的操作列表（创建、更新、删除、扩缩容等）。
9. 执行操作： 通过 API Server 创建/更新/删除子资源。每次操作都是一次 API 调用。
10. 更新 Status： 将调和结果（如 readyReplicas、phase）写回 CRD 实例的 status 字段。
11. 触发下一轮调和： 子资源的变化会再次触发 Informer 事件，进入下一轮 Reconcile，直至状态收敛。

以下表格总结了工作流程中每个步骤的延迟敏感度：