本篇主要介绍扩展的本质以及CRD与Operator之间的区别，帮助大家理解相关的概念以及知道要进行扩展需要做哪些工作。
CRD（CustomerResourceDefinition）
自定义资源定义,代表某种自定义的配置或者独立运行的服务。
用户只定义了CRD没有任何意义，只是注册了一种资源，但没有执行器参与逻辑处理。我们要去开发一个控制器去专门处理CRD的调度逻辑，控制器就是一个一直在工作的生产者消费者模型，监听着对象的变化，当对象发生改变时，就会根据对象的期望，去做相应的处理，最终达成对象的期望。像Deployment就是一个控制器。 而我们开发控制器的过程就是operator开发。
Operator
用来扩展Kubernetes API，特定的应用程序控制器。
严格来说只要新定义一个CRD一定会配套开发一个operator，否则没有任何意义。但开发operator不一定要新定义CRD，因为这个控制器可以是对已有资源类型的处理。
脚手架开发
由于k8s的基础架构模块已固定，在没有脚手架之前operator的开发是个很复杂的过程，于是官方给了operator开发的脚手架kubebuilder，同样受追捧的还有CoreOS出品的Operator-SDK。
总述：没脚手架前，图中涉及到的我们都要开发；有脚手架后，图中涉及到的我们只需要开发绿色部分。
scheme：k8s原生资源与CRD资源的映射依赖关系，因为最底层都是借助原生资源完成的，CRD只是他们的打包和封装。
cache：资源的共享信息，接收API调用，根据当前信息判断增删改查操作。
watcher：观察者模式，触发增删改操作，封装成命令包推送到Queue中。
Reconcller：开发者真正要编写的逻辑部分，对CRD的读写操作是通过controller manager中的client。
Read Client：对CRD的读直接走cache
Write Client：对CRD的写直接走API Server