Kubebuilder 学习笔记一：从 client-go、CRD 到 Operator，先搞懂 Kubebuilder 到底是什么

一、为什么运维需要学习 Kubebuilder？

传统运维更多关注的是：

部署服务
配置负载均衡
配置监控告警
处理故障
编写脚本自动化
维护 Kubernetes 集群

但是随着 Kubernetes 在企业内部越来越普及，很多平台能力已经不再是简单地写 Shell 脚本或者手动创建 YAML 就能解决的。

比如下面这些场景：

公司想在 Kubernetes 上统一管理自研中间件
想让用户提交一个简单 YAML，就自动创建 Deployment、Service、Ingress、ConfigMap
想让某个业务资源被删除时，自动清理外部系统里的数据
想在 Kubernetes 中管理数据库、缓存、消息队列、模型服务等复杂应用
想把平台能力封装成 Kubernetes 原生 API
想做一个内部 PaaS 平台
想开发自己的调度、网络、存储、AI Infra 平台组件

这时如果只靠普通 YAML，会有几个问题。

第一，资源太分散。

比如部署一个业务服务，可能要写：

Deployment
Service
ConfigMap
Secret
Ingress / Gateway
HPA
ServiceMonitor
RBAC

用户要理解所有底层资源，使用成本很高。

第二，缺少状态感知。

真正的平台系统不只是创建资源，还要知道当前资源是否正常，比如：

实际副本数是否符合预期
Pod 是否 Ready
子资源是否创建成功
外部资源是否清理完成
当前错误是什么

这些都需要一个持续运行的控制器来观察和调谐。

Kubebuilder 解决的就是这类问题。它可以帮助我们基于 Kubernetes 的声明式 API 模型，开发自己的 CRD 和 Controller，让我们把平台能力变成 Kubernetes 原生资源。

简单理解：

Kubebuilder 不是单纯用来生成代码的脚手架，而是用来开发 Kubernetes 自定义 API 和 Controller 的框架。

二、先理解 Kubernetes 原生资源

在 Kubernetes 中，我们平时使用的 Pod、Deployment、Service、ConfigMap、Secret 都是 Kubernetes API 里的资源。例如：

复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

这里的 Deployment 就是 Kubernetes 原生资源。

它有几个典型特点：

有固定的 apiVersion
有固定的 kind
有 metadata
有 spec
有 status
有对应的 Controller 持续维护它

例如 Deployment 的工作方式大概是：用户声明：

复制代码

spec:
  replicas: 3

意思是："我希望这个应用有 3 个副本。"

Deployment Controller 会持续观察当前状态，如果发现只有 2 个 Pod，就会创建新的 Pod；如果发现有 4 个 Pod，就会删除多余的 Pod。

这就是 Kubernetes 最重要的思想：

用户声明期望状态，Controller 负责让实际状态向期望状态靠拢。

这也是后面理解 CRD、Custom Controller、Operator 的核心。

三、原生资源不够用时，就需要自定义资源

Kubernetes 自带很多资源，例如：

Pod
Deployment
StatefulSet
DaemonSet
Job
CronJob
Service
ConfigMap
Secret
Ingress
Namespace
PersistentVolume
PersistentVolumeClaim

但是实际业务中，经常会遇到 Kubernetes 原生资源无法直接表达的对象。

例如我们想表达一个业务应用：

复制代码

apiVersion: platform.example.com/v1
kind: Application
metadata:
  name: user-center
spec:
  image: nginx:1.25
  replicas: 3
  port: 80
  enableIngress: true

Kubernetes 默认并不认识 Application 这个资源。

但是我们希望用户只写一个 Application，平台就能自动创建：

Deployment
Service
Ingress / Gateway
ConfigMap
HPA
ServiceMonitor

这时就需要扩展 Kubernetes API。扩展 Kubernetes API 最常见的方式就是 CRD。

四、什么是 CRD？

CRD 的全称是 CustomResourceDefinition，中文叫"自定义资源定义"。

它的作用是告诉 Kubernetes：

我要给集群新增一种资源类型。

比如你创建了一个 Application 的 CRD，那么 Kubernetes API Server 就会认识这种资源。

之后你就可以执行：

复制代码

