本篇主要介绍扩展的本质以及CRD与Operator之间的区别,帮助大家理解相关的概念以及知道要进行扩展需要做哪些工作。
自定义资源定义,代表某种自定义的配置或者独立运行的服务。
用户只定义了CRD没有任何意义,只是注册了一种资源,但没有执行器参与逻辑处理。我们要去开发一个控制器去专门处理CRD的调度逻辑,控制器就是一个一直在工作的生产者消费者模型,监听着对象的变化,当对象发生改变时,就会根据对象的期望,去做相应的处理,最终达成对象的期望。像Deployment就是一个控制器。 而我们开发控制器的过程就是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