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 官方提供的大集群最佳实践，将集群规模分为六等：
| 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 中可以查询到机器具体配置如下:
| 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 即可。
| 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)
5. 参考
- https://kubernetes.io/docs/setup/best-practices/cluster-large/
- https://cloud.google.com/compute/docs/machine-types
- https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/hardware.md
