基于Kubernetes的PaaS平台研究与实践
2018-08-03宗序梅任彦辉
宗序梅 任彦辉
中国移动通信集团江苏有限公司
1 引言
江苏移动公司业务云资源池主要为自有业务提供基于计算、存储和网络的IaaS层资源,承载了和娱乐、车卫士、和教育、视频能力等众多的业务平台,快速响应了公司的业务发展。由于业务系统多采用的是传统单体式应用,组件众多、布署耗时久、扩容周期长,无法灵活应对突发的业务访问;同时基于虚拟化的云资源难以有效动态调整,无法做到弹性扩展,云资源池的利用率也无法有效提升。
和教育业务通过传统的虚拟机承载相关的应用模块,云平台提供基础的IaaS层资源。随着代码量的增长,每次更新代码,必须进行全面检查以便确定对其他服务无影响,开发效率较低;业务在高峰期需紧急申请主机布署业务,配置网络策略,流程较长。因此计划通过对业务微服务化改造,降低应用耦合性,减少开发更新时间;同时结合容器平台的功能,保障业务轻松扩容。
2 PaaS技术说明及架构
2.1 技术说明
基于容器的PaaS平台为整个数据中心提供分布式调度与资源协调功能,实现数据中心级弹性伸缩能力的软件堆栈,它将所有数据中心的资源当做一台计算机来调度和管理。
Kubernetes(k8s)是Google开源的容器集群管理系统,是一个基于容器技术构建的数据中心操作系统的解决方案。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。
2.2 系统架构
江苏移动公司在业务云资源池进行PaaS的探索研究,基于Kubernetes开源软件在资源池改造6台物理机,部署容器PaaS平台。管理节点、负载均衡节点、镜像仓库节点、日志告警节点和业务节点分散部署。
图1 容器平台架构图
master节点:主要由 apiserver、controller-manager、schduler等组成。
apiserver:作为kubernetes系统的入口,封装了核心对象的增删改查操作,以RESTFul接口方式提供给外部客户和内部组件使用。
controller-manager:负责执行各种控制器。
schduler:负责集群的资源调度,为新建的pod(由一组紧耦合的容器组成的容器组)分配资源。
minion节点∶主要由kubelet、kube-proxy等组成。
kubelet:负责管控docker容器,如启动、停止、监控运行状态等。它定期从etcd获取分配到本机的pods,并根据pod信息启动或停止相应的容器。同时,接收apiserver的http请求,汇报pods的运行状态。
proxy:负责为pod提供代理。定期从etcd中获取所有的services,并根据service信息创建代理。当某个客户pod要访问其它pod时,访问请求会经过本机proxy做转发。
2.3 功能架构
PaaS平台由管理域和业务域两部分组成。
管理域:管理模块完全分布式微服务化,基于Kubernetes管理各个模块,使得平台模块可以独立升级和运维,对模块实现灰度发布、版本快速迭代。同时具有容错、自动负载均衡和扩缩容等功能。
业务域:业务运行的节点,提供业务平台运行环境和访问途径。业务域可以有多个集群,每个集群是完整的、独立的一套Kubernetes集群。Kubernetes集群部署在物理机资源上,由PaaS统一管理,并提供裸计算、存储、网络等资源。
图2 容器平台功能图
平台功能由七大功能模块组成,分别是PaaS平台应用管理、日志管理、监控告警、资源管理、镜像仓库、服务管理域管理,主要面向平台不同用户角色提供相应的功能。
应用管理:运行应用的全生命周期管理,功能覆盖应用的代码托管、应用的发布管理、弹性伸缩、应用配置等。
日志管理:实现系统组件和应用日志的采集、分析、展示。
监控告警:实现组件和应用的监控、告警功能。
资源管理:指运行在PaaS平台之上的所有服务组件及应用的硬件资源环境的统一管理,涉及资源模板、资源分配与编排、资源注入等功能。
服务管理:指运行在PaaS平台上的所有服务组件的全生命周期管理,功能覆盖服务上架、服务订阅、服务目录、服务运行等。
镜像仓库:可以让开发人员轻松存储、管理和部署Docker 容器镜像。采用分布式 的Docker镜像服务架构,支持快速、稳定的Docker镜像下载与发布。通过HTTPS传输容器镜像,然后自动对静态映像进行加密。
域管理:可以创建不同的用户、角色和域。各用户创建的资源池相对独立,互不影响。
3 和教育业务微服务改造
3.1 微服务组件框架
和教育微服务组件基于Spring Cloud框架开发,Spring Cloud框架的基本组件与关系如下:
图3 微服务组件框架图
网关:通过服务网关统一向外系统提供RESTFul API,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。
注册中心:用于云端服务发现与定位服务,以实现云端中间层服务发现和故障转移。客户端向注册中心提供关于自己的元数据(诸如主机和端口,健康指标URL,首页等)。
配置中心:把应用原本放在本地文件的配置抽取出来放在中心服务器,从而能够提供更好的管理、发布能力。SpringCloudCon fi g分服务端和客户端,服务端负责将Git中存储的配置文件发布成RESTFul接口,客户端可以从服务端RESTFul接口获取配置。
微服务:微服务应用,即开发的具体应用,向注册中心注册,从配置中心获取具体配置,由网关调用以实现访问。
3.2 微服务网络
PaaS平台中针对每个微服务应用启动多个pod,微服务应用本身遵循Spring Cloud的架构模式,向注册中心注册,从配置中心取配置。pod之间的访问地址为Kubernetes架构下的虚拟IP,以避免容器重启后容器IP变化导致的无法访问问题。
在对外提供服务时,使用PaaS提供的负载均衡器,只需将网关服务对外暴露,即可保证整个微服务系统的可访问性。在这种部署方式中,每一个微服务都能够无中断的自由扩展或缩减容器数量,以应对服务高峰期或低谷期的不同访问压力,且无需更改其他配置。
和教育微服务中的应用除discovery和con fi g以外,均对外提供服务,所有的请求均是通过网关服务来传达的,因此微服务架构中只需暴露网关服务即可。在Kubernetes环境中,客户端发来的请求首先经过硬件负载均衡分发到Nginx代理,然后通过Nginx ingress分发到不同的微服务应用上。
图4 微服务网络架构图
4 微服务改造效果
和教育平台经过微服务化改造后:
(1)应用弹性伸缩、水平扩展,扩容周期提高到秒级:结合PaaS平台的水平扩展功能、微服务的自动发现与注册,保障了和教育在开学季访问高峰期只需要增加容器数量就可以满足扩容;通过设置CPU和内存利用率阈值,实现容器自动扩容。
(2)软件系统开发解耦,缩短代码更新时间,上线周期缩短60%:和教育业务,对资源配置需求灵活,客户端接口模块进行微服务化后,降低耦合性,减少了开发更新的时间;编写代码提交到自动编译打包、持续集成、自动部署上线全流程自动化。
(3)应用服务实时检测、故障自动恢复,提升业务可靠性:PaaS系统平台设置监控粒度及监控对象,自动重启故障应用;微服务的健康检查能够自动踢除无效应用,对微服务组件的可靠性起到了极大的提升作用。
(4)资源精细化运营,内存利用率由原来40%提升到80%:和教育客户端组件原来承载于10台虚拟机,内存峰值利用率40%左右。微服务化后布署了45个Pod,内存峰值利用率达到80%。
5 结束语
PaaS平台基于Kubernetes技术,具有高扩展性、高兼容性、负载均衡、灰度升级、失败冗余、容灾恢复等优点。在使用中适合对这些因素有要求的场景,如:高峰时段和低谷时段业务量差异巨大,业务负载波动剧烈,且波峰不可预估;高峰期业务资源需求高,很多应用面临快速上线的压力;服务组件众多,每次部署需要耗费很长时间,且容错能力比较薄弱,无法应对大规模并发访问等。结合容器化本身的特性,此系统更适合于模块化程度高的应用系统。