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

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 由于加密了,它们的差距也不大。

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

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

原文地址:Benchmark results of Kubernetes network plugins (CNI) over 10Gbit/s network

发布于 2018-12-26

文章被以下专栏收录