Alauda Container Platform
  • 简体中文

    • 评估业务集群资源

    目录

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

    推荐的控制平面实践

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

    INFO

    以下要求基于安装了 Core packages 的最小 配置。安装 Extensions 后，实际需求可能更高。有关额外资源需求，请阅读特定于 Extension 的指导。

    控制平面节点规格调整

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

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

    上表数据基于一个安装了 的公有云虚拟机环境，使用 16 vCPU 和 128 GB RAM 的控制平面节点，以及 8 vCPU 和 32 GB RAM 的工作节点。

    在拥有三个控制平面节点的大型密集集群中，如果有一个节点离线——无论是由于电源或网络故障等意外问题、基础设施问题，还是为了节省成本而有意关闭——其余两个节点都必须处理额外的工作负载。此时，幸存的控制平面机器上的 CPU 和内存使用率可能会显著上升。
    在升级期间，你也会看到这种模式，因为控制平面节点通常会在控制平面 Operator 更新时依次被 cordon、drain 和重启。这样的顺序维护会将需求集中到仍处于活动状态的节点上。
    为降低级联故障的风险，请为控制平面服务器预留充足的余量：目标是将整体 CPU 和内存使用率控制在约 60% 或更低，以便集群能够吸收瞬时负载增加。如有必要，可增加控制平面的 CPU 和 RAM，以防止因资源耗尽而导致潜在故障。

    IMPORTANT NOTES

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

    主要版本测试的集群最大值

    WARNING

    对节点物理资源进行过度分配会削弱 Kubernetes 依赖的调度保证。请应用资源请求和限制、QoS 类以及节点调优等控制措施，以尽量减少内存交换和其他资源争用。

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

    INFO

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

    • 在可用时，将节点分布到所有可用区，这有助于提高可用性。
    • 每次扩容/缩容不超过 25 到 50 个节点。

    在对大型、密集部署的集群进行缩容时，该操作可能需要相当长的时间，因为必须先迁移或终止计划移除节点上的工作负载，然后才能关闭这些节点。当一次需要处理大量资源时，这种情况尤其耗时。
    如果需要逐出的大量对象过多，API 客户端可能会开始对请求进行限流。默认的 client queries-per-second（QPS）和 burst 设置分别为 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 数量来自测试环境。实际 pod 容量会因每个原生应用的内存、CPU 和存储需求而异。
    3. 在有许多活跃项目的情况下，如果 keyspace 增长过大并超过其空间配额，etcd 性能可能会下降。建议定期对 etcd 进行维护，例如执行碎片整理，以回收存储并避免性能问题。
    4. 一些控制循环会在状态变更时遍历命名空间中的所有对象。单个命名空间中某一类型对象数量过多会使这些循环开销很大，并可能降低处理速度。所述限制假设系统具有足够的 CPU、内存和磁盘来满足应用需求。
    5. 该测试运行在一个 29 台服务器的集群上（3 个控制平面节点、2 个基础设施节点和 24 个工作节点），并包含 500 个命名空间。 强制执行 1,024 个 CRD 的总上限，包括 提供的 CRD、集成产品添加的 CRD 以及用户创建的 CRD。创建超过 1,024 个 CRD 可能会导致 kubectl 请求被限流。

    示例

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

    • 200 个命名空间，除此之外还有默认命名空间
    • 每个节点 60 个 pod；30 个 server pod 和 30 个 client pod（总计 30k）
    • 每个 ns 15 个由 server pod 提供后端的 service（总计 3k）
    • 每个 ns 20 个 secret（总计 4k）
    • 每个 ns 10 个 config map（总计 2k）
    • 每个 ns 6 个 network policy，包括 deny-all、allow-from ingress 以及命名空间内规则

    以下因素已知会影响集群工作负载扩展，应在扩缩容规划中加以考虑。如需更多指导，请联系技术支持。

    • 每个节点的 pod 数量
    • 每个 pod 中的容器数量
    • 所使用的探针类型（例如 liveness/readiness、exec/http）
    • network policy 数量
    • 项目或命名空间数量
    • service/endpoints 的数量和类型
    • shard 数量
    • secret 数量
    • config map 数量
    • API 调用速率，即对集群配置变化速度的估算。
      • 用于统计 5 分钟窗口内 pod 创建请求每秒数的 Prometheus 查询：sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
      • 用于统计 5 分钟窗口内所有 API 请求每秒数的 Prometheus 查询：sum(irate(apiserver_request_count{}[5m]))
    • 集群节点的 CPU 资源消耗
    • 集群节点的内存资源消耗