Alauda Container Platform
  • 简体中文

    • 评估业务集群的资源

    目录

    推荐的控制平面实践控制平面节点规格主要版本的 已测试集群上限示例

    推荐的控制平面实践

    使用以下实践来规划 中业务集群控制平面的资源。

    INFO

    以下要求基于安装了 Core 软件包的最低 部署。安装 Extensions 后，实际要求可能会更高。请阅读特定于 Extension 的指导，了解其他资源要求。

    控制平面节点规格

    控制平面规格需求会随集群的节点数量、节点类型以及运行的对象数量和类型而变化。以下建议源自集群密度测试，这些测试用于评估负载下的控制平面行为。测试会在指定的一组命名空间中部署以下对象：

    • 6 个部署，其中的 Pod 仅运行 sleep 进程
    • 6 个服务
    • 6 个指向上述服务的 Ingress
    • 12 个包含 2048 个随机字符串字符的 Secret
    • 12 个包含 2048 个随机字符串字符的 ConfigMap
    工作节点数量集群密度（命名空间）CPU 核数内存（GB）
    24500416
    1201000832
    254400024128

    上表数据基于安装在公有云虚拟机上的 环境，其中控制平面节点配置为 16 个 vCPU 和 128 GB RAM，工作节点配置为 8 个 vCPU 和 32 GB RAM。

    在有三个控制平面节点的大型高密度集群中，若有一个节点下线——无论是由于电力或网络故障等意外问题、基础设施问题，还是为了节省成本而主动关机——剩余两个节点都必须承担额外工作。此时，存活的控制平面机器上的 CPU 和内存使用量可能会显著上升。
    升级期间也会出现这种情况，因为更新控制平面 Operator 时，通常会依次封锁、驱逐并重启控制平面节点。这种顺序维护会将负载集中到仍在运行的节点上。
    为降低级联故障的风险，请确保控制平面服务器有充足的资源余量：目标是将总体 CPU 和内存利用率保持在约 60% 或以下，以便集群能够应对短暂的负载增长。如有必要，请增加控制平面的 CPU 和 RAM，以防止资源耗尽导致潜在中断。

    重要说明

    节点规格会因集群中的节点数量和对象数量而异，也取决于是否正在集群中主动创建对象。创建对象期间，与对象处于 Running 阶段时相比，控制平面的资源使用活动会更加频繁。

    主要版本的 已测试集群上限

    WARNING

    过度使用节点的物理资源可能会削弱 Kubernetes 所依赖的调度保障。请采用资源请求和限制、QoS 类以及节点调优等控制措施，尽量减少内存交换和其他资源争用。

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

    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
    ConfigMap 数量40,000
    服务数量10,000
    每个命名空间的服务数量5,000
    每个服务的后端数量5,000
    每个命名空间的 Deployment 数量 [4]2,000
    自定义资源定义 (CRD) 数量1,024 [5]
    1. 支持超过 500 个节点的集群；此处列出的是建议的最大值。如果您的使用场景需要更大的集群，请联系技术支持。
    2. 此处列出的 Pod 数量是测试环境中的计数。实际 Pod 容量会因各原生应用的内存、CPU 和存储需求而异。
    3. 如果有大量活跃项目，etcd 的键空间可能会过大并超出空间配额，进而导致性能下降。建议定期维护 etcd（例如进行碎片整理），以回收存储空间并避免性能问题。
    4. 多个控制循环会在状态发生变化时遍历命名空间中的所有对象。在单个命名空间中，某一类型的对象数量过多会增加这些循环的开销，并减慢处理速度。此处给出的上限假设系统拥有足够的 CPU、内存和磁盘资源来满足原生应用的需求。
    5. 测试在一个包含 29 台服务器的集群上运行（3 个控制平面节点、2 个基础设施节点和 24 个工作节点），其中有 500 个命名空间。 将自定义资源定义 (CRD) 总数限制为 1,024 个，其中包括由 提供的 CRD、集成产品添加的 CRD，以及用户创建的 CRD。创建超过 1,024 个 CRD 可能导致 kubectl 请求遭到限流。

    示例

    在一个测试场景中，使用 4.1、Kube-OVN 网络插件以及以下工作负载对象，对 500 个工作节点进行了测试。每个工作节点配备 8 个 vCPU 和 32 GB 内存：

    • 除默认值外，另有 200 个命名空间
    • 每个节点 60 个 Pod；30 个服务器 Pod 和 30 个客户端 Pod（总计 30k 个）
    • 由服务器 Pod 提供后端的服务，每个命名空间 15 个（总计 3k 个）
    • 每个命名空间 20 个 Secret（总计 4k 个）
    • 每个命名空间 10 个 ConfigMap（总计 2k 个）
    • 每个命名空间 6 个网络策略，包括拒绝所有、允许来自 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]))
    • 集群节点的 CPU 资源消耗
    • 集群节点的内存资源消耗