蒋龙

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

一

引言

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

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

二

相关名词

民生智能运维项目

基于机器学习的智能运维项目致力于在科技运维领域，引入大数据技术、机器学习算法、自然语言处理等人工智能领域前沿技术，能够充分利用已有的报警、监控和日志信息构建大数据平台，使用人工智能技术分析大数据，发掘出有用知识，帮助运维工程师更快更准确地发现系统异常、找到问题原因甚至给出解决方案，让运维工作更加高效、准确和智能。

科技运维团队与清华大学实验室合作，搭建多维分析和异常检测平台。此外还结合当前运维痛点，自主研发其他分析工具，如变更检查、工单处理推荐等，更多更好的为运维工程师服务，提高整体运维水平。

民生容器云平台

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

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

docker

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

k8s客户端

k8s为kubernetes缩写，Google开源容器集群管理系统，使用中重点理解如下概念：

也需了解yaml文件语法，k8s平台通过yaml来配置、管理各个Pod/Service等资源。

k8s客户端工具——kubectl（一个二进制文件），可直接复制-粘贴使用。用于连接k8s平台，使用token方式认证客户端，客户端可提交yaml文件，管理pod/service/deployment等资源，还可进入容器中进行操作。

Jenkins

基于Java开发的一种持续集成的开源工具，把我们日常开发、测试中重复使用的命令，整理汇总成一条条流水线，使开发、测试、发布自动化，并通过网页显示进度等信息。

本文针对云平台的使用，主要使用Jenkins来管理/提交yaml文件、编译部署容器，从而降低人工维护文件复杂度及操作的重复度。

三

部署流程

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

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

一

镜像准备

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的技术指导，充分体现了民生科技运维团队的核心技术实力与高效的团队协作精神。

文章转载自民生运维，点击下方原文链接可以查看原文，民生运维相关技术分享、公示公告，文章发布。公众号：民生运维。

扫描下面的二维码(或微信搜索 k8s技术圈)关注我们的微信公众帐号，在微信公众帐号中回复加群即可加入到我们的 kubernetes 讨论群里面共同学习。