2.1 CustomResourceDefinition（CRD）#

CRD 是 Kubernetes 最常用的扩展方式。通过定义一个 CRD，开发者可以创建完全自定义的资源类型，Kubernetes 会自动为其生成 CRUD API，无需编写额外的 API 服务器代码。

定义一个 CRD 非常简单：

1
apiVersion: apiextensions.k8s.io/v1
2
kind: CustomResourceDefinition
3
metadata:
4
  name: myapps.myorg.io
5
spec:
6
  group: myorg.io
7
  names:
8
    kind: MyApp
9
    listKind: MyAppList
10
    plural: myapps
11
    singular: myapp
12
    shortNames:
13
      - ma
14
  scope: Namespaced # 或 Cluster
15
  versions:
16
    - name: v1
17
      served: true
18
      storage: true
19
      schema:
20
        openAPIV3Schema:
21
          type: object
22
          properties:
23
            spec:
24
              type: object
25
              properties:
26
                replicas:
27
                  type: integer
28
                image:
29
                  type: string
30
            status:
31
              type: object
32
              properties:
33
                availableReplicas:
34
                  type: integer

CRD 的局限性在于：它只是一个存储数据的机制，CRD 本身不包含任何业务逻辑。如果需要在创建/更新/删除资源时执行特定操作（例如自动创建关联的 Service 或 ConfigMap），就需要配合控制器（Controller）或 Operator 使用。

2.1.1 Operator 模式#

Operator 是 CRD 与控制器的组合产物。Operator 遵循 Kubernetes 的控制器模式——监听资源变化，将实际状态向期望状态收敛。Operator 的特别之处在于，它封装了运维领域的知识，使得复杂的运维操作可以被自动化执行。

以 Prometheus Operator 为例，它定义了 Prometheus、ServiceMonitor 等 CRD，用户只需声明式的配置，Operator 就会自动创建和管理关联的 StatefulSet、ConfigMap、Service 等资源。

编写一个 Operator 通常借助 Kubebuilder 或 Operator SDK 框架：

1
# 使用 kubebuilder 创建 Operator 项目
2
kubebuilder init --domain myorg.io --repo github.com/myorg/my-operator
3
kubebuilder create api --group myorg.io --version v1 --kind MyApp

Kubebuilder 会自动生成 CRD 定义、RBAC 配置和基础控制器代码，开发者只需要填充 Reconcile 逻辑：

1
func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
2
    log := log.FromContext(ctx)
3

4
    // 获取 MyApp 实例
5
    myapp := &myorgiov1.MyApp{}
6
    if err := r.Get(ctx, req.NamespacedName, myapp); err != nil {
7
        return ctrl.Result{}, client.IgnoreNotFound(err)
8
    }
9

10
    // 创建或更新关联的 Deployment
11
    deploy := r.generateDeployment(myapp)
12
    if err := r.createOrUpdate(ctx, deploy); err != nil {
13
        return ctrl.Result{}, err
14
    }
15

16
    // 更新状态
17
    myapp.Status.AvailableReplicas = deploy.Status.AvailableReplicas
18
    if err := r.Status().Update(ctx, myapp); err != nil {
19
        return ctrl.Result{}, err
20
    }
21

22
    return ctrl.Result{RequeueAfter: 30 * time.Second}, nil
23
}

Operator 的核心优势在于将运维知识编码为软件。例如，手动管理 Redis 集群需要了解主从切换、故障转移、持久化策略等复杂知识；将这些知识编码到 Operator 中，普通运维人员只需要声明 RedisCluster 资源的期望状态，Operator 自动完成所有运维操作。

2.2 API Aggregation（聚合 API）#

CRD 适合扩展存储层的资源类型，但对于需要自定义 API 行为的场景（如特殊的认证逻辑、自定义查询参数、跨多个资源类型的复杂操作），聚合 API Server（Aggregated APIServer）是更合适的选择。

Aggregated APIServer 的架构是：在 kube-apiserver 之外，运行一个或多个额外的 API Server，这些 API Server 通过特殊的方式注册到 kube-apiserver 的代理路径下（通常是 /apis/mygroup.myorg.io/），对外部表现为统一的 Kubernetes API。

聚合 API Server 的优势在于：

1. 完全独立的 API 行为：可以自定义认证、授权、序列化逻辑
2. 独立的存储后端：可以使用 etcd 之外的其他存储（如 PostgreSQL、Redis）
3. 独立的代码库：可以独立发布、版本演进，不影响核心 API

实现一个 Aggregated APIServer 通常需要：

1
import (
2
    "k8s.io/apiserver/pkg/server"
3
    "k8s.io/sample-apiserver/pkg/apiserver"
4
)
5

6
func main() {
7
    // 创建自定义 API Server
8
    cmd := apiserver.NewCommandStartFactory(os.Stdout, os.Stderr)
9
    if err := cmd.Execute(); err != nil {
10
        panic(err)
11
    }
12
}

社区中许多知名项目采用 Aggregated APIServer 方式扩展 Kubernetes，例如 metrics-server（通过 Heapster 的替代品提供自定义指标 API）、Istio（通过 MCP 协议提供服务网格配置 API）等。