K8S 网络插件（CNI）超过 10Gbit/s 的基准测试结果

编辑：小君君 技术校对：星空下的文仔、bot

Kubernetes 提供了应用部署、调度、更新、维护的一种机制，但它在 Pod-to-Pod 通信网络上还缺少一个普适的解决方案。在容器部署中，CNI 为容器集群工具（Kubernetes、Mesos、OpenShift 等）提供了一个网络标准。本文将从 Kubernetes 中的六种网络解决方案出发，利用在 10Gbit / s 上进行的基准测试的结果，说明在不同场景下，各种 CNI 解决方案的使用情况。以此帮助开发者在不同集群下更好的部署网络环境。

众所周知，虽然容器提供了应用程序打包，Kubernetes 提供了用简单的容器化组件编写大型复杂应用程序的能力，但这两种技术缺乏在其特定堆栈之外进行通信的常用方法。

在部署 Kubernetes 环境时，我们一般要求网络遵循以下规则：

• 所有 Pod 都可以在没有 NAT 的情况下相互通信；
• 所有节点都可以在没有 NAT 的情况下与两个方向的 Pod 进行通信；
• 容器接收到的 IP 与外部组件接收到的 IP 相同。

对此，开发者有两种类型的网络可进行设置：

• Kubernetes 默认网络；
• CNI 及其插件。

Kubernetes 默认网络

此解决方案的方法是创建具有 IP 范围的虚拟网桥，然后在每个主机上手动添加主机之间的路由。使用 Google 或 Amazon 云解决方案，可以进行手动配置。但是这个方法的弊端是当开发者不能完全坚持配置下去时，管理配置将变得十分困难。

CNI 及其插件

第二个解决方案是使用容器网络接口（CNI）和网络插件。此方法可以自动生成基本配置，让网络的创建和管理变得更加容易。如今，CNI 也成为网络供应商、项目与 Kubernetes 集成的标准方法。

*注：2016 年 CoreOS 发布了 CNI。2017 年 5 月， CNI 被 CNCF 技术监督委员会投票决定接受为托管项目。

在使用或创建 CNI 插件时，开发者主要使用三种解决方案：Calico、Flannel 和 WeaveNet。另外，Canal、Kube-router、Romana、JuniperContrail 和 TungstenFabric 方案也有一些有趣的特点。

那么重点来了！这么多 CNI 之间有什么区别？哪个性能最好？哪个性能最弱？

测试结果

本次测试从上述解决方案中选择 6 种。首先，我们看一下具体结果：

所有结果

基于本次测试，如果你遇到了相似的场景，我建议使用以下 CNI：

• 你的集群中有低资源节点（只有少量 GB 的 RAM、几个核心），而且你不需要安全功能，请使用 Flannel。这是我们测试的最精简的 CNI。而且，它与许多架构兼容（amd64、arm 等）；
• 出于安全原因，如果你需要加密网络，请使用 WeaveNet。如果你使用 jumbo 帧并通过在环境变量中提供密码来激活加密，请不要忘记设置你的 MTU 大小（忘记性能可能就是加密的代价）；
• 对于其他情况，我会推荐 Calico。就像 WeaveNet 一样，如果你使用的是 jumbo 帧，请不要忘记在 ConfigMap 中设置 MTU。事实证明，它在资源消耗、性能和安全性方面具有很大的优势。现在，Calico 已经被广泛应用于在大型集群，并且具有非常有趣的 BGP 功能。

基准测试环境

所有的解决方案都在 10Gbit / s 网络上进行基准测试。但是我不会测试 JuniperContrail、TungstenFabric，因为它需要的环境是 3.10 内核（我运行的 ubuntu 18.04 环境是 4.15 内核）。

此次，基准测试是在 Supermicro 10Gbit 交换机连接的三台 Supermicro 裸机服务器上进行的。服务器通过 DAC SFP + 无源电缆直接连接到交换机，并在激活的 jumbo 帧（MTU 9000）的同一 VLAN 中设置测试。

首先，在 Ubuntu 18.04 LTS 上安装 Kubernetes 1.12.2，并运行 Docker 17.12。

为了提高可重复性，测试会始终在第一个节点上安装主设备，在第二个服务器上设置基准测试的服务器部分，在第三个服务器上设置客户端部分。以上设置是通过 Kubernetes 部署中的 NodeSelector 来实现的。

下图是描述基准测试结果和解释的表情：

基准测试结果表情包

为基准测试选择 CNI

此基准测试仅关注文档中“bootstrap a cluster with kubeadm” 的集成 CNI 列表。

以下是我将要比较的 CNI 列表：

• Calico v3.3
• Canal v3.3（实际上是用于网络的 Flannel +用于防火墙的 Calico）
• Cilium 1.3.0
• Flannel 0.10.0
• Kube-router 0.2.1
• Romana 2.0.2
• WeaveNet 2.4.1

安装

虽然 CNI 很容易安装，但只是遵循文档还不足以安装 Cilium 和 Romana。因为 Cilium 需要一个 ETCD 数据存储区才能实现功能，我们必须搜索其文档的 minikube 部分才能找到一个单行部署的方法。

因为 Romana 是缺乏维护的。所以在 Kubernetes 1.11 版本下，Romana 无法对 “unready” 节点 (在 CNI 安装之前) 应用的 Toleration 进行更改。以至于，Romana 不会在一段时间内进行部署并让你的节点 “not-ready”！这需要修复 Romana Yaml 文件中所有 deployments/daemonsets 的 Tolerations。

