官方文档：https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
kubernetes 有两种机制供用户扩展API
第一种：CRD，复用Kubernetes的API Server，无须编写额外的APIServer。用户只需要定义CRD，并且提供一个CRD控制器，就能通过Kubernetes的API管理自定义资源对象了，同时要求用户的CRD对象符合API Server的管理规范。
第二种：使用API聚合机制 ，用户需要编写额外的API Server，可以对资源进行更细粒度的控制（例如，如何在各API版本之间切换），要求用户自行处理对多个API版本的支持。
CRD 定义：
CRD 的全称是 Custom Resource Definition。顾名思义，它指的就是，允许用户在 Kubernetes 中添加一个跟 Pod、Node 类似的、新的 API 资源类型，即：自定义 API 资源。
Custom resources：
是对K8S API的扩展，代表了一个特定的kubetnetes的定制化安装。在一个运行中的集群中，自定义资源可以动态注册到集群中。注册完毕以后，用户可以通过kubelet创建和访问这个自定义的对象，类似于操作pod一样。
Custom controllers 自定义控制器:
Custom resources可以让用户简单的存储和获取结构化数据。只有结合控制器才能变成一个真正的declarative API（被声明过的API）。控制器可以把资源更新成用户想要的状态，并且通过一系列操作维护和变更状态。定制化控制器是用户可以在运行中的集群内部署和更新的一个控制器，它独立于集群本身的生命周期。
定制化控制器可以和任何一种资源一起工作，当和定制化资源结合使用时尤其有效。
Operator模式
是一个customer controllers和Custom resources结合的例子。它可以允许开发者将特殊应用编码至kubernetes的扩展API内。
通俗理解：CR即创建一个自定义资源，CRD是对资源的描述，CC是提供CRD对象的管理。
CRD本身只是一段声明，用于定义用户自定义的资源对象。但仅有CRD的定义并没有实际作用，用户还需要提供管理CRD对象的CRD控制器（CRD Controller），才能实现对CRD对象的管理。CRD控制器通常可以通过Go语言进行开发，并需要遵循Kubernetes的控制器开发规范，基于客户端库client-go进行开发，需要实现Informer 、ResourceEventHandler、Workqueue等组件具体的功能处理逻辑，
以官网的例子说明：
以下就是创建一个CronTab 资源。其中 Group: stable.example.com ,version:v1,resource:CronTab。而这个yaml文件，就是一个具体的“自定义API资源”，也叫CR（Custom resources），而为了让kubernetes 能够认识这个CR，你就需要让kubernetes 明白这个CR的宏观定义是什么，即CRD（Custom Resource Definition）
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: crontabs.stable.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: stable.example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
# either Namespaced or Cluster
#该API的生效范围，可选项为Namespaced（由Namespace限定）和Cluster（在集群范围全局生效，不局限于任何Namespace），默认值为Namespaced。
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
# 复数形式的名称，要求全部小写
plural: crontabs
# singular name to be used as an alias on the CLI and for display
# 单数形式的名称，要求全部小写
singular: crontab
# kind is normally the CamelCased singular type. Your resource manifests use this.
# CRD的资源类型名称，要求以驼峰式命名规范进行命名
kind: CronTab
# shortNames allow shorter string to match your resource on the CLI
# 缩写形式的名称，要求全部小写
shortNames:
- ct
preserveUnknownFields: false
# CRD的校验（Validation）机制
validation:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
CRD的高级用途
1、CRD的subresources子资源
Kubernetes从1.11版本开始，在CRD的定义中引入了名为subresources的配置，可以设置的选项包括status和scale两类。
- stcatus：启用/status路径，其值来自CRD的.status字段，要求CRD控制器能够设置和更新这个字段的值。
- scale：启用/scale路径，支持通过其他Kubernetes控制器（如HorizontalPodAutoscaler控制器）与CRD资源对象实例进行交互。用户通过kubectl scale命令也能对该CRD资源对象进行扩容或缩容操作，要求CRD本身支持以多个副本的形式运行。
subresources:
status: {}
2、CRD的校验（Validation）机制
validation:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
3、自定义查看CRD时需要显示的列
# 自定义查看CRD时需要显示的列，即kubectl get 命令能够显示的字段
additionalPrinterColumns:
- JSONPath: .status.conditions[-1:].type
name: State
type: string
- JSONPath: .metadata.creationTimestamp
name: Age
type: date
4、Finalizer（CRD资源对象的预删除钩子方法）
Finalizer设置的方法在删除CRD资源对象时进行调用，以实现CRD资源对象的清理工作。
接下来，好好研究怎么编写Custom controllers
参考：https://blog.csdn.net/weixin_41806245/article/details/94451734
