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

转载本文需注明出处:微信公众号EAWorld,违者必究。

目录:

一、为何要上容器云?

二、普元容器云建设概述

三、关键设计

四、实践之路

五、总结

一、为何要上容器云?

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

相较于传统运维,我们有太多痛点,下面为大家分析一二。

痛点分析:

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

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

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

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

二、普元容器云建设概述

普元的容器云这几年一直在发展。2015年的时候,公司启动了新一代企业云平台(内部简称新一代)的预研与探索。我们将应用从需求调研到开发到部署到运维等等,拆分成了22个领域系统。其中包括PM(项目管理),IAM(身份识别与访问管理),SCM(软件配置管理),SPM(软件产品管理)等,容器云是做为SEM(软件环境管理)最初在公司出现的。

当时的SEM只是一个小模块,没有管理门户,也无需用户,配置等模板,只有最简单的容器部署能力。到了2016年,公司加大了对DevOps产品的投入力度。容器云需要做为DevOps的其中一个部署环境,为此我们开启了第二版(内部名为kunkka)的研发。这次在原有基础上加了模板相关的管理等,也有自己的用户,设置等,但仍然没有门户。

时至2017年年中,结合外部项目,容器云发展到了第三代(内部代号arturo)。这一次我们终于有了门户,也有租户,区域,报表,日志等模块。一步步走来,模块越来越多,功能越来越强越来越稳定,我们对前方的路也更清晰。

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

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

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

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

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

系统只是一个逻辑概念,我们一般把它对标一个软件系统,当然你也可以把它对标一个项目组或人员小组这样一个组织机构,比较灵活。它下面关联着多个部署空间。系统下的应用与服务都将运行在这些部署空间之中。

大家稍微分析一下就可以发现,系统通过关联多个部署空间,其实是间接关联到了多个集群。这说明,我们系统,其实是可以跨集群去进行部署的,它下面的应用与服务,可以部署在不同的集群中。

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

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

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

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

三、关键设计

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

1. 首先,这次的版本,我们摒弃了上一版本容器采用组装化部署的方式。容器镜像我们走回了采用完整镜像的标准打包方式。完整的镜像,更容易维护,也利于同DevOps等平台进行对接。

2. 从概念模型中,可以看出我们有租户的概念。但租户的并不是在每个表中置入一个租户字段,它有独立的对象。只需要将租户与一些关键的对象关联起来,就可以起到隔离的目的。

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

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

5. 容器云要上生产,高可用是必过的一道坎。普元容器云目前部署主要是四块: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来切换。

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

它有两个k8s中的service,一个是redis主服务的,一个是哨兵的。Redis主服务的主要用来redis master与slaver之间通信,保障集群的稳定。因为要对集群外也提供服务,所以这里redis主服务的容器,我们采用的是hostnetwork,直接在所在节点上暴露端口。

Redis哨兵则采用的是nodePort的方式对外提供服务。客户端首先连接哨兵,获取redis master的地址。因为redis主服务用的是hostnetwork,所以取得的master地址就是 redis master所在节点的IP加上它所暴露的端口。

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

7. 容器云,日志也是必不可少的一块。当前我们采用的是ELKB的方案。采用filebeat采集日志,kafka缓冲,logstash进行日志分析,入ES,最后由kibana进行展现。采集方面,我们采用了两套filebeat,分别对容器的标准输出与非标准输出进行采集。

标准输出采用deamonset中的filebeat进行采集,进入kafka中以Topic-主机名-deamon的topic中。非标准输出,则需要先将容器内部的日志挂载至主机某一目录之中,然后由运行在宿主机上的filebeat进行采集,进入kafka中以 topic-主机名-mount为名的topic之中。

四、实践分享

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

a. 首先介绍一下集群管理模块。添加集群时,需要添加集群的地址及https证书,同时也需要添加集群监控heapster中时序数据库influxdb的地址,这是目前我们监控信息的来源。

