CRD
GitHub地址：https://github.com/kubernetes-sigs/kubebuilder
Kubernetes 里资源类型有如下所示：
上述资源类型可以满足大多数分布式系统部署的需求
但是在不同应用业务环境下，对于平台可能有一些特殊的需求，这些需求可以抽象为 Kubernetes 的扩展资源，而 Kubernetes 的 CRD (CustomResourceDefinition)为这样的需求提供了轻量级的机制，保证新的资源的快速注册和使用。
举个栗子：
我希望在 kubernetes 中有 KafkaSource 这个资源， 资源示例 kafka-source.yaml如下：
我们希望在执行 kubectl create -f kafka-source.yaml 之后，在 kubernetes 里会启动一个 pod，这个 pod 会做下面的事情：
- 它会从地址是 my-cluster-kafka-bootstrap.kafka:9092，topic 是 knative- demo-topic 的 kafka 机群里读取消
- 将读到的消息，发送到 kubernetes 的一个 Service 去执行
Kuberentes 里并没有 KafkaSource 这个资源可以使用，所以直接执行 kubectl create -f kafka-source.yaml 的时候，会出错。但是 kubernetes 提供的 CRD 机制可以让我们轻松的把上述功能添加到 kubernetes 里。
CRD 机制以上述 Kafkasource 为例，如下：
- 需要把 KafkaSource 这个资源注册到 kubernetes 中，这样 kubernetes 才会知道这个资源
- 注册之后，还需要开发一个 controller 组件，来监听用户是否创建了 KafkaSource，也就是部署、更新或者删除如上的 yaml 文件。
- Controller 监听到有用户创建了 KafkaSource，就会创建一个 pod 来做相应的工作
归纳一下就是：
用户向 Kubernetes API 服务注册一个带特定 schema 的资源，并定义相关 API
- 将扩展资源的数据存储到 Kubernetes 的 etcd 集群
- 借助 Kubernetes 提供的 controller 模式开发框架，实现新的 controller，并借助 APIServer 监听 etcd 集群关于该资源的状态并定义状态变化的处理逻辑
具体流程如下图：
在这个流程里，大部分是 client-go 为用户提供的框架和逻辑，可以直接使用，灰色的 AddFunc等是用户需要实现的关于该扩展资源的业务逻辑。informer 会借助 APIServer 跟踪该扩展资源定义的变化，一旦被触发就会调用回调函数，并把变更的具体内容放到 Workqueue 中，自定义 controller 里面的 worker会获取Workqueue 里面内容，并进行相应的业务处理。
注册使用 CustomResourceDefinition，以如下 kafkasource 的一个简化版本为例，kubectl create -f kafkasource-customresourcedefinition.yaml:
可能这时候，大家还是不知道如何进行开发，就算好不容易搞清楚了，感觉开发也是很复杂的事情，我们可以使用工具-kubebuilder 来做开发，我们来做一下小的 demo，来看一下 kubebuilder 是如何帮我们进行开发的。
安装
依赖：docker/go/kubebuilder
https://github.com/kubernetes-sigs/kubebuilder/releases
到相应的网址下载相应的二进制包，解压压缩包，并把二进制包放到系统路径里。接下来我们一步一步创建一个自定的 CronJob, 这也是一个比较经典的例子：
第一步：创建项目
kubebuilder init --domain tutorial.kubebuilder.io --license apache2 --owner "Authors"
- A license. The reference project uses Apache 2.
- A domain name. This is the unique domain used to identify your project's resources.
- An author name. This is the copyright owner listed in the copyright notice at the top of each source file.
让我们看一下生成的项目的结构：
go.mod:项目第三方依赖
Makefile:用来构建和部署 controller
PROJECT: metadata
Main.go: 应用执行入口
Config 目录下目前只包含启动在集群里启动controller的文件，还不包含CustomResourceDe nitions, RBAC con guration,and WebhookCon gurations.
config/manager: launch your controllers as pods in the cluster
config/rbac: permissions required to run your controllers under their own service account
main.go 中的 schemeHui 描述 Kinds 的 go types.
到目前这个项目包含：
- 设置了 flag
- 初始化了一个 manager，它会跟踪所有的 controller
- 启动 manager
第二步：创建 API
Groups， Versions and Kinds
kubebuilder create api --group batch --version v1alpha1 --kind SampleSource
讲解一下自动创建的三个文件
接下来我们看一下，创建好的文件内容,看代码：
api/v1: 只需要修改CronJobSpec和CronJobStatus
+kubebuilder:object:root :表示这是一个Kind
设计 API 的规则：
（1） 变量需要是驼峰，所以需要使用 tag 来标注
（2） 变量的类型也有要求
Numbers: int32、int64和resource.Quantity(举例：resources requests and limits )
Spec:
- Schedule: 定时
- Template：pod spec
第三步：创建 controller
Controller 是 kubernetes 的核心，它负责保持集群资源实际状态和期望的状态一致（pod 数量之类的的），这个过程叫做 reconciling.
对某个具体的 Kind 进行 reconciling 的部分，叫做 reconciler.
请看代码：
Import 部分......
会为大家仔细讲解
剩下的主要是编码部分，和部署验证部分
......
获取视频+文档
来源：51CTO
作者：xjtuhit
链接：https://blog.51cto.com/51reboot/2480331