CRD创建
通过对Kubebuilder的介绍，我们已经了解了Kubebuilder 的功能与原理。从本节开始，我们深入分析 Kubebuilder 各模块的运行原理。首先，我们通过添加几条命令来添加几个自定义 CRD，Group表示 CRD所属的组，它可以支持多种不同版本、不同类型的资源构建；Version表示 CRD的版本号；Kind表示 CRD的类型，具体见代码清单 3-2。
#kubebuildercreateapi--groupdemo--versionv1--kindDemo
#kubebuildercreateapi--groupship--versionv1beta1--kindTest1#kubebuildercreateapi--groupship--versionv1beta1--kindTest2
执行上述命令后，我们先来看一下API层多出来的 CRD 文件结构，按照版本号进行了资源的一级划分，在上述案例中，创建了 1个 v1 版本的 Demo 类型的资源，因此，它自动生成了 {kind}types.go的文件，即 demotypes.go；同时创建了 2个 v1beta1版本的不同类型的资源，可以看到生成了 2个资源文件，分别是 test1_types.go、test2_types.go。我们看到 Kind定义的资源类型在Kubernetes 中一定以大写字母开头，而它的资源文件都自动转化成小写字母，这是Kubernetes的一种约定。并且在每个版本的资源生成的过程中， 都会包含 groupversion_info.go、zz_generated.deepcopy.go 文件，它们的作用是什么呢？ 这与 Scheme模块的原理有关，即 Scheme通过这 2个文件实现了 CRD的注册及资源的拷贝，具体见代码清单 3-3。
[root@crd/demo]#treeapi/api/
├──v1
│ ├──demo_types.go
│ ├──groupversion_info.go
│ └──zz_generated.deepcopy.go
└──v1beta1
├──groupversion_info.go
├──test1_types.go
├──test2_types.go
└──zz_generated.deepcopy.go
到这里，细心的读者会思考上述 3个资源的定义文件，除了类型、版本号、所属组不同，即 demo_types.go、test1_types.go、test2_types.go，这几个文件的内容有什么实质性的差异吗？下面我们继续看一下资源文件的具体内容，经过实践我们发现，资源本身的结构 除了名称上的差异，并无任何区别。换句话说，Kubebuilder创建出来的 CRD，结构体是相似的，用户只需要定义自己资源的结构体、做 Controller的协调部分的逻辑。这个简化 过程，对于初次接触 KubernetesCRD 的用户来说非常有益，可以帮助用户快速构建应用。
下面我们挑选其中的test1_types.go内容进行说明（截取部分内容）。Test1表明资源的结构体，包括 metadata、spec、status，以及继承的 Kubernetes资源属性，如 kind、apiVersion等；Test1List 表明资源的列表结构体，即当用户查询这一类资源时，各test1的内容放在了Items键的下面。另外，init() 初始化方法的作用是将资源的类型注册到Scheme对应的 ship组的 v1beta1版本下，在介绍 Kubebuilder框架的时候，我们提及了Scheme的作用，在这里就体现了，具体见代码清单 3-4。
typeTest1struct{
metav1.TypeMeta `json:",inline"`metav1.ObjectMeta`json:"metadata,omitempty"`Spec Test1Spec `json:"spec,omitempty"`StatusTest1Status`json:"status,omitempty"`
}
typeTest1Liststruct{
metav1.TypeMeta`json:",inline"`
metav1.ListMeta`json:"metadata,omitempty"`Items []Test1`json:"items"`
}
funcinit(){
SchemeBuilder.Register(&Test1{},&Test1List{})
}
除了CRD的定义外，我们还需要思考它的 Controller部分，这也可以通过代码清单 3-2的几条命令初始化出来的 Controller 文件来理解。下面，我们先来看一下文件的结构，其中每一个 CRD，默认会创建对应的 {kind}controller.go文件，如 test1_controller.go，这就是 CRDController逻辑构造的位置，具体见代码清单 3-5。
 |
[root@crd/demo]#treecontrollers/controllers/
├──demo_controller.go
├──suite_test.go
├──test1_controller.go
└──test2_controller.go
那么 {kind}controller.go 文件的内容是什么呢？为了阐明它的原理，我们截取部分代码。通过观察我们发现，自动生成的 Reconciler的对象名称是 {kind}Reconciler，它的主方法是 Reconcile()，即通过在这个函数的空白处填入逻辑完成对应的 CRD 构造工作，剩下的是安装、运行工作。另外，我们还发现了 SetupWithManager 方法，这个方法的作用是什么？下一节将会系统介绍。这里，我们只需要清楚，它用于 CRDController的安装。安装完成后，CRDController才能运行，具体内容见代码清单 3-6。
typeDemoReconcilerstruct{client.Client
Loglogr.LoggerScheme*runtime.Scheme
}
func(r*DemoReconciler)Reconcile(reqctrl.Request)(ctrl.Result,error){
_=context.Background()
_=r.Log.WithValues("demo",req.NamespacedName)
//yourlogicherereturnctrl.Result{},nil
}
//SetupWithManagersetsupthecontrollerwiththeManager.
func (r*DemoReconciler)SetupWithManager(mgrctrl.Manager)error{returnctrl.NewControllerManagedBy(mgr).
For(&yangweiweiv1.Demo{}).
Complete(r)
}
