【必看】实践总结：银行容器云平台建设需求与设计(系统设计平台,关键词优化)

容器平台的建设要考虑场景、技术、系统对接、成本、人员技能等因素，有不小的复杂度。本文从一个最精简容器平台所需考虑的各个方面，结合作者的项目实践，提出供大家参考的建议。

作者：蔡凯

来源： talkwithtrend

目录

1 银行建设容器平台的背景

2 需求分析

3 业务架构

4 关键设计

4.1 资源池管理

4.2 网络设计

4.2.1 技术方案选择

4.2.2 网络拓扑规划

4.3 镜像仓库

4.4 应用管理

4.4.1 应用编排

4.4.2 生命周期管理

4.5 安全管理

4.5.1 对接安全合规体系

4.5.2 多租户隔离

4.5.3 应用等级隔离

4.6 监控日志

4.6.1 监控

4.6.2 日志

5 总结和建议

1 银行建设容器平台的背景

随着互联网金融的兴起，互联网企业依托互联网，特别是移动互联网为公众提供越来越多方便快捷、稳定高效的金融类服务，对传统的银行业务带来了很大冲击。作为应对，传统银行也在业务上不断创新，带来对IT基础设施和应用架构方面进行转型升级的要求。例如为了支撑电商促销活动对银行带来的高峰期海量支付请求，某银行很早就对支付渠道相关业务应用进行微服务架构改造，由此带来了容器技术的研究和运用。此银行的多年实践证明，采用容器技术平台很好地支撑了新的业务模式和业务容量。

基于业务发展的需要，和快速进步的金融科技技术，越来越多的传统银行在思考自身的互联网金融战略、金融云规划等。其中重要内容之一，是希望从技术层面更有效地支持业务创新，如微服务架构、更好的灵活性、扩展性、高可用性、更高效的业务上线效率等，因此跟上云计算技术发展的趋势，建设并推广适合自身的基于容器技术的云平台是关键任务。

2 需求分析

银行建设容器平台，不仅需要为基于微服务架构的新业务提供容器化运行和管控平台之外，还必须非常重视满足金融行业严苛的监管和安全要求。这样的定位决定了在银行建设容器平台除了要具备市场上大多数容器平台产品的能力，还应该为银行的特殊监管需求进行定制。

因此制定银行容器平台的需求时，建议考虑包括的方面有：

管理大规模容器集群能力，包括：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。

为满足金融业务的监管和安全要求，平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志；如果容器平台还对公网提供访问，那么还需要考虑访问链路加密、安全证书等。

还有一个重要方面是，银行的金融云是一个范围更大的复杂云环境，容器平台通常是这个复杂系统中的一部分，因此容器平台还要遵从银行已有IT技术规范和运维要求，例如可能还需要考虑：

支持银行自身的应用发布体系、持续集成系统、应用建模规范、高可用管理策略

对接金融云底层资源池（例如IaaS），遵从云计算资源的统一管理和分配

对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对银行现有网络管理模式的冲击

对接统一身份验证、和整个金融云其它系统采用统一的租户定义、角色定义、资源配额定义等

对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统

3 业务架构

基于对容器平台的需求分析，可以用如下的业务架构图描述容器平台应提供的业务能力、以及容器平台在银行可能和周边系统的对接关系：

各业务模块提供的功能，以及可能需要集成、对接的情况是：

4 关键设计

以下讨论业务架构中各个业务模块的关键设计思路。

4.1 资源池管理

容器平台资源池管理负责容器运行所需的计算、存储资源申请、分配、容量管理，以及适合的容器网络通信方案。容器网络方案比较复杂，稍后专门论述，这里先探讨关于计算和存储资源的管理。

对于计算和存储资源的申请、分配、容量管理，可能的两种做法是：

按照容量预估，预先为容器平台分配预测的计算节点、存储容量的资源，在容器平台中将这些资源注册到容器集群中使用。当需要扩容或删除某些资源时，重复相应的动作。

对接外部的资源管理和供给系统，通常是IaaS系统或者具备资源供给能力的自动化系统，通过调用外部系统的接口，容器平台按需获取所需的计算和存储资源。