如前所述，服务器和交换机都配置了激活的 Jumbo 帧（通过将 MTU 设置为 9000）。技术人员通常非常希望 CNI 可以根据适配器自动发现要使用的 MTU。实际上，Cilium、Flannel 和 Romana 是唯一能够正确自动检测 MTU 的组件。其他大多数 CNI 在 GitHub 中都存在一些问题（比如启用 MTU 自动检测）。但是现在，我们需要手工修复它，方法是修改 Calico、Canal 和 Kube -router 的 ConfigMap，或者通过 WeaveNet 的 ENV var。

那错误的 MTU 会产生什么影响呢？下表显示了 WeaveNet（默认的 MTU）与 WeaveNet（Jumbo 帧）之间的区别：

MTU 设置对带宽性能的影响

以下是安装结果的总结：

安装基准测试结果

安全

在比较这些 CNI 的安全性时，我们会关注两个点：它们加密通信的能力，以及它们的 Kubernetes 网络策略的实现（根据实际测试，而不是官方文档）。

WeaveNet 是唯一可以加密通信面板的 CNI。（原理：将加密密码设置为 CNI 的 ENV 变量）。

在网络策略实现方面，Calico、Canal 和 Cilium 实现了 Ingress 和 Egress 的规则，而 Kube-router 和 WeaveNet 只实现了 Ingress 的规则，Flannel 和 Romana 没有实现网络策略。

以下是结果对比：

安全基准测试结果

性能

该基准测试显示每次测试的三次运行（至少）的平均带宽。现在，我们测试 TCP 和 UDP 的性能（使用 iperf3），它们都是像 HTTP（使用 nginx 和 curl）和 FTP（使用 vsftpd 和 curl）这样的真实应用程序。最后，我们再使用 SCP 协议进行应用程序加密（使用 OpenSSH 服务器和客户端）。

对于所有测试，我们还在裸机节点（图中为绿色条）上运行基准测试，以比较 CNI 与本机网络性能的有效性。为了与我们的基准测试比例保持一致，我们在 chart 上使用以下颜色：

• Yellow = Very good
• Orange = Good
• Blue = Fair
• Red = Poor

TCP

TCP 测试结果如下：

TCP 性能

从 TCP 的测试结果来看，除了加密的 WeaveNet，其他的 CNI 都非常好。这是因为加密过程会大大降低 WeaveNet 的性能。

UDP

UDP 性能

上表的测试已重复运行多次，结果稳定。各 CNI 的 UDP 基准测试表现结果如下：

• 加密的 WeaveNet 结果比在 TCP 基准测试中表现的更差；
• 没有加密的 WeaveNet 表现的性能则略低于其他产品，表现合理（97％ 的裸机性能）；
• Kube-router 和 Romana 比裸机更快（小于 1％）。

HTTP

HTTP 性能

即使 HTTP 是基于 TCP 的协议，但现实应用程序似乎也会对其性能产生影响。这一环节的测试对象是一个由 nginx 提供的（在 curl 客户端下载）10GB 随机字节的文件（以避免可能的压缩副作用）。

实验结果：

• WeaveNet Encrypted 以 TCP 性能的 17％ 运行；
• Cilium 似乎遇到了一些问题；
• 没有加密的 WeaveNet、Flannel 和 Canal 也落后于其他 CNI。

FTP

FTP 性能

FTP 的测试结果与 HTTP 非常相似，它的测试结果如下：

• 未加密的 WeaveNet 与 Cilium 类似，两者都落后于其他 CNI；
• 加密的 WeaveNet 像往常一样，性能很低。

注：该测试与 HTTP 的情况相同，只是我们在匿名模式下用 VSFTPD 替换 nginx。

SCP

SCP 性能

针对 SCP 性能测试，我们使用 OpenSSH 服务器和客户端，在 scp 上传输 10GB 随机文件。

测试结果：

• 即使是裸机性能也比以前低很多；
• 所有 CNI 都差不多，除了加密的 WeaveNet，因为使用了双重加密（SCP +网络加密）。

以下是 CNI 的情况总结：

基准测试性能结果

资源消耗

现在，我将比较一下 CNI 在负载很重的情况下如何处理资源消耗问题（在 TCP 10Gbit 传输期间）。在性能测试中，我将 CNI 与 bare metal（绿色条）进行比较。在资源消耗测试中，我们还测试了在没有任何 CNI 安装情况下，Kubernetes 在空闲时（紫色条）的消耗。然后我们可以计算出 CNI 真正消耗了多少。

让我们从内存开始吧。以下是传输期间 RAM 资源的平均使用情况(没有缓冲区/缓存)，单位为 MB。

每个节点的 RAM 的使用情况（无缓冲区/缓存）

测试结果如下：

• Flannel 是最小的，只比没有 CNI 的 Kubernetes 多 20MB；
• Calico、Canal、Kube-router 和 Romana 都接近 Flannel；
• WeaveNet 稍稍落后于 WeaveNet，这表明加密对内存消耗没有影响；
• Cilium 消耗的内存远远高于其他组件。

现在，让我们看看 CPU 消耗（注：图单位不是百分比，而是千分比，bare metal 的千分之一实际上是 0.1％）。结果如下：

千分比的平均 CPU 使用率

CPU 的消耗测试结果如下：

• Calico 和 Flannel 比没有 CNI 的 Kubernetes 节点多消耗不到 1% 的 CPU （表现良好）；
• Kube-router 和 Romana 紧随其后，多消耗了约 1.5％；
• 未加密的 WeaveNet 和 Canal 的开销都很高，达到了 3％；
• 加密的 WeaveNet 和 Cilium 都超过了 4％；
• Cilium 的开销是最高的，而 WeaveNet 由于加密了，它们的差距也不大。

以下是资源消耗部分的对比：

以上就是本次测试的所有结果，希望这篇文章对你有帮助！