kubectl get applications
kubectl describe application user-center
kubectl delete application user-center

从使用体验上看，自定义资源和 Kubernetes 原生资源非常像。比如：

复制代码

apiVersion: platform.example.com/v1
kind: Application
metadata:
  name: user-center
spec:
  image: nginx:1.25
  replicas: 3
  port: 80

这里的 Application 就是一个 CR，也就是 Custom Resource，自定义资源对象。

需要注意：

CRD 和 CR 不是一个东西。

CRD 是资源定义，表示 Kubernetes 里新增了一类资源。

CR 是资源实例，表示这类资源中的某一个具体对象。

可以简单类比：

复制代码

CRD 类似表结构
CR 类似表中的一行数据

例如：

复制代码

CustomResourceDefinition：applications.platform.example.com
CustomResource：user-center 这个 Application 实例

但是只创建 CRD 还不够。CRD 只能让 Kubernetes 存储和读取这种自定义资源，它本身不会自动帮你创建 Deployment、Service，也不会自动做业务逻辑。也就是说：

CRD 只解决"让 Kubernetes 认识一种新资源"的问题，不解决"这个资源应该如何工作"的问题。

真正让自定义资源工作起来的，是 Custom Controller。

五、什么是 Custom Controller？

Controller 是 Kubernetes 的控制器。

它的核心逻辑是：

监听某类资源变化
获取用户声明的期望状态
获取集群中的实际状态
对比期望状态和实际状态
如果不一致，就执行创建、更新、删除等操作
最终让实际状态逐步接近期望状态

对于原生资源，Kubernetes 自带了很多 Controller。例如：

Deployment Controller
StatefulSet Controller
DaemonSet Controller
Job Controller
Node Controller
EndpointSlice Controller

对于自定义资源，就需要我们自己写 Controller。这个自己写的 Controller 就叫 Custom Controller。举个例子，假设我们定义了一个 Application 自定义资源：

复制代码

apiVersion: platform.example.com/v1
kind: Application
metadata:
  name: user-center
spec:
  image: nginx:1.25
  replicas: 3
  port: 80

那么 Application Controller 的逻辑可能是：

监听 Application 资源
发现用户创建了 user-center
读取 spec.image
读取 spec.replicas
创建对应的 Deployment
创建对应的 Service
如果 Deployment 被误删，重新创建
如果用户把 replicas 从 3 改成 5，更新 Deployment
如果用户删除 Application，清理相关资源
更新 Application.status，告诉用户当前状态

所以 CRD 和 Controller 的关系是：

复制代码

CRD：定义一种资源
CR：用户创建的资源实例
Controller：让这个资源真正按照预期工作

没有 Controller 的 CRD，本质上只是一份存储在 Kubernetes 里的结构化数据。

有了 Controller 之后，CRD 才真正变成了声明式 API。

六、什么是 Operator？

Operator 可以理解为一种更高级的 Controller 模式。

Operator 是一种扩展 Kubernetes 行为的方式，它通过 Custom Resource 和 Controller，把某个应用或系统的运维经验编码到 Kubernetes 中。

这个定义里面有几个关键词：

Custom Resource
Controller
运维经验
自动化
控制循环

举个例子，假设我们要管理一个数据库集群。如果人工运维，可能需要做很多事情：

创建 StatefulSet
创建 Service
初始化数据库
创建用户
配置主从复制
做备份
做恢复
做扩容

如果把这些经验写进 Controller 中，再配合一个自定义资源，比如：

复制代码

apiVersion: db.example.com/v1
kind: MySQLCluster
metadata:
  name: mysql-prod
spec:
  replicas: 3
  version: "8.0"
  storage: 100Gi
  backup:
    enabled: true

那么用户只需要提交一个 MySQLCluster，Operator 就可以自动完成后面的工作。可以这样理解：

复制代码

Custom Controller：自定义控制器
Operator：面向某个具体应用或系统领域的自定义控制器

不是所有 Controller 都一定叫 Operator。但是大多数 Operator 都包含：

CRD
Custom Resource
Custom Controller
领域运维逻辑

一句话总结：

Operator 就是把人的运维经验写成代码，并通过 Kubernetes 的声明式 API 暴露出来。

七、client-go 是什么？

