2022.8.11心血来潮,写下了这篇内容,以下内容均来自个人理解,无摘抄,有不对的地方还请指出。


        对于一个应用在kubernetes的发布,对于新人来说,常常会考虑不周到,束手无策,那么如何能够成为经验丰富的大牛呢?看如下(对于单体服务发布的思路):

1、应用镜像文件的制作(具体怎么制作这里就不多赘述了)。

2、应用是有状态的还是无状态的?具体要采用kubernetes哪种资源类型来进行部署。(这个是需要考虑的)

3、服务端口怎么暴露?(采用service还是ingress)

4、需要考虑应用数据文件、日志文件的持久化(这里就暂时不考虑,根据需求添加pv即可)

以上思路仅是单体服务发布思路。


那么想一下,生产场景(应用怎么部署呢?)

对于生产场景,App应用之间是存在耦合性的。怎么说呢?我就拿Java服务来举例子吧,因为目前来说Java项目还是占大头的(哈哈,因为目前我们公司的业务基本上都是java写的)。好,那我们来看项目发布需要考虑到的问题:

1、一般采用Java服务,都会采用自动注册和自动发现,那么对于这类服务,开发人员开发期间采用最多的就是Nacos、Eureka、Consul。具体这些服务我就不分析了。以我们公司为例,用的其实是Nacos。那么大家想一下,对于这类服务我们需要以单体服务发布思路来考虑吗?

首先:

(1)我们考虑一下镜像文件的制作,目前官网已经有现成的镜像文件,并且已经十分成熟,我们直接拿着用就行了。

(2)nacos应用是有状态的还是无状态的?具体要采用kubernetes哪种资源类型来进行部署?

可能大家还不知道什么是有状态服务什么是无状态服务,这里我给大家简单明了的说一下:

无状态服务不会在本地存储持久化数据,多个服务实例对于同一个用户请求的响应结果是完全一致的,这种多服务实例之间是没有依赖关系。

有状态服务需要在本地存储持久化数据,典型的是分布式数据库的应用,分布式节点实例之间有依赖的拓扑关系。比如:主从关系。如果K8S停止分布式集群中任一实例pod,就可能会导致数据丢失或者集群的crash。

那么我们现在知道了,nacos应用是无状态服务,所以我们就可以考虑具体要采用kubernetes哪种资源类型来进行部署。关于k8s资源类型需要大家做详细了解和学习啦,这里我就直接给出答案,建议:使用Statefulset管理有状态服务、Deployment来管理无状态服务。

(3)服务端口怎么暴露?在k8s中一般采用service和ingress进行端口暴露,service是基于IP端口暴露,ingress是基于域名暴露,然后代理到对应的service上。


2、服务发现和注册组件以及部署上去了,那么接下来就是SpringCloud中的Api网关服务了,微服务之间要通信,那就一定离不开网关这个桥梁。具体它的部署方式其实和nacos一样。参考上面即可。


3、接下来就是中间件服务的部署了,中间件服务大家应该都是比较了解的,比如:MySQL、MongoDB、Redis、ES、RabbitMQ等。

对于这类服务,我们就需要考虑它的数据存放问题。我们必须要保证数据的安全性、可用性(毕竟数据至上)。

对于数据存放的问题,在生产环境建议大家针对数据存放问题单独做一套数据存储集群,使用nfs或者ceph技术为k8s集群提供数据存储。

那么大家可能要问了?我为什么要花大价钱单独再弄一套存储呢?这个和K8s的功能息息相关,容我慢慢道来,假设:你有1M3N的集群环境,现在数据库调度到了N1机器,数据在N1做的存储(因为现在用的是单独创建的PV),现在机器突然down机,容器发生漂移,这时候它还能使用到N1机器存储的数据吗?这显然不可以。所以对于高可用就不贴合实际了。好,那么数据存储问题就聊到这里。

通过上面的学习,这里我们也应该知道这类中间件服务属于有状态服务,具体怎么部署,大家还得努努力学习。

然后我们还需要考虑的是服务端口怎么暴露,个人理解:对于这类中间件服务非必要不暴露端口,一般采用k8s内部FQDN进行通信即可。如果有特殊需求,可以采用端口暴露,上层可以使用一些安全审计、防火墙等一些设备(因为数据安全太重要了)。


4、接下来就是业务部署了。业务又分前端和后端。

(1)我们先来聊一下后端。我们需要考虑到:1.后端业务怎么连接中间件服务进行通信(这个问题显然也不是我们需要考虑的,嘿嘿,一般是在业务部署前,我们会把中间件通信地址给开发人员)。2.后端业务如何与网关通信,这一点很重要(这个问题显然也不是我们需要考虑的,我们只是一个执行者)。3.后端业务如何自动注册到Nacos(哈哈,这个问题显然不是我们考虑的,这是开发人员应该做的)。

那么对于后端业务进行容器化,我们应该怎么做呢?首先,业务开发完毕后,开发人员会把jar包给你,这个时候开发人员工作就已经完成了。我们需要做什么呢?第一步:我们需要将这些jar包使用dockerfile做成镜像。第二步:考虑日志是否要持久化存储,一般情况下是不需要的,因为我们后期可以使用EFK这种日志收集系统进行日志收集存储。第三步:考虑这类服务是有状态还是无状态,想必大家应该也知道了,无状态服务。第四步:端口暴露问题,可以直接告诉大家这类服务不需要进行端口暴露,因为之后客户访问前端,前端代理的gateway,然后gateway转发到对应后端服务上。

(2)接下来聊一下前端。这里就以vue项目为例。我们仅需要配置一个nginx,访问来过来的请求转发到gateway api网关上即可。无状态服务。端口暴露使用service + ingress方式进行暴露。


5、业务上线后,可以根据需求,部署集群、容器监控系统(prometheus技术栈)、日志收集系统(ELK Stack)、链路监控(skywalking)等。


好,那么到此为止,整套业务就完美上线了,当然,在部署期间肯定会有大大小小的坑等着我们运维工程师去排查。

这种方式对于显然对于业务量比较大的场合下是不合适的。那么延伸出去就又有了自动化应用交付场景(GitOps)。


那么想一下,生产场景(自动化应用交付场景怎么做呢?)

这里我先对架构做一个假想。如下:

Gitlab -> jenkins -> harbor -> 测试集群 -> 生产集群

这里我简述一下,开发人员推送代码到Gitlab仓库,jenkins检测仓库代码发生更新,然后拉取代码进行编译、构建镜像,构建好的镜像推送到harbor镜像仓库中,然后构建服务发布到测试环境的k8s集群中,测试没问题后,我们运维人员,点击确认发布到生产环境的k8s集群中。这是理想状态,也不难实现。

目前已经有了十分成熟的技术。自建流水线业务是可以的,不过成本会比较大。当然个人推荐大家可以学习一下KubeSphere技术栈,构建流水线业务还是十分方便的。