微众银行案例|容器化实践在金融行业落地面临的问题和挑战
本文整理自微众银行容器负责人陈广镇和李焕 在 Techo 开发者大会云原生专题的分享内容——微众容器化实践。本文主要和大家介绍微众的容器化实践,具体分为三个部分:里程碑、实践之路,以及未来的规划。
文章图片
img 微众应用容器化项目始于2018年底,我们的生产环境在私有机房上,由于基础设施的差异,容器管理系统主要走自研路线,基于开源产品定制。
2019年1月,微众上线了第一个版本,主要实现多K8s集群管理、以及适配公司现有的基础架构。
2019年2月,微众系统接入TKE服务,用于快速构建开发测试环境,我们大部分业务都需要独立的测试环境,利用腾讯云强大的伸缩能力可以减少我们很多的环境维护工作。
2019年6月,平台优化了核心的调度逻辑,支持了多业务多DCN共享资源池,提升了私有云资源交付的效率。
2019年12月,微众研发了一套统一的通用的运维服务,这套服务收敛过去各式各样的运维工具,并且增加了金融级的安全管理,优化了K8s执行命令的性能问题。
2020年年初,启动了全量应用容器化项目,现在已经有超过一半的实例跑在了容器上。其中就包括我们的核心金融系统。
2020年年中,平台开始了2.0的迭代,包括定制化Harbor、应用画像、通用Operator API等特性。
未来微众在容器化上小小的积累通过开源的方式贡献给社区。
文章图片
img 下面部分我们介绍一下容器化实践中遇到的问题和解决方案。
文章图片
img 首先,我们看看传统虚拟机部署业务的效率问题。容器化之前,在虚拟机和物理机上,应用部署流程非常复杂,新业务上线和扩容慢,交付效率低,资源需要预留。流程无法全自动化。应用缺少统一的规范,平台很难做统一的优化。
文章图片
img 在容器上,我们要优化VM应用部署的问题。下面是我们对平台的设计。
首先我们对容器平台的定位是公司级的平台服务,要对所有行内业务都通用;
第二,所有功能都要API服务化,为其他工具系统提供接口;
第三,从VM迁移到容器,能实现快速扩容、缩容;
第四,通过合理的调度,资源利用率得到提升;
第五,重新定义我们的基础架构,将IAAS层服务化,和PAAS层融合,提高资源的交付效率和交付体验。
在实施的策略上,主要有两点,一是必须适配现有的基础设施和运维体系,在初期需要保持和VM一致的体验,让应用无感迁移;二是要稳,金融机构有监管的压力,必须杜绝大面积不可用的现象出现,系统保持稳定是最起码的要求。
基于这两点,我们对kubernetes的能力做了很多的限制和定制化,后面会详细讲到。
文章图片
img 下图是微众的容器生态全景图,最顶层是我们的应用层,包括业务系统、工具系统、中间件和创新应用;
第二层是我们平台的API层,组合下层云原生的服务,对上层提供定制化的协议;第三层是容器编排管理层,我们的K8s、prometheus、harbor、我们核心的云原生应用管理引擎等云原生产品位于这一层。再往下就是我们的iaas层,最底层是机房、网络、腾讯公有云等。
文章图片
img 容器平台逻辑架构图,左边是我们原有的运维管理系统,包括发布系统、CMDB等,这些系统通过WCS API管理容器;通过运维服务,运维容器,包括登陆、查日志、上传下载文件等。
每个worker节点上都有运行很多的agent,我们提供了统一的agent管理系统进行管理,限制agent的权限和审计其操作。安全在我们行业是一个非常重要的课题。
文章图片
img 再来看一下容器的网络的实践。在很多公司上云的时候都会选择一些开源的网络插件,假设我们选择了开源的网络会遇到一些问题,首先,有两套网络体系,没办法做直连,还有很多中间件、数据库进行容器化。第二,很难做IP固定,因为K8s云原生是不推荐做IP固定,但是我们必须要做。第三拆包、分包过程中所导致的性能损耗以及不稳定的情况,在我们一些网联交易的系统里面耗时非常敏感,不可以接受。
文章图片
img 考虑到上述问题,我们选择了直接使用underlay的网络架构。我们把虚拟机和容器放到了同个网络层面上,这样一来,容器网络运维就转化成了网络部门同事熟悉的虚拟机运维,使用相同的防火墙策略。
这里简单提一下,公有云场景下,我们使用vpc将cvm和容器打通。
文章图片
img 在微众的私有云上,我们选择了underlay,所以我们自研了适配的网络插件wecni。其工作原理是把容器的虚拟网卡插到了网桥上,然后使用交换机做网关。
由于我们需要固定IP,而IP又是和母机所在的TOR关联,因此我们实现了ipamd模块记录了容器、ip、机架的关系,业务应用发版、重启保持ip不变。
我们生产上还有另一个需求,在DMZ/ECN区,容器需要支持同时连内外网。对此,我们wecni支持单容器多网卡特性,在容器里配置两块虚拟网卡,默认出外网,内网使用静态路由表。
公有云上我们也希望腾讯云能早日支持这种Pod级的外网方案。
文章图片
img
平台解决完网络问题之后要需要解决调度的问题,K8s原生的调度编排能力无法满足我们在dcn架构下的高可用部署需求,每组DCN是由一组应用和DB组成的数据单元,每组DCN支持一定容量的客户,我们的调度策略首要是实现DCN级别的高可用,而K8s的调度只能看到本集群的状况,数据中心有很多K8s,因此我们开发了一个全局调度服务,要跨K8s集群,跨业务部门的统一服务,能够精确控制每个子系统在每个DCN实地的数量,也要同时考虑未容器化的vm上的实例。
文章图片
img 我们的容器调度编排除了支持了复杂的DCN高可用规则外,还支持基于应用画像的调度策略。应用画像系统收集prometheus的动态监控数据、CMDB定义的元数据推送至大数据平台,通过一定的算法生成应用画像,对子系统和应用进行打标签,最后通过亲和度、应用优先级打散相似实例的分布。现在支持应用属性、监控数据、运维属性、依赖关系数据的聚合。
文章图片
img 下面是关于微众银行在容器方面的一些实践相关的介绍。
首先,介绍微众的日志系统。日志系统由三个模块组成,数据采集模块、数据缓存模块、数据处理展示模块,日志采集模块是通过一个标准Daemonset部署的日志Agent进行采集,每个业务容器都会将日志挂载到母机的特定目录中,日志Agent采集到数据后将数据上传到数据缓存模块,最终通过数据处理模块统一进行数据的处理和展示。在日志系统中实现了这样一些功能,比如有异常展示功能,通过Opentracing协议做异常定位和分析,此外还按照监管的要求,统一进行日志归档。另外还有实时流计算、指标的聚合查询等功能,方便在出现问题的时候能够快速定位问题。
文章图片
img 接下来是监控模块。在我们微众银行有一个统一的标准监控平台,因此,在进行容器化的时候,容器的监控必须要适配现存的这套标准的监控模块,所以,在监控方案做了拆分,主要分成两部分。第一部分容器指标采集相关的,用Prometheus和Thanos来做数据的聚合和采集,另外,我们还自研了一个模块,通过将容器的监控数据,比如CPU、内存、网络指标上传到统一的监控平台,做成与跟VM一致的监控数据。
文章图片
img 接下来再给大家介绍一下容器部署平台。在原生的K8s中,发布的时候需要编辑yaml文件,通过kubectl的操作来将容器部署到集群中。这种发布方式是非常难以运维的,主要存在的问题是:发布的时候存在大量手工操作,容易误操作;在发布过程无法做发布的模板化和可视化;历史发布记录无法追溯、无法审计。为了解决这些问题,我们做了一套容器的部署系统,可以通过这套部署系统来完成容器发布的模板化、可视化、可审计化。容器的部署分成两部分,第一部分是宿主机的部署,我们主机的同学将初始好系统的容器宿主机登记到资源管理服务中,然后可以通过管理台对这个宿主机机进行K8s的初始化。初始化完之后,在资源池中就存在了可以分配的资源。业务方就可以通过流程管理系统发起一个应用实例的申请,实例分配好以后,将实例信息回写到元数据管理系统里,业务同学可以在发布平台中选中对应的实例,调用相应的服务来进行结构化的容器的发布。
文章图片
img 接下来是统一的运维平台,与部署类似,通常在定位某个容器的问题的时候,需要通过kubectl exec的方式完成。这样的问题是,kubectl 权限过高,同时登陆到容器中时可能会有误操作,从而引发新的问题。为了解决这些问题,我们做了一个统一的运维平台。首先,我们封装了一个类似于kubectl的客户端,提供文件的上传、下载,快速拉起一个容器,调试某个容器等功能。这个客户端可以通过统一运维平台接入到K8s中,在运维平台中,我们可以收敛所有对容器的运维操作,可以审计、过滤在容器中 执行的命令。同时,我们在工具中封装大量的高频操作的命令,让工具更方便易用。因为金融安全的要求,容器是默认关闭特权模式的。在定位某些问题时,可以通过运维平台有计划地放开一些特权,让业务同学可以快速定位相关问题。
文章图片
img 接下来介绍一些复杂应用的容器化,比如PaaS应用的容器化。普通业务应用大部分是是无状态的应用,非常容易进行容器化。但是如果PaaS应用跟普通业务应用有很大区别,很多PaaS应用的组件之间会有复杂上下游依赖关系,增加了容器化复杂性。这里我们以Redis为例来介绍PaaS应用的容器化。微众的Redis主要有管理台、Observer、Proxy、Cluster等几个模块。管理台主要负责整个集群的管理,负责发起集群的扩缩容,修改集群的配置等。Observer负责观察集群的状态,Proxy提供了访问鉴权和熔断、降级服务等工作,Cluster是负责KV存储的模块。在对Redis发起扩容的时候,首先要通过管理台进行发起,调用WCS API的服务,WCS会通过操作K8s,增加对应服务副本数,等相对应的容器启动完成后,会将实例信息通知管理台,管理台感知到这个新增的实例之后,就会把这个实例的信息下发至Proxy,Proxy就可以把接入流量打到新的实例上去。
文章图片
img 接下来是我们在基础架构上的容器服务化的工作。之前,在申请一个应用实例往往要做大量工作,要申请一个VM、划分资源、LB的配置工作、申请网络策略,最终才能部署应用,交付业务使用。在容器化初期,我们将前面的申请VM和划分资源这两步合并了,后面的工作还是需要做。在进一步优化之后,我们的目标是将把申请网络策略,申请VIP等工作全部做成自动化,这样用户在申请资源后就可以使用,不需要再另外关注防火墙、VIP这些问题。
文章图片
img 以上简单介绍微众在容器实践上的一些工作,接下来讲一下我们在实践过程中遇到的一些风险和问题,以及还有未来的规划。
我们遇到的主要问题归了几类,主要有:
- 安全问题。Docker和K8s会不可避免地存在漏洞,每次漏洞修复都要大规模升级集群,每次升级有可能对上面运行的容器造成影响,对K8s的运维是非常大的压力。因此,要定时评估,尽量将多个安全漏洞和Feature进行合并,定期升级软件版本。另外就是,特权模式的管理,要通过管理的方式来保证容器安全的管理。
- 资源隔离。K8s里面,磁盘IO的隔离做得还不是非常好,我们在生产环境中遇到多次,某个容器高IO导致同宿主机机另外一个容器的故障。这些问题的解决方案是,需要把一些IO敏感和IO不敏感的部署调度到同一个母机上,减少这些影响。同时还需要调研IO隔离技术,比如Cgroup2等
- 底层兼容的问题,比如,我们在生产环境的OS内核是3.10版本的,在K8s的有些版本会导致内存泄漏的问题,导致容器的OOM。需要定时关注社区有没有相关介绍,定时升级版本
- 数据丢失的风险。K8s用ETCD来存取数据,对数据的备份、故障恢复要做多做预防工作。我们会对ETCD的数据进行多重备份,同时进行跨IDC多地高可用部署,来保证数据的可用性。
- 故障影响。比如在生产环境我们遇到过宿主机失联一段时间后重新恢复连接,这时K8s会驱逐容器,大量的关闭操作导致宿主机CPU高,导致联机交易受到影响。需要有快速介入和恢复的能力
文章图片
img 最后,是我们微众容器平台的规划。我们现在所做的工作更多还是在推动银行系统去做容器化,未来我们会更多拥抱云原生的东西,在CI/CD、微服务、动态扩缩容等方面进行努力,同时,也会把我们这些小小的积累通过开源的方式回馈给社区。
文章图片
img 总之来说,在容器化这条道路上,我相信,只要积极拥抱云原生,一定会有一个光明的未来,谢谢大家!
微众容器化实践 PPT 下载方式,请在腾讯云原生后台回复关键字“微众”获取。
【微众银行案例|容器化实践在金融行业落地面临的问题和挑战】【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,关注同名公众号,及时获取更多干货!!
推荐阅读
- 翼光家长沙龙复盘
- 小程序有哪些低成本获客手段——案例解析
- 【文魁大脑实用记忆第五期】贤派张丽琼第8次案例一地理记忆有汽泡图
- 借呗用户被银行拉黑贷不到款(马云(怪我咯?))
- W15L21-L22-电商企业案例分析
- 案例11(|案例11: “我们” 小成功关注个人,大成功关注大多数人)
- 有声阅读2021-05-18
- 爱情银行中需要不定期存款
- 从正面管教看家庭案例
- 集合框架(集合嵌套存储和遍历元素的案例代码实现)