本文是对我之前的基准测试（2018 年和 2019 年）的更新，该基准测试基于 Kubernetes 1.19 和 Ubuntu 18.04，并于 2020 年 8 月更新了 CNI 版本。
1) 基准测试申明
1.1) 自 2019 年 4 月以来的变动 ?
测试您本人的集群：当初，您能够应用咱们的“Kubernetes 网络基准”工具公布的版本在您本人的集群上运行基准测试: knb (https://github.com/InfraBuilder/k8s-bench-suite)。欢送来到 CNI 战斗中的新挑战者：VMware Tanzu 的“Antrea”和 alauda.io 的“Kube-OVN”新计划：此基准测试涵盖“Pod-to-Pod”网络性能，但也波及到新的“Pod-to-Service”计划，该计划波及理论测试案例。实际上，您的 API 容器将通过服务而不是容器 IP 耗费服务中的数据库（当然，咱们会在两种状况下都测试 TCP 和 UDP）。资源耗费：当初，每个测试都有本人的资源比拟。删除了某些测试：咱们不再运行 HTTP，FTP 和 SCP 测试。咱们与社区和 CNI 维护者的行之有效的单干突显了 iperf TCP 后果与 curl 后果之间的差距，这是因为 CNI 启动的提早（在 Pod 启动的最后几秒钟，在理论应用案例中并不令人欣慰）。开源：所有基准测试源（脚本，CNI yml 和原始后果）都能够在 github 上找到：https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08。
1.2) 基准测试协定
整个协定在 https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08/blob/master/PROTOCOL.md 中有具体阐明
请留神，以后文章仅关注具备默认内核的 Ubuntu 18.04。
1.3) 抉择 CNI 作为基准
该基准旨在比拟能够与单个 yaml 文件设置的 CNI（因而不包含所有基于脚本的装置，如基于 VPP 的 CNI 等）。
咱们将比拟的 CNI 如下：
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Flannel network + Calico Network Policies)
- Cilium 1.8.2
- Flannel 0.12.0
- Kube-router latest (2020–08–25)
- WeaveNet 2.7.0
2) CNI MTU tuning
首先，咱们将查看 MTU 检测对 TCP 性能的影响：
UDP 的影响更加显著：
思考到此处显示的对性能的微小影响，咱们心愿向所有 CNI 维护者传播有意义的信息：请在 CNI 中施行 MTU 自动检测。
然而，如果您的确必须抉择未实现主动 MTU 的 CNI，则须要本人对其进行调整以放弃性能。请留神，这实用于 Calico, Canal 和 Weavenet。
3) CNI 基准测试 : 原始数据
在本节中，咱们将比拟 CNI 与正确的 MTU（自动检测或手动调整）。这里的次要指标是在图表中显示原始数据。
- Gray : Reference (aka Bare metal)
- Green : bandwidth > 9 500 Mbit/s
- Yellow : bandwidth > 9 000 Mbit/s
- Orange : bandwidth > 8 000 Mbit/s
- Red : bandwidth < 8 000 Mbit/s
- Blue : neutral (not-bandwidth related)
3.1) Idle
第一件事是在整个集群处于闲暇时建设 CNI 消耗量？
3.2) Pod-to-Pod
在这种状况下，客户端 Pod 通过其 IP 地址间接连贯到服务器 Pod。
3.2.1) TCP
“Pod 到 Pod”TCP 的后果和相干资源耗费如下：
3.2.2) UDP
“Pod-to-Pod”UDP 和相干资源耗费的后果如下：
3.3) Pod-to-Service
在本节中，客户端 Pod 通过 ClusterIP 服务连贯到服务器 Pod。这与理论用例更相干。
3.3.1) TCP
“Pod 到服务”TCP 的后果和相干资源耗费如下：
3.3.2) UDP
“Pod 到服务”UDP 的后果和相干资源耗费如下：
3.4) 网络策略
在此基准测试中列出的所有 CNI 中，惟一不能齐全反对网络策略的是 Flannel。其余所有接口都正确地施行了网络策略，包含入口和进口。
4) CNI Encryption
在咱们测试的所有 CNI 中，以下可能加密 Pod 间的通信：
- Antrea with IPsec
- Calico with wireguard
- Cilium with IPsec
- WeaveNet with IPsec
4.1) Bandwidth
因为这场战斗中的 CNI 较少，因而让咱们在一张图中概括所有场景：
4.2) 资源耗费
在本节中，咱们将查看 Pod 到 Pod 通信应用的资源，包含 TCP 和 UDP。在此处显示 Pod 至服务图没有意义，因为它没有提供更多信息。
5) 总结
让咱们尝试回顾所有这些图表。咱们在这里通过用“very fast”，”low”等修饰符代替理论值来引入一些主观性。
6) 个人观点
最初一部分是主观的，传播了我对后果的解释。
我很快乐看到 CNI 的新成员退出。Antrea 提供了许多性能，甚至在晚期版本中也施展了杰出的作用：主动 mtu，加密选项和间接装置。
思考到性能，除 Kube-OVN 和 Kube-Router 外，所有 CNI 都体现良好。对于 Kube-Router，它无奈检测到 MTU，并且我在文档的任何中央都找不到调整它的办法（此处存在无关 MTU 配置的未解决问题）。
在资源耗费方面，Cilium 仍比竞争对手应用更多的 RAM，但该公司公开地针对大型集群，而这 3 个节点的基准状况并非如此。Kube-OVN 也是 RAM 和 CPU 密集型设施，它依然是一个年老的 CNI，它依赖于 Open vSwitch（Antrea 也是如此，但 Antrea 更轻便并且性能更好）。
网络策略由除 Flannel 之外的所有通过测试的 CNI 施行。Flannel 很可能永远不会（永远）实现它，因为他们的目标很明确：越轻越好。
此外，加密性能是这里真正的令人诧异的成果。Calico 是最古老的 CNI 之一，然而直到几周前它们才提供加密。他们更喜爱应用 wireguard，而不是 IPsec，至多能够说，它在该畛域中表现出色。当然，因为加密负载，它耗费了大量的 CPU，然而它们实现的带宽是齐全值得的（请记住，Calico 加密的性能大概是 Cilium 的 6 倍，后者排名第二）。此外，在集群上部署 Calico 之后，您还能够随时激活 Wireguard 加密，也能够在短期内或永恒禁用它。这是十分用户敌对的。然而！咱们提醒您，Calico 目前无奈自动检测 MTU（该性能打算在不久后公布），因而，如果您的网络反对巨型帧（MTU 9000），请不要遗记调整 MTU。
此外，请留神 Cilium 可能加密整个节点到节点的流量（不仅是 pod 流量），这对于面向公众的集群节点来说可能是一个十分吸引人的性能。
总结一下，这是我对以下用例的倡议：
- 我须要一个 CNI 来包容额定的小型节点集群，或者我不在乎安全性
而后应用 Flannel，这简直是最轻的稳固 CNI。 - 我的规范集群须要一个 CNI
好的，Calico 是您的抉择，如果须要，请不要遗记调整 MTU。您能够应用网络策略，轻松启用 / 禁用加密等。 - 我的（十分）大型集群须要一个 CNI
好吧，该基准测试无奈反映大型集群的行为。我很乐意为此工作，然而咱们没有数百台具备 10Gbit / s 连接性的服务器。因而，最好的抉择是至多应用 Calico 和 Cilium 在您的节点上运行自定义的基准测试。
PS: 本文属于翻译，原文