CRD 与自定义控制器

Kubernetes 默认资源类型（Pod、Deployment…）不够用的时候，平台团队用 CustomResourceDefinition（CRD） 扩展 API，再用 Controller / Operator 把「期望状态 → 实际状态」的调谐循环写进集群。本课是 Operator 模式入门——读懂 CRD YAML、知道何时用现成 Operator，而非手写全套 Go controller。

学习目标

• 解释 CRD、CR（Custom Resource）、Controller 三者的关系
• 阅读一份第三方 CRD 清单（如 Prometheus Operator 的 ServiceMonitor）
• 判断 CodeRoadMap 适合「Helm 装现成 Operator」还是「自研 CRD」

扩展模型

API Server
  ├─ 内置资源：Deployment、Service…（[kubernetes-essentials](/tracks/kubernetes-essentials)）
  └─ CRD 注册新类型：Certificate、KafkaCluster、Application…

Controller（控制循环）
  watch CR + 关联资源
  → reconcile：创建 Deployment / Secret / 调云 API

你 kubectl apply 的仍是 YAML；语义 从「3 个 Pod」变成「一个 Postgres 集群含备份策略」这类 领域级 声明。

CRD 最小示例（概念）

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  names:
    kind: Widget
    plural: widgets
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: integer

创建 CRD 后，可 kubectl apply -f my-widget.yaml（kind: Widget）。Validation schema 在 API 层拒错 spec，减少无效对象进 etcd。

Operator 模式

层次	说明
CRD	定义「长什么样」
Controller	监听 CR，创建/更新/删除子资源
Operator	CRD + Controller + 运维知识（备份、升级、故障恢复）

常见现成 Operator：Prometheus Operator、Strimzi（Kafka）、Crossplane（云资源）。监控栈见 prometheus-essentials 的 Operator 安装路径；发布仍可由 helm-gitops-essentials 管理 Operator 本身的 Helm chart。

何时自研 vs 复用

选自研 CRD	选现成 Operator / Helm