10 Gbps 网络上的 Kubernetes 网络插件 (CNI) 基准测试结果（2019 年 XNUMX 月更新）

这是我的更新 之前的基准，现在运行在 Kubernetes 1.14 上，最新的 CNI 版本截至 2019 年 XNUMX 月。

首先，我要感谢 Cilium 团队：他们帮助我检查并纠正了指标监控脚本。

自 2018 年 XNUMX 月以来发生了什么变化

以下是自那时以来发生的变化（如果您感兴趣的话）：

Flannel 仍然是最快、最简单的 CNI 接口，但仍然不支持网络策略和加密。

Romana 不再受支持，因此我们已将其从基准测试中删除。

WeaveNet 现在支持入口和出口的网络策略！ 但生产力却下降了。

在 Calico 中，您仍然需要手动配置最大数据包大小 (MTU) 以获得最佳性能。 Calico 提供了两种安装 CNI 的选项，因此您无需单独的 ETCD 存储库即可完成：

• 将状态存储在 Kubernetes API 中作为数据存储（集群大小 < 50 个节点）；
• 使用 Typha 代理将状态存储在 Kubernetes API 中作为数据存储，以减轻 K8S API 上的负载（集群大小 > 50 个节点）。

Calico 宣布支持 应用层策略 在 Istio 之上实现应用程序级安全。

Cilium 现在支持加密！ Cilium 通过 IPSec 隧道提供加密，并提供加密 WeaveNet 网络的替代方案。 但启用加密后，WeaveNet 比 Cilium 更快。

由于内置的​​ ETCD 操作符，Cilium 现在更容易部署。

Cilium 团队试图通过降低内存消耗和 CPU 成本来减轻其 CNI 的重量，但其竞争对手的重量仍然更轻。

基准上下文

该基准测试在三台带有 10 Gb Supermicro 交换机的非虚拟化 Supermicro 服务器上运行。 服务器通过无源 DAC SFP+ 电缆直接连接到交换机，并使用巨型帧 (MTU 9000) 配置在同一 VLAN 上。

Kubernetes 1.14.0 使用 Docker 18.04（此版本中的默认 Docker 版本）安装在 Ubuntu 18.09.2 LTS 上。

为了提高可重复性，我们决定始终在第一个节点上配置主服务器，将基准测试的服务器部分放在第二个服务器上，将客户端部分放在第三个服务器上。 为此，我们在 Kubernetes 部署中使用 NodeSelector。

我们将按以下比例描述基准测试结果：

选择 CNI 作为基准

这只是本部分列表中 CNI 的基准 关于使用 kubeadm 创建一个主集群 请参阅 Kubernetes 官方文档。 在 9 个 CNI 中，我们只选择 6 个：我们将排除那些难以安装和/或在没有根据文档配置的情况下无法工作的 CNI（Romana、Contiv-VPP 和 JuniperContrail/TungstenFabric）。

我们将比较以下 CNI：

• 印花布 v3.6
• Canal v3.6（本质上是用于网络的 Flannel + 作为防火墙的 Calico）
• 纤毛1.4.2
• 绒布0.11.0
• Kube-路由器 0.2.5
• 编织网2.5.1

安装

CNI 安装越容易，我们的第一印象就越好。 基准测试中的所有 CNI 都非常容易安装（只需一两个命令）。

正如我们所说，服务器和交换机配置为启用巨型帧（我们将 MTU 设置为 9000）。 如果 CNI 根据适配器的配置自动确定 MTU，我们会很高兴。 然而，只有 Cilium 和 Flannel 做到了这一点。 其余的 CNI 在 GitHub 上请求添加自动 MTU 发现，但我们将通过更改 Calico、Canal 和 Kube-router 的 ConfigMap 或传递 WeaveNet 的环境变量来手动配置它。

MTU 不正确会产生什么问题？ 下图显示了默认 MTU 和启用巨型帧的 WeaveNet 之间的区别：

MTU 如何影响吞吐量？

我们已经了解了 MTU 对性能的重要性，现在让我们看看我们的 CNI 如何自动确定它：

CNI自动检测MTU

该图显示您需要为 Calico、Canal、Kube-router 和 WeaveNet 配置 MTU 以获得最佳性能。 Cilium 和 Flannel 无需任何设置即可自行正确确定 MTU。

安全

我们将从两个方面来比较 CNI 的安全性：加密传输数据的能力和 Kubernetes 网络策略的实现（基于真实测试，而非文档）。

只有两个 CNI 加密数据：Cilium 和 WeaveNet。 加密 编织网 通过将加密密码设置为 CNI 环境变量来启用。 在 文件资料 WeaveNet 描述得很复杂，但一切都做得很简单。 加密 柠檬 通过命令、创建 Kubernetes 密钥以及修改 daemonSet 来配置（比 WeaveNet 中稍微复杂一点，但是 Cilium 已经一步步进行了） 指示).

在网络政策的实施方面，他们取得了成功 Calico、Canal、Cilium 和 WeaveNet，您可以在其中配置入口和出口规则。 为了 Kube路由器 仅针对 Ingress 有规则，并且 绒布 根本没有网络策略。

以下是总体结果：

安全绩效基准结果

Производительность

