小公司的应用服务部署历程
先声明一下:我所在的公司是一个小团队,做物联网相关的,前后端、硬件、测试加起来也就五六十个人左右;本人的岗位是Java开发(兼DBA、运维。。。);我进公司时整个项目的部署架构为 简单jar包部署微服务集群形式;去年公司将部分服务使用docker进行部署;因为现在服务稍微有点多导致容器管理起来也比较难,再加上我们公司没有专门的运维人员,所以现在打算使用云商的k8s来对容器统一进行管理。因为运维相关的事情我一直在负责,上周老大让我画一下用k8s部署接口调用链路图,所以我便顺便总结了一下,以下大部分内容为我自己理解,如果有什么不对的地方还请大家多多指出。
一.常见服务部署架构
1.传统服务器jar运行部署(公司之前使用的部署方式)
服务部署架构图
优点
- 学习成本低:只需要掌握Linux命令即可操作,不需要掌握其他特殊命令;
缺点
- 隔离性差: 1.各个集群中所有服务共用相同运行环境,如果环境发生错误将会影响集群当前节点上所有的服务;2.如果其中某一个服务发生死锁、内存泄漏等异常,此服务部署的所有节点(服务器)的内存/CPU可能会被占满,也将影响整个集群的其他服务,导致所有应用不可用;[之前一个项目CPU占用过高进而影响到节点上所有的服务]
- 部署步骤繁琐:想要部署一个服务,必须得一台一台的进行部署;
- 有操作风险:开发人员直接操作服务器,有存在误操作的风险(sudo rm -rf /*)。
- 服务启动速度慢。
2.docker 容器化部署(公司目前使用的部署方式)
服务部署架构图
优点
- 使用方便:只需要拉取镜像、运行镜像 两步操作即可运行一个服务;
- 隔离性好:一个容器一个运行环境,互不影响,运行时分配好内存,如果某一个服务出现内存泄漏、CPU占用高等问题,只会影响当前容器,不会触及到其他容器;
- 快速回滚:当前版本如果出现问题,可以快速的拉取前一个容器的版本,如果使用上面那个部署形式则需要使用git回滚完,再重新打包部署;
- 系统利用率高:docker对系统资源的利用率更高,无论是应用执行速度,内存损耗或者文件存储速度,都要比传统虚拟机技术更高效。因此,相比虚拟机技术,一个相同配置的主机往往可以运行更多数量的应用;
- 启动服务的速度更快。
缺点
- 管理麻烦:随着业务的不断发展,微服务不断的增加,导致容器太多管理麻烦,增加运维成本;
- 误操作风险:跟上面那一张部署方式一样,开发人员直接操作服务器,有一定的风险;
- 学习成本:稍微需要一点容器相关的知识,需要学习docker常见的一些命令
- 其他的暂时没太关心。
3.k8s容器化部署(现在公司需要升级的部署方式)
服务部署架构图
名词解释
- Node:单台主机,可以是物理的或虚拟的计算机。结点分为主结点(master)和工作结点(worker) – 个人理解:一个节点就是一台服务器(实例)
- Master:k8s 集群控制节点,对集群进行调度管理,接受集群外用户去集群操作请求
- Pod :K8s中的工作单元,服务运行的最小单元。每个Pod中包含一至多个容器;一个Pod的容器在K8s集群中有相同的地址和端口范围,即容器暴露于K8s集群的端口号不可重复- 个人理解:一个每个Pod就是k8s虚拟出来的一个微型服务器,它有自己的虚拟IP、端口等等
- Deployment:无状态工作负载,个人理解:就是管理Pod的,负载Pod的扩缩容等操作。
- StatefulSet:有状态工作负载,与Deployment一样。不同点在于 Deployment的Pod名称,主机名称 ,存储等都是随机,不稳定的,所以不适合数据库等需要持久化的服务器运行,而StatefulSet就可以。
优点
- 自动部署和回滚:我们可以直接通过k8s控制台一键实现目标版本代码的回滚、部署。
- 服务发现和负载均衡:Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 如果进入容器的流量很大, Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。
- 自我修复:Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器。
- 不需要直接操作服务器:控制台操作,简化了部署流程,减少了运维成本,开发人员无需关注服务器运维相关事情。
- 资源调度:当node节点上的CPU、内存不够用的时候,可以扩充node节点,新建的pod就会被调度到新扩充的node节点上。
- 故障迁移:当某一个node节点关机或挂掉后,node节点上的服务会自动转移到另一个node节点上,这个过程所有服务不中断
- 资源隔离:可以通过创建开发、测试、预发、生产等命名空间实现不同环境的隔离,各环境之间互不影响。
- 扩缩容方便:只需要在控制台调整每个Deployment中Pod的数量就可以实现自动扩缩容。
- 减少了公司运维成本
- Docker有的其他优点。
缺点
- 部署麻烦(自己搭建)
- 占用资源多(自己搭建)
- 运维成本高(自己搭建)
综上所述:咱们使用云商搭建好的k8s,所以说目前对我们来说没有什么缺点 -- 嘿嘿~。
二.k8s部署、服务调用链路相关
1.简介
就不介绍了,有兴趣的可以看一下官方文档:https://kubernetes.io/zh-cn/docs/concepts/overview/
2.基本概念
Pod里是容器,Pod被ReplicaSet管理,ReplicaSet控制pod的数量;
ReplicaSet被Deployment管理,Deployment控制pod应用的升级、回滚,当然也能控制pod的数量。
Service提供一个统一固定入口,负责将前端请求转发给Pod
3.调用链路
1.目前公司前后端服务调用链路
前端
1、 前端访问域名;
2、 域名DNS解析到部署前端项目的服务器(集群:则解析到集群对应的SLB负载均衡公网IP上—SLB负责具体将请求打在某一台服务器上);
3、 被请求的服务器用Nginx通过域名加目录的形式将请求转发到不同的前端项目。
后端接口
1、 访问api接口
2、 域名DNS解析到部署网关服务器(集群:则解析到集群对应的SLB负载均衡公网IP上—SLB负责具体将请求打在某一台服务器上);
3、 被请求的服务器用Nginx将请求转发到当前服务器的Gateway网关
4、 网关对请求接口进行鉴权、匹配路由等操作。
5、 通过Nacos自带负载均衡Ribbon负载到具体某一个应用服务
6、 返回结果请求结束。
2.使用k8s部署后,前后端调用链路
前端
1、SLB监听80和443端口。
2、请求进来进行域名DNS解析,解析到集群暴露出来的公网SLB的IP上。
3、经过nginx Ingress 转发匹配请求路径,将请求转发到不同的Server(一个Server对应一个Deployment,对应一个项目)上。
4、Server会通过k8s自身的负载均衡算法将请求负载到某一个Pod上面(这一步k8s内部有一个负载均衡选择具体服务的哪一个Pod)
5、访问到具体的Pod,返回结果。
后台接口
1、 SLB监听80和443端口。
2、 请求进来进行域名DNS解析,解析到集群暴露出来的公网SLB的IP上。
3、 经过nginx Ingress 转发到对应的gateway网关Server上。
4、 Server会通过k8s自身的负载均衡算法将请求负载到某一个网关Pod上面。
5、 网关对请求接口进行鉴权、匹配路由等操作。
6、 通过Nacos自带负载均衡Ribbon负载到具体某一个应用服务
7、 返回结果请求结束。
4.阿里云流水线 + Kubernetes 镜像升级部署实践
K8s镜像部署
先进行镜像构建 如下两步操作并运行流水线
在k8s管理界面的 [工作负载] --> [无状态] 目录根据需要部署的环境切换命名空间,如:测试环境(namespace-dev)
创建对应的 Deployment 与 pod
点击右上角“使用镜像创建”、对k8s编排掌握好的可以直接使用 yaml 创建,推荐使用镜像创建。
a.填写对应的应用服务信息
b.选择对应的镜像和版本(刚才创建的)
其他的不需要填、如果有提示不能为空的直接删掉就可以了
c.下一步直接点击创建、完成后出来到无状态目录下找到创建的Deployment,点击去 ---> 容器组 --> 点进去 ---> 日志 (进行日志查看)
k8s镜像升级
回到流水线页面在构建镜像的基础上新建一个 部署任务--Kubernetes 镜像升级,注意: 命名空间、Deployment名称、容器名称 不要填错。
这样就完成了k8s镜像的升级
本文来自博客园,作者:Tom-shushu,转载请注明原文链接:https://www.cnblogs.com/Tom-shushu/p/16913567.html
标签:容器,负载,k8s,部署,应用服务,服务器,Pod,历程 From: https://www.cnblogs.com/sexintercourse/p/16916663.html