普元容器云平台实践分享

转载本文需注明出处：微信公众号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公众号，我们会不断分享。

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


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


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