b. 系统管理模块。创建系统的时候,需要选择它所在的业务区与部署区。业务区只能选择一个,但部署区可以选择多个(参考前面的概念模型),系统中的应用与服务,可以部署在不同的集群之中。系统有系统成员的概念,只有为此系统成员的用户,才可以在自己的面板中看到这个系统,在此系统中创建应用与服务。

c. 服务管理模块。服务详情页面中,可以实时看到各个实例的cpu与内存状态,可以看到他们对外提供的访问点。

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

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

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

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

五、总结

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

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

精选提问:

问1:请问普元ISSA层采用什么技术方案?

答:普元几年前曾与银联合作开发过IAAS平台,底层采用的是openstack。

问2:直接在界面支持dubbo配置吗?

答:现在在界面上只支持添加dubbo的注册中心,可以支持添加多个,部署时由用户选择使用哪一个注册中心。

问3:租户分隔如何实现?

答:要看你想隔离到什么程度。轻一点的,就是共库共表,所有表加租户字段。或者有租户对象,关联几个顶层对象。重一点的,可以一个租户单独的一个数据库实例,甚至单独的数据库实例,达到物理上的强隔离。

问4:当流量高峰突然到来时,k8s的根据哪些指标来进行扩/缩容的?

答:目前还只支持k8s官方的根据cpu阀值来动态伸缩。后续会考虑添加内存,流控做为指标。

问5:如何解决200节点以上的集群?比消息中间件和数据库?如何实现跨域跨zone管理?

答:k8s目前官方的就已经可以支持1千节点的集群管理。跨域跨zone管理可以考虑k8s的fedaration。但是它只能解决跨域的管理问题,无法解决如网络,数据共享之类的问题。

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

原文发布于微信公众号 - EAWorld(eaworld)

原文发表时间:2018-07-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

Oracle 数据库版本发布计划变更:下一版本将是 18

编辑手记: 在最近举行的Oracle数据库技术大会上,Andy Mendelsohn 透漏了关于Oracle Database 产品发布计划的变更。自2018年...

45840
来自专栏IT大咖说

数据库容器化|未来已来

摘要 “你不是不够好,你只是过时了”这句话用到 IT 行业特别合适,每隔一段时间都会有新的技术出现, 让码农们应接不暇。借着回顾DBA工作中的几个时期,跟大家分...

42770
来自专栏沃趣科技

数据库容器化|未来已来

导语:“你不是不够好,你只是过时了”这句话用到 IT 行业特别合适,每隔一段时间都会有新的技术出现, 让码农们应接不暇。借着回顾DBA工作中的几个时期,跟大家分...

54760
来自专栏EAWorld

容器时代的DevOps部署

本文目录: 一、企业应用的部署发展 二、普元容器云与DevOps的部署设计 三、面向微服务的部署设计 四、容器组装化部署 五、容器云集成之路 六、结语 一、企业...

65570
来自专栏云计算D1net

保护微服务需要知道的那些事

随着容器的持续流行,将应用改造成云上的微服务,对于很多希望IT运营更加敏捷高效的企业来说是显而易见的下一步。但是,在容器化应用并且部署之前,需要首先确保你的应用...

35870
来自专栏lgp20151222

SSH(struts2+hibernate+spring)总结

10520
来自专栏Java架构师历程

Docker与CI持续集成/CD持续部署

Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。容器...

39730
来自专栏SDNLAB

容器和云给网络带来巨大的压力

鉴于开发人员已经开始采用敏捷、方便的可编排技术,因此会越来越多地采用基于容器的应用程序。但是当这些应用程序进入生产阶段时,他们的编排解决方案对操作复杂性产生了相...

36090
来自专栏祝威廉

开源选型中的基因论

如果能通过上面的几条,我么可能就会采用该套技术了。然而这往往会导致很多误用。比如很多人就把zookeeper当存储用了,因为倒也满足上面的一些需求。

7440
来自专栏小白课代表

不好意思,是我玩物丧志了!

我知道即使上图只是看到的话也看不出效果来,只能看到这是一个花里胡哨的动图,那再加上一段魔性的声音呢?

31130

扫码关注云+社区

领取腾讯云代金券