普元容器云关键设计和实践之路

17天前

作为基石之一的容器云,普元也一直不断在致力发展。那么,普元的容器云,又是具体如何来建设的呢?

为何要上容器云

目前,Devops,微服务与容器云,可以说是炙手可热的三大话题,甚至可以说它们是云时代企业新一代IT架构的三大基石也不为过。微服务主要解决的是开发期的设计问题,devops则是解决开发,测试与运维之间的衔接问题,容器云则是重点在于简化部署与解放运维。



痛点分析:

  • 流程: 有过传统项目实施经验的同学都知道,原来要上一个项目,一般企业都有很严格的上线流程。首先开发要出一个很长的上线手册。先是测试环境,再是预发环境,特别是到了生产环境,需要对着手册反复核对,谨慎操作。一个项目上线下来,心力交粹。
  • 安全:传统运维很多时候都需要通过命令行进行部署或运维。有时一不小心,很容易对系统造成冲击,甚至销毁宝贵的数据。一个运维毁了一个公司的事不是没有发生过。操作安全,始终都是让运维心惊的雷区。
  • 环境:有时候一个应用,在开发,测试乃至预发环境都一直好好的,一上生产,各种问题,百思不得其解。运维人员也焦头烂额,压力山大。
  • 自动:应用上线后难免有出现问题需要回滚的情况,此时需要删除原有版本,再上新版本,各种配置的修改烦不胜烦。如果这一切都可以自动,那该多好 ...
  • 智能:传统运维中,应用横向扩展困难。当流量高峰突然到来时,往往猝不及防,最终结果往是服务器崩溃,对外服务中断。如何智能应对流量高峰?
  • 追踪:传统运维中,应用出现问题也难以定位。问题可能出在哪呢,应用?服务器?网络?存储?可能因素太多



那么,如果上了容器云,这些痛点能缓解甚至消失吗?我们再来看看

  • 流程: 在容器云中,应用都是打包部署,镜像中已经包括了一切,所以上线流程必定大幅简化。只需要界面中选择,就可以在不同的环境中快速验证
  • 安全: 在容器云中,应用打包部署,无需执行shell命令。运维过程中,平台上基本可以看到一切,无需直接登陆生产主机。针对操作安全提高了不止一个档次
  • 环境: 容器镜像中自带标准环境,可最大程度减少运行环境差异。部署与运维对宿主机系统无乎零侵入,不易出现环境差异问题,程序运行也会更稳定
  • 自动: 在容器云中,因为部署过程中平台已经记录了应用的所有编排信息,应用的升级与回退变得极其简单
  • 智能: 配合对每个容器的性能监控,容器云可以根据负载自动调节应用运行的实例数,智能应对流量或性能需求高峰
  • 追踪: 在容器云中,对应用运行产生影响的因素相对较少。配合监控与日志休系,可快速发现并定位问题 

当然,上面我们分析所列出的问题可能并不全。但是无可否认,容器云的确可以为部署与运维带来不少的便利与提升。

普元容器云简介

普元的容器云这几年一直在发展。15年的时候,公司启动了新一代企业云平台(内部简称新一代)的预研与探索。我们将应用从需求调研到开发到部署到运维等等,拆分成了22个领域系统。其中包括PM(项目管理),IAM(身份识别与访问管理),SCM(软件配置管理),SPM(软件产品管理)等,容器云是做为SEM(软件环境管理)最初在公司出现的。当时的SEM只是一个小模块,没有管理门户,也无需用户,配置等模板,只有最简单的容器部署能力。到了16年,公司加大了对devops产品的投入力度。容器云需要做为devops的其中一个部署环境,为此我们开启了第二版(内部名为kunkka)的研发。这次在原有基础上加了模板相关的管理等,也有自已的用户,设置等,但仍然没有门户。时至17年年中,结合外部项目,普元容器云发展到了第三代(内部代号arturo)。这一次我们终于有了门户,也有租户,区域,报表,日志等模块。一步步走来,模块越来越多,功能越来越强越来越稳定,我们对前方的路也更清晰。


以下是我们当前版本的容器云的功能架构。底层基于kubernetes,上层则是容器云提供的能力。上层我们分了两大块,左边是平台的功能特性,如租户,用户,权限等等管理。而右侧呢,则是平台能够提供出来的基础服务,包括一系列的中间件。落在我们的平台中,就是一堆的模板拆解,参数封装,部署编排


