欢迎访问我的GitHub
https://github.com/zq2599/blog_demos
内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；
系列文章链接kubebuilder实战之一：准备工作
kubebuilder实战之二：初次体验kubebuilder
kubebuilder实战之三：基础知识速览
kubebuilder实战之四：operator需求说明和设计
kubebuilder实战之五：operator编码
kubebuilder实战之六：构建部署运行
kubebuilder实战之七：webhook
kubebuilder实战之八：知识点小记
本篇概览作为《kubebuilder实战》系列的第四篇，经历了前面的充分准备，从本篇开始，咱们来开发一个有实际作用的operator，该operator名为elasticweb，既弹性web服务；
这将是一次完整的operator开发实战，设计、编码、部署等环节都会参与到，与《kubebuilder实战之二：初次体验kubebuilder》的不同之处在于，elasticweb从CRD设计再到controller功能都有明确的业务含义，能执行业务逻辑，而《kubebuilder实战之二》仅仅是一次开发流程体验；
为了做好这个operator，本篇不急于编码，而是认真的做好设计工作，咱们的operator有什么功能，解决了什么问题，有哪些核心内容，都将在本篇整理清楚，有了这样的准备，才能在下一章写出符合要求的代码；
接下来咱们先聊一些背景知识，以便更好的进入正题；
需求背景QPS：Queries-per-second，既每秒查询率，就是说服务器在一秒的时间内处理了多少个请求；
背景：做过网站开发的同学对横向扩容应该都了解，简单的说，假设一个tomcat的QPS上限为500，如果外部访问的QPS达到了600，为了保障整个网站服务质量，必须再启动一个同样的tomcat来共同分摊请求，如下图所示(简单起见，假设咱们的后台服务是无状态的，也就是说不依赖宿主机的IP、本地磁盘之类)：
以上是横向扩容常规做法，在kubernetes环境，如果外部请求超过了单个pod的处理极限，我们可以增加pod数量来达到横向扩容的目的，如下图：
以上就是背景信息，接下来咱们聊聊elasticweb这个operator的具体功能；
需求说明为了说清楚需求，这里虚构一个场景：小欣是个java开发者，就是下图这个妹子：
现在小欣要将springboot应用部署到kubernetes上，她的现状和面临的问题如下：
springboot应用已做成docker镜像；
通过压测得出单个pod的QPS为500；
估算得出上线后的总QPS会在800左右；
随着运营策略变化，QPS还会有调整；
总的来说，小欣手里只有三个数据：docker镜像、单个pod的QPS、总QPS，她对kubernetes不了解，需要有个方案来帮她将服务部署好，并且在运行期间能支撑外部的高并发访问；
以上就是小欣的需求了，咱们来小结一下：
咱们为小欣开发一个operator（名为elasticweb），对小欣来说，她只要将手里的三个参数（docker镜像、单个pod的QPS、总QPS）告诉elasticweb就完事儿了；
elasticweb在kubernetes创建pod，至于pod数量当然是自动算出来的，要确保能满足QPS要求，以前面的情况为例，需要两个pod才能满足800的QPS；
单个pod的QPS和总QPS都随时可能变化，一旦有变，elasticweb也要自动调整pod数量，以确保服务质量；
为了确保服务可以被外部调用，咱们再顺便帮小欣创建好service（她对kubernetes了解不多，这事儿咱们就顺手做了吧）；
自保声明
看过上述需求后，聪明的您一定会对我投来鄙视的眼光，其实kubernetes早就有现成的QPS调节方案了，例如修改deployment的副本数、单个pod纵向扩容、autoscale等都可以，本次使用operator来实现仅仅是为了展示operator的开发过程，并不是说自定义operator是唯一的解决方案；
所以，如果您觉得我这种用operator实现扩容的方式很low，请不要把我骂得太惨，我这也只是为了展示operator开发过程而已，况且咱这个operator也不是一无是处，用了这个operator，您就不用关注pod数量了，只要聚焦单实例QPS和总QPS即可，这两个参数更贴近业务；