k8s网络方案flannel 和calico 的分析对比？

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

• 原生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地址消耗比较大的问题。

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

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