理解 Kubebuilder 之前，需要先理解 client-go。client-go 是 Kubernetes 官方提供的 Go 语言客户端库。我们可以把它理解为：

Go 程序访问 Kubernetes API Server 的基础 SDK。

如果你用 Go 写程序，想操作 Kubernetes 资源，例如：

获取 Pod
创建 Deployment
删除 Service
监听 ConfigMap 变化
更新 CRD 状态
编写 Controller

底层基本都会涉及 client-go。client-go 提供了很多能力，包括：

1. RESTClient

RESTClient 是更底层的 Kubernetes API 访问客户端。

它负责向 API Server 发送 HTTP 请求。

2. 类型化客户端

类型化客户端用于操作 Kubernetes 原生资源。例如：

复制代码

clientset.AppsV1().Deployments("default").Get(...)
clientset.CoreV1().Pods("default").List(...)

这种方式的优点是类型明确，代码提示友好。

3. 动态客户端

动态客户端可以操作任意 Kubernetes 对象，包括 CRD。

它不依赖具体 Go 结构体，更适合写通用工具。

4. Informer

Informer 是 Kubernetes Controller 中非常核心的机制。如果每个 Controller 都不停地直接请求 API Server，会给 API Server 带来很大压力。Informer 的作用是：

通过 List + Watch 监听资源变化
在本地维护缓存
触发事件回调
减少对 API Server 的直接请求

5. Workqueue

Workqueue 是控制器中的工作队列。Informer 监听到资源变化后，一般不会直接在事件回调里处理复杂逻辑，而是把对象的 key 放进队列。Controller 的 worker 再从队列中取出 key，执行具体的调谐逻辑。典型流程是：

复制代码

API Server
   ↓
Informer List/Watch
   ↓
本地缓存
   ↓
事件处理函数
   ↓
Workqueue
   ↓
Reconcile 处理逻辑

所以 client-go 是 Kubernetes Go 生态里非常底层、非常核心的库。但是如果直接用 client-go 手写 Controller，会有很多模板代码。例如：

创建 client
创建 informer
创建 workqueue
处理事件
处理重试
处理缓存同步
处理对象 key
处理 RBAC
处理 CRD 类型生成
处理 deepcopy
处理 controller 启动和停止

这对初学者和业务开发来说成本比较高。于是就有了 controller-runtime 和 Kubebuilder。

八、controller-runtime 是什么？

controller-runtime 是 Kubernetes SIG 维护的一组 Go 库，用来帮助开发 Controller。

它可以理解为：

对 client-go 控制器开发模式的一层封装。

它把很多 Controller 开发中通用的东西封装好了，比如：

Manager
Client
Cache
Reconciler
Controller Builder
Webhook
Scheme
EventRecorder
Leader Election
Metrics
Health Probe

在 Kubebuilder 生成的代码里，经常能看到这些包：

复制代码

ctrl "sigs.k8s.io/controller-runtime"
"sigs.k8s.io/controller-runtime/pkg/client"

例如 Reconciler 结构体里常见的写法：

复制代码

type ApplicationReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

这里的 client.Client 就是 controller-runtime 提供的客户端。

它封装了常用的 Kubernetes API 操作，比如：

复制代码

r.Get(ctx, key, obj)
r.List(ctx, list)
r.Create(ctx, obj)
r.Update(ctx, obj)
r.Delete(ctx, obj)
r.Status().Update(ctx, obj)

相比直接写 client-go，controller-runtime 更适合写 Operator。

因为它把 Controller 开发抽象成了一个核心方法：

复制代码

func (r *ApplicationReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 调谐逻辑
}

也就是说，我们大部分时间只需要关注：

当某个资源发生变化时，我应该如何让实际状态变成期望状态？

这就是 Reconcile 的核心。

九、Kubebuilder 是什么？

Kubebuilder 是一个用于构建 Kubernetes API 和 Controller 的开发框架。它不是凭空发明了一套新机制，而是建立在 Kubernetes 标准扩展机制之上。它主要基于：

CRD
controller-runtime
controller-tools
Kubernetes API 设计规范
Go 代码生成机制

Kubebuilder 可以帮助我们快速生成一个 Operator 项目的基本结构。例如：

