微众银行案例｜容器化实践在金融行业落地面临的问题和挑战

本文整理自微众银行容器负责人陈广镇和李焕 在 Techo 开发者大会云原生专题的分享内容——微众容器化实践。本文主要和大家介绍微众的容器化实践，具体分为三个部分：里程碑、实践之路，以及未来的规划。

微众应用容器化项目始于2018年底，我们的生产环境在私有机房上，由于基础设施的差异，容器管理系统主要走自研路线，基于开源产品定制。

2019年1月，微众上线了第一个版本，主要实现多K8s集群管理、以及适配公司现有的基础架构。

2019年2月，微众系统接入TKE服务，用于快速构建开发测试环境，我们大部分业务都需要独立的测试环境，利用腾讯云强大的伸缩能力可以减少我们很多的环境维护工作。

2019年6月，平台优化了核心的调度逻辑，支持了多业务多DCN共享资源池，提升了私有云资源交付的效率。

2019年12月，微众研发了一套统一的通用的运维服务，这套服务收敛过去各式各样的运维工具，并且增加了金融级的安全管理，优化了K8s执行命令的性能问题。

2020年年初，启动了全量应用容器化项目，现在已经有超过一半的实例跑在了容器上。其中就包括我们的核心金融系统。

2020年年中，平台开始了2.0的迭代，包括定制化Harbor、应用画像、通用Operator API等特性。

未来微众在容器化上小小的积累通过开源的方式贡献给社区。

下面部分我们介绍一下容器化实践中遇到的问题和解决方案。

首先，我们看看传统虚拟机部署业务的效率问题。容器化之前，在虚拟机和物理机上，应用部署流程非常复杂，新业务上线和扩容慢，交付效率低，资源需要预留。流程无法全自动化。应用缺少统一的规范，平台很难做统一的优化。

在容器上，我们要优化VM应用部署的问题。下面是我们对平台的设计。

首先我们对容器平台的定位是公司级的平台服务，要对所有行内业务都通用；

第二，所有功能都要API服务化，为其他工具系统提供接口；

第三，从VM迁移到容器，能实现快速扩容、缩容；

第四，通过合理的调度，资源利用率得到提升；

第五，重新定义我们的基础架构，将IAAS层服务化，和PAAS层融合，提高资源的交付效率和交付体验。

在实施的策略上，主要有两点，一是必须适配现有的基础设施和运维体系，在初期需要保持和VM一致的体验，让应用无感迁移；二是要稳，金融机构有监管的压力，必须杜绝大面积不可用的现象出现，系统保持稳定是最起码的要求。

基于这两点，我们对kubernetes的能力做了很多的限制和定制化，后面会详细讲到。

下图是微众的容器生态全景图，最顶层是我们的应用层，包括业务系统、工具系统、中间件和创新应用；

第二层是我们平台的API层，组合下层云原生的服务，对上层提供定制化的协议；第三层是容器编排管理层，我们的K8s、prometheus、harbor、我们核心的云原生应用管理引擎等云原生产品位于这一层。再往下就是我们的iaas层，最底层是机房、网络、腾讯公有云等。

容器平台逻辑架构图，左边是我们原有的运维管理系统，包括发布系统、CMDB等，这些系统通过WCS API管理容器；通过运维服务，运维容器，包括登陆、查日志、上传下载文件等。

每个worker节点上都有运行很多的agent，我们提供了统一的agent管理系统进行管理，限制agent的权限和审计其操作。安全在我们行业是一个非常重要的课题。

再来看一下容器的网络的实践。在很多公司上云的时候都会选择一些开源的网络插件，假设我们选择了开源的网络会遇到一些问题，首先，有两套网络体系，没办法做直连，还有很多中间件、数据库进行容器化。第二，很难做IP固定，因为K8s云原生是不推荐做IP固定，但是我们必须要做。第三拆包、分包过程中所导致的性能损耗以及不稳定的情况，在我们一些网联交易的系统里面耗时非常敏感，不可以接受。

