普元容器云平台实践分享

时间 2019-11-13

标签容器平台实践分享繁體版

原文原文链接

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

1、为什么要上容器云？

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

相较于传统运维，咱们有太多痛点，下面为你们分析一二。服务器

痛点分析：微信

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

那么，若是上了容器云，这些痛点能缓解甚至消失吗？咱们再来看看。

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

固然，上面咱们分析所列出的问题可能并不全。可是无能否认，容器云的确能够为部署与运维带来很多的便利与提高。

2、普元容器云建设概述

普元的容器云这几年一直在发展。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，能够提供从介质至应用镜像的构建能力。

3、关键设计

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

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之中。

4、实践分享

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

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

b. 系统管理模块。建立系统的时候，须要选择它所在的业务区与部署区。业务区只能选择一个，但部署区能够选择多个（参考前面的概念模型），系统中的应用与服务，能够部署在不一样的集群之中。系统有系统成员的概念，只有为此系统成员的用户，才能够在本身的面板中看到这个系统，在此系统中建立应用与服务。

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

建立服务时，须要先选择服务所在的系统，而后选择部署区（只能选择一个）。而后填写服务的参数。通常的参数咱们都设有默认值，这里只提供最经常使用的参数供用户修改。可选是否进行服务扩展，部署dubbo服务提供者。若是须要部署dubbo服务提供者，须要选择一个dubbo的注册中心（支持多注册中心，在系统配置中设置）。

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

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

e. 最后介绍一下镜像管理模块。咱们将镜像分红了公共镜像与应用镜像。公共镜像统一放置在harbor的一个专有project中，应用镜像则放在每一个系统在harbor上对应的project中。用户能够经过使用公共镜像中的基础镜像，加本身的介质，构建出本身的应用镜像，而后用来应用部署。

5、总结

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

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

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