复制代码

kubebuilder init --domain example.com --repo example.com/project

这个命令会初始化一个 Kubebuilder 项目。

再比如：

复制代码

kubebuilder create api --group apps --version v1 --kind Application

这个命令会生成一个新的 API 资源和对应 Controller 骨架。

以当前 Kubebuilder go/v4 默认项目布局为例，通常会生成类似下面的内容：

复制代码

api/v1/application_types.go
internal/controller/application_controller.go
config/crd/
config/rbac/
config/samples/
cmd/main.go
Makefile
PROJECT

需要注意，不同 Kubebuilder 历史版本和不同插件生成的目录结构可能不完全一样。如果你在旧文章里看到 controllers/ 或 internal/controllers/，不要惊讶。以当前主流 go/v4 默认脚手架为准，Controller 代码默认在 internal/controller/ 目录下。

Kubebuilder 的作用不是替你写完所有业务逻辑，而是帮你搭好一套标准的 Operator 开发工程。

你真正需要写的是：

自定义资源的 Spec 和 Status
Reconcile 调谐逻辑
子资源的创建和更新逻辑
Status 更新逻辑
Finalizer 清理逻辑
Webhook 默认值填充与校验逻辑
权限和部署配置

十、client-go、controller-runtime、Kubebuilder 的关系

这几个概念可以按层次理解。

1. client-go：最底层的 Kubernetes Go 客户端

client-go 负责和 API Server 通信。

它提供：

RESTClient
Clientset
Dynamic Client
Informer
Lister
Workqueue
Kubernetes API 访问能力

它更底层，也更灵活，但直接写起来模板代码较多。

2. controller-runtime：Controller 开发库

controller-runtime 基于 client-go，封装了 Controller 开发中的常见模式。

它提供：

Manager
Client
Cache
Reconciler
Controller Builder
Scheme
Webhook
Metrics
Leader Election

它让我们不用直接处理大量 informer 和 workqueue 细节，而是把核心逻辑收敛到 Reconcile 方法里。

3. Kubebuilder：Operator 项目开发框架

Kubebuilder 基于 controller-runtime 和 controller-tools，提供完整的项目脚手架和代码生成能力。

它可以帮我们生成：

项目目录
API 类型文件
Controller 骨架
CRD YAML
RBAC YAML
Webhook 配置
示例 CR
Makefile
Dockerfile
部署用 kustomize 配置

三者关系可以画成这样：

复制代码

┌────────────────────────────────────────────────────────┐
│                    Kubebuilder                         │
│       Project Layout / Makefile / Manifests            │
│       API Scaffold / Controller Scaffold               │
└───────────────────────────┬────────────────────────────┘
                            │ 基于 / 简化
┌───────────────────────────▼────────────────────────────┐
│                    controller-runtime                  │
│       Manager / Cache / Client / Reconciler            │
│       Controller Builder / Webhook / Scheme            │
└───────────────────────────┬────────────────────────────┘
                            │ 基于 / 封装
┌───────────────────────────▼────────────────────────────┐
│                        client-go                       │
│       RESTClient / Clientset / Informer / Workqueue    │
└───────────────────────────┬────────────────────────────┘
                            │ HTTP 请求
┌───────────────────────────▼────────────────────────────┐
│                  kube-apiserver                        │
└────────────────────────────────────────────────────────┘

也可以这样理解：

复制代码

client-go：提供底层 API 访问能力
controller-runtime：封装 Controller 开发模式
Kubebuilder：提供完整的 Operator 开发工程框架

十一、Kubebuilder 能帮我们自动生成什么？

Kubebuilder 最大的价值不是"自动生成业务逻辑"，而是自动生成大量标准化、容易出错的基础代码和配置。常见包括：

1. 项目结构

执行：

复制代码

kubebuilder init --domain example.com --repo example.com/project

会生成基础项目结构。

2. API 类型代码

执行：

复制代码

kubebuilder create api --group apps --version v1 --kind Application

会生成类似：

复制代码

api/v1/application_types.go

这个文件用于定义：

ApplicationSpec
ApplicationStatus
Application
ApplicationList

例如：

复制代码

type ApplicationSpec struct {
    Image    string `json:"image,omitempty"`
    Replicas int32  `json:"replicas,omitempty"`
}