为什么我们要把基础服务单独列出来呢?因为我们认为,容器云平台如果仅仅提供应用的部署,那就有点大材小用了,他有着隐藏的paas特性。现在一般的分布式应用,或多或少都会用到一些中间件,如果容器云能化身为一个PAAS平台,可以方便地提供这些稳定的中间件服务,将会大大简化应用的部署。

 

下面来看一下我们平台的整体概念。



其它的概念都比较好理解。我们重点讲一下我们的系统,部署空间,应用与服务的这四个概念。

首先是部署空间,它其实对标kubernetes中的namespace,是集群中用来做资源隔离用的,一个集群可以有多个namespace,所以也就有多个部署空间。

系统只是一个逻辑概念,我们一般把它对标一个软件系统,当然你也可以把它对标一个项目组或人员小组这样一个组织机构,比较灵活。它下面关联着多个部署空间。系统下的应用与服务都将运行在这些部署空间之中。大家稍微分析一下就可以发现,系统通过关联多个部署空间,其实是间接关联到了多个集群。这说明,我们系统,其实是可以跨集群去进行部署的,它下面的应用与服务,可以部署在不同的集群中。

应用比较简单,就是由一个镜像跑起来的容器,当然不至容器,也包括k8s中的service,HPA之类的,就是一个应用。它的镜像一般由用户构建,运行着用户的实际业务。

服务其实就是我们上面的基础服务,它由平台提供模板,镜像,参数,部署编排等,一般对应着第三方服务。相对应用,它就要复杂多了,可能有多组Service, Deployment,或者 StatefulSet之类的。


技术选型上,我们基本上是围绕着k8s来的,监控目前也就是用的k8s自带的heapster。镜像仓库用的是harbor。


这是目前我们容器云的一个部署关系图。平台本身的管理中心arturo是前后端端分离的。Harbor做为镜像仓库,k8s做为部署的载体,由Nas通过nfs协议为pod提供持久存储。我们还集成有jenkins,可以提供从介质至应用镜像的构建能力。

 关键设计

下面介绍一些我们容器云中的一些关键设计。


  • 首先这次的版本,我们摒弃了我们上一版本容器采用组装化部署的方式。容器镜像我们走回了采用完整镜像的标准打包方式。完整的镜像,更容易维护,也利于同devops等平台进行对接。
  • 从概念模型中,可以看出我们有租户的概念。但租户的并不是在每个表中置入一个租户字段,它有独立的对象。只需要将租户与一些关键的对象关联起来,就可以起来隔离的目的。




  • 集群之上,我们有区域的概念。但这个区域,我们将它们细分成了两类,业务区与部署区。每一个集群,必须同时设置业务区与部署区。不同重要等级的业务系统,我们建议通过创建搭建不同的集群进行物理隔离。不同的集群可能通过采用不同级别的硬件配置及高可靠配置,来达到不同的保障级别。业务区与部署区的二维度设计,更利于企业对集群进行规划。



  • 应用与服务的部署,需要占用切实的物理资源。很多企业对资源使用,都有比较完善的审批制度。为了满足这一需求,普元容器云集成了自已的BPS流程编排引擎,可以针对不同的企业定制精准的审批流程。我们目前默认的审批是很简单的一字型。



  • 容器云要上生产,高可用是必过的一道坎。普元容器云目前部署主要是四块:arturo管理平台,harbor,jenkins以及kubernetes。



Arturo本身是前后端分离的,后端无状态设计,数据库则采用msqyl主备保证高可用。
Harbor我们利用了它本身的镜像同步功能来实现双Harbor高可用。两个harbor之间都配置了针对对方的复制规则。外部通过vip往harbor中推送或拉取镜像,vip则由keepalive来保障始终分配在可用的harbor服务器上。每一个系统,我们都会在harbor中为它创建一个对应的project用来存储系统的应用镜像。系统创建时,我们会在两个harbor上都创建针对对方的复制规则。Harbor服务器故障恢复之后,只需要重新触发一次高可用检查,我们就可以在两个harbor服务上对恢复过程中缺失的同步规则补充完整,最终保障两边有着相同的镜像。
Jenkins我们采用的是多主的一个部署,而由客户端来决定构建应当在哪个服务器上去执行。目前采用的是轮询的方式。构建任务中会记录当前它在哪个服务器上进行构建,如果因为服务器失效而失败了,没有关系,重新构建一次就行。
Kubernetes我们的采用的是多master的模式。多master之间,采用的是同一套https的证书,对外只提供一个vip。Vip同样通过keep avlive来切换。



  • 容器云平台提供的基础服务,我们提供集群化的部署方案。以redis为例,我们采用的是一主二从三哨兵的部署模式。


