Alauda Container Platform
  • 简体中文

    • 评估业务集群资源

    目录

    推荐的控制平面实践控制平面节点规格主要版本测试的集群最大规模示例

    推荐的控制平面实践

    本主题提供了 中控制平面的性能和可扩展性推荐实践。

    INFO

    以下所有要求均基于 的最小安装配置，即核心包的安装。
    实际使用中，资源需求可能更高，请参考扩展组件的说明以获取详细的额外资源需求。\

    控制平面节点规格

    控制平面规格需求会随着集群节点数量、节点类型以及运行对象的数量和种类而变化。以下推荐基于 Cluster-density 测试，该测试评估了控制平面在负载下的行为。测试在指定的命名空间集合中部署了以下对象：

    • 6 个 deployment，Pod 仅运行 sleep 进程
    • 6 个 service
    • 6 个 ingress，指向上述服务
    • 12 个包含 2048 个随机字符串字符的 secret
    • 12 个包含 2048 个随机字符串字符的 config map
    工作节点数量Cluster-density（命名空间数）CPU 核数内存（GB）
    24500416
    1201000832
    254400024128

    上述数据基于在 AWS 上安装的 环境，控制平面节点使用 r5.4xlarge 实例（16 vCPU，128 GB RAM），工作节点使用 m5.2xlarge 实例（8 vCPU，32 GB RAM）。

    在大型且密集的集群中，拥有三个控制平面节点时，若其中一个节点因意外故障（如断电、网络故障）、基础设施问题或为节约成本而主动关闭，剩余的两个节点将承担额外负载。此时，存活控制平面节点的 CPU 和内存使用率可能显著上升。
    升级过程中也会出现类似情况，因为控制平面节点通常会被依次标记为不可调度、驱逐 Pod 并重启，同时更新控制平面 Operator。该顺序维护会集中负载于仍在运行的节点。
    为降低级联故障风险，应为控制平面服务器预留足够的资源余量：目标是整体 CPU 和内存利用率保持在约 60% 或以下，以便集群能应对瞬时负载增加。如有必要，提升控制平面 CPU 和内存配置，防止因资源耗尽导致潜在故障。

    重要提示

    节点规格会根据集群节点数量和对象数量变化而不同，也取决于对象是否处于创建阶段。对象创建阶段，控制平面的资源使用比对象处于运行阶段时更为活跃。

    主要版本测试的集群最大规模

    WARNING

    过度分配节点的物理资源会削弱 Kubernetes 的调度保障。请使用资源请求和限制、QoS 类别及节点调优等控制手段，尽量减少内存交换和其他资源争用。

    本文中的数据基于 Alauda 的特定配置、方法和调优。以下内容并非固定上限，而是 在测试条件下观察到的最大值。
    由于 版本、控制平面工作负载和网络插件的组合无限多，这些数值不保证适用于所有部署，也可能无法在所有维度同时达到。
    请在规划类似特征的部署时，将其作为参考依据。\

    INFO

    在增加或减少 集群节点数量时，建议：

    • 节点尽量分布在所有可用可用区，以提升可用性。
    • 每次扩缩容不超过 25 至 50 个节点。

    缩减大型密集集群时，操作可能耗时较长，因为待移除节点上的工作负载必须先迁移或终止后才能关闭节点。当需要驱逐大量对象时，API 客户端可能会开始限流。默认客户端的 QPS 和突发值分别为 50 和 100，且在 中不可更改。\

    最大类型测试最大值
    节点数量500 [1]
    Pod 数量 [2]100,000
    每节点 Pod 数量250
    命名空间数量 [3]10,000
    每命名空间 Pod 数量 [4]25,000
    Secret 数量40,000
    Config Map 数量40,000
    Service 数量10,000
    每命名空间 Service 数量5,000
    每 Service 后端数量5,000
    每命名空间 Deployment 数量 [4]2,000
    自定义资源定义（CRD）数量1,024 [5]
    1. 支持超过 500 节点的集群，此处为推荐最大值。如需更大规模集群，请联系技术支持。
    2. Pod 数量为测试环境计数，实际容量取决于各应用的内存、CPU 和存储需求。
    3. 当活跃项目众多时，若 etcd 键空间过大且超出配额，性能可能下降。建议定期维护 etcd（如碎片整理）以回收存储，避免性能问题。
    4. 多个控制循环会遍历命名空间内所有对象以响应状态变化。单一命名空间内某类型对象数量过多会增加循环开销，影响处理速度。此限制假设系统具备足够的 CPU、内存和磁盘资源满足应用需求。
    5. 测试在 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（共 3 千个）
    • 每命名空间 20 个 Secret（共 4 千个）
    • 每命名空间 10 个 Config Map（共 2 千个）
    • 每命名空间 6 个网络策略，包括 deny-all、允许来自 ingress 和命名空间内规则

    以下因素已知会正面或负面影响集群工作负载的扩展性，规划部署时应考虑这些因素。更多信息和指导，请联系技术支持团队。

    • 每节点 Pod 数量
    • 每 Pod 容器数量
    • 探针类型（如存活/就绪探针，exec/http）
    • 网络策略数量
    • 项目或命名空间数量
    • 服务/端点数量及类型
    • 分片数量
    • Secret 数量
    • Config Map 数量
    • API 调用速率，即集群配置变化速度的估计
      • Prometheus 查询每秒 Pod 创建请求（5 分钟窗口）：sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
      • Prometheus 查询每秒所有 API 请求（5 分钟窗口）：sum(irate(apiserver_request_count{}[5m]))
    • 集群节点 CPU 资源消耗
    • 集群节点内存资源消耗