不同集群规格的资源数据量说明
随着业务规模的不断扩张，单个Kubernetes集群节点数量的限制直接影响了业务的扩展性和灵活性。在现有集群中部署更多服务或实例时，可能会遇到集群资源不足的问题，导致服务部署失败或性能下降。不同集群规格的资源数据量可能存在瓶颈，您可以根据表1选择和业务规模适配的集群规格，满足大规模业务部署的需求，提升集群的资源利用率和业务承载能力。
| 资源类型（理论上限） | 50节点 | 200节点 | 1000节点 | 2000节点 |
|---|---|---|---|---|
| etcd存储总容量 | 200Mi | 500Mi | 2Gi | 4Gi |
| 每种资源类型etcd对象总大小 | 20Mi | 50Mi | 200Mi | 400Mi |
| 节点数 | 50 | 200 | 1000 | 2000 |
| Pod（Pod平均大小不超过15K，单Pod中凭据容器数量不超过2） | 1000 所有Pod中Secret/ConfigMap的总挂载量不超过2000 | 4000 所有Pod中Secret/ConfigMap的总挂载量不超过8000 | 20000 所有Pod中Secret/ConfigMap的总挂载量不超过4w | 40000 所有Pod中Secret/ConfigMap的总挂载量不超过8w |
| 集群中Pending Pod数量 | 100 | 400 | 2000 | 4000 |
| 支持的创删Pod并发量（Pod平均大小不超过15K，单Pod中凭据容器数量不超过2） | 100 | 400 | 2000 | 4000 |
| HPA/CronHPA总策略数量 | 20 | 40 | 200 | 400 |
| Namespace | 20 | 80 | 400 | 800 |
| ConfigMap（平均资源大小不超过15K） | 250 | 1000 | 4000 | 10000 |
| Secret（平均资源大小不超过15K） | 250 | 1000 | 4000 | 10000 |
| PVC | 500 | 2000 | 10000 | 20000 |
| PV | 500 | 2000 | 10000 | 20000 |
| Service |
|
|
|
|
| Role | 250 | 1000 | 4000 | 20000 |
| RoleBinding | 250 | 1000 | 4000 | 20000 |
| CRD | 40 | 80 | 200 | 400 |
| 所有CRD类型总CR资源数 （平均CR资源大小不超过15K） | 2000 | 4000 | 20000 | 40000 |
| 集群内所有更新类（POST/PUT/PATCH/DELETE）操作QPS上限 （更新资源目标对象平均大小不超过15k估算） | 50QPS | 100QPS | 200QPS | 400QPS |
| 集群内所有只读类请求（GET/List/Watch）QPS上限及每秒读取数据总量 （需要v1.31及以上集群支持流式输出方式） | 100QPS 50Mi/s | 200QPS 100Mi/s | 400QPS 200Mi/s | 800QPS 300Mi/s |
| 所有用户自定义CR资源的GET类请求QPS上限（单CR资源15K） | 5QPS | 5QPS | 20QPS | 20QPS |
| 用户组件访问kube-apiserver watch stream长链接数量 | 50 | 200 | 1000 | 2000 |
| 支持大List请求并发数（需要v1.31及以上集群支持流式输出方式） | 50Mi/平均单次List返回数据量 | 100Mi/平均单次List返回数据量 | 200Mi/平均单次List返回数据量 | 300Mi/平均单次List返回数据量 |
- 除节点数为强限制外，其他资源为建议项，超规格使用集群存在过载风险，您需要根据自身资源使用量选择对应规格集群。
- 资源数据量大小是指API接口查询出来的JSON格式资源数据大小，包含managedField字段（查询单个资源大小可通过kubectl get {resourceType} {resourceName} -ojson -n {namespace} --show-managed-fields > tmp.json命令，最终tmp.json文件大小即为资源大小）。如单个CongfigMap为10KB， 集群中有10000个这样类似的ConfigMap，则ConfigMap数据总量约为100Mi。
- 上述资源支持的数量按平均大小15K折算，若资源平均大小大于此值，则支持的数据量则降低。如大规格（1000节点）默认支持20000个Pod（15K以下），若Pod平均大小为30K，则支持的最大数量则降为10000。
对于请求QPS采用同样的折算方式，如大规格（1000节点）支持15K以下资源的更新类操作QPS为200，如更新资源的平均大小为30K，则实际支持的QPS减少至100。
- 更新类请求资源大小是指更新目标的资源大小，并不是请求body体的大小。
