民生银行智能运维项目在容器云平台的部署实践

蒋龙

毕业于北京大学计算机科学技术系，于2012年加入民生银行信息科技部，先后在基础环境组、PE开发组工作，目前在应用运维二中心担任运维工程师。热衷于大数据、机器学习、云技术等领域研究，目前致力于智能运维项目在民生银行运维中的实践落地。

伴随着大数据和机器学习技术的发展，世界已经在全面向智能化迈进。当下，人工智能技术持续不断地向传统行业赋能，改变人类的生活。而在运维领域工程师们也希望借助AIOps改变IT行业中原有的完全依靠人工经验、重复而枯燥的工作模式，完成从生产运维到技术运营的转变。

民生科技也从未停止持续创新与不断挑战的步伐，为顺应人工智能技术的飞速发展潮流，民生银行信息科技部数据中心启动了智能运维项目，展开了我行智能运维方面的研究与探索。为了提升应用版本部署效率，本项目使用民生容器云平台进行环境搭建。本文旨在帮助大家了解智能运维项目在民生云平台中搭建、部署过程，为其它项目的云化提供必要参考。

民生智能运维项目

民生容器云平台

已经有越来越多的应用，特别是创新类应用需要用到容器技术，来实现快速上线、快速迭代、精益控制。传统的应用也需要容器技术的支撑，来实现DevOps和微服务改造。

我行容器云平台基于kubernetes和 docker 技术构建，采用分布式存储提供数据持久化存储能力，可帮助我们DevOps快速落地，使应用微服务化，提升资源使用效率，实现快速高效的HA切换能力，更有利于应用创新，有利于标准化的配置管理和版本管理，有利于标准化的监控和日志处理。

docker

docker镜像（Image）是较精简版的 linux 虚拟机镜像，以磁盘文件体现，含有操作系统和应用程序，使用Dockerfile文件生成镜像；docker容器（Container）为实际运行着的镜像，可使用docker命令进入容器内部进行操作，修改后的容器若未反向保存为镜像，则容器在删除后，使用镜像再次启动容器时已经启动了新的容器，修改的内容已经丢失；一个镜像可启动N个容器，镜像与容器的关系类似于类和实例的关系。更多知识可参考docker官网。

k8s客户端

Jenkins

三

部署流程

假设您已经准备好可发布的应用程序包，我们的目标是将此应用程序部署在云平台中，从而提高后期变更、迁移、维护（如重启）等的效率。因此完整的上线部署关键步骤为：

下文分别讲解各个步骤的关键知识：

一

镜像准备

docker镜像来源一般有2种：官方或社区（Docker Hub）镜像和自己编译的镜像。

