宜信公司从2018年初开始建设容器云，至今，容器云的常用基本功能已经趋于完善，主要包括服务管理、应用商店、Nginx配置、存储管理、CI/CD、权限管理等，支持100+业务线、3500+的容器运行。伴随公司去VMware以及DevOps、微服务不断推进的背景，后续还会有更多的业务迁移到容器云上，容器云在宜信发挥着越来越重要的作用。本次分享主要介绍宜信容器云平台的背景、主要功能、落地实践及未来规划。

一、宜信容器云平台背景

宜信容器云平台的建设背景主要包括：

提高资源利用率。容器云建设之前，每台物理机上平均运行的虚拟机大概是20个，使用了容器云之后，每台物理机上平均运行的容器数达到50个；之前的CPU利用率大概在10%左右，迁移到容器云后，CPU利用率提高到20%以上，整个资源利用率得到了极大的提升。
提升服务可靠性。传统的虚拟机运维方式下，当机器宕机或系统故障时，需要运维手动重启虚拟机和服务，整个过程最快需要几十分钟到几个小时才能解决；使用容器云后，通过健康检查的方式，一旦发现有问题就自动重启恢复服务，可以达到分钟级甚至秒级的恢复。
节约成本。通过容器云提高了资源利用率，同时也节约了成本。公司每年会采购一些商业化软件，如虚拟化软件、商业存储等，费用动辄千万。我们基于开源技术自研一套容器解决方案，每年为公司节省上千万的软件采购和维保费用。
弹性伸缩。我们公司每年都会组织财富峰会，在这里有一个很经典的场景：秒杀，秒杀场景需要很快扩展业务的计算能力。为了快速应对互联网突发流量，如上述的财富峰会、APP线上活动，我们为服务设置了自动伸缩的策略：当CPU利用率达到60%的时候，自动做容器扩容，应对突发的业务流量，提高响应速度；活动过后，自动回收资源，提高资源的利用率。
DevOps整合。DevOps和敏捷开发的理论已经提出很多年了，为什么DevOps一直没有得到很好的推进和实践呢？因为缺乏一种工具把Dev和Ops联系起来，而容器的诞生很好地解决了这个问题。开发人员在开发完代码并完成测试以后，可以拿着测试的产物直接到生产环境部署上线，而部署的问题可以直接反馈给开发，形成闭环。也就是说，通过容器的方式，可以实现一次构建多次运行。由此可见，通过容器的方式实现DevOps是最佳的方案，企业亟需一套成熟的平台帮助开发和运维人员保持各个环境的一致性和快速发布、快速回滚。

在上述背景下，我们结合宜信的业务场景开发建设宜信容器云平台。

二、宜信容器云平台主要功能

宜信容器云平台经过一年多时间的建设和开发，基本的常用功能已经具备。如图所示。

上图左侧是宜信容器云平台的主要功能，包括：服务管理、CI/CD、代理出口、配置管理、文件存储、告警策略、镜像管理、用户管理、权限管理、系统管理等。右侧是一个服务管理的界面，从中可以看到服务列表、服务名称、服务状态及当前服务数量，还有当前镜像版本及更新时间。

2.1 宜信容器云平台架构

上图所示为整个容器云平台的架构图，在各种开源组件（包括Harbor镜像仓库、Kubernetes容器管理、Prometheus 监控、Jenkins构建、Nginx流量转发和Docker容器虚拟化等）的基础之上，我们自研开发了5个核心模块。

Cluster-mgr，负责多个Kubernetes集群之间的管理和调度，在一个Kubernetes集群出现问题后，将该集群的容器迁移到其他可用的Kubernetes集群，并且负责资源的计量。
Ipaas，负责对接各种资源，如调用Kubernetes API创建容器、对接Ceph创建存储、对接Harbor获取镜像等。前端页面通过Ipaas获取容器相关的新闻数据、监控指标等。
Codeflow，负责代码构建。通过对接Jenkins实现代码编译、打包镜像以及服务的滚动升级等工作。
Nginx-mgr，一个对接多个Nginx集群的管理系统，负责将用户在页面配置的规则转成Nginx配置，并下发到对应的Nginx集群。
Dophinsync，和公司CMDB系统打通，从CMDB系统同步公司所有项目和服务的相关数据和信息。

最上面是对用户提供的web-portal页面，一个用户自助的终端。

本次分享的标题是《宜信容器云的A点与B点》，之所以称为A点和B点，这与我们的公司文化有关，我们以“A点”代指现在已经做到的事情，以“B点”代指未来或者下个阶段要做的事情。

