kubebuilder实战四:operator需求描述和设计

欢迎访问我的 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、本地磁盘这类)：

kubebuilder实战四:operator需求描述和设计插图

以上是打横扩大基本上做法，在Kubernetes地理环境，倘若外部规定超过了独立pod的处理极限，我们可以提高pod数量来保证打横扩大的目的，如下图：

kubebuilder实战四:operator需求描述和设计插图1

以上就是状况信息，下边大家聊一聊elasticweb这一operator的首要功效；

规定说明

为了更好地更好地说清楚规定，这里虚构一个场景：小琪是个java开发者，就是下边这一妹子：

kubebuilder实战四:operator需求描述和设计插图2

现如今小琪要将Spring Boot应用部署到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就可以，这两个基本参数更贴近工作流程；
为了更好地更好地不把事情弄复杂，假设每一个pod必须的CPU和运作运行内存是明确的，马上在operator编号中写死，事实上您还能够本身改编号，改成可以在外部配置，好似镜像系统名称基本参数那样；
把规定都交代懂了，下边进到方案设计环节，先把CRD方案设计出来，这可是主要的优化算法设计方案；

CRD方案设计之Spec一部分

Spec是用来存储用户的期待的，也就是小琪手里的三个基本参数（docker镜像系统、独立pod的QPS、总QPS），再再再加上端口号：

image：工作流程服务相对应的镜像系统
port：service占据的宿主机端口，外部规定依据此端口访问pod的服务
singlePodQPS：独立pod的QPS限定
totalQPS：现如今所有工程的总QPS

对小琪来讲，输入这四个基本参数就完事儿了；

CRD方案设计之Status一部分

Status用以存储实际值，这里方案设计成只有一个列名realQPS，说明现如今所有operator实际能适合的QPS，那般不管怎样情况下，只需小琪用kubectl describe命令就能掌握现如今系统软件软件实际上能可用多少钱QPS；

CRD源码

把计算机算法说明白的比较好方法就是看编号：

package v1

Import (
	"fmt"
	Metav1 "K8s.io/apiMachinery/pkg/apis/meta/v1"
	"strconv"
)

// 希望状况
type ElasticWebSpec struct {
	// 工作流程服务相对应的镜像系统，包括名称:tag
	Image string `json:"image"`
	// service占据的宿主机端口，外部规定依据此端口访问pod的服务
	Port *int32 `json:"port"`

	// 独立pod的QPS限定
	SinglePodQPS *int32 `json:"singlePodQPS"`
	// 现如今所有工作的总QPS
	TotalQPS *int32 `json:"totalQPS"`
}

// 详细情况，该计算机算法中的值都是工作流程编号计算出来的
type ElasticWebStatus struct {
	// 现如今kubernetes中主要适合的总QPS
	RealQPS *int32 `json:"realQPS"`
}

//  kubebuilder:object:root=true

// ElasticWeb is the Schema for the elasticwebs API
type ElasticWeb struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   ElasticWebSpec   `json:"spec,omitempty"`
	Status ElasticWebStatus `json:"status,omitempty"`
}

func (in *ElasticWeb) String() string {
	var realQPS string

	if nil == in.Status.RealQPS {
		realQPS = "nil"
	} else {
		realQPS = strconv.Itoa(int(*(in.Status.RealQPS)))
	}

	return fmt.Sprintf("Image [%s], Port [%d], SinglePodQPS [%d], TotalQPS [%d], RealQPS [%s]",
		in.Spec.Image,
		*(in.Spec.Port),
		*(in.Spec.SinglePodQPS),
		*(in.Spec.TotalQPS),
		realQPS)
}

//  kubebuilder:object:root=true

// ElasticWebList contains a list of ElasticWeb
type ElasticWebList struct {
	metav1.TypeMeta `json:",inline"`
	metav1.ListMeta `json:"metadata,omitempty"`
	Items           []ElasticWeb `json:"items"`
}

func Init() {
	SchemeBuilder.Register(&ElasticWeb{}, &ElasticWebList{})
}

工作流程数据 逻辑性

CRD的开展代表着重要计算机算法早就确立，下边是领域模型的方案设计，主要是理清楚controller的Reconcile方法里面做些啥，事实上重要思维逻辑或者非常简单的：算出务必多少个pod，接着依据升級deployment让pod数量保证要求，在这儿重要的基础上再把创建deployment和service、更新status这类零碎的事情做好，就完事儿了；
这里将所有领域模型的流程图模板给出来下列所表明，用于指导设计开发：

kubebuilder实战四:operator需求描述和设计插图3