日前，国内银行业成功部署华为新一代云原生2.0 容器网络方案，率先化解国内银行核心业务容器化所引发的容器网络性能提升的极端挑战。
在网络加速方面，华为云原生2.0 容器网络方案采用独创的容器直通网络，让两层网络变成一层，端到端连通时间缩短一半，有效支撑业务秒级扩容上千容器，平稳应对流量浪涌；还在业界首次实现容器独立配置安全组规则和QoS，不仅提升了容器的安全性，还提升了大业务流量下容器网络的转发效率，减少网络阻塞。
容器网络面临性能挑战
举例来说，容器可以把业务应用切割为成千上万的微服务，而虚拟机的规模仅从几百至几千不等 ，所以容器对底层承载网络有着更高要求。
容器规模受网络规格限制，在传统二层网络环境下，数据报文通过查询MAC±1toh 表进行二层转发，而网络设备ＭＡＣ地址表的容量限制了容器集群的数量上限。跨宿主容器之间的ARP Flooding 也会造成大量的网络资源浪费。
由于容器体积更轻量、启动速度更快，所以容器的迁移速度更快，这就对网络策略的及时更新、网络拓扑的快速收敛提出了更高要求 。因为容器的生命周期短 ，重启非常频繁，所以网络地址的有效管理将变得非常关键，需要具备快速分配、 及时回收的能力。
而且由于在隔离和安全性方面存在的天然缺陷，安全一直是企业容器改造化进程中关注的核心问题之一。出于安全考虑，很多情况下容器会被部署在虚拟机内部，这种嵌套部署（nested deployment）需要设计新的网络模型。
总之，传统的物理网络架构无法满足容器平台高灵活性的需求，容器网络构建必须要有一种崭新的设计架构来满足，这推动了容器网络设计的发展。
尤其是，k8s的快速发展把容器网络的地位也提到一个很高的层次，又因为K8s开放的CNI（容器网络接口）标准，让容器网络解决方案呈现百花齐放的状态。
主流容器网络方案及发展趋势
一隧道模式（ Overlay Networking ）
隧道模式在IaaS层的网络中应用比较多。业界共识是随着节点规模的增长，复杂度会提升，而且出了网络问题，跟踪起来比较麻烦，这是大规模集群情况下需要考虑的一点。
目前主流的隧道方案有Weave、Open vSwitch（OVS）、Flannel、Racher等。以Flannel为例说明如下。
Flannel由CoreOS公司开发，是一种基于隧道模式（overlay Networking）的跨主机容器网络解决方案，即将TCP数据包封装在另一种网络包里面进行路由转发和通信。Flannel之所以可以搭建Kubernetes依赖的底层网络，是因为它能实现以下两点（见下图）。
图片来源 ：华为供图
Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接docker0网桥，另一端连接一个叫作flanneld的服务进程。flanneld进程上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立一个Pod节点路由表；flanneld进程下连docker0和物理网络，使用内存中的Pod节点路由表，将docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成Pod到Pod之间的直接地址通信。
Flannel之间的底层通信协议的可选技术包括UDP、VxLan、AWS VPC等多种方式。通过源flanneld封包、目标flanneld解包，最终docker0收到的就是原始数据，对容器应用来说，上述过程是透明的，感觉不到中间Flannel的存在。
Flannel每次分配的地址段都在同一个公共区域获取，存储在集中的etcd上，从而实现不同Node上的Pod分配的IP不产生冲突。Flannel通过修改Docker的启动参数将分配给它的地址段传递进去。
通过如上方式，Flannel就控制了每个Node上的docker0地址段的地址，从而保障了所有Pod的IP地址在同一个水平网络中且不产生冲突。Flannel完美地实现了对Kubernetes网络的支持，但是它引入了多个网络组件，在网络通信时需要转到flannel0网络接口，再转到用户态的flanneld程序，到对端后，还需要走一个反过程，所以也会造成一些网络的时延损耗。另外，Flannel模型默认采用了UDP作为底层传输协议，UDP本身是非可靠协议，虽然两端的TCP实现了可靠传输，但在大流量、高并发的应用场景下，建议进行多次测试，以保证准确度。
二路由模式（Routing Networking）
路由模式一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。以由Tigera公司开发的Calico方案为例。
Calico是一个基于BGP（边界网关协议）的纯三层的网络方案（Calico架构见下图），支持很细致的ACL控制，对混合云的亲和度比较高；与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。
Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。
图片来源 ：华为供图
Calico在小规模集群中可以直接互联，在大规模集群中可以通过额外的BGP route reflector来完成。Calico基于iptables还提供了丰富的网络策略，实现了Kubernetes的Network Policy策略，提供容器间网络可达性限制的功能。Calico的主要组件如下。
1.Felix：Calico Agent，运行在每个Node上，负责为容器设置网络资源（IP地址、路由规则、iptables规则等），保证跨主机容器网络互通；
2.etcd：Calico使用的后端存储；
3.BGP Client：负责把Felix在各Node上设置的路由信息通过BGP协议广播到Calico网络；
4.Route Reflector：通过一个或者多个BGP Route Reflector来完成大规模集群的分级路由分发；
5.CalicoCtl：Calico命令行管理工具。
对比来看，隧道模式（overlayNetworking）提供了很好的隔离和安全，但在包处理上花费了一些开销；路由模式（Routing Networking）比隧道模式更高效，但只支持部分网络协议并且需要底层基础设施支持BGP。从难易度上来看，Callico最简单。总之，不同的容器网络方案，适用于不同的应用场景，需要企业根据实际情况选择部署。
随着容器网络技术的发展，未来有以下两个明显趋势。
1.安全问题会促使容器网络和虚拟网络进一步融合，起到类似网关的作用。
2.网络的控制面和转发面会逐步统一到一个平台上，或者下沉到专用硬件，类似SDN硬件化的结果。比如品牌云厂商会逐步适配或者开源一些CNI，这些CNI可以在线下使用（更大可能是与DPU (Data Processing Unit)一起输出）；或者提供统一网络管理平台，输出超大规模网络管理、运维能力。
总之，如何能把超大规模、超高性能、快速逃逸和快速故障定位的能力进行产品化的输出，会是容器网络方案有较高附加值的机会点。由此，更加看好CNI+DPU打包输出的方案，软硬一体，既能满足性能与稳定性，又有一定的门槛，具备较高的附加值。
下一代容器网络及其优势
最近几年，华为云联合国内银行在容器网络的架构和性能上做了深度优化和研发创新，推出了下一代CCE Turbo容器网络方案，让容器网络与原生云网络达到完全一样的效果，使得容器网络的性能有了突破性的增长。
下一代容器网络Stack CCE Turbo，继承Kubernetes的IP-Per-Pod-Per-Network的容器网络模型，即每个Pod在每个网络平面下都拥有一个独立的IP地址，Pod内所有容器共享同一个网络命名空间，集群内所有Pod都在一个直接连通的扁平网络中，无需NAT可直接通过Pod的IP地址访问。Kubernetes只提供了如何为Pod提供网络的机制，并不直接负责配置Pod网络；Pod网络的具体配置操作交由具体的容器网络插件实现。容器网络插件负责为Pod配置网络并管理容器IP地址。
参考文章：
[1] 向趄胜、牛军等，《电信行业容器云平台网络设计的研究》
[2] 容器网络的一点思考 - 哔哩哔哩 https://www.bilibili.com/read/cv20791529/