考虑到上述问题，我们选择了直接使用underlay的网络架构。我们把虚拟机和容器放到了同个网络层面上，这样一来，容器网络运维就转化成了网络部门同事熟悉的虚拟机运维，使用相同的防火墙策略。

这里简单提一下，公有云场景下，我们使用vpc将cvm和容器打通。

在微众的私有云上，我们选择了underlay，所以我们自研了适配的网络插件wecni。其工作原理是把容器的虚拟网卡插到了网桥上，然后使用交换机做网关。

由于我们需要固定IP，而IP又是和母机所在的TOR关联，因此我们实现了ipamd模块记录了容器、ip、机架的关系，业务应用发版、重启保持ip不变。

我们生产上还有另一个需求，在DMZ/ECN区，容器需要支持同时连内外网。对此，我们wecni支持单容器多网卡特性，在容器里配置两块虚拟网卡，默认出外网，内网使用静态路由表。

公有云上我们也希望腾讯云能早日支持这种Pod级的外网方案。

平台解决完网络问题之后要需要解决调度的问题，K8s原生的调度编排能力无法满足我们在dcn架构下的高可用部署需求，每组DCN是由一组应用和DB组成的数据单元，每组DCN支持一定容量的客户，我们的调度策略首要是实现DCN级别的高可用，而K8s的调度只能看到本集群的状况，数据中心有很多K8s，因此我们开发了一个全局调度服务，要跨K8s集群，跨业务部门的统一服务，能够精确控制每个子系统在每个DCN实地的数量，也要同时考虑未容器化的vm上的实例。

我们的容器调度编排除了支持了复杂的DCN高可用规则外，还支持基于应用画像的调度策略。应用画像系统收集prometheus的动态监控数据、CMDB定义的元数据推送至大数据平台，通过一定的算法生成应用画像，对子系统和应用进行打标签，最后通过亲和度、应用优先级打散相似实例的分布。现在支持应用属性、监控数据、运维属性、依赖关系数据的聚合。

下面是关于微众银行在容器方面的一些实践相关的介绍。

首先，介绍微众的日志系统。日志系统由三个模块组成，数据采集模块、数据缓存模块、数据处理展示模块，日志采集模块是通过一个标准Daemonset部署的日志Agent进行采集，每个业务容器都会将日志挂载到母机的特定目录中，日志Agent采集到数据后将数据上传到数据缓存模块，最终通过数据处理模块统一进行数据的处理和展示。在日志系统中实现了这样一些功能，比如有异常展示功能，通过Opentracing协议做异常定位和分析，此外还按照监管的要求，统一进行日志归档。另外还有实时流计算、指标的聚合查询等功能，方便在出现问题的时候能够快速定位问题。

接下来是监控模块。在我们微众银行有一个统一的标准监控平台，因此，在进行容器化的时候，容器的监控必须要适配现存的这套标准的监控模块，所以，在监控方案做了拆分，主要分成两部分。第一部分容器指标采集相关的，用Prometheus和Thanos来做数据的聚合和采集，另外，我们还自研了一个模块，通过将容器的监控数据，比如CPU、内存、网络指标上传到统一的监控平台，做成与跟VM一致的监控数据。

接下来再给大家介绍一下容器部署平台。在原生的K8s中，发布的时候需要编辑yaml文件，通过kubectl的操作来将容器部署到集群中。这种发布方式是非常难以运维的，主要存在的问题是：发布的时候存在大量手工操作，容易误操作；在发布过程无法做发布的模板化和可视化；历史发布记录无法追溯、无法审计。为了解决这些问题，我们做了一套容器的部署系统，可以通过这套部署系统来完成容器发布的模板化、可视化、可审计化。容器的部署分成两部分，第一部分是宿主机的部署，我们主机的同学将初始好系统的容器宿主机登记到资源管理服务中，然后可以通过管理台对这个宿主机机进行K8s的初始化。初始化完之后，在资源池中就存在了可以分配的资源。业务方就可以通过流程管理系统发起一个应用实例的申请，实例分配好以后，将实例信息回写到元数据管理系统里，业务同学可以在发布平台中选中对应的实例，调用相应的服务来进行结构化的容器的发布。