目前整个宜信容器云平台已经完成了大部分主要功能点的开发，这部分已经实现的功能即为“A点”，包括服务管理、应用商店、域名管理、CI/CD、镜像管理、文件存储、监控告警、定时任务、配置管理等。后续还有部分功能需要添加和完善，即为“B点”，主要包括：对象存储、大数据容器云、全面日志收集、自定义指标伸缩、智能调度和混部、多集群管理、安全隔离、站点监控等，

2.2 宜信容器云功能模块

上图为宜信容器云平台的整体功能图，其中蓝色代表已经完成的功能、黄色代表需要优化和改善的功能。

整个系统从资源管理的角度来看：

底层是硬件层面的计算、存储、网络；
其上是资源管理层，负责容器、存储、域名、镜像、集群管理；
往上是中间件层，包括Kafka、MySQL等中间件服务；
再往上是应用层，提供给用户使用的终端；
两侧分别是CI/CD的构建流程和安全认证相关的功能组件。

下面将通过页面截图的方式，详细介绍容器云的主要功能点。

2.2.1 主要功能点——服务管理

上图是服务管理页面的截图，逐一介绍各个功能。

容器列表。上侧的菜单是服务管理的列表，进入到某一个服务管理，就可以对服务进行具体操作，包括基本配置、升级、扩缩容、域名管理、同步生产环境等。
历史容器。服务升级或故障迁移之后，容器的名称、IP地址等会发生变化，历史容器的功能是记录一个服务下面容器的变化情况，方便我们追踪容器的变化，追溯性能监控数据，进行故障定位。
日志下载。可以通过页面方式直接下载用户日志数据。终端信息与前面的日志输出是有区别的。前面的日志下载是应用把日志保存到容器里的某一个指定路径下；终端信息是容器标准输出的日志，Event信息里主要记录容器的状态信息，比如什么时候拉取镜像、什么时候启动服务等。Webshell主要提供容器登录，可以像SSH一样通过页面的方式登录到终端。
非root登录。为了保持容器生产环境的安全，我们以非root的方式登录容器控制台，避免误删数据。
Debug容器实现，通过启动一个工具容器，挂载到业务容器里，共享网络、进程等数据。传统的方式希望容器镜像尽可能小、安装的软件尽可能少，这样启动更快、安全性更高，但由于容器本身只安装了程序必要的依赖，导致排查文件困难。为了解决这个问题，我们基于开源技术开发了debug容器功能：debug容器挂载到业务容器中，共享业务容器的网络内存和主机相关的各种信息，这样一来，就相当于在业务容器中执行了debug命令，既方便运维和业务人员排查故障，保障了容器的快速安全，又为业务提供了一种更好的debug方式。安装的客户端如Reids客户端、MySQL客户端、Tcpdump等。
容器性能监控，包括CPU、内存、网络IO、磁盘IO等监控指标。
审计，用户所有操作命令都会通过审计工具进行审核。
摘除实例，主要是针对一些异常容器的故障定位，将流量从负载均衡上摘除。
销毁功能，当容器需要重建时会用到销毁功能。

除了上文介绍的一排容器按钮以外，还有一些针对服务的相关操作，比如服务的基本配置：环境变量、域名解析、健康检查，服务的升级，替换镜像、扩缩容等操作。

2.2.2 主要功能点——应用商店

很多业务场景有这样的需求：希望可以在测试环境里实现一键启动中间件服务，如MySQL、Zookerper 、Redis、Kafka等，不需要手动去配置kafka等集群。因此我们提供了中间件容器化的解决方案，将一些常用的中间件导入容器中，后端通过Kubernetes维护这些中间件的状态，这样用户就可以一键创建中间件服务。

但由于这些中间件服务本身相对来说比较复杂，所以目前我们的应用商店功能主要是为大家提供测试环境，等这部分功能成熟之后，会把应用商店这些常用的中间件拓展到生产环境上，到时候就可以在生产环境使用容器化的中间件服务了。

2.2.3 主要功能点——CI/CD

CI/CD是代码构建流，我们内部称为codeflow。其实代码构建流程非常简单，一句话概括起来，就是：拉取仓库源代码，通过用户指定的编译脚本构建出执行程序，将执行程序放到用户指定部署路径，并通过启动命令启动这个服务。系统会为每个codeflow生成对应的Dockerfile用于构建镜像，用户不需要具备Docker使用经验。

上面的流程是代码编译，下面是通过系统预先生成的Dockerfile，帮用户打包成Docker Image，这就是从代码拉取、代码编译、打包到Docker Image并推送到镜像仓库的整个流程。

用户完成配置并点击提交代码后，就可以通过手动或Webhook的方式触发整个构建流程。也就是说只要用户一提交代码，就会触发整个构建流程，编译源代码、打包Docker镜像、推送镜像仓库并触发滚动升级，用户可以在分钟级别看到效果。在这里我们还做了一些小的功能：