type ApplicationStatus struct {
    ReadyReplicas int32 `json:"readyReplicas,omitempty"`
}

其中：

复制代码

Spec 表示期望状态
Status 表示实际状态

3. Controller 骨架

Kubebuilder 会生成类似：

复制代码

func (r *ApplicationReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    return ctrl.Result{}, nil
}

后续我们就在这个方法里编写调谐逻辑。

4. DeepCopy 代码

当我们定义 Kubernetes API 类型时，这些类型通常需要实现 runtime.Object 相关能力。

Kubebuilder 项目里会通过 controller-gen 生成类似下面的文件：

复制代码

api/v1/zz_generated.deepcopy.go

这个文件里通常包含：

DeepCopy
DeepCopyInto
DeepCopyObject

修改 _types.go 之后，推荐执行：

复制代码

make generate

它会重新生成 DeepCopy 相关代码，确保 Go 类型和自动生成代码保持一致。

5. CRD、RBAC、Webhook 等 YAML 配置

通过：

复制代码

make manifests

可以生成或更新 Kubernetes YAML 配置，例如：

CRD
RBAC
WebhookConfiguration

CRD 会告诉 Kubernetes API Server：

复制代码

现在集群里新增了一种 Application 资源

所以标准开发流程通常是：

复制代码

make generate
make manifests

简单理解：

复制代码

make generate  ：生成 Go 代码，例如 DeepCopy
make manifests ：生成 Kubernetes YAML，例如 CRD、RBAC、WebhookConfiguration

6. RBAC 权限

在 Controller 代码里写 marker：

复制代码

// +kubebuilder:rbac:groups=apps.example.com,resources=applications,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=apps.example.com,resources=applications/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=apps.example.com,resources=applications/finalizers,verbs=update

再执行：

复制代码

make manifests

Kubebuilder 会通过 controller-gen 生成对应 RBAC YAML。

7. 示例资源

Kubebuilder 会生成：

复制代码

config/samples/

里面可以放自定义资源示例，例如：

复制代码

apiVersion: apps.example.com/v1
kind: Application
metadata:
  name: application-sample
spec:
  image: nginx:1.25
  replicas: 3

8. 部署配置

Kubebuilder 项目中通常会包含：

Dockerfile
Makefile
config/default
config/manager
config/rbac
config/crd

后续可以通过：

复制代码

make docker-build
make deploy

构建镜像并部署 Controller 到 Kubernetes 集群中。

十二、从运维角度理解 Kubebuilder 的价值

从运维角度看，Kubebuilder 的价值不是"写 Go 代码很高级"，而是它能帮助我们把运维动作平台化。传统方式可能是：

复制代码

写文档 → 让业务照着文档创建 YAML → 出问题运维排查

Kubebuilder / Operator 方式是：

复制代码

把规则写进 Controller → 用户提交简单 CR → Controller 自动完成复杂操作

例如以前部署一个应用，需要用户写很多 YAML：

复制代码

Deployment
Service
Ingress
ConfigMap
HPA
ServiceMonitor

现在可以封装成一个 Application：

复制代码

apiVersion: platform.example.com/v1
kind: Application
metadata:
  name: user-center
spec:
  image: nginx:1.25
  replicas: 3
  port: 80
  expose: true
  monitor: true

Controller 自动创建底层资源。这对运维平台非常有意义。因为它实现了几个能力。

1. 屏蔽复杂底层资源

用户不用关心底层到底创建了几个资源。

2. 统一公司内部标准

比如统一 label、annotation、资源限制、探针、监控、日志采集方式。

3. 自动纠偏

如果有人误删了 Deployment，Controller 可以自动恢复。

4. 状态可见

用户可以通过 status 看到当前资源状态。例如：

复制代码

status:
  phase: Running
  readyReplicas: 3
  message: Application is ready

5. 删除自动清理

通过 OwnerReference 和 Finalizer，可以实现资源删除时自动清理子资源或外部资源。

6. 形成内部平台 API

最后用户面对的不再是一堆零散 YAML，而是平台提供的 Kubernetes 原生 API。

7. 更贴近 AI Infra 场景

