kubebuilder实战之四：operator需求说明和设计

系列产品文章内容连接

1. kubebuilder实战演练之一：准备工作
2. kubebuilder实战演练之二：第一次感受kubebuilder
3. kubebuilder实战演练之三：基本知识快评
4. kubebuilder实战演练之四：operator要求表明和设计方案
5. kubebuilder实战演练之五：operator编号
6. kubebuilder实战演练之六：搭建布署运作
7. kubebuilder实战演练之七：webhook
8. 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上，她的状况和面对的情况以下：

1. springboot运用已制成docker镜像系统；
2. 根据压测得到单独pod的QPS为500；
3. 估计得到发布后的总QPS会在800上下；
4. 伴随着运营策略转变 ，QPS还会继续有调节；
5. 总体来说，小琪手上仅有三个数据信息：docker镜像系统、单独pod的QPS、总QPS，她对kubernetes不了解，必须 有一个计划方案来帮她将服务项目布署好，而且在运转期内能支撑点外界的分布式系统浏览；

之上便是小琪的要求了，我们来总结一下：

1. 我们为小琪开发设计一个operator（名叫elasticweb），对小琪而言，她只需将手上的三个主要参数（docker镜像系统、单独pod的QPS、总QPS）告知elasticweb就完事情了；
2. elasticweb在kubernetes建立pod，对于pod总数自然是全自动算出來的，要保障能达到QPS规定，以之前的具体情况为例子，必须2个pod才可以达到800的QPS；
3. 单独pod的QPS和总QPS都随时随地有可能转变 ，一旦发生变化，elasticweb也需要全自动调节pod总数，以保证 服务水平；
4. 为了更好地保证 服务项目能够被外界启用，我们再顺带帮小琪建立好service（她对kubernetes掌握很少，这事情我们就随手干了吧）；

自我保护申明

• 看了以上要求后，聪慧的您一定会对于我投来瞧不起的目光，实际上kubernetes早已有已有的QPS调整计划方案了，比如改动deployment的团本数、单独pod竖向扩充、autoscale等都能够，此次应用operator来完成只是是为了更好地展现operator的研发全过程，并不是说自定operator是唯一的解决方法；
• 因此，假如您认为我这类用operator完成扩充的方法很low，请不要将我骂得太惨，我这也就是为了更好地展现operator开发设计全过程罢了，更何况咱这一operator也不是一无是处，用了这一operator，您就无需关心pod总数了，只需对焦单案例QPS和总QPS就可以，这两个主要参数更接近业务流程；
• 为了更好地不把事儿弄繁杂，假定每一个pod需要的CPU和运行内存是确定的，立即在operator编码中写死，实际上您还可以自身改编码，改为能够在外界配备，如同镜像系统名字主要参数那般；
• 把要求都交待明白了，下面进到设计方案阶段，先把CRD设计方案出去，这但是关键的算法设计；

CRD设计方案之Spec一部分

Spec是用于储存客户的期望的，也就是小琪手上的三个主要参数（docker镜像系统、单独pod的QPS、总QPS），再再加上端口：

1. image：业务流程服务项目相应的镜像系统
2. port：service占有的宿主机端口号，外界要求根据此端口号浏览pod的服务项目
3. singlePodQPS：单独pod的QPS限制
4. totalQPS：当今全部项目的总QPS

• 对小琪而言，键入这四个主要参数就完事情了；

CRD设计方案之Status一部分

• Status用于储存具体值，这儿设计方案成只有一个字段名realQPS，表明当今全部operator具体能适用的QPS，那样不论什么时候，只需小琪用kubectl describe指令就能了解当今系统软件事实上能适用是多少QPS；

CRD源代码

• 把算法设计说清楚的较好办法便是看编码：

code

1. package v1
2. import (
3. "fmt"
4. metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
5. "strconv"
6. )
7. // 期待情况
8. type ElasticWebSpec struct {
9. // 业务流程服务项目相应的镜像系统，包含名字:tag
10. Image string `json:"image"`
11. // service占有的宿主机端口号，外界要求根据此端口号浏览pod的服务项目
12. Port *int32 `json:"port"`
13. // 单独pod的QPS限制
14. SinglePodQPS *int32 `json:"singlePodQPS"`
15. // 当今全部业务的总QPS
16. TotalQPS *int32 `json:"totalQPS"`
17. }
18. // 具体情况，该算法设计中的值全是业务流程编码推算出来的
19. type ElasticWebStatus struct {
20. // 当今kubernetes中具体适用的总QPS
21. RealQPS *int32 `json:"realQPS"`
22. }
23. // kubebuilder:object:root=true
24. // ElasticWeb is the Schema for the elasticwebs API
25. type ElasticWeb struct {
26. metav1.TypeMeta `json:",inline"`
27. metav1.ObjectMeta `json:"metadata,omitempty"`
28. Spec ElasticWebSpec `json:"spec,omitempty"`
29. Status ElasticWebStatus `json:"status,omitempty"`
30. }
31. func (in *ElasticWeb) String() string {
32. var realQPS string
33. if nil == in.Status.RealQPS {
34. realQPS = "nil"
35. } else {
36. realQPS = strconv.Itoa(int(*(in.Status.RealQPS)))
37. }
38. return fmt.Sprintf("Image [%s], Port [%d], SinglePodQPS [%d], TotalQPS [%d], RealQPS [%s]",
39. in.Spec.Image,
40. *(in.Spec.Port),
41. *(in.Spec.SinglePodQPS),
42. *(in.Spec.TotalQPS),
43. realQPS)
44. }
45. // kubebuilder:object:root=true
46. // ElasticWebList contains a list of ElasticWeb
47. type ElasticWebList struct {
48. metav1.TypeMeta `json:",inline"`
49. metav1.ListMeta `json:"metadata,omitempty"`
50. Items []ElasticWeb `json:"items"`
51. }
52. func init() {
53. SchemeBuilder.Register(&ElasticWeb{}, &ElasticWebList{})
54. }

业务流程数字逻辑

• CRD的进行意味着关键算法设计早已明确，下面是领域模型的设计方案，主要是理清晰controller的Reconcile方式里边做些啥，实际上关键逻辑性或是比较简单的：算出必须多少个pod，随后根据升级deployment让pod总数做到规定，在这里关键的根基上再把建立deployment和service、更新status这种零碎的事儿搞好，就完事情了；
• 这儿将全部领域模型的流程表给出去以下所显示，用以具体指导开发设计：

• 到此，我们完成了全部elasticweb的需要和设计方案，聪慧的您毫无疑问早已成竹在胸，并且急不可耐的想运行开发设计了，好的，下一篇我们正式开始编号！

参考文献

• 您也许会怪异，小琪对kubernetes不了解，为什么会了解docker镜像系统的制做，也有单独pod的QPS她是怎么测的呢？
• 实际上她是程序猿欣宸的粉絲，早已阅读文章过下列blog：

1. 《SpringBoot-2.3镜像方案为什么要做多个layer》
2. 《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》
3. 《详解SpringBoot(2.3)应用制作Docker镜像(官方方案)》
4. 《Kubernetes下web服务的性能测试三部曲之一：准备工作》
5. 《Kubernetes下web服务的性能测试三部曲之二：纵向扩容》
6. 《Kubernetes下web服务的性能测试三部曲之三：横向扩容》

你并不孤单，欣宸原創一路相伴

1. Java系列
2. Spring系列
3. Docker系列产品
4. kubernetes系列
5. 数据库查询 分布式数据库系列产品
6. DevOps系列