Spiderpool 性能测试¶
Spiderpool 是一个适用于 underlay 网络的高性能 IPAM CNI 插件，此文将对比其与市面上主流的 underlay IPAM CNI 插件（如 Whereabouts，Kube-OVN）以及被广泛使用的 overlay IPAM CNI 插件 calico-ipam 在 ”1000 Pod“ 场景下的性能表现。
背景¶
为什么要做 underlay IPAM CNI 插件的性能测试？
- IPAM 分配 IP 地址的速度，很大程度上的决定了应用发布的速度。
- 大规模的 Kubernetes 集群在故障恢复时，underlay IPAM 往往会成为性能瓶颈。
- underlay 网络下，私有的 IPv4 地址有限。在有限的 IP 地址范围内，并发的创建 Pod 会涉及 IP 地址的抢占与冲突，能否快速的调节好有限的 IP 地址资源具有挑战。
环境¶
- Kubernetes:
v1.25.4 - container runtime:
containerd 1.6.12 - OS:
CentOS Linux 8 - kernel:
4.18.0-348.7.1.el8_5.x86_64
| Node | Role | CPU | Memory |
|---|---|---|---|
| master1 | control-plane | 4C | 8Gi |
| master2 | control-plane | 4C | 8Gi |
| master3 | control-plane | 4C | 8Gi |
| worker4 | 3C | 8Gi | |
| worker5 | 3C | 8Gi | |
| worker6 | 3C | 8Gi | |
| worker7 | 3C | 8Gi | |
| worker8 | 3C | 8Gi | |
| worker9 | 3C | 8Gi | |
| worker10 | 3C | 8Gi |
测试对象¶
本次测试基于 0.3.1 版本的 CNI Specification，以 macvlan 搭配 Spiderpool 作为测试方案，并选择了开源社区中其它几种对接 underlay 网络的方案作为对比：
| Main CNI | Main CNI 版本 | IPAM CNI | IPAM CNI 版本 | 特点 |
|---|---|---|---|---|
| macvlan | v1.1.1 |
Spiderpool | v0.4.0 |
集群中存在多个 IP 池，每个池中的 IP 地址都可以被集群中的任意一个节点上的 Pod 所使用，当集群中的多个 Pod 并发的从同一个池中分配 IP 地址时，存在竞争。支持托管 IP 池的全生命流程，使其同步的与工作负载创建、扩缩容、删除，弱化了过大的共享池所带来的并发或存储问题。 |
| macvlan | v1.1.1 |
Whereabouts (CRD backend) | v0.6.1 |
各节点可以定义各自可用的 IP 池范围，若节点间存在重复定义的 IP 地址，那么这些 IP 地址上升为一种共享资源。 |
| Kube-OVN (underlay) | v1.11.3 |
Kube-OVN | v1.11.3 |
以子网来组织 IP 地址，每个 Namespace 可以归属于特定的子网， Namespace 下的 Pod 会自动从所属的子网中获取 IP 地址。子网也是一种集群资源，同一个子网的 IP 地址可以分布在任意一个节点上。 |
| Calico | v3.23.3 |
calico-ipam (CRD backend) | v3.23.3 |
每个节点独享一个或多个 IP block，各节点上的 Pod 仅使用本地 IP block 中的 IP 地址，节点间无任何竞争与冲突，分配的效率非常高。 |
方案¶
测试期间，我们会遵循如下约定：
- IPv4/IPv6 双栈场景。
- 测试 underlay IPAM CNI 插件时，尽最大可能的确保可用的 IP 地址数量与 Pod 数量为 1:1。例如，接下来我们计划创建 1000 个 Pod，那么应当限制可用的 IPv4/IPv6 地址数量均为 1000 个。
具体的，我们会尝试以如下两种方式在上述 Kubenetes 集群上来启动总计 1000 个 Pod，并记录所有 Pod 均达到 Running 的耗时：
- 仅创建一个 Deployment，其副本数为 1000。
- 创建 100 个 Deployment，每个 Deployment 的副本数为 10。
接下来，我们会使用如下命令一次性的删除这 1000 个 Pod，记录被重建的 1000 个 Pod 再次全部达到 Running 的耗时：
最后，我们删除所有的 Deployment，记录所有 Pod 完全消失的耗时。
结果¶
单个 1000 副本的 Deployment¶
| CNI | 创建 | 重建 | 删除 |
|---|---|---|---|
| macvlan + Spiderpool | 2m35s | 9m50s | 1m50s |
| macvlan + Whereabouts | 25m18s | 失败 | 3m5s |
| Kube-OVN | 3m55s | 7m20s | 2m13s |
| Calico + calico-ipam | 1m56s | 4m6s | 1m36s |
在测试 macvlan + Whereabouts 这个组合期间，创建的场景中 922 个 Pod 在 14m25s 内以较为均匀的速率达到
Running状态，自此之后的 Pod 增长速率大幅降低，最终 1000 个 Pod 花了 25m18s 达到Running状态。至于重建的场景，在 55 个 Pod 达到Running状态后，Whereabouts 就基本不工作了，耗时类比于正无穷。
100 个 10 副本的 Deployment¶
| CNI | 创建 | 重建 | 删除 |
|---|---|---|---|
| macvlan + Spiderpool | 1m37s | 3m27s | 1m22s |
| macvlan + Whereabouts | 21m49s | 失败 | 2m9s |
| Kube-OVN | 4m6s | 7m46s | 2m8s |
| Calico + calico-ipam | 1m57s | 3m58s | 1m35s |
小结¶
虽然 Spiderpool 是一种适用于 underlay 网络的 IPAM CNI 插件，其相较于主流的 overlay IPAM CNI 插件，面临着更多的复杂的 IP 地址抢占与冲突的问题，但它在大多数场景下的性能表现亦不逊色于后者。