该基准测试显示每个测试至少运行三次的平均吞吐量。 我们测试 TCP 和 UDP（使用 iperf3）、HTTP（使用 Nginx 和curl）或 FTP（使用 vsftpd 和curl）等实际应用程序的性能，最后使用基于 SCP 的加密（使用客户端和服务器 OpenSSH）的应用程序性能。

对于所有测试，我们执行了裸机基准测试（绿线），以将 CNI 性能与本机网络性能进行比较。 这里我们使用相同的比例，但颜色不同：

• 黄色=非常好
• 橙色=好
• 蓝色=马马虎虎
• 红色=不好

我们不会采用错误配置的 CNI，并且只会显示具有正确 MTU 的 CNI 的结果。 （注意：如果启用加密，Cilium 不会正确计算 MTU，因此您必须在版本 8900 中手动将 MTU 减少到 1.4。下一版本 1.5 会自动执行此操作。）

结果如下：

TCP性能

所有 CNI 在 TCP 基准测试中都表现良好。 具有加密功能的 CNI 远远落后，因为加密成本高昂。

UDP性能

在这方面，所有 CNI 也都表现良好。 加密后的 CNI 显示了几乎相同的结果。 Cilium 稍微落后于竞争对手，但只有裸机的 2,3%，所以这个结果还不错。 不要忘记，只有 Cilium 和 Flannel 自己正确确定了 MTU，并且这些是它们的结果，没有任何额外的配置。

真正的应用又如何呢？ 正如您所看到的，HTTP 的整体性能略低于 TCP。 即使您将 HTTP 与 TCP 结合使用，我们也会在 TCP 基准测试中配置 iperf3，以避免启动缓慢而影响 HTTP 基准测试。 这里每个人都做得很好。 Kube-router 优势明显，但 WeaveNet 表现不佳：比裸机差约 20%。 带加密功能的 Cilium 和 WeaveNet 看起来真的很悲伤。

对于另一种基于 TCP 的协议 FTP，结果各不相同。 Flannel 和 Kube-router 可以完成这项工作，但 Calico、Canal 和 Cilium 稍稍落后，比裸机慢约 10%。 WeaveNet 落后多达 17%，但加密的 WeaveNet 领先加密的 Cilium 40%。

通过 SCP，我们可以立即看到 SSH 加密的成本是多少。 几乎所有 CNI 都表现良好，但 WeaveNet 再次落后。 由于双重加密（SSH + CNI），具有加密功能的 Cilium 和 WeaveNet 预计是最差的。

以下是包含结果的汇总表：

资源消耗

现在我们来比较一下 CNI 在重负载下（TCP 传输期间，10 Gbps）如何消耗资源。 在性能测试中，我们将 CNI 与裸机进行比较（绿线）。 对于资源消耗，我们展示没有 CNI 的纯 Kubernetes（紫色线），看看 CNI 消耗了多少额外资源。

让我们从记忆开始。 这是传输期间节点 RAM（不包括缓冲区和高速缓存）的平均值（以 MB 为单位）。

内存消耗

Flannel 和 Kube-router 显示出出色的结果 - 仅 50 MB。 Calico 和 Canal 各有 70 个。WeaveNet 显然比其他网络消耗更多 - 130 MB，而 Cilium 使用多达 400 MB。
现在让我们检查一下CPU 时间消耗。 值得注意的：该图显示的不是百分比，而是 ppm，即“裸铁”的 38 ppm 为 3,8%。 结果如下：

CPU消耗

Calico、Canal、Flannel 和 Kube-router 的 CPU 效率非常高 - 仅比没有 CNI 的 Kubernetes 高 2%。 WeaveNet 远远落后，多出了 5%，其次是 Cilium，为 7%。

资源消耗总结如下：

结果

包含所有结果的表：

一般基准测试结果

结论

在最后一部分我将表达我对结果的主观看法。 请记住，此基准测试仅测试非常小的集群（3 个节点）上单个连接的吞吐量。 它不适用于大型集群（<50 个节点）或并行连接。

我建议根据场景使用以下 CNI：

• 你的集群中有 资源较少的节点 （几GB RAM，几个核心）并且您不需要安全功能 - 选择 绒布。 这是最具成本效益的 CNI 之一。 并且兼容多种架构（amd64、arm、arm64等）。 此外，这是两个可以自动确定 MTU 的 CNI（另一个是 Cilium）之一，因此您无需配置任何内容。 Kube-router 也适用，但它不是标准的，您需要手动配置 MTU。
• 如有必要 加密网络 为了安全，请采取 编织网。 如果您使用巨型帧，请不要忘记指定 MTU 大小，并通过环境变量指定密码来启用加密。 但最好忘记性能——这就是加密的成本。
• 为 正常使用 我建议 印花布。 该CNI广泛应用于各种Kubernetes部署工具（Kops、Kubespray、Rancher等）。 与 WeaveNet 一样，如果使用巨型帧，请务必在 ConfigMap 中配置 MTU。 它是一个在资源消耗、性能和安全性方面高效的多功能工具。

最后，建议大家关注事态发展 柠檬。 这个 CNI 有一个非常活跃的团队，在他们的产品上做了大量工作（功能、资源节省、性能、安全性、集群......），并且他们有非常有趣的计划。

CNI选型可视化图

来源： habr.com