第一种做法的优势在于系统简单，不需要对接外部资源管理系统，适合技术验证平台，或容量不需要频繁变化的情况。对于生产系统或复杂的测试系统，基本上都应该考虑第二种做法，虽然带来了系统集成的复杂性，但容器平台可以借助外部的IaaS等系统，确保所申请的资源的高可用性，例如可以借助底层IaaS系统的功能，确保容器平台获得的宿主机均匀分布在不同的可用区AZ，这些不同的可用区AZ可能具备不同的供电、网络连接设备等，通常对应于数据中心不同的物理区域、楼层或楼宇，由此减少某一故障导致大部分甚至全部容器宿主机瘫痪的可能性；同时，第二种做法让资源申请和获得无需人工介入，因此能做到容器平台资源的按需自动申请、弹性扩容。

目前市场上的容器平台开源技术方案，或商业容器平台，大多具备了和IaaS系统的集成能力，或者需要开发的相关集成逻辑也并不复杂，例如只需通过IaaS的接口获取虚拟机，并用自动化任务在虚拟机中执行容器平台添加计算节点的命令，即可完成从资源申请到自动加入容器平台的完整过程。

4.2 网络设计

4.2.1 技术方案选择

在资源管理中，网络的管理是比较复杂的。对于容器平台可能的网络方案，基本上分为以下几类：

原生NAT方案

隧道方案（Overlay），代表性的方案有Flannel、Docker Overlay、OVS等

路由方案，代表性的方案有Calico、MacVlan

自定义网络方案

原生NAT方案中，容器借助宿主机端口映射、以及在宿主机上配置的iptables规则，对容器的网络数据包进行NAT转换，再通过宿主机的路由转发实现不同容器间跨主机的网络通信。这种方式的优势是原生支持、简单、容器实例不需要额外消耗骨干网络IP地址、也不会增加在宿主机间传递数据包的长度；但是缺陷也是明显的：

同一宿主机上不同容器在宿主机上的映射端口必须区分开以避免端口冲突；

容器迁移到不同宿主机时，很可能需要改变所映射的宿主机端口，控制比较麻烦；

通过NAT通信使得容器网络数据包在骨干网上使用的不是自身的IP，给防火墙策略带来不便；

端口映射带来的网络性能损失，笔者自己的环境下测试结果是，使用NAT方式的容器在进行跨宿主机通信是，吞吐率只能达到宿主机间吞吐率的1/3。

因此，原生的NAT网络比较适合小规模的功能验证和试验环境，网络性能不是重要的考虑因素，测试的场景中也不涉及很多容器迁移、防火墙安全等问题。很显然，在银行正式的测试环境、生产环境下，采用原生NAT方案不足以满足功能、性能和安全监管要求。

隧道方案，也就是Overlay方案，借助容器宿主机网络，构建出一个对于容器来说三层路由可达虚拟网络。具体做法是通过把容器网络数据包整体封装放进宿主机网络报文，由宿主机网络转发到目标容器所在的宿主机，再由目标容器所在的宿主机对报文进行拆解得到容器网络数据包，交给容器网桥，由容器网桥再转发到目标容器。隧道方案的好处是没有NAT方案的端口冲突问题、不消耗额外的骨干网络IP、与现有网络技术不产生冲突因此灵活性大、通过构建不同的VLAN虚拟网络很容易实现网络隔离、网络性能损失比原生NAT方案小，在满足银行业务功能和安全监管要求的同时，对性能也有一定的照顾。因此隧道（Overlay）方案目前是应用比较多的选择，在技术上的可选择性也最大，方案成熟度也比较高，所以相对其他的方案，隧道方案的实施、定制化、维护的成本比较低。不过事情都有两面，如果选择隧道方案，您还是有一些不可回避问题需要考虑解决：

如果容器平台中运行业务与其它平台上运行业务需要通信，则需要配置从容器外部访问容器的路由，否则容器的地址从容器平台外部不能直接路由访问。由于容器动态变化和跨主机迁移的特点，配置从外部访问容器的路由是一个比较复杂的问题，不仅需要在外部路由器、宿主机路由表中进行配置，还需要将这些配置动作和容器的启停联动起来，这需要复杂的SDN能力；