社区镜像，可登录Docker Hub (https://hub.docker.com)进行搜索，如ubuntu/mysql/mongo/redis等，常用的镜像一般都可以找到。若未找到所需的，可基于这些已有镜像编译自己的镜像。

自定义镜像，一般是将应用程序打包在镜像里，在本地电脑或云服务器进行编译生成。

本项目中共使用9个镜像，其中50%为社区镜像，50%为自定义镜像。社区镜像有 mongodb 、influxdb、 mysql 、 redis 、nginx，自定义镜像有focus-web、hadoop_krb5、autotrin、alpine-java。

针对自定义镜像，主要基于alpine、 python 、jdk镜像编译生成，镜像清单详见后文。

二

测试云平台应用部署

当准备好镜像后，则需上线云平台的测试环境进行验证、调试。下文使用znyw表示当前项目的英文编写名称。整个上线云平台的过程如下：

申请相关账户，主要为svn账户、云平台账户、Jenkins账户。

svn账户：用于上传镜像，jenkins会从svn中下载镜像并上传到DTR（镜像库）中；

云平台账户：用于操作云平台资源，如查看容器资源状态、操作容器启停等、操作DTR库等，主要包括DTR（镜像库）账号、k8s的config文本文件；

Jenkins账户用于jenkins界面操作。

云平台运行环境的相关配置，主要是DTR仓库创建、密钥制作。

DTR仓库创建：仓库创建是在DTR的对应组织(znyw)下创建对应的镜像仓库，如nginx.tar镜像包应创建nginx这个仓库名称；

密钥制作：DTR密钥存在DTR服务端，与申请下来的客户端config文件配对使用，密钥需根据config文件制作生成，可使用kubectl小 工具 制作，也可在jenkins界面中制作。

yaml文件语法可参考k8s官网，也可参考我行制定的部署文档。编写好后通过jenkins界面上传保存，当然也可以自行保存，但为达到统一配置管理目的，不建议自行保管。当前主要使用 Deployment 和 Service 两种模板。

jenkins界面可进行构建编译，当在线修改完yaml配置后，可进行重新构建并重启容器。在构建过程中，也可使用kubectl客户端工具查看进度，kubectl的常用基本命令有：

1、Pod/Deploy/Service/集群情况概述【kubectl get pod/deploy/svc/quota】

2、查询单个描述信息【kubectl describe pod/deploy/svc 相应名称】

3、查看pod日志【kubectl logs pod的名称】，即容器运行过程中的日志

4、查看集群资源情况【kubectl get quota 集群名称 -o yaml】

5、删除某个资源【kubectl delete pod/deploy/svc 相应名称】

6、进入容器【kubectl exec -it pod的名称 bash】，假设容器安装了bash

四

智能运维项目应用部署

生产云平台应用部署参照测试云平台步骤，但应遵循在测试中调试通过的程序、脚本等资源，应重新编译成新镜像，配置尽量均写到yaml文件中，确保生产的镜像在运行时不再需要手工进入容器进行变更操作，从而提高程序的可维护性。

本项目应用程序按功能可分为两类：多维分析和异常检测。因此在部署时容器的名称按此两类进行命名。

一

镜像与容器的对应关系

在云平台中运行的容器，与镜像存在多对一的关系。同镜像的不同功能容器，是根据应用的配置或运行的程序代码决定的。其对应关系如下图所示：

多维分析模块（简称Focus）共使用4个镜像及4个容器。

异常检测模块（简称Anomaly）使用6个镜像及15个容器。

二

多维分析部署架构

多维分析Focus的架构图如下。主要通过浏览器上传需分析的文件（csv格式），然后平台通过机器学习分析，在网页上展现出分析的结果。

三

异常检测部署架构

异常检测Anomaly的架构图如下:

其中“云平台部署”中每一个节点均为一个（或多个复本的）容器。主要包括以下功能：

实时的异常检测：后台通过spark-streaming实时计算出结果，保存至influx中。前端浏览器通过调用api查询influx中异常结果数据。

自动发现KPI配置：将influx中KPI结果与mongo中KPI配置对比，发现新增的KPI配置，再调api将新配置保存至mongo中。

异常告警及根因定位：查询influx中异常检测结果，若存在符合配置要求的告警（配置数据在mongo中，由人工设定），则发送邮件通知，并触发异常定位，调api，通过spark集群计算，找到与此异常相关的服务器信息。

自动更新模型：会定期（时间由人工设定）调api，使用spark集群进行模型训练，并将新模型保存至mongo中，保证模型的及时更新。

mongo：保存了存KPI/训练模型/异常信息。

五

常见问题

1.

jenkins构建过程中显示Pod状态为非Running状态

可使用describe和logs两个命令结合，查看pod在启动过程中的详细报错信息。主要原因可能有：

1、容器的启动脚本在执行时异常了，导致容器自动退出。可先在启动脚本中写个死循环，循环体内sleep一下（也可使用tail -f命令），确保容器不会主动退出，然后再进入容器中，手工执行脚本，检查错误原因。

2、DTR密钥不正确。需按文档中步骤重建DTR密钥。

2.

构建后Pod一直未显示在get pod的列表中

可先查看deploy，是否Deployment部署成功。再看DESIRED数目是否与CURRENT数目一致，若不一致，则很可能是当前项目的所有部署的yaml文件中申请/限制的计算资源（即CPU和内存）的总和超过云平台资源的设定。

资源限制规则一：yaml中requests的数量总和不能超过项目集群的50%。

资源限制规则二：单个yaml中limits不能超过单个虚拟机的70%。

例如本项目申请2台虚拟机（每台8C/32G），则正在运行的yaml文件的requests总和不能超过8C/32G，单个yaml中limits不能超过5.6C/22G。

最后可视情况进行扩容或缩小资源使用情况。

本项目部署在一周左右时间，从零基础开始到上线完成，实现了程序的全部云化。在此过程中得到了科技运维团队各位老师的大力支持，尤其是对云平台k8s、jenkins的技术指导，充分体现了民生科技运维团队的核心技术实力与高效的团队协作精神。

编辑：民生运维文化建设团队

作者：蒋龙