CRD与Operator：K8s自定义扩展

可视化演示

展示Kubernetes自定义资源定义CRD与Operator模式：API扩展机制、控制循环Reconcile、Leader选举高可用及AI模型服务自动化实践。切换模式查看不同环节。

CRD 概念入门

物业中心的文件柜里，已经有「住户登记表」「公寓入住表」这些标准表。忽然有一天，小区要开设「AI 模型游乐园」，但现有表格里没有任何一类能描述「游乐园想养几只模型、需要多少显卡、对外服务端口是多少」。于是物业中心提交了一份崭新的「宠物乐园登记表」给总管理处（Kubernetes API Server），申请把这个新表纳入官方表格体系。这张新表，就是你向 Kubernetes 申请的自定义资源定义 CRD。

在 Kubernetes 集群中，Pod、Deployment、Service 是内建资源；CRD 是让你自己发明新资源类型的方法。开发者提交一份 YAML 配置，声明「我想要一个模型服务，两个副本，模型名 bert」，这份配置被称为自定义资源对象。Kubernetes 并不会真的帮你拉起模型，它只是把你的「心愿单」存下来——真正的执行者，是后续会出现的 Operator。

自定义资源本质上就是「类型 + 声明」的组合：类型告诉系统这是什么，声明告诉系统你希望它最终变成什么样。

回到小区比喻：你递给物业的「宠物乐园登记表」，只是让系统知道世上存在这种表、也知道你想要的设施清单。可如果没有管家来按表施工和照看，这张表就永远只是一纸空文。

API 定义规范

拿到新表之前，物业中心需要先规定表格的「版式」：哪些格子必须填、填数字还是填文本、可不可以留空。在 Kubernetes 中，这份「版式」就是 CRD 的 Schema，它用 OpenAPI 描述自定义资源的字段结构。

定义 Schema 时，最核心的是 spec 字段的结构。比如 replicas 的类型是整数，范围是 1 到 100；model 是字符串且不能为空；port 是 1 到 65535 的整数。这样当用户提交 YAML 时，API Server 可以直接校验格式，不合法就拒绝存储。就像物业管理员一眼看出「登记表里年龄填了 -5」，马上打回。

除了校验，Schema 还能设置默认值。如果用户没写 replicas，系统自动填入 1；如果没写 strategy，默认使用 RollingUpdate。这些规则让用户写配置时更轻松，也让资源行为更可控。

表格版式定好了，剩下的问题就是：谁来照着这份版式，把小区的宠物乐园真正建起来并维护好？这个答案，正是后面的「协调循环」。

协调循环原理

管家怎么知道该干活呢？他不会等业主来吆喝，而是每隔一会儿就在小区里转一圈，对照「登记表上的理想样子」和「游乐园的当前样子」：要是垃圾桶满了就清空，要是设施坏了就报修，要是宠物少了就补领。这种「看两眼、改一改、再看两眼」的循环，在 Kubernetes 里叫协调循环。

在 Operator 中，核心逻辑被封装进一个函数：Reconcile。当自定义资源被创建、更新、删除，或底层资源状态发生变化时，事件会触发这个函数。它读取资源当前的 Spec 和 Status，算出期望与现实的差距，然后执行创建 Pod、更新 Deployment、滚动升级等操作，操作完成后再次观察。

如果把协调循环写成直觉公式，就是：期望状态减去实际状态等于误差，当误差不为零时，控制器就该行动了。

管家不会因为打扫过一次就永远收工，只要小区状态发生变化，他都会再次出现在宠物乐园里检查。这种永不满足的「纠偏」机制，正是 Operator 能持续保证系统处于期望状态的原因。

Operator 设计模式

如果说 CRD 是登记表，那么 Operator 就是负责照单维护的专属管家。它的设计模式很简单：用 CRD 定义资源的「期望结构」，再用一个控制器监听这类资源的生命周期，按你写好的运维逻辑自动执行。传统运维靠人盯着监控、手动扩容、手动回滚；Operator 把人的经验固化成代码，让机器自己盯着。

比如一个 AI 模型的线上服务，过去需要运维同学半夜盯告警、手动拉起新 Pod。有了 Operator，Controller 会定期检查模型服务副本数、GPU 利用率、模型版本是否与 Spec 一致。不一致就自动调整，完全不需要人肉介入。

所以，Operator 不是一个神秘的黑盒，它是「控制器 + 自定义资源 + 领域知识」的组合，把一个垂直领域的运维自动化变成现实。

有了这位专属管家，小区管理者不再需要为每一件小事操心。但要让管家在真实小区里可靠上岗，我们还需要一套标准工具来「雇佣」他——这就是 controller-runtime 框架。

controller-runtime 实践

自己从零搭建一个 Kubernetes 控制器，首先要写 API 客户端、事件监听、缓存、重试队列，工作量巨大。于是社区提供了 controller-runtime 库，相当于给所有 Operator 管家提供了一套标准培训体系和工具箱。你只需要关心 Reconcile 函数里写什么业务逻辑，其他与 K8s 交互的复杂度由框架接管。

