kubebuilder实战一：什么是CRD编程，什么是operator开发？

本片摘要

        从本文开始，将会给大家带来一个关于kubebuilder实战的系列文章，这个系列融入了我本人开发EMR on k8s的经验，相信大家学习完后，都可以上手完成自己的operator开发。

CRD编程&&operator开发

       熟悉k8s的同学都知道，k8s中定义了一系列的资源对象，比如pod，deployment,svc等等，使用kubectl api-resources可以看到当前版本的k8s所支持的全部资源以及分组等信息。比如下图是执行该命令后所展示的资源对象的一部分：

       在这些资源对象中，有一种名叫customresourcedefinitions的对象，简称crd。该资源的作用是让用户可以自定义自己的资源对象，从而方便用户的不同场景需求。我们kubectl get crd -A就可以看到一些已经安装的crd，比如：

       在上图可以看到已经安装的crd，比如calico相关的crd。 

       下面在用一个场景解释一下crd，比如有一个需求是，用户希望通过yaml只传入一个版本号，就能拉起对应版本的nginx deployment，而不需要关心deployment的其他字段细节，比如副本数，优雅启动，优雅终止等。此时使用k8s自带的deployment是无法满足要求的，于是便可以使用CRD编程，去自己写一个对象，这个对象只有一个资源属性，就是version。

       这就是所谓的CRD编程，就是按照customresourcedefinitions规定的格式，自己写一个资源对象。

       那么有了crd后，如何让用户通过apply yaml的方式，将nginx deployment启动起来呢，此时我们就要自己写一个控制器，控制器就是一个一直在工作的生产者消费者模型，监听着对象的变化，当对象发生改变时，就会根据对象的期望，去做相应的处理，最终达成对象的期望。例如deployment也是一个控制器，当我们将replicas改为2时，会给我们创建出两个pod。我们编写控制器的代码过程，就是operator开发。

kubebuilder

       上一小节，我们解释了crd编程和operator开发，就是要我们自己去写一个crd对象以及一个控制器。这些代码，在一些编程框架没出来之前，我们需要使用client-go去自己编写，非常复杂。而有了编程框架之后，编程框架会帮我们自动生成控制器和crd的代码，对于crd编程，我们只需要像写结构体一样定义变量即可，而operator开发，我们也需要关系控制器接收到对象变化的具体业务处理逻辑，比如拉起nginx deployment，而无需关系控制器的框架代码。大大简化了编写难度与复杂度，使得新手也很容易上手。

       目前主流的框架有两种，一种是官方的叫做kubebuilder，一种是非官方的叫做operator-sdk，operator-sdk是在kubebuilder的基础上，做了扩展，比如支持Helm等等。推荐大家在没有特殊需求的时候，尽量选择kubebuilder，毕竟是官方的。当然考虑到目前helm使用的非常广泛，后面我也会出一个系列，讲解一下operator-sdk的helm编程。

小结：

       今天讲解了crd编程和operator开发，以及operator编程框架简介。crd是k8s给我们提供了扩展对象的能力，而想达到对象的期望，就需要开发一个控制器，也就是operator开发。

       开源社区给我们提供了kubebuilder和operator-sdk两种框架（脚手架），简化了crd编程和operator开发的复杂度，让我们只关心控制器具体的业务逻辑就可。