标签：容器 VF SR 深度 网络 网卡 macvlan IOV 对比
前言
随着容器的普及，越来越多的人关注容器网络性能。目前容器网络都会符合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
标签：容器,VF,SR,深度,网络,网卡,macvlan,IOV,对比 来源： https://blog.51cto.com/u_15127570/2711338
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。