在这个框架里，Manager 是总调度中心：它负责启动所有控制器、维护缓存、提供客户端。Builder 则像招聘流程：指定 watch 哪种资源，再把事件交给哪个 Reconcile 方法。开发者通常用 ctrl.NewControllerManagedBy(mgr) 在几行代码内完成「监听 ModelService 资源，并调用 Reconcile 处理」的装配。

Reconcile 函数本身是一个纯逻辑函数，它接收一个资源名字（NamespacedName），返回处理结果。框架负责把事件变成调用，把重试和排队从业务逻辑中剥离出去。

有了统一工具箱，Operator 的开发效率大幅提升。不过，当很多小区业主同时依赖这位管家时，还要解决「多个管家不能重复打扫」的问题。

高可用与状态管理

如果把 Operator 部署多份，就能避免单点故障。但如果两个管家同时发现垃圾桶满了，双双伸手去清，反而可能互相干扰。Kubernetes 给出的方案叫 Leader Election（领导者选举）：所有副本中只选出一个「值班管家」，其余作为候补，只有在 Leader 挂掉时才顶上。

controller-runtime 内置了 Leader Election 机制。每个 Operator 副本启动时会争夺一个 lease 锁，获得锁的副本成为 Leader，真正执行 Reconcile；其他副本保持待命。这就像小区里虽然雇了三个管家，但只有戴着值班牌的那位可以动工具，其他人只观察、不干预。

另一个关键机制是 Status 子资源。用户定义的 spec 是「心愿」，控制器把实际运行情况写进 status，比如当前副本数、最近一次成功更新时间、可用的模型版本。Kubernetes 会保护 status 字段，普通用户不能随意篡改，只有控制器有权限写入，确保状态信息来源可信。Leader 数量 N 与配额 Q 的关系：

多个副本安全值班，状态又能被可信记录后，Operator 终于可以放心上岗。最后，我们来看看它是如何被用在 AI 模型服务这种真实的高价值场景中的。

AI 模型服务实战

在 AI 平台中，模型从训练到上线、再到版本更新和回滚，链路非常长。传统方式是平台工程师写一堆运维脚本，再配一个值班机器人；但这种方式难以应对复杂状态变化。用 CRD 和 Operator，我们可以为「模型服务」量身定制一套自动化的生命周期管理系统。

比如定义一个 ModelService 自定义资源：用户提交 YAML，声明模型名、需要的 GPU 数量、期望副本数和版本策略。ModelService Operator 收到后，会自动创建底层 Deployment、Service、HorizontalPodAutoscaler，并把推理服务的实时状态写回 status。当模型流量突增时，Operator 还会根据等待队列长度自动扩缩容。

扩缩容可以抽象为一道简单计算题：假设当前请求负载为 L，单副本能承受的阈值为 T，那么需要的副本数 R 至少是 L/T 向上取整，并且不能小于 1。

回到「AI 模型游乐园」的比喻：ModelService CRD 是那张「游乐园经营申请书」，而 ModelService Operator 就是那个懂模型、懂 GPU、懂扩容缩容的超级管家。从今往后，你只需要在申请书上写清楚「我要多大的游乐园」，剩下的脏活累活，管家全部搞定。

AI 应用场景

Python 演示

class ModelServiceOperator:    def __init__(self, model="bert", replicas=1):        self.model = model        self.replica_count = replicas        self.generation_count = 0     def fetch_actual(self):        return {            "replicas": self.replica_count,            "generation": self.generation_count        }     def apply_change(self, target_replicas):        self.replica_count = target_replicas        self.generation_count += 1     def reconcile(self, spec):        desired = spec.get("replicas", 1)        actual = self.fetch_actual()        if actual["replicas"] == desired:            return ("no-op", actual)        old = actual["replicas"]        self.apply_change(desired)        new_state = self.fetch_actual()        return ("scaled", {            "from": old,            "to": new_state["replicas"],            "generation": new_state["generation"]        })  def main():    operator = ModelServiceOperator(model="bert-base", replicas=2)    specs = [        {"name": "bert-qa", "replicas": 3},        {"name": "gpt-lite", "replicas": 1},        {"name": "bert-qa", "replicas": 3},    ]    for spec in specs:        action, detail = operator.reconcile(spec)        print("%s %s -> %s" % (spec["name"], action, detail))  if __name__ == "__main__":    main()

1. class ModelServiceOperator:对应一个自定义资源的专属控制器，就像宠物乐园的专属管家。
2. def fetch_actual(self)读取当前实际状态，对应控制器从 K8s 集群查询真实资源。
3. def reconcile(self, spec)核心协调函数，比较 spec 中的期望值与 observed 实际值。
4. if actual["replicas"] == desired:差距为零时无需动作，直接返回 no-op。
5. self.apply_change(desired)差距非零时执行扩缩容，并更新 generation 记录变更代数。
6. print("%s %s -> %s" % ...)模拟观察者看到的一次次协调结果。

常见误区

面试题