谈起云原生基础设施构建，就必然会提到云原生的容器网络。

众所周知，容器网络作为云原生的基石，是云原生平台必不可少的基础组件，也是云原生容器平台构建时的最大挑战之一。

随着银行应用数量和类型的进一步增多，对网络复杂度的要求也越来越高。银行的应用有自身特点，银行应用的管理级别不同，访问特色也不同，需要考虑如何兼容传统网络架构，实现传统网络和容器网络之间的互联互通，同时，传统应用容器化迁移后如何实现固定IP，以及对于容器多网络平面、多网卡的管理，多租户和跨云网络、容器流量的监测、调度与QoS等也都面临新的挑战。

目前有很多银行容器网络的内部其实是一个“黑盒”，容器内部和外部的网络没有打通，也无法实现跨云多网络集群的互通，亟需进行转型改造。

在这种压力下，构建高性能的容器网络就显得尤为重要，然而：

• 两地三中心架构中的容器网络怎么改造可用性更高？

• 高并发场景下，银行的容器网络如何规划？

• 如何打造高性能的容器网络？

本篇文章将为你解答。

两地三中心架构中的容器网络怎么改造可用性更高？

面对应用的高可用性需求，很多银行都在积极建设两地三中心，或者异地灾备建设。那么如何对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对银行现有网络管理模式的冲击呢？

首先从整体来看，两地三中心架构下的容器网络改造，需要依据容器平台所依赖的IaaS能力而定。譬如容器平台部署在传统虚拟化平台，也没有启用SDN网络，如果容器网络设计为hostnetwork模式，则容器POD的应用和传统虚拟机、物理机的旧业务系统是直接可以通信的。

如果容器平台的宿主节点在用IaaS的虚拟机，且启用了SDN网络，容器平台启用的CNI特性，则容器POD的应用可以和IaaS虚拟机的业务应用直接通信。如果和传统网络中的旧应用通信，则需要开启IaaS的NAT特性或者为宿主节点配置EIP地址。

银行容器平台中的容器应用与传统虚拟机、物理机中旧业务系统的相互通信遇到最多的问题都集中在IP有状态这件事情上，因为传统容器平台上应用如果要实现对外通讯，主要有两种方式：一种是基于宿主机IP+端口，另外一种是基于域名，这两种应用的对外暴露模式都隐藏了容器平台上应用的真实IP信息，所以不仅会造成传统虚拟机、物理机中旧业务系统无法和容器平台中应用的IP扁平化访问的问题，同时也让银行现有网络管理模式无法对于容器平台上的应用进行IP定位和网络资源管理。

针对以上问题，银行在两地三中心架构中可以采用Kube-OVN Underlay网络解决方案对接或改造容器平台网络，Kube-OVN underlay网络解决方案通过采用OpenStack的ovs二层虚拟交换技术，将容器平台上的应用和传统虚拟机、物理机中旧业务系统拉平到一个二层网络平面，让容器平台上的容器应用和传统虚拟机、物理机一样的使用底层网络资源并实现IP直达通讯。这样可以使银行现有的网络管理模式在Kube-OVN的underlay容器网络下依然有效。

高并发场景下，银行的容器网络如何规划？

在高并发场景下，银行传统的网络架构相对缺少灵活性，已无法满足日益增长的敏态业务需求。采用容器后，容器网络如何兼容传统网络和安全管理，并提供扩展的灵活性，是每一个银行用户都在关注的问题。

我们在金融行业的大量实践中发现，云原生的平台化思维和传统IT的条线式思维存在着一定矛盾。云原生希望通过一个yaml文件描述应用，所有的部署工艺、应用的计算、存储、网络应该能够自动化生成，而银行专门的网络部门都有严格定义的网络规范，它们之间的矛盾在银行业是特别突出的。

从实际落地的角度来看，可以采取以下几点建议来有针对性地解决这个矛盾，合理规划银行的容器网络。

首先，在技术思路方面，建议underlay和overlay同时进行。目前容器网络两个基本技术思路是overlay和underlay，overlay是建设虚拟网络，容器采用虚拟IP；underlay是复用下层物理网络，容器像虚拟机一样使用下层网络。从某种意义上说，overlay是平台化思维的产物，underlay是条线式管理思维的产物。某些银行可以允许大规模overlay，个别场景采用underlay（例如多播、运管功能等），这样两个一起搞，同时兼顾。另外还有些银行目前基本没有overlay的空间，更多采用underlay管理；而还有些银行在虚拟化上建设容器平台，underlay不能用（underlay可能会和IaaS网络有冲突），导致只能用overlay。鉴于这些情况，我的建议是两个都上，不同的集群采用不同的方案，甚至通过多网卡同时采用underlay和overlay。即便仅有一种需求，也两种方案都规划到位，保证未来拓展的可能性。

在建设思维方面，可以参考IaaS的网络建设思维。IaaS典型的网络思维是三网分离、四网分离，容器网络目前规划中，以前不太考虑这种方案，这是因为以前更多是IaaS负责基础设施网络，但是如果一旦在裸金属上部署容器平台，那么IaaS原来遇到的问题，今天容器平台也会遇到。

在容器网络与外部网络通信管控方面，可以通过统一的接入点（ingress、egress）管控容器内网的网络互访，加强到“稳态”和“敏态”之间的安全交互。

在networkpolicy管理方面，如果有可能，更多采用networkpolicy为每个应用设置安全管控策略，这也是更“云原生”的一种做法。

从集群管理角度来看，容器云有多个集群，其中高并发高性能集群中，宿主机上使用传统网络，容器网络使用ovs。高容量高扩展性的集群，宿主机上采用IaaS的基于VPC隔离的SDN网络，容器网络使用CNI组件，直接offload到宿主机网络上。

如何打造高性能的容器网络？

一些银行虽然针对传统网络已经做了很多优化工作，由于网络插件的简化，还有许多性能问题没有解决，也许这些问题在容器云里不是问题，但是到金融场景里就是比较大的挑战了。

因此，我们需要一个工具实现从传统网络向容器网络的平滑过渡，目前业内也已经出现了一些比较好的CNI方案。以目前比较活跃的Kube-OVN网络方案为例，它以成熟的OVS作为容器网络底座，通过将OpenStack领域成熟的网络功能平移到Kubernetes，融合了安全强化、智能运维、硬件加速等多方面的特性，极大增强了Kubernetes容器网络的安全性、可运维性、管理性和性能。

通过Kube-OVN的一些调优，可以实现和现有容器网络有同等流量性能，并未发生性能损耗的现象。比如某股份制银行，之前用到Calico方案，是最接近于物理网络性能的吞吐量，通过对比，Kube-OVN在性能上与Calico是相当的，另外它还可以支持OVS、DPDK这种自定义协议栈以及硬件加速方案，可以提升整个的容器性能。通常金融行业在上核心系统时要经过严格的容器网络性能的压测，测试结果基本能达到预期，解决了性能上的后顾之忧。

另外还结合了一些在不同的银行里落地的经验，尤其是把一些安全或者管控、监管侧的要求，结合起来做了相应的构建，能够有效地帮助银行用户构建更加适配金融云原生的高性能容器网络。

最后，希望大家都能够依据自身企业的实际情况，顺利构建高并发、高可用、高性能的云原生容器网络，稳健、高效地实现云原生化转型。