评估业务集群资源
目录
推荐的控制平面实践
本主题提供了 控制平面的性能和可扩展性推荐实践。
以下所有要求均基于 的最小安装配置，即核心包的安装。
在实际应用中，实际需求可能更高，请参考扩展组件的说明以获取详细的额外资源需求。\
控制平面节点规格
控制平面规格需求会随着集群节点数量、节点类型以及运行的对象数量和种类而变化。以下建议来源于对控制平面负载行为的集群密度测试。测试在指定的命名空间集合中部署了以下对象：
- 6 个 Deployment，Pod 仅运行 sleep 进程
- 6 个 Service
- 6 个指向上述 Service 的 Ingress
- 12 个包含 2048 个随机字符串字符的 Secret
- 12 个包含 2048 个随机字符串字符的 ConfigMap
| 工作节点数量 | 集群密度（命名空间数） | CPU 核数 | 内存 (GB) |
|---|---|---|---|
| 24 | 500 | 4 | 16 |
| 120 | 1000 | 8 | 32 |
| 254 | 4000 | 24 | 128 |
上述表格数据基于安装在 AWS 上的 环境，控制平面节点使用 r5.4xlarge 实例（16 vCPU，128 GB 内存），工作节点使用 m5.2xlarge 实例（8 vCPU，32 GB 内存）。
在拥有三个控制平面节点的大型高密度集群中，若因意外问题（如电力或网络故障）、基础设施问题或为节省成本而有意关闭其中一个节点，剩余两个节点将承担额外负载。此时，存活控制平面节点的 CPU 和内存使用率可能显著上升。
升级过程中也会出现类似情况，因为控制平面节点通常会依次被隔离、驱逐并重启，同时更新控制平面 Operator。此顺序维护会使活跃节点的负载集中。
为降低级联故障风险，应为控制平面服务器预留足够余量：目标整体 CPU 和内存利用率约为 60% 或更低，以便集群能承受瞬时负载增加。如有必要，增加控制平面的 CPU 和内存，以防止因资源耗尽导致的潜在故障。
节点规格会根据集群中节点数量和对象数量而变化，也取决于对象是否处于创建阶段。对象创建期间，控制平面的资源使用比对象处于运行阶段时更为活跃。
主要版本测试的集群最大规模
过度分配节点的物理资源会削弱 Kubernetes 依赖的调度保障。请应用资源请求和限制、QoS 类别以及节点调优等控制措施，尽量减少内存交换和其他资源争用。
本文档中的数据来自 Alauda 的特定配置、方法和调优。以下条目列出了 在测试条件下观察到的最大值，而非固定上限。
由于 版本、控制平面工作负载和网络插件的组合无限，以下数值并非所有部署的保证限制，且可能无法在所有维度同时达到。
请在规划具有类似特征的部署时，将其作为参考。\
当增加或减少 集群节点数量时，建议：
- 在可用时，将节点分布在所有可用区，以提高可用性。
- 每次扩缩容不超过 25 到 50 个节点。
缩减大型高密度集群时，操作可能耗时较长，因为待移除节点上的工作负载必须先迁移或终止，才能关闭节点。若需处理大量资源，时间会更长。
若需驱逐大量对象，API 客户端可能开始限制请求速率。默认客户端的 QPS 和突发值分别为 50 和 100，且这些值在 中不可更改。\
| 最大类型 | 测试最大值 |
|---|---|
| 节点数量 | 500 [1] |
| Pod 数量 [2] | 100,000 |
| 每节点 Pod 数量 | 250 |
| 命名空间数量 [3] | 10,000 |
| 每命名空间 Pod 数量 [4] | 25,000 |
| Secret 数量 | 40,000 |
| ConfigMap 数量 | 40,000 |
| Service 数量 | 10,000 |
| 每命名空间 Service 数量 | 5,000 |
| 每 Service 后端数量 | 5,000 |
| 每命名空间 Deployment 数量 [4] | 2,000 |
| 自定义资源定义（CRD）数量 | 1,024 [5] |
- 支持超过 500 个节点的集群，此处数字为推荐最大值。如需更大规模集群，请联系技术支持。
- Pod 数量为测试环境统计值，实际容量会根据各应用的内存、CPU 和存储需求有所不同。
- 当活跃项目众多时，若 etcd 键空间过大且超出配额，性能可能下降。建议定期进行 etcd 维护（如碎片整理）以回收存储并避免性能问题。
- 多个控制循环会响应状态变化遍历命名空间内所有对象。单一命名空间内某类对象数量过多会导致循环开销大，处理变慢。此限制假设系统有足够的 CPU、内存和磁盘满足应用需求。
- 测试在 29 服务器集群上进行（3 个控制平面节点，2 个基础设施节点，24 个工作节点），包含 500 个命名空间。 限制总自定义资源定义（CRD）数量为 1,024，包括 自带的、集成产品添加的及用户创建的 CRD。超过 1,024 个 CRD 可能导致 kubectl 请求被限流。
示例
例如，测试并支持使用 4.1 版本、Kube-OVN 网络插件和以下工作负载对象的 500 个工作节点（规格为 m5.2xlarge，即 8 vCPU 和 32 GB 内存）：
- 除默认外，200 个命名空间
- 每节点 60 个 Pod；30 个服务器 Pod 和 30 个客户端 Pod（共 3 万个）
- 每命名空间 15 个由服务器 Pod 支持的 Service（共 3 千个）
- 每命名空间 20 个 Secret（共 4 千个）
- 每命名空间 10 个 ConfigMap（共 2 千个）
- 每命名空间 6 个网络策略，包括 deny-all、allow-from ingress 和命名空间内规则
以下因素已知会正面或负面影响集群工作负载的扩展，应在规划部署时考虑。更多信息和指导，请联系技术支持团队。
- 每节点 Pod 数量
- 每 Pod 容器数量
- 探针类型（例如存活/就绪探针，exec/http）
- 网络策略数量
- 项目或命名空间数量
- 服务/端点数量及类型
- 分片数量
- Secret 数量
- ConfigMap 数量
- API 调用速率，即集群配置变化速度的估计
- 5 分钟窗口内 Pod 创建请求的 Prometheus 查询：
sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m])) - 5 分钟窗口内所有 API 请求的 Prometheus 查询：
sum(irate(apiserver_request_count{}[5m]))
- 5 分钟窗口内 Pod 创建请求的 Prometheus 查询：
- 集群节点 CPU 资源消耗
- 集群节点内存资源消耗