很多刚接触 K8s 的朋友对 CRD、CR 这两个概念很迷糊觉得是高阶复杂知识点。其实它俩核心逻辑特别简单是 K8s 自定义扩展能力的核心。今天用大白话讲清楚零基础也能看懂。一、先搞懂CRD 和 CR 到底是什么前置小认知K8s 原生资源我们平时常用的 K8s 资源都是官方提前定义好的比如 Pod、Deployment、Service、ConfigMap。这些是 K8s 自带的「固定模板」你只能按照官方规则用不能随便改规则、新增资源类型。CRD自定义资源模板蓝图CRD 全称自定义资源定义CustomResourceDefinition大白话CRD 就是你自己在 K8s 里新建的一种「资源模板」。K8s 原生资源不够用时我们通过 CRD 告诉 K8s我要新增一种全新的资源类型定义好它的字段、规则、格式。打个比方K8s 原生自带「员工模板」Pod/Deployment字段只有姓名、岗位但我需要「程序员专属模板」需要新增编程语言、项目字段这个新建模板的动作就是 CRD。CR自定义资源实例具体对象CR 全称自定义资源CustomResource大白话CR 就是基于 CRD 模板创建出来的具体实例。继续用上面的例子CRD 是「程序员模板」那根据这个模板创建出来的「张三、后端程序员」这条具体数据就是 CR。核心关系总结CRD 模板类CR 实例对象先有 CRD注册规则才能有 CR具体资源。二、CRD CR 有什么用核心作用突破 K8s 原生限制无限扩展 K8s 能力K8s 官方资源只能覆盖通用场景但实际业务中很多个性化需求原生不支持比如自动扩缩容、网关规则、备份策略、数据库运维、微服务治理等。如果没有 CRD这些个性化功能只能用脚本、外部程序实现杂乱难维护。有了 CRD/CR 之后所有自定义功能都能像操作原生 K8s 资源一样管理统一命令、统一监控、统一运维。最常见的实际场景Ingress-Nginx用 CRD 定义路由规则、限流规则Prometheus 监控用 CRD 定义监控采集规则、告警规则ArgoCD/Flux用 CRD 定义持续部署规则istio 服务网格几乎所有路由、熔断、治理规则都是 CRD/CR 实现三、最简实操手把手学会怎么用全程只做两件事1. 部署 CRD注册模板 2. 创建 CR使用模板步骤1编写一个简单的 CRD自定义模板新建 crd-demo.yaml定义一个自定义资源自定义应用MyApp包含名称、副本数两个字段。apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: myapps.demo.com spec: group: demo.com names: kind: MyApp plural: myapps scope: Namespaced versions: - name: v1 served:truestorage:true执行命令部署 CRD让 K8s 识别这个新资源kubectl apply -f crd-demo.yaml此时 K8s 就新增了一种资源类型MyApp和 Pod、Deployment 同级。步骤2编写 CR创建具体资源实例新建 cr-demo.yaml基于上面的 CRD 模板创建一个具体的资源apiVersion: demo.com/v1 kind: MyApp metadata: name: my-first-app spec: appName:测试应用replicas:2执行命令创建 CR kubectl apply-fcr-demo.yaml步骤3查看自定义资源查看我们创建的 MyApp 资源CRkubectl get myapps能看到刚刚创建的 my-first-app说明操作成功。四、关键补充为什么大家都用它统一运维方式不管是原生资源还是自定义资源都用 kubectl 操作不用记各种奇葩命令可扩展、可定制业务需要什么能力就定义什么 CRD适配所有场景生态基础现在 K8s 主流中间件、运维工具全部基于 CRD/CR 实现是进阶 K8s 的必备知识点。五、极简总结牢记即可CRD自定义资源模板给 K8s 新增资源类型定规则CR基于 CRD 模板创建的具体业务资源核心价值扩展 K8s 原生能力实现个性化业务运维使用顺序先装 CRD再建 CR。