热烈欢迎浏览我的GitHub

https://github.com/zq2599/blog_demos

內容:全部原创文章内容筛选及配套设施源代码,涉及到Java、Docker、Kubernetes、DevOPS等;

系列产品文章内容连接

  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源代码

  • 把算法设计说清楚的较好办法便是看编码:
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这种零碎的事儿搞好,就完事情了;

  • 这儿将全部领域模型的流程表给出去以下所显示,用以具体指导开发设计:

在这里插入图片描述

  • 到此,我们完成了全部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系列

热烈欢迎扫码关注:程序猿欣宸

搜索微信「程序猿欣宸」,我是欣宸,希望与您一同遨游Java世界...
https://github.com/zq2599/blog_demos

评论(0条)

刀客源码 游客评论