它有两个k8s中的service,一个是redis主服务的,一个是哨兵的。Redis主服务的主要用来redis master与slaver之间通信,保障集群的稳定。因为要对集群外也提供服务,所以这里redis主服务的容器,我们采用的是hostnetwork,直接在所在节点上暴露端口。Redis哨兵则采用的是nodePort的方式对外提供服务。客户端首先连接哨兵,获取redis master的地址。因为redis主服务用的是hostnetwork,所以取得的master地址就是 redis master所在节点的IP加上它所暴露的端口。

目前微服务是大势所趋,一般的微服务框架都有服务注册中心。如果可以将基础服务再封装一下,直接将它的能力接口在注册中心注册,这样其它的微应用使用起来会更加方便。目前我们针对Dubbo框架,对redis等已经做了封装,如果你用的是dubbo,可以很方便地集成它们。


  • 容器云,日志也是必不可少的一块。当前我们采用的是ELKB的方案。采用filebeat采集日志,kafka缓冲,logstash进行日志分析,入ES,最后由kibana进行展现。采集方面,我们采用了两套filebeat,分别对容器的标准输出与非标准输出进行采集。标准输出采用deamonset中的filebeat进行采集,进入kafka中以Topic-主机名-deamon的topic中。非标准输出,则需要先将容器内部的日志挂载至主机某一目录之中,然后由运行在宿主机上的filebeat进行采集,进入kafka中以 topic-主机名-mount为名的topic之中。



实践分享

下面是我们在某银行中的一些实践:

  1. 首先介绍一下集群管理模块。添加集群时,需要添加集群的地址及https证书,同时也需要添加集群监控heapster中时序数据库influxdb的地址,这是目前我们监控信息的来源。
  2. 系统管理模块。创建系统的时候,需要选择它所在的业务区与部署区。业务区只能选择一个,但部署区可以选择多个(参考前面的概念模型),系统中的应用与服务,可以部署在不同的集群之中。系统有系统成员的概念,只有为此系统成员的用户,也可以在自已的面板中看到这个系统,也可以在此系统中创建应用与服务。
  3. 服务管理模块。服务详情页面中,可以实时看到各个实例的cpu与内存状态,可以看到他们对外提供的访问点。

创建服务时,需要先选择服务所在的系统,然后选择部署区(只能选择一个)。然后填写服务的参数。一般的参数我们都设置有默认值,这里只提供最常用的参数供用户修改。可选是否进行服务扩展,部署dubbo服务提供者。如果需要部署dubbo服务提供者,需要选择一个dubbo的注册中心(支持多注册中心,在系统配置中设置)。

      4. 应用管理。应用详情页面中,可以看到应用的性能情况,以及对外地址。应用支持启动,停止,重启,升级,回退,以及删除。

同样,应用创建时需要选择系统与部署区,还需要选择应用镜像,填写应用的版本,参数等。应用支持添加命令行参数及环境变量。应用对外的端口,已在镜像的配置中预置。

      5. 最后介绍一下镜像管理模块。我们将镜像分成了公共镜像与应用镜像。公共镜像统一放置在harbor的一个专有project中,应用镜像则放在每个系统在harbor上对应的project中。用户可以通过使用公共镜像中的基础镜像,加自已的介质,构建出自已的应用镜像,然后用来应用部署。

目前,容器云很多公司都在发展,很多也是基于k8s的。就像docker一样的,k8s基本上已成了容器编排的公认标准。但是,怎样才能用好这个编排呢?怎样才能让他更贴近我们的业务,更好地与微服务框架进行整合呢?普元一直在思考这个问题,也一直在摸索。

今天我们带来我们的部分经验,愿与诸君共勉,一起促进容器云在企业中的落地

 



关于作者秦双春现任普元云计算架构师。曾在PDM,云计算,数据备份,移动互联相关领域公司工作,10年IT工作经验。曾任上海科企软件桌面虚拟化产品的核心工程师,主导过爱数TxCloud云柜的设计与开发,主导过万达信息的食安管理与追溯平台的移动平台开发。国内云计算的早期实践者,开源技术爱好者,容器技术专家。


关于EAWorld:微服务,DevOps,数据治理,移动架构原创  技术分享


COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。