由于容器网络数据包在底层网络上传输时被封装在宿主机网络报文中，因此对普通防火墙来说，容器网络数据包的地址不可见。如果需要对容器数据包进行精确的防火墙规则设置，代价很大，几乎不可行；变通的方法可以考虑把需要进行网络隔离的容器，在启动时指定所在的VLAN，通过不同的VLAN来实现隔离；

由于容器网络数据包需要被封装在底层宿主机网络报文中，因此会增加底层网络数据包的长度，当您的底层网络也是Overlay网络，或者Overlay的层数较多时，会影响网络数据包承载数据的效率，并且封装和拆解数据包的次数也会显著影响网络的传输效率，对于性能关键的场景，这个问题也需要引起重视。

路由方案通过路由技术从三层或者二层实现跨主机容器互通，没有NAT，没有Overlay方案需要的数据包封装和拆解，每一个容器具有路由可达的IP地址，且可以做到从容器平台外部路由可达。这种网络方案的好处是性能损失小、外部路由可达、传统的防火墙仍然能正常发挥作用等。但缺点是：

IP地址消耗大，如果容器数量规模大，特别是采用微服务架构后，大量的容器IP资源被消耗，且可能出现大量IP冲击到路由表里，导致路由效率降低等问题；

容器平台外部对容器网络中网络实体的变化仍不能感知，例如新的容器创建或发生跨主机迁移时，以Calico方案为例，Felix和BGP client模块可以保证容器网络内的路由策略更新，但由于容器平台外界不能感知容器的变化，外部到此新创建容器的路由则没办法被自动创建，仍然需要额外的路由更新工作补充。

再来探讨自定义网络方案，本文所提的自定义网络方案泛指针对自身特定需求，而在既有网络技术基础之上进行改造，或者将不同的网络技术进行整合、打通而形成的特殊方案。例如在某银行，容器平台作为整个金融云平台的一部分，在设计容器网络时，需要考虑整个金融云网络管理上的一致性，由此要求容器网络具备和底层宿主机网络相同的网络层级、IP地址规划、子网划分规则，并能够实现容器实例和容器平台以外的直接路由互通，以便能够对容器网络复用既有的SDN控制器管理、防火墙、安全漏扫、网络抓包分析工具等的能力。因此该银行在建设自己容器平台网络时，对接了IAAS的Neutron+SDN进行统一网络管理，工作原理是：

当容器平台需要为新的租户分配网络资源时，通知Neutron，由Neutron对接的SDN控制器按照预先定义的规则为容器平台分配所需的子网和网络地址空间；

开发网络驱动，实现CNI接口。当容器平台创建新的容器实例时，网络驱动调用Neutron接口创建port，为容器实例在子网中分配MAC和IP，并把IP绑定到容器网卡（类似nova-compute的工作），然后通知Neutron容器IP配置成功；

容器平台记录容器的IP地址，作为进行服务注册、服务发现、监控服务的基础；

Neutron和SDN联动，完成为容器实例设置相关的路由策略、防火墙策略等。

这种方案的效果即保证网络效率、也能完全融入现有网络管理体系、还能做到完全的SDN联动，但复杂程度高，定制的成本也比较大，且由于完全基于路由而没有Overlay，也存在IP地址消耗比较大的问题。

需要声明以上只是以某个特定银行的定制方案为例，读者所在的银行和企业可能有自己对容器网络的需求，以及自己的技术考虑，因此自定义网络方案的可能性多种多样，最终实现的能力和代价也差别很大。

如何选择容器平台的网络技术方案会相当复杂，涉及技术、场景、人员技能、成本等多方面。容器平台网络方案直接关系到平台的容量、效率、实施和运维成本，因此选择需要充分论证，考虑容器平台的定位、规模发展、承载的业务场景、对现有网络的影响、对与集中监控系统、安全合规检查系统集成的影响等，需要认真评估需求、平衡收益和成本。

4.2.2 网络拓扑规划