如果只用数据库举例，可能会觉得 Operator 离 AI Infra 比较远。实际上，AI Infra 里也非常适合使用 Operator 思路。例如我们可以定义一个 vLLMService 自定义资源：

复制代码

apiVersion: ai.example.com/v1
kind: vLLMService
metadata:
  name: qwen-service
spec:
  model: Qwen2.5-1.5B-Instruct
  gpuResource: vGPU-8G
  replicas: 1
  storage:
    modelPath: oss://models/qwen/Qwen2.5-1.5B-Instruct
  gateway:
    enabled: true
    host: qwen.example.com

然后由 Controller 自动完成：

创建 Deployment
申请 GPU / vGPU 资源
配合 HAMi、Volcano 或其他 GPU 调度组件
创建 Service
创建 Gateway / HTTPRoute
通过 InitContainer 下载模型权重
配置环境变量
暴露 OpenAI 兼容接口
更新模型服务状态
接入 Prometheus 监控
删除时清理相关资源

这样用户不需要理解底层所有 Kubernetes 资源，只需要声明一个模型服务对象。这就是典型的：

复制代码

AI Infra 运维经验代码化

十三、什么时候应该写 Operator？

不是所有场景都应该写 Operator。

适合写 Operator 的场景一般有这些特点。

1. 资源生命周期复杂

比如创建一个对象后，需要自动创建多个子资源：

Deployment
Service
PVC
Secret
ConfigMap
Job

并且后续还需要持续维护这些资源。

2. 需要持续调谐

如果实际状态可能被修改，系统需要自动纠偏，就适合 Controller。

比如：

Deployment 被误删，需要重建
副本数被改错，需要恢复
Service 被删，需要重新创建
外部资源状态异常，需要更新 status

3. 需要封装运维经验

比如数据库、中间件、模型服务这类系统，不只是部署，还涉及：

初始化
扩容
备份
恢复
升级
故障处理
删除清理

这些都适合用 Operator 表达。

4. 需要把平台能力做成 Kubernetes API

例如内部平台希望提供：

复制代码

kubectl apply -f app.yaml

就能创建完整应用，那么适合用 CRD + Controller。

5. 需要管理外部资源

例如：

云数据库
DNS 记录
负载均衡
对象存储 Bucket
外部账号
第三方系统配置

这类资源虽然不一定运行在 Kubernetes 中，但可以通过 Operator 把它们纳入 Kubernetes 的声明式管理。

十四、总结

Kubebuilder 的本质不是：

复制代码

生成代码的工具

而是：

复制代码

帮助开发者按照 Kubernetes API 设计方式，构建自定义资源和控制器的框架

它的核心思想是：

复制代码

声明式 API + 控制循环

用户通过 CR 声明期望状态：

复制代码

spec:
  replicas: 3
  image: nginx:1.25

Controller 持续观察实际状态：

复制代码

当前 Deployment 是否存在？
副本数是否正确？
Pod 是否 Ready？
Service 是否创建？

如果实际状态和期望状态不一致，Controller 就执行调谐：

复制代码

创建资源
更新资源
删除资源
更新状态
重新排队

最终让系统不断接近期望状态。

可以用下面几句话总结：

Kubernetes 原生资源是 Kubernetes 已经内置的 API 对象，例如 Pod、Deployment、Service。
CRD 可以让我们扩展 Kubernetes API，新增自己的资源类型。
CR 是 CRD 的具体实例。
只有 CRD 没有 Controller，本质上只是存储了一份结构化数据。
Custom Controller 会监听资源变化，并持续把实际状态调谐到期望状态。
Operator 是把某个领域的运维经验写进 Controller，并通过 CRD 暴露成 Kubernetes API。
client-go 是 Kubernetes 官方 Go 客户端库，提供底层 API 访问能力。
controller-runtime 是构建 Controller 的 Go 库，封装了 Manager、Client、Reconciler 等能力。
Kubebuilder 是基于 controller-runtime 和 controller-tools 的 Operator 开发框架。
从运维角度看，Kubebuilder 的价值是把复杂运维流程平台化、自动化、声明式化。
从 AI Infra 角度看，Kubebuilder 可以用来封装模型服务、GPU 调度、Gateway 暴露、监控接入等复杂生命周期。