接下来是统一的运维平台，与部署类似，通常在定位某个容器的问题的时候，需要通过kubectl exec的方式完成。这样的问题是，kubectl 权限过高，同时登陆到容器中时可能会有误操作，从而引发新的问题。为了解决这些问题，我们做了一个统一的运维平台。首先，我们封装了一个类似于kubectl的客户端，提供文件的上传、下载，快速拉起一个容器，调试某个容器等功能。这个客户端可以通过统一运维平台接入到K8s中，在运维平台中，我们可以收敛所有对容器的运维操作，可以审计、过滤在容器中执行的命令。同时，我们在工具中封装大量的高频操作的命令，让工具更方便易用。因为金融安全的要求，容器是默认关闭特权模式的。在定位某些问题时，可以通过运维平台有计划地放开一些特权，让业务同学可以快速定位相关问题。

接下来介绍一些复杂应用的容器化，比如PaaS应用的容器化。普通业务应用大部分是是无状态的应用，非常容易进行容器化。但是如果PaaS应用跟普通业务应用有很大区别，很多PaaS应用的组件之间会有复杂上下游依赖关系，增加了容器化复杂性。这里我们以Redis为例来介绍PaaS应用的容器化。微众的Redis主要有管理台、Observer、Proxy、Cluster等几个模块。管理台主要负责整个集群的管理，负责发起集群的扩缩容，修改集群的配置等。Observer负责观察集群的状态，Proxy提供了访问鉴权和熔断、降级服务等工作，Cluster是负责KV存储的模块。在对Redis发起扩容的时候，首先要通过管理台进行发起，调用WCS API的服务，WCS会通过操作K8s，增加对应服务副本数，等相对应的容器启动完成后，会将实例信息通知管理台，管理台感知到这个新增的实例之后，就会把这个实例的信息下发至Proxy，Proxy就可以把接入流量打到新的实例上去。

接下来是我们在基础架构上的容器服务化的工作。之前，在申请一个应用实例往往要做大量工作，要申请一个VM、划分资源、LB的配置工作、申请网络策略，最终才能部署应用，交付业务使用。在容器化初期，我们将前面的申请VM和划分资源这两步合并了，后面的工作还是需要做。在进一步优化之后，我们的目标是将把申请网络策略，申请VIP等工作全部做成自动化，这样用户在申请资源后就可以使用，不需要再另外关注防火墙、VIP这些问题。

以上简单介绍微众在容器实践上的一些工作，接下来讲一下我们在实践过程中遇到的一些风险和问题，以及还有未来的规划。

我们遇到的主要问题归了几类，主要有：

安全问题。Docker和K8s会不可避免地存在漏洞，每次漏洞修复都要大规模升级集群，每次升级有可能对上面运行的容器造成影响，对K8s的运维是非常大的压力。因此，要定时评估，尽量将多个安全漏洞和Feature进行合并，定期升级软件版本。另外就是，特权模式的管理，要通过管理的方式来保证容器安全的管理。
资源隔离。K8s里面，磁盘IO的隔离做得还不是非常好，我们在生产环境中遇到多次，某个容器高IO导致同宿主机机另外一个容器的故障。这些问题的解决方案是，需要把一些IO敏感和IO不敏感的部署调度到同一个母机上，减少这些影响。同时还需要调研IO隔离技术，比如Cgroup2等
底层兼容的问题，比如，我们在生产环境的OS内核是3.10版本的，在K8s的有些版本会导致内存泄漏的问题，导致容器的OOM。需要定时关注社区有没有相关介绍，定时升级版本
数据丢失的风险。K8s用ETCD来存取数据，对数据的备份、故障恢复要做多做预防工作。我们会对ETCD的数据进行多重备份，同时进行跨IDC多地高可用部署，来保证数据的可用性。
故障影响。比如在生产环境我们遇到过宿主机失联一段时间后重新恢复连接，这时K8s会驱逐容器，大量的关闭操作导致宿主机CPU高，导致联机交易受到影响。需要有快速介入和恢复的能力