编辑:小君君 技术校对:星空下的文仔、bot
Kubernetes 提供了应用部署、调度、更新、维护的一种机制,但它在 Pod-to-Pod 通信网络上还缺少一个普适的解决方案。在容器部署中,CNI 为容器集群工具(Kubernetes、Mesos、OpenShift 等)提供了一个网络标准。本文将从 Kubernetes 中的六种网络解决方案出发,利用在 10Gbit / s 上进行的基准测试的结果,说明在不同场景下,各种 CNI 解决方案的使用情况。以此帮助开发者在不同集群下更好的部署网络环境。
众所周知,虽然容器提供了应用程序打包,Kubernetes 提供了用简单的容器化组件编写大型复杂应用程序的能力,但这两种技术缺乏在其特定堆栈之外进行通信的常用方法。
在部署 Kubernetes 环境时,我们一般要求网络遵循以下规则:
对此,开发者有两种类型的网络可进行设置:
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:
基准测试环境
所有的解决方案都在 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 列表:
安装
虽然 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 上使用以下颜色:
TCP
TCP 测试结果如下:
TCP 性能
从 TCP 的测试结果来看,除了加密的 WeaveNet,其他的 CNI 都非常好。这是因为加密过程会大大降低 WeaveNet 的性能。
UDP
UDP 性能
上表的测试已重复运行多次,结果稳定。各 CNI 的 UDP 基准测试表现结果如下:
HTTP
HTTP 性能
即使 HTTP 是基于 TCP 的协议,但现实应用程序似乎也会对其性能产生影响。这一环节的测试对象是一个由 nginx 提供的(在 curl 客户端下载)10GB 随机字节的文件(以避免可能的压缩副作用)。
实验结果:
FTP
FTP 性能
FTP 的测试结果与 HTTP 非常相似,它的测试结果如下:
注:该测试与 HTTP 的情况相同,只是我们在匿名模式下用 VSFTPD 替换 nginx。
SCP
SCP 性能
针对 SCP 性能测试,我们使用 OpenSSH 服务器和客户端,在 scp 上传输 10GB 随机文件。
测试结果:
以下是 CNI 的情况总结:
基准测试性能结果
资源消耗
现在,我将比较一下 CNI 在负载很重的情况下如何处理资源消耗问题(在 TCP 10Gbit 传输期间)。在性能测试中,我将 CNI 与 bare metal(绿色条)进行比较。在资源消耗测试中,我们还测试了在没有任何 CNI 安装情况下,Kubernetes 在空闲时(紫色条)的消耗。然后我们可以计算出 CNI 真正消耗了多少。
让我们从内存开始吧。以下是传输期间 RAM 资源的平均使用情况(没有缓冲区/缓存),单位为 MB。
每个节点的 RAM 的使用情况(无缓冲区/缓存)
测试结果如下:
现在,让我们看看 CPU 消耗(注:图单位不是百分比,而是千分比,bare metal 的千分之一实际上是 0.1%)。结果如下:
千分比的平均 CPU 使用率
CPU 的消耗测试结果如下:
以下是资源消耗部分的对比:
以上就是本次测试的所有结果,希望这篇文章对你有帮助!