1. 为什么你需要CRD当Kubernetes原生资源不够用的时候先从一个真实场景说起。我在帮客户做内部PaaS平台时遇到了一个很典型的需求团队希望用一套统一的方式管理“业务应用”这个概念。这个东西包含了Deployment、Service、ConfigMap、Ingress还要绑定额外的业务元数据比如负责团队、监控告警阈值、备份策略。如果用现有的Deployment加一堆Annotation去硬撑Annotation里全是JSON字符串写起来痛苦校验基本没有出了问题排查也很费劲。这就是CRD存在的根本原因Kubernetes本身是一个声明式API系统但内置资源是平台级的不是业务级的。你可以用Deployment描述“我要跑3个副本”但它无法描述“这是我的订单服务、属于交易团队、SLA是99.95%、故障要把日志发到某个群”。前者是运维语义后者是业务语义。而Kubernetes的架构恰恰允许你把这些业务语义以一等公民的身份扩展到APIServer里——这就是CustomResourceDefinition做的事。我见过不少团队一开始用CRD做很炫的事情比如自己写Operator管理数据库集群、管理消息队列、甚至管理整个应用的发布流程。但也有很多团队对CRD的理解停留在“定义一个YAML文件然后在Kubernetes里能apply”完全没用到它的校验、默认值、版本转换、子资源这些能力。结果就是CRD变成了一个“更高级的ConfigMap”字段写错只能等到控制器运行时报错谈不上声明式API的优雅。这篇内容适合什么人看一种是准备在Kubernetes上做二次开发的平台工程师一种是已经在用某些开源Operator比如Prometheus Operator、Elastic Cloud on Kubernetes但想搞懂背后原理的运维和开发。文章会从“CRD到底是什么”讲起然后用一个完整的例子走通定义、注册、校验、控制器开发、排查问题全流程。说实话这些东西单独看文档都能查到但把它们串起来并且告诉你哪些地方会踩坑就有价值了。2. 先理解CRD的工作机制它其实是帮你“写API Server的插件”2.1 一次API请求是怎么被处理的要真正理解CRD得先知道Kubernetes的API Server是怎么处理请求的。你在终端敲下kubectl apply -f my-crd.yaml这个命令本质上是发了一个HTTP请求到APIServer的某个路径。APIServer收到请求后会做认证、鉴权、准入控制、schema校验然后把对象存到etcd里。内置资源比如Pod、Deployment它们的schema是写死在APIServer代码里的类型定义、校验规则、默认值逻辑全部内置。你不可能在运行时给Pod增加一个新字段因为APIServer根本不知道这个字段存在也不知道怎么校验它。CRD做的事情就是把这个本来写死的过程“插件化”。你提交一个CustomResourceDefinition对象告诉Kubernetes请注册一个新的RESTful资源路径它的结构是这样一个JSON Schema存到etcd里的格式是这样的请按这个规则校验。APIServer收到后会在运行时就地“长出”一个新的API端点。从这一刻起你的自定义资源就跟Pod、Deployment一样走完整的API请求链路。这个过程用一句话总结CRD 运行时注册的新资源类型 声明式的schema校验规则 可扩展的控制器逻辑。2.2 CRD和API Aggregation的取舍有人会问Kubernetes不是还有一个API Aggregation机制吗把独立的服务挂到APIServer的聚合层后面也能实现自定义资源。这里说下我的看法。API Aggregation适合那种你需要完全掌控API语义、要自定义HTTP方法、要做复杂子资源操作的场景相当于自己写了一个小型的APIServer。但代价是非常重的你得维护一个独立服务处理认证、TLS、资源存储开发和运维成本都高。CRD就不一样它把存储和基础校验都交给了Kubernetes自身你只需要写schema和控制器。大部分场景尤其是定义业务领域对象CRD完全够用。只有那种你确实需要“不像Kubernetes资源”的API风格时才值得去碰Aggregation。在我接触的客户项目里用CRD解决不了的问题极少多数是设计问题而不是机制问题。2.3 CRD的本质从“YAML解析”到“类型系统”很多初学者对CRD有个误区以为CRD就是一个用来“让kubectl能apply自定义YAML”的工具。实际上CRD做的最重要的事情是引入了一个类型系统。你定义了spec.replicas是integer且最小值为1那APIServer就会在写入前校验类型不对直接拒绝。你定义了spec.tags是一个字符串数组那存进去的就一定是数组控制器读出来可以放心用。我们做传统开发时后端接口有DTO、有参数校验CRD给Kubernetes的资源对象提供了同样的能力。而且它不止有静态校验CRD支持OpenAPI v3 Schema里面有default可以设置默认值有enum限定取值范围有pattern做正则校验有x-kubernetes-preserve-unknown-fields保留未知字段还有更高级的x-kubernetes-validations做跨字段校验。这些组合起来就可以在数据进etcd之前把绝大部分错误拦下来。3. 手把手写一个完整的CRD从Schema设计到版本演进3.1 我的示例场景定义一个“应用发布单”讲原理总是虚的我们来做一个实际会用到的东西。假设你的团队需要管理“应用发布流程”每次发版都要记录哪个应用、哪个环境、目标版本、灰度比例、回滚版本、发布负责人。原生Kubernetes资源里没有这个东西我们就用CRD把它定义出来。apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: releasorders.app.example.com spec: group: app.example.com scope: Namespaced names: plural: releaseorders singular: releaseorder kind: ReleaseOrder shortNames: - ro versions: - name: v1 served: true storage: true subresources: status: {} schema: openAPIV3Schema: type: object properties: spec: type: object properties: appName: type: string minLength: 1 environment: type: string enum: [dev, staging, prod] targetVersion: type: string replicas: type: integer minimum: 1 maximum: 100 canaryPercent: type: integer minimum: 0 maximum: 100 default: 0 rollbackVersion: type: string owner: type: string required: [appName, environment, targetVersion] status: type: object properties: phase: type: string enum: [Pending, Rolling, Completed, Failed, RolledBack] lastUpdateTime: type: string format: date-time这里有几个细节需要特别说明。subresources.status必须显式声明否则你的CRD没有/status子路径控制器就无法通过标准的status子资源更新状态。shortNames里的ro让团队可以用kubectl get ro来查看发布单少打几个字符开发者体验提升是实打实的。scope: Namespaced意味着这个资源归属于某个命名空间绝大多数业务资源都应该是Namespaced的除非你要定义集群级别的抽象比如某种全局策略。3.2 为什么推荐“一个CRD一个版本”版本转换的坑与选择很多人第一次写CRD时会看到versions是一个数组于是想当然地写多个版本。但在生产环境里我的建议是如果不需要只保留一个v1版本设置storage: true和served: true。Kubernetes 1.16之后支持CRD的多版本转换即你可以声明v1和v1beta1都提供服务存储时用其中一个版本读的时候自动转换。这个机制很棒但极其容易踩坑。比如你在v1的schema里新增了一个字段而你的转换webhook没同步更新那从v1beta1读数据到v1时这个新字段就是空的。更麻烦的是当你删除了某个版本etcd里存储的历史对象可能需要迁移这个过程中如果转换逻辑有边界情况没覆盖数据就丢了。我见过不止一次因为多版本转换webhook的bug导致存量CR对象无法正常读取最后只能手动改etcd里的数据。所以我的经验是早期版本迭代阶段不要轻易加版本用单版本扩展字段的方式熬过不稳定的时期等API真的稳定了再考虑多版本。尤其是团队小、没有专门开发webhook经验的情况下单版本能省掉80%的版本管理痛苦。3.3 OpenAPI Schema里的细节校验把错误拦截在写入前我们再看schema里的细节。required字段列表定义了哪些字段是必填的如果创建时缺少这些字段APIServer会直接拒绝不会等到控制器跑起来才发现。这个能力价值很大因为控制器是异步的如果数据已经写进etcd但你控制器一处理就报错用户看到的现象就是“资源创建成功但没有反应”排查起来体验极差。enum限定字段取值范围比如环境只能是dev/staging/prod防止有人手抖填个production结果控制器怎么都匹配不上。minimum和maximum则限制了副本数和灰度比例避免出现replicas: -5这种荒唐数据。default这个功能要特别注意它是在对象写入etcd之前由APIServer填入的不是控制器填的。也就是说用户创建时如果没写canaryPercent他在kubectl get里看到的资源对象就已经有canaryPercent: 0了。这个行为和Deployment的默认值逻辑一致。还有一点容易被忽略CRD的schema可以给metadata之外的任意字段设置校验但metadata.name等字段的校验其实是Kubernetes内部固定的你在openAPIV3Schema里写metadata的校验通常不生效。这个算是比较容易误解的地方。3.4 创建CR对象并验证定义好CRD后把它应用到集群kubectl apply -f releaseorder-crd.yaml然后等几秒钟资源类型就会注册好。可以用kubectl get crd releaseorders.app.example.com查看状态当ESTABLISHED变成True时就可以创建自定义资源对象了apiVersion: app.example.com/v1 kind: ReleaseOrder metadata: name: order-20250101 namespace: default spec: appName: order-service environment: prod targetVersion: v2.3.1 canaryPercent: 10 owner: team-payment执行kubectl apply -f order.yaml然后kubectl get releaseorders查看。你会发现它像一个原生资源一样工作甚至可以用kubectl get ro来获取用kubectl describe releaseorder.order-20250101查看详情。4. 控制器才是CRD的灵魂让自定义资源“活”起来4.1 为什么光有CRD还不够如果你只定义CRD并创建了自定义资源对象你会发现它没有任何实际作用就像往数据库里插了一行记录但没有程序去读它。真正让CRD产生业务效果的是控制器——一个持续监听自定义资源变化并把它翻译成实际操作的组件。控制器的核心逻辑就是Kubernetes的调谐循环reconcile loop从集群里读取期望状态就是CR的spec对比当前实际状态可能是Deployment的副本数、Service的配置等然后执行操作让实际状态逼近期望状态。这个循环是持续的不只是创建资源时跑一次。比如用户改了spec.replicas控制器监听到事件后就会去更新对应的Deployment副本数。控制器运行在集群内部时通常用Deployment部署使用的权限由RBAC控制。控制器代码通过client-go监听CRD资源的事件处理逻辑写在事件回调里。如果用Kubebuilder或Operator SDK那模板就自动生成了你只需要填充Reconcile函数里的业务逻辑。4.2 写一个极简控制器的核心逻辑我们用Kubebuilder脚手架开发ReleaseOrder控制器。项目结构大概是这样的release-operator/ ├── api/v1/releaseorder_types.go ├── controllers/releaseorder_controller.go ├── config/crd/bases/ ├── config/rbac/ └── main.go核心文件releaseorder_controller.go里的Reconcile函数是灵魂所在func (r *ReleaseOrderReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { logger : log.FromContext(ctx) var order appv1.ReleaseOrder if err : r.Get(ctx, req.NamespacedName, order); err ! nil { return ctrl.Result{}, client.IgnoreNotFound(err) } logger.Info(reconciling release order, app, order.Spec.AppName, env, order.Spec.Environment) // 1. 根据 spec 生成期望的 Deployment 对象 desiredDeployment : appsv1.Deployment{ ObjectMeta: metav1.ObjectMeta{ Name: fmt.Sprintf(%s-%s, order.Spec.AppName, order.Spec.Environment), Namespace: order.Namespace, }, Spec: appsv1.DeploymentSpec{ Replicas: pointer.Int32Ptr(int32(order.Spec.Replicas)), Selector: metav1.LabelSelector{ MatchLabels: map[string]string{ app: order.Spec.AppName, managed-by: release-operator, }, }, Template: corev1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{ app: order.Spec.AppName, managed-by: release-operator, }, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name: main, Image: fmt.Sprintf(registry.example.com/%s:%s, order.Spec.AppName, order.Spec.TargetVersion), }, }, }, }, }, } // 2. 对比当前实际状态和期望状态 var currentDeployment appsv1.Deployment err : r.Get(ctx, types.NamespacedName{ Name: desiredDeployment.Name, Namespace: desiredDeployment.Namespace, }, currentDeployment) if apierrors.IsNotFound(err) { // 不存在就创建 if err : r.Create(ctx, desiredDeployment); err ! nil { return ctrl.Result{}, err } logger.Info(created deployment for release order) } else if err ! nil { return ctrl.Result{}, err } else { // 存在就更新镜像等关键字段 currentDeployment.Spec.Template.Spec.Containers[0].Image desiredDeployment.Spec.Template.Spec.Containers[0].Image currentDeployment.Spec.Replicas desiredDeployment.Spec.Replicas if err : r.Update(ctx, currentDeployment); err ! nil { return ctrl.Result{}, err } } // 3. 更新 CR 的 Status 子资源 order.Status.Phase Rolling order.Status.LastUpdateTime metav1.Now().String() if err : r.Status().Update(ctx, order); err ! nil { return ctrl.Result{}, err } return ctrl.Result{RequeueAfter: 30 * time.Second}, nil }注意几个关键点。r.Get拿CR对象时如果对象已被删除会返回NotFound这时候就跳过处理因为发布单被删除意味着这次发布被取消了。RequeueAfter是调谐循环的重要参数它表示即使没有事件触发控制器也会每隔30秒重新检查一次状态这对确保“实际状态最终收敛到期望状态”是有用的兜底。4.3 子资源status的更新时机我在上面代码里用r.Status().Update(ctx, order)来更新status子资源这是一个规范做法。Kubernetes从1.11开始支持CRD的status子资源它带来两个好处一是status和spec是分开的普通用户如果有权限可以改spec但不能随意改status二是避免控制器循环更新整个对象导致大量写操作。如果你没有声明subresources.status那就只能在同一个对象里用普通Update同时改spec和status容易产生写冲突。实际开发中我建议控制器只写status绝不写spec字段。原因很简单spec是用户的声明控制器修改spec会破坏用户预期而且会引起和用户操作的冲突。status才是控制器汇报实际状态的专属地盘。4.4 RBAC给控制器授予操作权限控制器要读取和操作Deployment、Pod等资源还需要操作自己的CR这些都需要RBAC授权。Kubebuilder生成的脚手架会用kubebuilder:rbac标记自动生成Role。ReleaseOrder控制器的RBAC标记大概长这样// kubebuilder:rbac:groupsapp.example.com,resourcesreleaseorders,verbsget;list;watch // kubebuilder:rbac:groupsapp.example.com,resourcesreleaseorders/status,verbsget;update;patch // kubebuilder:rbac:groupsapps,resourcesdeployments,verbsget;list;watch;create;update;patch;delete // kubebuilder:rbac:groupscore,resourcesservices,verbsget;list;watch;create;update;patch;delete第一行授权读取CR本身第二行授权更新status子资源后面两行授权管理Deployment和Service。如果漏了某个verbs运行时会以403错误报错调试方法就是看控制器的日志。这个过程有点烦人但也是安全机制的体现——控制器能拿到什么权限完全由RBAC规则决定不是代码里说了算。5. 把CRD用出花来的几个关键技巧5.1 生命周期管理Finalizer与删除保护很多业务场景中自定义资源被删除时要做一些清理工作。比如ReleaseOrder被删除时你可能需要把灰度流量切回旧版本或者清理对应的Service。如果你在控制器里直接删CR而CR还在被占用就会有隐患。Kubernetes的Finalizer机制解决的就是这个问题。你在CR的metadata.finalizers里添加一个字符串标识比如release.app.example.com/finalizer然后当用户删除该CR时APIServer不会真正删除它而是把deletionTimestamp设置成当前时间。控制器看到deletionTimestamp后执行清理逻辑最后把这个finalizer从metadata里移除APIServer才会真正删除对象。if !order.ObjectMeta.DeletionTimestamp.IsZero() { // 执行清理逻辑切换回滚版本、删除灰度发布状态 if controllerutil.ContainsFinalizer(order, release.app.example.com/finalizer) { controllerutil.RemoveFinalizer(order, release.app.example.com/finalizer) if err : r.Update(ctx, order); err ! nil { return ctrl.Result{}, err } } return ctrl.Result{}, nil }这是一个极其重要但容易忽视的机制。没有Finalizer你删除CR时APIServer直接把对象从etcd里抹掉了控制器根本来不及响应。有了Finalizer你才有机会在对象消失前做最后的清理。5.2 强大但容易被忽略的x-kubernetes-validationsOpenAPI Schema在Kubernetes 1.25以上版本支持了x-kubernetes-validations这是CELCommon Expression Language表达式。它能做跨字段的逻辑校验这在纯JSON Schema里实现起来很痛苦。举个例子灰度发布场景中如果canaryPercent大于0那rollbackVersion就必须填写否则发布失败了都没法回滚x-kubernetes-validations: - rule: self.canaryPercent 0 ? has(self.rollbackVersion) : true message: rollbackVersion is required when canaryPercent is greater than 0这个校验会在CR资源创建或更新时由APIServer执行不符合就拒绝写入。CEL的威力很大它可以直接引用self表示当前对象、用oldSelf表示更新前的对象、用has()判断字段是否存在。我用它做过很多复杂的跨字段同步校验比如“环境是prod时必须有owner”这种规则。5.3 原子更新还是部分更新了解两个更新策略在控制器开发中更新CR对象有两种方式Update和Patch。Update是整体替换你把整个对象读出来修改再写回去问题是如果有其他控制器也在改同一个对象会产生冲突。Patch是局部更新只改指定字段。实际操作中更新spec通常用Patch语义会更安全比如修改某个嵌套字段patch : client.MergeFrom(order.DeepCopy()) order.Spec.TargetVersion v3.0.0 if err : r.Patch(ctx, order, patch); err ! nil { return ctrl.Result{}, err }MergeFrom生成的patch只包含前后差异减少冲突概率。但要注意status子资源不能用普通Update必须用r.Status().Update或r.Status().Patch因为status子资源在API层是隔离的。5.4 默认的ListKind与OpenAPI校验的坑CRD定义里还有一个容易忽略的东西names.listKind和names.categories。如果你不显式定义listKind它默认就是Kind加上List后缀比如ReleaseOrder的listKind是ReleaseOrderList。这个默认值通常没问题但是如果你在控制器或客户端代码里硬编码了这个值后来改了CRD的名字就会对不上。categories则可以把你的CR归入某个大类让kubectl get all这类命令也包含你的资源。不过这个功能默认不开启需要在CRD定义里加上categories: [all]否则kubectl get all不会显示你的自定义资源。我见过团队期望CR能被all列出但实际没列出来最后查文档才发现是个显式配置。6. 常见问题与排查技巧实录6.1 CRD创建后一直显示ESTABLISHED为False遇到这个情况首先查看CRD的Eventskubectl describe crd releaseorders.app.example.com常见原因有三种一是schema校验失败比如某个字段的OpenAPI类型写错了APIServer在处理时发现schema不合法二是name格式不对CRD的metadata.name必须是plural.group格式写错了一律报错三是group已经被另一个CRD占用也就是不同CRD的spec.group相同在同一个集群里不允许注册重复group。如果是schema的问题报错信息里会明确指出哪个字段有问题比如“spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.replicas.maximum: Invalid type. Expected: integer, given: null”就得回头检查那个字段的写法。6.2 控制器启动时报RBAC权限不足新写的控制器接入集群时最常见的问题是RBAC漏配了某个资源的权限。日志里会看到类似forbidden: User system:serviceaccount:default:release-operator cannot get resource deployments in API group apps in the namespace default这样的报错。处理方法是把缺失的权限补到Role或ClusterRole里再绑定到控制器使用的ServiceAccount上。这里有个细节如果你的控制器管理所有命名空间的资源你需要的是ClusterRole而不是Role对应的RoleBinding也要改ClusterRoleBinding。6.3 CR更新后控制器没有任何反应这通常是事件监听的问题。Kubebuilder脚手架默认通过For(appv1.ReleaseOrder{})绑定主资源如果你的控制器没有正确绑定CRD类型的事件源或者RBAC里没有watch权限事件根本发不到控制器的Processor里。排查步骤是先确认kubectl get events里有没有相关的Normal/ Warning事件再查看控制器日志有没有reconcile调用记录最后确认RBAC规则里确实有watch。6.4 写入了相同的期望状态但控制器反复reconcile这是调谐循环正常的表现之一不一定是bug。控制器可能返回了RequeueAfter也可能是两个控制器都在modify同一个资源导致事件不断触发。比如你的控制器同时管理Deployment和CR而Deployment的spec里某些字段被kube-controller-manager更新了这又触发了你的控制器。避免无限调谐的办法是在reconcile开头判断期望状态和当前状态是否一致不一致时才执行写操作写完Deployment后不需要立即再修改CR的status除非状态确实变化了。加一个深度对比逻辑能显著降低无效调谐。6.5 CEL校验表达式写错了导致整个CRD注册失败x-kubernetes-validations的rule如果语法不正确APIServer会拒绝接受整个CRD定义。常见问题是引用了一个不存在的字段或者类型不匹配。CEL规则里self的类型是当前字段类型比如有一个self.canaryPercent那self必须是object类型否则表达式直接报错。调试办法是把CEL表达式简化先在本地用CEL的在线编译器验证确认语法没问题再放进CRD定义。6.6 Operator SDK与Kubebuilder选哪个很多初学者会困惑CRD开发到底用Kubebuilder还是Operator SDK。实际上Operator SDK底层就是使用Kubebuilder的脚手架生成的两者在CRD生成和控制器框架上基本一致。实际使用时Kubebuilder更新频率更高社区也更活跃。Operator SDK搞了一个Operator SDK bundle的概念对打包和发布Operator更容易一些。如果你只是做内部平台用Kubebuilder就够了能少学一堆概念。7. 最后的实战建议少走弯路的几个操作习惯如果你正准备在项目里用CRD我建议你从这几个习惯开始。第一个习惯先手工写CRD定义和YAML而不是一上来就跑脚手架。手工写能让你理解每个字段的含义对这个资源类型有完整的认知。跑脚手架生成的模板很大新手很容易被生成的代码量吓到反倒搞不清楚核心逻辑。第二个习惯把CRD的Schema校验当作API文档来维护。你的OpenAPI Schema写得越严格越细团队的协作效率就越高。字段默认值、枚举值、必填项这些信息比写在Wiki里的文字强一万倍因为它们是机器强制执行而不是靠人自觉。第三个习惯绝对不要把Controller里的业务逻辑写在CRD的事件回调里。调谐循环应该是无状态的、幂等的——同一时刻无论执行多少次结果应该一致。如果你想在状态变化时发一条通知那也是reconcile过程中检查状态差后做动作而不是直接监听create事件发消息。第四个习惯CRD升级要谨慎删除字段要三思。一旦CRD被线上集群使用修改schema是影响很大的操作。字段删除了存量对象怎么办新字段加进来控制器兼容旧对象吗这些都是必须提前想清楚的问题。建议CSD版本从v1alpha1开始等稳定后再升到v1。如果你直接把CRD定为v1后续改动就需要兼容性承诺限制反而多。最后一个我个人的经验CRD是Kubernetes生态中最被低估的扩展能力之一。很多人谈到Kubernetes扩展就想到写Operator、写webhook觉得门槛高但实际上CRD本身就能解决很多架构问题。把业务领域模型定义成Kubernetes资源自动获得版本管理、声明式API、权限控制、审计日志能力这种收益在传统开发模型里是很难得到的。如果你还在犹豫要不要上CRD挑一个真正有业务语义的对象把它定义为CRD再写一个简单的控制器管起来跑两周就能感受到这套模式的价值。
