CustomResourceDefinition（CRD）是Kubernetes中用于扩展API的机制，允许用户定义自定义资源类型。通过CRD，可像原生资源一样使用kubectl管理自定义对象，例如创建名为Database的资源并执行kubectl get databases。标准资源无法覆盖所有业务场景，如数据库、消息队列或机器学习任务需抽象为一级资源，CRD结合控制器可实现自动化操作并简化用户使用。CRD以YAML文件定义资源元信息，API Server据此注册新的REST路径，供API或kubectl调用；通常配合控制器监听资源变化并执行具体逻辑。例如定义MyApp资源后，可创建replicas为3、镜像为nginx:latest的实例。实际使用中需注意校验和版本控制，建议结合Kubebuilder或Operator SDK进行管理。
Kubernetes 的 CustomResourceDefinition（CRD）是一种扩展机制，允许用户自定义资源类型，就像原生的 Pod、Service 那样使用。通过 CRD，你可以定义自己的对象模型，让 Kubernetes API 理解并管理这些新类型的资源。
CustomResourceDefinition 是什么
CRD 全称是 CustomResourceDefinition，它告诉 Kubernetes 集群如何处理一种新的资源类型。一旦创建了一个 CRD，你就可以像使用 Deployment 或 ConfigMap 一样，用 kubectl 创建、删除或查询这种资源。例如，你可以定义一个叫 Database 的资源，然后执行 kubectl get databases 来查看实例。
为什么需要 CRD
标准资源无法满足所有业务场景。比如运维数据库、消息队列或机器学习训练任务时，可能希望把这些抽象成一级资源。CRD 提供了这样的能力：
- 把复杂应用打包成声明式 API
- 与控制器配合实现自动化操作（如自动备份、扩缩容）
- 简化平台用户的使用方式，隐藏底层细节
CRD 怎么工作
CRD 本身是一个 YAML 文件，描述了新资源的元信息，包括名字、版本、字段结构等。Kubernetes API Server 会根据这个定义注册新的 REST 路径，比如 /apis/example.com/v1/myapps。之后用户就能通过 API 或 kubectl 操作这些资源。
通常搭配一个自定义控制器来监听这些资源的变化，当用户创建一个自定义对象时，控制器会执行具体逻辑，比如部署对应的 workload。
一个简单例子
假设你要定义一个叫 MyApp 的资源：
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: myapps.example.com
spec:
group: example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
replicas:
type: integer
image:
type: string
scope: Namespaced
names:
plural: myapps
singular: myapp
kind: MyApp
应用后，你就能创建如下对象：
apiVersion: example.com/v1 kind: MyApp metadata: name: hello spec: replicas: 3 image: nginx:latest
基本上就这些。CRD 不复杂但容易忽略校验和版本控制的问题，实际使用中建议结合 Kubebuilder 或 Operator SDK 来管理。
