前言
随着容器的普及，越来越多的人关注容器网络性能。目前容器网络都会符合CNI（Container Network Interface）的标准。红帽OpenShift的容器网络使用的是OVS。此前不少人质疑OVS的性能（VxLAN），因此考虑将OVS换成其他SDN，如Calico等。随着K8S的发展，OpenShift4支持pod的多网络平面。在这个时候，就不必替换现有的OVS SDN，直接附加第二个CNI网卡即可。在这个时候，就会出现macvlan、ipvlan、SRIOV之类选择的对比。本恩就此展开讨论。
SR-IOV的本质
那么什么是SR-IOV？简短的答案是SR-IOV是一个规范，它允许PCIe设备看起来像是多个单独的物理PCIe设备。SR-IOV规范是由PCI SIG创建并维护的，其思想是标准规范将有助于促进互操作性。
没有SR-IOV的前提下，传统的网卡在虚拟化上如vSphere、KVM也能实现网络虚拟化，如下图所示：
使用SR-IOV对于虚拟化而言的好处是：在SR-IOV虚拟化中，VM通过直接内存访问（DMA）直接与网络适配器通信。使用DMA可使VM绕过虚拟化传输（如VM Bus），并避免要求管理分区中的任何处理。通过避免使用开关，可以实现最佳的系统性能，提供接近“裸机”的性能。有无SR-IOV的路径区别如下：
SR-IOV通过引入物理功能（PF）和虚拟功能（VF）的来工作。物理功能（PF）是功能齐全的PCIe功能。虚拟功能（VF）是缺少配置资源的“轻量级”功能。
每个 SR-IOV 设备都可有一个物理功能 (Physical Function, PF)，并且每个 PF 最多可有 64,000 个与其关联的虚拟功能 (Virtual Function, VF)。PF 可以通过寄存器创建 VF，这些寄存器设计有专用于此目的的属性。
如下图所示，在vSphere层可以配置SR-IOV的VF和PF
SR-IOV的VF可以直接映射给VM，而无需Hypervisor协调。但VF必须要与一个PF相关联。在虚拟化环境中，PF是需要和Hypervisor交互的（因为映射给了Hypervisor）。
下图中修改SRIOV PF的VF数量：
VF数量设置为6
然后在一个VM中添加SR-IOV的VF。
VF添加成功：
最后的拓扑图如下：portgroup是vSphere中隔离vlan的对象（在虚拟交换机上为每个VLAN提供一个端口组，然后将虚拟机的虚拟网卡放入端口组而不是直接连接到虚拟交换机）
目前CNI只支持SR-IOV的VF模式：https://github.com/intel/sriov-cni。因此如果将OCP使用SR-IOV，那么最好将OCP安装在物理机上。否则如果将VF映射给VM，VM中安装OCP，那么对pod而言，VF和普通的虚拟网卡无异。在物理机上安装OCP，要使用SR-OVI的VF的话，BIOS需要特殊设置，OCP Worker Node上启用PF驱动，Pod里底层用VF。
macvlan的本质
Macvlan允许您配置父级物理以太网接口（也称为上级设备）的子接口（也称为从设备），每个子接口都有自己的唯一MAC地址，因此也有自己的IP地址。然后，应用程序、VM和容器可以绑定到特定的子接口，以使用其自己的MAC和IP地址直接连接到物理网络。有些NIC对其在硬件中支持的MAC地址数量有限制。超过限制可能会影响性能。
以在vSphere上安装OCP为例，使用macvlan的结果是：ocp中pod的网卡和VM的网卡（近似）连接相同的uplink（通过portgroup），即容器和vm的网络在一个平面上。如果将OCP安装在物理机上，那么pod的网卡和物理网卡在相同平面。
网络性能对比
参考文档：
测试架构图：
测试环境硬件：
三个测试场景：
这三个测试场景中，我们主要关注第一个BMP2BMP，也就是说，测试将容器部署到物理机上的网络性能。这种测试场景下，各种网络技术的性能纵向对比都是最高的。
第一个场景的架构图。测试中使用了OVS、Flannel、MACVLAN, IPVLAN和SRIOV。
测试结果如下图。
三层网络对比：VxLAN的性能对比中，OVS比Flannel高10%的性能。
二层网络对比：
（1）吞吐量：macvlan最高（在四种大小网络包的测试场景下），比ovs-vlan高20%，其次是SR-IOV，最差的是ipvlan。具体见下图：
（2）网络延迟：SR-IVO最高，macvlan的延迟最低（在三种大小网络包的测试场景下）。
（3）对于相同的SDN技术，vxlan的性能比相同SDN vlan低10%.
接下来，我们再关注另外一个测试报告：
在进行吞吐量测试时：macvlan的极限值和线性与物理网卡非常接近，ovs和linux bridge的线性较差。
结论
（1）如果客户在生产环境想提升容器网络性能，不必再考虑替换SDN。使用macvlan的多网络平面即可。这样既能保证OCP原生架构不会破坏从而带来PaaS方案的多厂商支持的问题，也提升容器的性能。
（2）使用macvlan，需要打开父网卡的混杂模式。在虚拟化上，如vSphere需要打开vSphere的Portgroup的混杂模式。
（3）容器平台如果安装在虚拟机中，不推荐使用SR-IOV。如果使用SR-IOV（容器平台安装在物理机上），考虑结合DPDK技术来提升性能。
macvlan配置示例
而macvlan适用于ipvlan的所有场景。
在OCP 4.3上测试macvlan。首先验证静态IP模式。
首先确认worker节点的网段：192.168.91.0/24
登录worker节点，查看节点的网卡：
确认192.168.137.0/24的网关是192.168.137.1
修改网络CO，增加如下，配置静态IP，赋予到tomcat项目：
oc edit networks.operator.openshift.iocluster
查看赋予项目的网络：
确认IP未被使用：
书写创建pod的yaml，使用cni网络注释
文本格式：
[root@lb.weixinyucluster ~]# cat 1.yaml
apiVersion: v1
kind: Pod
metadata:
name: example-staticip
annotations:
k8s.v1.cni.cncf.io/networks: macvlan-network
spec:
containers:
- name: example-pod
command: ["/bin/bash", "-c", "sleep 2000000000000"]
image: centos/tools
[root@lb.weixinyucluster ~]# oc apply -f 1.yaml
pod/example-staticip created
登录pod，确认IP增加：
在pod里ping网关：
在外部主机ping pod ip：
增加DHCP网络：
修改网络co，增加如下内容，添加dhcp网络到tomcat1：
[root@lb.weixinyucluster ~]# oc get network-attachment-definitions -n tomcat1
NAME AGE
macvlan-network1 9s
书写创建pod的yaml
但是，查看pod创建过程，出现报错，原因是我的和环境中没有配置dhcp server。需要注意的是，dhcp server不能配置在pod所在的worker节点上（Linux does not allow to communicate between macvlan interface and its master interface,），需要配置在外部。因此，即worker节点能够访问到的dhcp server。这与很多客户的环境不匹配，因此不再进行测试。建议使用静态分配IP的方式。
参考文档：
1.两份测试报告，文章中已经给出名称。
2.http://l1b0k.github.io/2018/06/04/sr-iov-4-nic/
3.https://www.marvell.com/content/dam/marvell/en/public-collateral/ethernet-adaptersandcontrollers/marvell-ethernet-adapters-fastlinq-sr-iov-improves-server-virtualization-performance-white-paper-2017-12.pdf
4.https://www.youtube.com/watch?v=n0A6LPL6COE