📚 课程目录第1章 Operator模式概述

1. Operator模式概述：Operator设计哲学、Kubernetes控制器模式、CRD与Controller的关系

1.1 Operator设计哲学：从“运维脚本”到“智能机器人”

Operator 的核心设计哲学可以概括为：将领域专家的运维知识编码为软件，由 Kubernetes 自动执行。传统运维依赖人工执行脚本或 Runbook，而 Operator 将这一过程转变为声明式、自愈、自扩展的自动化闭环。

维度	传统运维（脚本/手动）	Operator 模式
驱动方式	事件驱动、人工触发	声明式、期望状态驱动
状态管理	外部数据库或文件	Kubernetes CR 对象（etcd）
故障恢复	人工介入、告警响应	自动协调、持续回填期望状态
扩展性	线性增加运维人力	水平扩展 Controller 实例
知识载体	Wiki、Runbook、个人经验	Operator 代码 + CRD 定义

设计哲学要点： Operator 不是简单的“Kubernetes 上的脚本调度器”，而是一个有状态、有闭环、有领域逻辑的自治代理。它通过不断观察当前状态与期望状态的差异，执行调谐逻辑（Reconcile），使系统始终趋向用户定义的期望状态。

1.2 Kubernetes控制器模式：核心工作循环

Kubernetes 控制器模式是 Operator 的底层运行机制。其核心是一个无限循环的“观察-分析-行动”模型，通常称为 Reconciler Loop（调谐循环）。

  关键机制：
  Informer / Watcher： Controller 通过 Kubernetes API 的 Watch 机制监听资源变化，避免频繁轮询。
Work Queue： 变更事件被放入工作队列，Reconciler 从队列中取出事件进行调谐，支持去重和重试。
幂等性： 每次 Reconcile 调用必须是幂等的，即多次执行结果与一次执行结果相同。

1.3 CRD与Controller的关系：数据定义与行为实现的分离

CRD（Custom Resource Definition）和 Controller 是 Operator 的两大核心组件，它们的关系可以类比为“数据库表结构”与“后台服务进程”。

组件	角色	类比	关键职责
CRD	数据模型定义	数据库 Schema / 类定义	定义资源的字段、校验规则、版本、作用域（Namespaced/Cluster）
Controller	行为逻辑实现	后台 Worker / 服务进程	监听 CR 实例变化，执行调谐逻辑，管理关联子资源

当用户在集群中应用一个 CRD 定义后，Kubernetes API Server 会开放一个新的 RESTful 端点。用户可以通过 kubectl apply 创建该 CRD 类型的实例（CR）。此时，如果没有 Controller 监听这些 CR，它们只是存储在 etcd 中的静态数据，不会产生任何实际行为。

# 示例：定义一个简单的 CRD（MyApp）
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myapps.example.com
spec:
  group: example.com
  names:
    kind: MyApp
    plural: myapps
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                image:
                  type: string

# 创建 CR 实例
apiVersion: example.com/v1
kind: MyApp
metadata:
  name: myapp-sample
spec:
  replicas: 3
  image: nginx:1.25

常见误区： 只定义 CRD 而不开发对应的 Controller，CR 实例将永远停留在“期望状态”阶段，不会触发任何实际资源（如 Pod、Service）的创建。Operator 的“智能”完全体现在 Controller 的调谐逻辑中。

1.4 CRD与Controller的协作流程

下图展示了从 CRD 定义到 Controller 调谐的完整协作链路：

用户提交 CR： 通过 kubectl apply 将 CR 实例发送到 API Server。
API Server 存储： 验证 CR 是否符合 CRD 定义的 Schema，然后持久化到 etcd。
Controller 感知变化： Controller 通过 Watch 机制收到 CR 的创建/更新/删除事件。
调谐执行： Controller 执行 Reconcile 逻辑，根据 CR 的 spec 字段创建或调整子资源（如 Deployment、Service、ConfigMap）。
状态回写： Controller 将子资源的运行状态（如 Ready 副本数）写回 CR 的 status 字段，形成闭环。

  工程要点： 在 Operator SDK 开发中，CRD 的 status 子资源是 Controller 与用户交互的关键接口。用户通过 spec 声明期望，Controller 通过 status 报告实际状态。这种“spec-status”分离模式是声明式 API 的核心设计模式。