非root构建。我们的后端其实是在一个Jenkins集群下构建的，这样就存在一个问题：如果用户在编辑脚本的时候，不小心写错代码就可能会将整个主机上的东西都删除，非常不安全。为了解决这个问题，我们在整个构建过程中采用非root构建的方式，避免某个用户因编译脚本执行某些特权操作而影响系统安全。
自定义Dockerfile。支持某些用户使用自己的Dockerfile构建镜像，用户通过上传Dockerfile的方式，覆盖系统生成的Dockerfile。
预处理脚本，主要针对Python类的镜像构建，Python类的镜像构建本身不需要编译源代码，但运行环境需要依赖很多第三方的包和库，如果将这些依赖包都安装到基础镜像，不仅会导致基础镜像过大，而且后期维护也很麻烦。为了支持Python软件容器化的运行，我们提供了预处理脚本，即在业务镜像之前先执行预处理脚本，帮用户安装好所需要的依赖包，然后再把用户的代码拷贝过来，基于预处理脚本之后的镜像去生成业务镜像，下次构建的时候，只要预处理脚本不变，就可以直接构建业务镜像了。
Webhook触发和Gitlab集成，通过Gitlab的Webhook，当用户在提交代码或者merge pr的时候便可以触发codeflow，执行自动上线流程。

2.2.4 主要功能点——文件存储

容器通常需要业务进行无状态的改造，所谓“无状态”是需要把一些状态数据放在外部的中间件或存储里。

我们提供了两种存储方式：NFS和Cephfs文件存储。用户在页面选择存储的容量，然后点击创建，就可以直接创建一个Cephfs文件存储，并且可以在服务管理页面指定将这一存储挂载到容器的某一个路径下，当容器重启或者迁移后，文件存储会保持之前的目录挂载，从而保障数据不丢失。

2.2.5 主要功能点——Nginx配置

公司有大概100多个Nginx集群，之前这些Nginx集群都是通过运维人员手动方式变更配置和维护，配置文件格式不统一，且容易配置错误，问题和故障定位都很困难。为此我们在容器云集成了Nginx配置管理，通过模板的方式生产Nginx配置。Nginx配置的功能比较多，包括健康检查规则、灰度发布策略等相关配置。

上图是一个系统管理员可以看到的页面，其中部分项目开放给业务用户，允许用户自己定义部分Nginx配置，如upstream列表，从而将公司域名配置模板化。

除此之外，我们还做了配置文件的多版本对比，Nginx的每次配置都会生成一个对应的版本号，这样就可以看到在什么时间Nginx被谁修改了哪些内容等，如果发现Nginx配置修改有问题，可以点击回滚到Nginx的历史版本。

泛域名解析，主要适用于测试环境。之前每一个测试服务都需要联系运维人员单独申请一个域名，为了节省用户申请域名的时间，我们为每个服务创建一个域名，系统通过泛域名解析的方式，将这些域名都指定到特定的Nginx集群。

Nginx后端可以包含容器也可以包含虚拟机，这是在业务迁移过程中非常常见的，因为很多业务迁移到容器都并非一蹴而就，而是先将部分流量切换到容器内运行。

2.2.6 主要功能点——配置文件管理

现在的架构提倡代码和配置分离，即在测试环境和生产环境使用相同的代码，不同的配置文件。为了能够动态变更配置文件，我们通过Kubernetes的Configmap实现了配置文件管理的功能：将配置文件挂载到容器内，用户可以在页面上传或者编辑配置文件，保存后，系统将配置文件更新到容器内。

就是说当用户在页面上传或编译某个配置文件以后，平台会自动把配置文件刷新到容器里，容器就可以使用最新的配置文件了。为了避免用户误删配置文件，当系统发现配置文件被使用则不允许删除。

2.2.7 主要功能点——告警管理

告警管理功能基于Prometheus实现。平台会把所有的监控数据，包括容器相关的（CPU、内存、网络IO等）、Nginx相关的、各个组件状态相关的数据，都录入到Prometheus里，用户可以基于这些指标设置监控阈值，如果达到监控阈值，则向运维人员或业务人员发送告警。

值得一提的是，我们提供了一种特殊的告警：单个容器性能指标。按常理，每个容器监控指标应该是类似的，没有必要针对单个容器设置告警，但在实际生产环境中，我们遇到过多次由于某个特定请求触发的bug导致CPU飙升的场景，所以开发了针对单个容器的性能告警。

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/336

创作场景

支持 100+ 业务线、累计发布 17 万次|宜信容器云的 A 点与 B 点