Kubernetes 平台管理软件运行在 Kubernetes ,用于管理运行在 Kubernetes 上的资源对象。
1. 测试思路
测试在一定负载一定集群规模下,平台软件的管理能力,而不是 Kubernetes 的管理能力。平台软件的管理能力主要体现在能通过 UI 对负载、PV 进行增删改查,在 UI 上能够直接查看负载的监控和日志。
明确测试内容和目的非常重要。测试对象不是 Kubernetes 。Kubernetes 相关的测试,社区会给出更好的答案。这里需要测试的是平台软件对 Kubernetes 资源对象的管理能力。
2. 测试组合
根据 Kubernetes 社区的建议:
- 节点数不超过 5000
- Pod 总数不超过 150000
- 容器总数不超过 300000
- 每个节点的 pod 数量不超过 100
所有的测试内容,需要在相关组件的推荐配置下进行。既然上游有推荐,那么下游遵循就可以,有问题再提交给上游。
2.1 负载率
使用较多的一组序列是 50%、90%、99% 。也就是将 Kubernetes 集群的负载水位控制在 50%、90%、99% ,然后再对相关指标进行测试。
负载类型也是一个需要思考的地方。被社区广泛使用、认可的负载是最佳的选择,但是在压力测试方面,还没有达成测试负载共识,认可某一个负载的测试结果。
这里主要推荐使用的是 Kubernetes 社区提供的 examples :
- WordPress with MySQL - https://github.com/kubernetes/examples
- Go app with Redis - https://github.com/kubernetes/examples
- Java shopping - https://github.com/danielbryantuk/oreilly-docker-java-shopping/tree/master/kubernetes
- Nginx - https://github.com/kubernetes/examples/blob/master/staging/pod
这些负载基本能够覆盖常用的类型,而且与同类产品也更容易进行对比。
2.2 节点数量
根据 Kubernetes 官方提供的大集群最佳实践,将集群规模分为六等:
节点数\负载率 | 50% | 90% | 99% |
---|---|---|---|
5 (n1-standard-1) | |||
10 (n1-standard-2) | |||
100 (n1-standard-4) | |||
250 (n1-standard-8) | |||
500 (n1-standard-16) | |||
多于 500 (n1-standard-32) |
在 Google Cloud 中可以查询到机器具体配置如下:
机器名称 | vCPU | 内存(GB) | 是否 SSD |
---|---|---|---|
n1-standard-1 | 1 | 3.75 | 是 |
n1-standard-2 | 2 | 7.50 | 是 |
n1-standard-4 | 4 | 15 | 是 |
n1-standard-8 | 8 | 30 | 是 |
n1-standard-16 | 16 | 60 | 是 |
n1-standard-32 | 32 | 120 | 是 |
2.3 Etcd 配置
对于大规模 Kubernetes 集群,Etcd 的配置显得十分重要。因为全部节点的 Kubelet 都需要连接 Etcd ,节点增加会对 Etcd 产生最直接的压力。
根据 Etcd 社区的推荐配置,根据节点数,配置 Etcd 即可。
节点数 | 数据大小 | vCPUs | 内存 (GB) | Max concurrent IOPS | Disk bandwidth (MB/s) |
---|---|---|---|---|---|
50 | no more than 100 MB | 2 | 8 | 3600 | 56.25 |
250 | no more than 500 MB | 4 | 16 | 6000 | 93.75 |
1000 | no more than 1 GB | 8 | 32 | 8000 | 125 |
3000 | more than 1 GB | 16 | 64 | 16,000 | 250 |
Etcd 的节点数量维持在 3、5、7 个即可,不是越多越好,节点多写数据慢。具体可以参考: Etcd、Etcdctl 应用实践 。
2.4 测试设备和费用
进行大规模 Kubernetes 集群压力测试,资金开销肯定不会少。
如果有足够的物理机资源,可以使用物理机安装 IaaS 软件,基于 VM 进行测试。通常 IaaS 云厂商的 2 个 vCPU 对应一个物理 CPU ,而内存是 1:1 进行售卖。在虚拟化的过程中,需要保证物理资源具有一定冗余,否则测试结果可能不具备参考意义。
如果没有足够的物理机,那么只能够借助于云服务器了。使用 Terraform 等编排工具,是一个不错的选择,可以用于快速创建资源。测试完成之后,又可以快速销毁,能够减少部分资金开销。可以参考: 如何使用 Terraform Provider 提供 Iac 级别的应用 。
3. 测试输出
- 能够管理 Node 的最大数量
- 能够管理 Workload 的最大数量
- 能够管理 PV 的最大数量
- 能够承受的最大日志量(频次、大小,与 Node 数量相关)
- 能够承受的最大的监控量(与 Node 数量相关)
- 各个梯度下的推荐配置
- 各个梯度下的管理能力
- 各个梯度负载下,平台管理软件的容错恢复能力(HA)
4. 测试维度
4.1 功能点
- UI 页面
- 查询负载
- 管理负载/PV
- 查询/检索日志
- 查看监控
- …(核心功能)
4.2 观察指标
- 呈现(是否能打开相关功能)
- 速度 (2 秒以内,超过 10 秒算失败)
- 准确度(操作是否正常,返回数据是否正常)
- 高可用(HA)