Pool Coordinator 性能测试

背景

Pool Coordinator 是边缘节点池中一个重要的组件，它是一个由 apiserver 和使用内存存储数据的 etcd 组成的 Pod。

边缘节点池中的 node 会通过 Pool Coordinator 选出一个主节点，节点池依赖此主节点做云端探活；Pool Coordinator 也用于备份边缘节点的本地资源。

本文中，我们将对 Pool Coordinator 的性能进行测试，并给出一个推荐的 Pool Coordinator 资源配置。

测试环境

Kubernetes 版本

Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T17:57:25Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"

Node 配置

Master 节点与 worker 节点均使用运行在 VMWare Fusion 中的虚拟机。

操作系统

MasterNode
LSB Version:core-4.1-amd64:core-4.1-noarch:core-4.1-amd64:core-4.1-noarch
Distributor IDCentOSCentOS
DescriptionCentOS Linux release 8.4.2105CentOS Linux release 8.4.2105
Release8.4.21058.4.2105

CPU

MasterNode
Architecturex86_64x86_64
CPU op-mode (s)32-bit, 64-bit32-bit, 64-bit
Byte OrderLittle EndianLittle Endian
CPU (s)44
On-line CPU(s) list0-30-3
Thread(s) per core11
Core(s) per socket11
Socket(s)44
NUMA node(s)11
Vendor IDGenuineIntelGenuineIntel
CPU family66
Model158158
Model nameIntel(R) Core(TM) i7-9750H CPU @ 2.60GHzIntel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Stepping1010
CPU MHz2592.0002592.000

内存

MasterNode
Total memory7829472 K7829472 K

磁盘

MasterNode
Total Size20GiB20GiB

测试方法

  1. 启动 pool-coordinator，观察初始时的资源占用情况。
  2. 向 pool-coordinator 中写入 1000 个 Pod 和 500 个 Node。其中，单个 Pod、Node 资源大小均约为 8kb，观察写入后的资源占用情况。
  3. 删除 pool-coordinator 中的所有 Pod 和 Node 资源，观察资源占用情况。
  4. 向 pool-coordinator 中再次写入 1000 个 Pod 和 500 个 Node，并持续随机更新 Pod、Node 信息，观察资源占用情况。
  5. 请求 pool-coordinator 选主，观察是否成功。

测试结果

第一阶段

启动 pool-coordinator，观察 CPU 和内存的占用情况（pause 容器和 kubectl 容器占用较少，暂不统计，下同）：

  • CPU 占用量约为 70m ~ 90m。
  • 内存占用量约为 370MB。其中，apiserver 约占用 205MB；etcd 约占用 165MB。

Pool Coordinator 性能测试 - 图1 Pool Coordinator 性能测试 - 图2 Pool Coordinator 性能测试 - 图3 Pool Coordinator 性能测试 - 图4

第二阶段

向 pool-coordinator 中写入 1000 个 Pod 和 500 个 Node 资源，观察 CPU 和内存的占用情况：

  • CPU 峰值使用量约为 310m，整体涨幅不明显。其中，apiserver CPU 使用量略有上涨；etcd 变化不明显。
  • 内存占用量约为 450MB。其中，apiserver 约占用 240MB；etcd 约占用 210MB。

Pool Coordinator 性能测试 - 图5 Pool Coordinator 性能测试 - 图6 Pool Coordinator 性能测试 - 图7 Pool Coordinator 性能测试 - 图8

第三阶段

删除 pool-coordinator 中的所有 Pod 和 Node 资源，观察资源占用情况。

  • CPU 峰值使用量约为 260m，变化不明显。
  • 内存占用量最高约到 590MB。其中，apiserver 约占用 350MB；etcd 约占用 240MB。

Pool Coordinator 性能测试 - 图9 Pool Coordinator 性能测试 - 图10 Pool Coordinator 性能测试 - 图11 Pool Coordinator 性能测试 - 图12

第四阶段

向 pool-coordinator 中再次写入 1000 个 Pod 和 500 个 Node，并持续随机更新 Pod、Node 信息，观察资源占用情况。

  • CPU 使用量最高位约为 640m。
  • 内存使用量持续上涨，直到 etcd container 发生 OOM。

Pool Coordinator 性能测试 - 图13 Pool Coordinator 性能测试 - 图14 Pool Coordinator 性能测试 - 图15 Pool Coordinator 性能测试 - 图16

第五阶段

启动外部程序，以 500 个 client 请求 pool-coordinator 选主。如单个 client 选主成功，则在 sleep 1s 后退出。

由代码输出可知，不同的 client 轮流选主成功，结果正常。

  1. I1212 14:58:43.652733   41875 leaderelection.go:258] successfully acquired lease default/test-lock
  2. I1212 14:58:43.652766   41875 main.go:656] new leader elected: ff43ffde-3551-47d6-b2af-1fa3ef115b86
  3. I1212 14:58:43.652779   41875 main.go:562] Controller loop...
  4. I1212 14:58:44.653060   41875 main.go:564] Controller quit.
  5. I1212 14:58:44.662196   41875 main.go:648] leader lost: ff43ffde-3551-47d6-b2af-1fa3ef115b86
  6. I1212 14:58:44.679782   41875 leaderelection.go:258] successfully acquired lease default/test-lock
  7. I1212 14:58:44.679826   41875 main.go:656] new leader elected: 76870bb5-eaa0-44b0-a8a8-203c36a2d373
  8. I1212 14:58:44.679915   41875 main.go:562] Controller loop...
  9. I1212 14:58:45.680211   41875 main.go:564] Controller quit.
  10. I1212 14:58:45.686105   41875 main.go:648] leader lost: 76870bb5-eaa0-44b0-a8a8-203c36a2d373
  11. I1212 14:58:45.697108   41875 leaderelection.go:258] successfully acquired lease default/test-lock
  12. I1212 14:58:45.697131   41875 main.go:656] new leader elected: b127e7bc-beeb-474a-b0e9-5023b1563d94
  13. I1212 14:58:45.697210   41875 main.go:562] Controller loop...
  14. I1212 14:58:46.698199   41875 main.go:564] Controller quit.
  15. I1212 14:58:46.702313   41875 main.go:648] leader lost: b127e7bc-beeb-474a-b0e9-5023b1563d94
  16. I1212 14:58:46.733931   41875 leaderelection.go:258] successfully acquired lease default/test-lock
  17. I1212 14:58:46.733953   41875 main.go:656] new leader elected: 7a4dd5d7-5e25-4f69-a882-d32e17bb703a
  18. I1212 14:58:46.734007   41875 main.go:562] Controller loop...
  19. I1212 14:58:47.739147   41875 main.go:564] Controller quit.
  20. I1212 14:58:47.743684   41875 main.go:648] leader lost: 7a4dd5d7-5e25-4f69-a882-d32e17bb703a
  21. ...

请求 pool-coordinator 查看 lease 信息，可知：lease 创建成功，并且 lease 的 holder 随着 client 的退出持续不断变化。

  1. $ kubectl get lease
  2. NAME        HOLDER                                 AGE
  3. test-lock   ff43ffde-3551-47d6-b2af-1fa3ef115b86   5m
  5. $ kubectl get lease
  6. NAME        HOLDER                                 AGE
  7. test-lock   76870bb5-eaa0-44b0-a8a8-203c36a2d373   5m
  9. $ kubectl get lease
  10. NAME        HOLDER                                 AGE
  11. test-lock   b127e7bc-beeb-474a-b0e9-5023b1563d94   5m
  13. $ kubectl get lease
  14. NAME        HOLDER                                 AGE
  15. test-lock   7a4dd5d7-5e25-4f69-a882-d32e17bb703a   5m

结论

当 NodePool 内的资源在一定数量内（Pod：1000，单个 8KB；Node 500，单个 8KB）时，pool-coordinator 的最小资源占用量约为 CPU 310m、内存 450MB。

由于 etcd 自身的存储机制，删除资源并不会让 pool-coordinator 的内存用量下降，反而短期会导致内存用量上涨。

短时间内频繁更新资源，将导致 etcd 中的 revision 变多，引发 etcd 数据量快速上涨。如 etcd container 配置了 resource limit，则会使得 container 触发 OOM。

根据测试结果可知，CPU 并非资源瓶颈；而内存在极端情况下会暴涨，影响边缘资源使用效率。

故当单个边缘节点池的 Node 数量小于 500、Pod 数量小于 1000 时，推荐使用以下资源限制配置：

  1. apiserverResources:
  2.   requests:
  3.     cpu: 250m
  4. ---
  5. etcdResources:
  6.   limits:
  7.     cpu: 200m
  8.     memory: 512Mi
  9.   requests:
  10.     cpu: 100m
  11.     memory: 256Mi