TL; DR： 所有 CNI 都按其应有的方式工作，除了 Kube-Router 和 Kube-OVN 之外，Calico（除了自动 MTU 检测之外）是最好的。
我过去检查的文章更新（ и ），在测试时，我在 Ubuntu 1.19 上使用 Kubernetes 18.04，并于 2020 年 XNUMX 月更新了 CNI。
在我们深入研究指标之前...
自 2019 年 XNUMX 月以来有哪些新变化？
- 可以在您自己的集群上进行测试：您可以使用我们的工具在您自己的集群上运行测试 Kubernetes 网络基准测试:
- 新成员出现了
- 来自 VMware Tanzu
- 来自 alauda.io
- 新场景：当前检查运行“Pod-to-Pod”网络性能测试，并且添加了新的“Pod-to-Service”脚本，该脚本运行的测试更接近真实条件。 在实践中，带有 API 的 Pod 与基础作为服务一起工作，而不是通过 Pod IP 地址（当然，我们在这两种情况下都会检查 TCP 和 UDP）。
- 资源消耗：每个测试现在都有自己的资源比较
- 删除应用程序测试：我们不再进行 HTTP、FTP 和 SCP 测试，因为我们与社区和 CNI 维护人员进行了富有成效的合作，发现由于 CNI 启动延迟（Pod 的前几秒），TCP 上的 iperf 结果与curl 结果之间存在差距。启动，这在实际情况下并不典型）。
- 开源：所有测试源（脚本、yml 设置和原始“原始”数据）均可用
参考测试协议
协议有详细描述 请注意，本文是关于具有默认内核的 Ubuntu 18.04。
选择 CNI 进行评估
本次测试的目的是比较使用一个yaml文件配置的CNI（因此不包括VPP等所有通过脚本安装的CNI）。
我们选择的 CNI 进行比较：
- 安特里亚 v.0.9.1
- 印花布 v3.16
- Canal v3.16（Flannel 网络 + Calico 网络策略）
- 纤毛1.8.2
- 绒布0.12.0
- Kube-router 最新 (2020–08–25)
- 编织网2.7.0
为 CNI 配置 MTU
首先我们检查一下自动MTU检测对TCP性能的影响：
MTU 对 TCP 性能的影响
使用 UDP 时会发现更大的差距：
MTU 对 UDP 性能的影响
鉴于测试中揭示的巨大性能影响，我们想向所有 CNI 维护者发出一封希望信：请为 CNI 添加自动 MTU 检测。 您将拯救小猫、独角兽，甚至是最可爱的一只：小德沃普。
但是，如果您需要使用不支持自动 MTU 检测的 CNI，则可以手动配置它以获得性能。 请注意，这适用于 Calico、Canal 和 WeaveNet。
我向随行的 CNI 提出一个小小的请求...
CNI 测试：原始数据
在本节中，我们将比较 CNI 与正确的 MTU（自动确定或手动设置）。 这里的主要目标是在图表中显示原始数据。
颜色图例：
- 灰色 - 样品（即裸铁）
- 绿色 - 带宽高于 9500 Mbps
- 黄色 - 带宽高于 9000 Mbps
- 橙色 - 带宽高于 8000 Mbps
- 红色 - 带宽低于 8000 Mbps
- 蓝色 - 中性（与带宽无关）
空载资源消耗
首先，检查集群“睡眠”时的资源消耗情况。
空载资源消耗
Pod 到 Pod
此场景假设客户端 Pod 使用其 IP 地址直接连接到服务器 Pod。
Pod 到 Pod 场景
TCP
Pod-to-Pod TCP 结果和相应的资源消耗：
UDP
Pod-to-Pod UDP 结果和相应的资源消耗：
Pod 到服务
本节与实际用例相关，客户端 Pod 通过 ClusterIP 服务连接到服务器 Pod。
Pod 到服务脚本
TCP
Pod-to-Service TCP 结果以及相应的资源消耗：
UDP
Pod-to-Service UDP结果以及相应的资源消耗：
网络政策支持
其中，唯一不支持政治的就是Flannel。 所有其他人都正确实施网络策略，包括入站和出站。 做得好！
CNI加密
在检查的 CNI 中，有一些可以加密 Pod 之间的网络交换：
- Antrea 使用 IPsec
- Calico 使用 wireguard
- 使用 IPsec 的 Cilium
- 使用 IPsec 的 WeaveNet
容量
由于剩下的 CNI 较少，我们将所有场景放入一张图中：
资源消耗
在本节中，我们将评估在 TCP 和 UDP 中处理 Pod 到 Pod 通信时使用的资源。 绘制 Pod 到服务图是没有意义的，因为它不提供附加信息。
把它们放在一起
让我们尝试重复所有的图表，我们在这里引入了一点主观性，用“vwry fast”、“low”等词替换实际值。
结论和我的结论
这有点主观，因为我正在传达我自己对结果的解释。
我很高兴新的CNI出现了，Antrea表现良好，很多功能甚至在早期版本中就实现了：自动MTU检测、加密和易于安装。
如果我们比较性能，除了 Kube-OVN 和 Kube-Router 之外，所有 CNI 都运行良好。 Kube-Router 也无法检测到 MTU，我没有在文档中的任何位置找到配置它的方法（ 关于此主题的请求已开放）。
在资源消耗方面，Cilium仍然比其他厂商使用更多的RAM，但制造商显然是针对大型集群，这显然与在三节点集群上的测试不一样。 Kube-OVN 也消耗大量 CPU 和 RAM 资源，但它是一个基于 Open vSwitch 的年轻 CNI（与 Antrea 一样，性能更好且消耗更少）。
除了 Flannel 之外，每个人都有网络策略。 他很可能永远不会支持他们，因为目标比蒸萝卜简单：越轻越好。
此外，除其他外，加密性能也令人惊叹。 Calico 是最古老的 CNI 之一，但加密是在几周前才添加的。 他们选择了wireguard而不是IPsec，简单地说，它的效果非常好，令人惊叹，在这部分测试中完全超越了其他CNI。 当然，由于加密而导致资源消耗增加，但所实现的吞吐量是值得的（与排名第二的 Cilium 相比，Calico 在加密测试中显示出六倍的提升）。 此外，您可以在将 Calico 部署到集群后随时启用wireguard，也可以根据需要短期或永久禁用它。 不过，这非常方便！ 我们提醒您，Calico 目前无法自动检测 MTU（此功能计划在未来版本中提供），因此如果您的网络支持巨型帧 (MTU 9000)，请务必配置 MTU。
除此之外，请注意，Cilium 可以加密集群节点之间（而不仅仅是 Pod 之间）的流量，这对于公共集群节点非常重要。
作为结论，我建议以下用例：
- 非常小的集群需要 CNI 或者我不需要安全性： 与 绒布，最轻最稳定的CNI（他也是最古老的之一，据传说他是由Homo Kubernautus或Homo Contaitorus发明的）。 您可能还对最巧妙的项目感兴趣 ， 查看！
- 常规集群需要 CNI: 印花布 - 您的选择，但如果需要，请不要忘记配置 MTU。 您可以轻松自然地使用网络策略、打开和关闭加密等。
- （非常）大规模集群需要 CNI：嗯，测试没有显示大型集群的行为，我很乐意进行测试，但我们没有数百台具有 10Gbps 连接的服务器。 因此，最好的选择是在节点上运行修改后的测试，至少使用 Calico 和 Cilium。
来源： habr.com