为了不把事情弄复杂，假设每个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这些琐碎的事情做好，就完事儿了；
这里将整个业务逻辑的流程图给出来如下所示，用于指导开发：
至此，咱们完成了整个elasticweb的需求和设计，聪明的您肯定已经胸有成竹，而且迫不及待的想启动开发了，好的，下一篇咱们正式开始编码！
参考资料您可能会奇怪，小欣对kubernetes不了解，怎么会知道docker镜像的制作，还有单个pod的QPS她是怎么测的呢？
其实她是程序员欣宸的粉丝，已经阅读过以下博客：
《SpringBoot-2.3镜像方案为什么要做多个layer》
《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》
《详解SpringBoot(2.3)应用制作Docker镜像(官方方案)》
《Kubernetes下web服务的性能测试三部曲之一：准备工作》
《Kubernetes下web服务的性能测试三部曲之二：纵向扩容》
《Kubernetes下web服务的性能测试三部曲之三：横向扩容》
你不孤单，欣宸原创一路相伴Java系列
Spring系列
Docker系列
kubernetes系列
数据库+中间件系列
DevOps系列
欢迎关注公众号：程序员欣宸微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos