博客

• 版本更新
• Cluster Optimizer v1.3.1版已发布
• Cluster Optimizer v1.3.0版已发布
• Cluster Optimizer v1.2.1版已发布
• Cluster Optimizer v1.2.0版已发布
• Cluster Optimizer v1.1.0版已发布
• Cluster Optimizer v1.1.0版已发布
• 新闻
• Cluster Optimizer: 一款云原生集群优化平台
• 博客
• 评估集群休眠节省成本

版本更新

Cluster Optimizer v1.3.1版已发布

集群优化平台 Cluster Optimizer v1.3.1 已正式发布。

主要特性包括：

1. Spot 节点支持：在节点和GPU 节点页面提供对Spot实例的支持。
2. 访问密钥管理：为用户管理访问密钥。通过访问密钥，用户可以以编程方式与 Cluster Optimizer API 交互。
3. 集群休眠节省估算工具：提供集群休眠节省估算工具，支持 Amazon AWS 和 阿里云。

要快速部署并试用 Cluster Optimizer，请参阅：免费试用。

Cluster Optimizer v1.3.0版已发布

集群优化平台Cluster Optimizer版本1.3.0已发布。

主要特性包括：

1. 商业版 自动化动作：支持自动化的调整数据存储卷（Persistent Volume）的容量大小，目前仅限于Deployment。
2. 商业版 集群休眠：支持集群休眠功能，可手动或定时将集群休眠，释放集群的节点资源，同时可以在恢复时同时恢复集群数据。

快速部署和试用Cluster Optimizer，请参见：免费试用。

Cluster Optimizer v1.2.1版已发布

集群优化平台Cluster Optimizer版本1.2.1已发布。

主要特性包括：

1. 数据库Schema自动升级。
2. 支持测试通知渠道连通性，方便验证输入参数的正确性。

快速部署和试用Cluster Optimizer，请参见：免费试用。

Cluster Optimizer v1.2.0版已发布

集群优化平台Cluster Optimizer版本1.2.0已发布。

主要特性包括：

1. 认证和授权：支持用户认证和权限，为用户提供了管理员和用户两种角色，管理员具备所有操作权限，用户仅有查看权限。
2. 集群访问账户：支持管理用户的集群访问账户，能够为每个用户设置集群级别的集群访问账户，包括该用户的云服务商账号，以及集群的Kubeconfig等配置。用户可以通过此身份来操作相应的集群。同时，若集群支持自动更新Kubeconfig，则用户的集群访问账户在使用时也可以定时更新。
3. 自动化动作：支持应用级的资源推荐、未设置资源额度和内存溢出，以及删除未使用的持久卷等自动化动作，支持标准的工作负载Deployment、StatefulSet、DaemonSet和CronJob。不支持Job，其资源额度（Resource Quota）不可修改。
4. 任务管理：支持创建、运行、重运行、取消、查看任务日志、删除任务等日常任务管理操作。

快速部署和试用Cluster Optimizer，请参见：免费试用。

Cluster Optimizer v1.1.0版已发布

集群优化平台Cluster Optimizer版本1.1.0已发布。

主要特性包括：

1. AWS Cloud EKS集成：支持导入AWS EKS集群，查看针对集群的优化建议。
2. GPU节点：支持查看GPU利用率低的GPU节点。
3. 快速资源关联：支持通过资源的标签快速将资源和相应的部门、组、用户关联起来，并能够展示到Web界面。
4. 邮件通知：针对具体的优化策略，用户可以订阅邮件通知，方便通过邮件了解到相应的优化建议。
5. 集群状态：能够展示导入集群中的Kubernetes状态和Metrics服务的状态。对于异常状态，能够快速发现到异常原因。
6. 支持自动创建数据库Schema：可通过数据库连接配置项中的参数createDatabaseIfNotExist=true来指明在数据库不存在是是否自动创建数据库。当指定的用户名和密码具备创建数据库权限时，系统将自动创建数据库。

快速部署和试用Cluster Optimizer，请参见：免费试用。

Cluster Optimizer v1.1.0版已发布

集群优化平台Cluster Optimizer版本1.0.0已发布。

主要特性包括：

1. 阿里云ACK集成：支持导入阿里云ACK集群，查看针对集群的优化建议，包括节点组、节点、磁盘、Persistent Volume和应用等维度。
2. 设置页面：编辑集群和云账户。

新闻

Cluster Optimizer: 一款云原生集群优化平台

云原生成本优化亟待优化

云原生已成为未来技术发展的主流趋势之一。据Gartner估计，到2025年，超过95%的新数字工作负载将被部署在云原生平台。随着云原生技术的广泛应用，企业可以实现更高效的资源利用率、更快的应用交付速度以及更好的可扩展性和可靠性。然而，在实践中，受多种因素的影响，实际成本存在失控的风险。据《2021 CNCF FinOps Kubernetes Report》显示，迁移至 Kubernetes 平台后，68% 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%。CNCF在2023年《Cloud Native and Kubernetes Finops Microsurvey》调查报告中指出，49%的受访者表示其成本略有增加或显著增加。Flexera 2024 年云现状报告调查中指出，59%的用户更关注成本优化。FinOps产业推进方阵在2023年中国FinOps产业发展研究报告也指出，超过半数企业IT存在资源浪费的情况，超过八成企业有IT资源及成本优化的诉求。因此，对云原生应用的成本进行监控和管理，并及时采取手段进行成本优化变得越来越迫切。

在云原生成本优化方面主要面临三方面的问题：

1. 资源闲置：资源闲置表现为未及时释放占用资源，例如开发测试环境中未及时释放的应用实例或未及时释放的相关资源（例如弹性 IP）。
2. 配置不当：配置不当表现为资源容量超量申请、不合理使用扩缩容机制等。例如，为保障应用峰值性能而超量申请 CPU 或内存，或者错误配置弹性扩缩容时机，以及设置的应用最小副本数过大等。
3. 缺乏自动化的优化机制：缺乏自动化的优化机制意味着在云环境中往往需要依靠人工干预来进行优化，导致运维复杂。例如，节点上挂载的磁盘可能会在一段时间内经历使用量的波动，但由于缺乏自动化的机制，当磁盘使用量下降时，系统无法自动将磁盘容量缩减至实际需求的水平。

云原生集群优化平台Cluster Optimizer

Cluster Optimizer的主要目标是通过自动化智能化的平台和工具帮助客户降低使用云的成本，解决云原生架构广泛实践带来的成本难以管理、难以优化的问题。Cluster Optimizer是我们通过深度学习、序列决策等先进算法，结合云计算实践经验，构建一套全新的技术平台。该平台能够全面分析云资源、应用、用户行为以及云服务商数据，精准识别优化机会（包括识别闲置资源、配置不当等），为用户提供多个维度的优化推荐并为用户后续操作提供指导和自动化能力支持，帮助用户降低成本、提高性能、提升效率。

云原生集群优化平台Cluster Optimizer提供了多个维度的优化建议，包括：

• 节点组：包括节点组推荐策略，能够为推荐实例类型，是否启动自动扩缩容，以及其最大节点数和最小节点数的配置。
• 节点：包括低利用率节点策略，能够评估节点的利用率，推荐合适的实例类型。
• GPU节点：能够识别GPU利用率比较低的节点，并推荐合适的实例类型。
• 磁盘：包括低利用率磁盘识别，能够评估磁盘的利用率，帮助用户设置合适的磁盘容量。
• Persistent Volume：包括未使用Persistent Volume识别和低利用率Persistent Volume识别，能够识别未使用或低利用率Persistent Volume，帮助用户删除未使用Persistent Volume和调整低利用率Persistent Volume的容量。
• 应用：包含资源推荐、未设置资源限额和OOM三个策略。资源推荐策略能够为负载推荐合适的Request和Limit。未设置资源限额能够为未设置资源Quota的负载推荐合适的值。OOM策略能够监控内存溢出的应用。

以节点组推荐为例。一般来说，集群中的节点会划分为多个节点组，每个组节点有其特定用途（例如，用于区分不同的业务）。云产商会提供节点组的自动扩缩容，然而，设置节点组的实例类型、自动扩缩容的节点最大和最小值是非常具有挑战的事情。通过节点组推荐策略，我们基于当前节点组上运行的负载的度量指标、云提供商实例价格、实际地域分布情况等，为用户推荐成本最低的实例类型、是否启动自动扩缩容、节点最大值和最小值，能随着节点组上负载的变化持续优化节点组的配置。

如下图所示，节点组us-pre-eks-cluster-node-r5a-20240229当前设置实例类型为r6a.4xlarge，已启用自动扩缩容，最大节点数和最小节点数都是2。其优化设置中我们的策略推荐了多个实例类型，包括r5a.large，r6a.large，r5a.2xlarge等；其最大节点数为7，最小节点数为1。基于这些优化设置好，可以设置节点组相应属性，从而显著降低利用率低时的节点使用成本。

如何安装和试用Cluster Optimizer

我们提供了Cluster Optimizer社区版，您可以参考下述地址免费安装试用：免费试用。

安装试用过程中有任何问题，请与我们联系，我们将会尽快回复您。

• 电子邮箱：business@wiseinf.com
• 微信：
• 飞书：

博客

评估集群休眠节省成本

集群休眠概述

资源闲置和利用率低是用户使用云原生集群时的痛点之一。例如，开发、测试和演示环境等线下运行的集群通常在工作时间之外的利用率很低，但企业仍需为这些资源支付费用。

集群休眠能够自动或手动控制集群的休眠和恢复，释放和恢复集群中的节点来降低集群的资源占用，提高资源利用率，节约成本。例如， 通过合理配置集群休眠策略，在非工作时间段（如夜间或周末）自动关闭集群，企业可以显著减少不必要的资源消耗，实现显著的成本节约。因此，集群休眠是一种有效的成本管理策略，特别适用于线下非生产环境。

集群休眠策略

集群休眠在休眠期间逐步释放集群中的节点，存储集群中负载（例如Deployment、Job等）的状态。在恢复期间，恢复集群节点和集群中负载（例如Deployment、Job等）的状态。集群一般通过节点组（也叫节点池）来管理，节点组中会配置不同的节点类型，比如预留节点（例如包年包月）和按需节点（例如按量付费，抢占式实例）。根据节点组是否能够自动扩缩容，可将其分为非自动扩缩容节点组和自动扩缩容节点组，并采用不同的集群休眠策略。

非自动扩缩容节点组中节点数量是固定配置，无法根据负载动态调整资源，需手动管理节点数量。针对此类节点组，休眠期间会将其节点数量调整为0，促使云服务商逐步释放该节点组的节点。恢复期间调整为原节点数量。值得注意的是，将节点数设置为0并不意味着节点组内所有节点都会被释放掉。一般情况下，节点组内的预留节点仍将保留。

自动扩缩容节点组是一种根据实际负载动态调整节点数量的机制，以优化资源利用。针对此类节点组，集群休眠将可调整的工作负载都进行调整，并依赖于该节点组的扩缩容策略进行缩容。例如，将Deployment的副本数调整为0，将CronJob暂停等，从而触发该节点组的缩容，减少节点数量。

集群休眠收益评估

集群休眠收益评估工具

我们提供了工具cluster-hibernate-saving-estimate帮助用户评估集群中可节约的资源。该工具能够扫描集群中每个节点组的详情，给出节点组概况、最大潜在节省、潜在节省、推荐操作和节点组Deployment资源请求总和。其中：

• 最大潜在节省（Max Potential Saving）：指在调整节点组中各类型节点达到理想分布情况下所能够节省的最大空间。
• 潜在节省（Potential Saving）：指在当前节点组现状下所能够节省的空间。
• 节点组Deployment资源请求总和（Sum of Deployment Resource Requests）：指该节点组中实际部署的Deployment的Pod的资源Request的总和，该值主要是用于参考值，用于粗略评估该节点组中Deployment的资源请求占用情况。其占比越高，则对于自动扩缩容节点组能够达到的最大潜在节省最高。

注：集群休眠收益评估工具可在https://github.com/wiseinf/cluster-hibernate-saving-estimate/tags 下载， 目前仅支持阿里云、AWS等云平台。

下面我们分析下两种常见场景下集群休眠的收益。

场景1：非自动伸缩节点组，仅包含预留节点

非自动伸缩节点组中若仅包含预留节点，典型输出如下：

NodeGroup: cpu-ng(npa324882932487c9777eaa7f6854e4)  Total Nodes: 4  Autoscaling: false
  OnDemandNodes: 0  
  SpotNodes: 0  
  ReservedNodes: 4  cpu: 32 cores, memory: 128 gib
    Node: cn-beijing.171.19.105.70(i-bp19u4ufadv9niflo1o4) NoSpot, InstanceType: ecs.g7ne.2xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.19.105.74(i-bp19u4ufadv9niflo1o3) NoSpot, InstanceType: ecs.g7ne.2xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.19.105.71(i-bp19u4ufadv9niflo1o5) NoSpot, InstanceType: ecs.g7ne.2xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.19.105.251(i-bp161b0ldoqt1k771t5e) NoSpot, InstanceType: ecs.g7ne.2xlarge, ChargeType: PrePaid
  Max Potential Saving: CPU: 14125.71 core hours; Memory: 56502.86 gib hours
  Potential Saving: No saving, no spot or on demand nodes
  Recommendation: adjust some reserved nodes to on-demand or spot nodes based on its usage
  Sum of Deployment Resource Requests: CPU 8.63 cores, Memory 18.68 gibs
该节点组包含4个预留节点，总计包含32核CPU和128Gi内存。假设该节点组在周一至周五晚上9点开始休眠，周一至周五早上8点开始恢复（也就是结束休眠），每月按照30日计算。

该节电组最大潜在节省中CPU可节约核时是 14125.71核时，计算如下：

    14125.71核时 = 32（CPU核数）* 720（每月小时数） * 103(每周休眠小时数) / 168（每周小时数）

其中，32核是该节点组的总核数。最大潜在节省时将预留节点都调整为按需节点，此时可达到最大潜在节省。

内存的可节约Gi时计算方式同CPU类似，不再赘述。

该节点组潜在节省为0。在当前现状下，节点组都是预留节点，将节点组节点数量调整为0时不会释放任何节点，此时无法节省成本。若期望节省成本，需将部分节点调整为按需节点。

注：实际调整节点类型时需考虑预留节点和按需节点价格差异。

场景2：自动伸缩节点组， 包含按需节点

NodeGroup: as-cpu-ng(np151adb107448039712d3a24f0d50a)  Total Nodes: 12  Autoscaling: true
  OnDemandNodes: 6  cpu: 192 cores, memory: 384 gib
    Node: cn-beijing.171.18.106.158(i-bp6f7txtyecxuauzgk6m) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.76(i-bp6f7txtyecxuauzgk6o) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.69(i-bp6f7txtyecxuauzgk6j) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.79(i-bp6f7txtyecxuauzgk6k) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.159(i-bp6f7txtyecxuauzgk6h) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.125(i-bp6f7txtyecxuauzgk6g) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
  SpotNodes: 0  
  ReservedNodes: 6    cpu: 192 cores, memory: 384 gib
    Node: cn-beijing.171.18.106.75(i-bp6f7txtyecxuauzgk6d) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.120(i-bp6f7txtyecxuauzgk6l) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.71(i-bp6f7txtyecxuauzgk6f) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.123(i-bp6f7txtyecxuauzgk6i) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.78(i-bp6f7txtyecxuauzgk6n) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid
    Node: cn-beijing.171.18.106.248(i-bp6f7txtyecxuauzgk6e) NoSpot, InstanceType: ecs.hfc7.8xlarge, ChargeType: PrePaid  
  Max Potential Saving: CPU: 98880 core hours; Memory: 197760 gib hours
  Potential Saving: CPU: 84754.29 core hours; Memory: 169508.57 gib hours
  Recommendation: no recommendation
  Sum of Deployment Resource Requests: CPU 224.00 cores, Memory 448.00 gibs

该节点组最大潜在节省中CPU可节约核时计算如下：

    98880核时 = 224（CPU核数）* 720（每月小时数）* 103(每周休眠小时数) / 168（每周小时数）

其中，计算时采用的CPU核数是节点组Deployment资源请求总和（224核）。

该节点组潜在节省中CPU可节约核时数计算如下：

    84754.29核时 = 192（CPU核数）* 720（每月小时数）* 103(每周休眠小时数) / 168（每周小时数）

其中，计算时采用的CPU核数是节点组Deployment资源请求总和中CPU核数和按需节点组核数总和的较小值（192核）。

该节点组中潜在节省中CPU可节约核时数小于最大潜在节省中CPU最大可节约核时，此时可通过将部分预留节点调整为按需节点，达到最大潜在节省中CPU最大可节约核时。

问题&解决方案

工作负载状态的保存和恢复

集群休眠涉及到工作负载状态的保存和恢复，用户主要顾虑是集群恢复时无法完全恢复工作负载的状态，导致工作负载不可用，需要进行排障，从而影响工作效率。集群休眠主要通过调整节点组（释放和恢复节点）来进行，若集群休眠和恢复导致工作负载不可用，则同样的问题也会出现在线上。在云原生的场景中，应用必须具备弹性能力，最好的解决方式是排查工作负载不可用的原因并彻底解决，使得该应用能够忍受节点故障，同时也消除该应用线上由于节点故障等导致的不可用风险。

期望工作负载在集群休眠时保持运行状态

若期望工作负载在集群休眠期间仍保持运行状态，需保证工作负载具备如下特性：

该负载可调度到自动扩缩容节点组上运行（集群中至少包含一个自动扩缩容节点组） 包含标签wiseinf.com/reserved，其值是true。集群休眠调整工作负载状态时会忽略包含该标签的工作负载。目前仅支持三种类型：Deployment、DaemonSet和CronJob。

总结

集群休眠是一个行之有效的成本管理策略，特别适用于线下非生产环境。集群休眠收益评估工具能够快速评估集群使用集群休眠策略时每个节点池可节约的空间，同时也给出了两个典型场景（包括自动扩缩容节点组和非自动扩缩容节点组）下的评估案例，帮助用户更好的进行评估收益，从而可通过调整设置，降低资源成本。

关于集群优化平台

集群优化平台Cluster Optimizer是云智优本公司研发的一站式云原生优化平台，致力于帮助客户降低云原生集群和应用的成本，提升运营效率。它是一个基于数据驱动的智能决策平台，是基于云资源、应用以及用户、云厂商行为数据，利用深度学习、序列决策等算法，结合云、微服务、云原生等实践经验，构建的一套技术解决方案。此平台能够全面深入分析云资源、应用、用户行为及服务商数据及使用情况，预测未来资源需求，精准识别成本优化的机会，并提供个性化的优化建议。此外，平台采用全链路闭环的自动化优化机制，提高了优化效率，减少了人为错误，使客户能够轻松实现云原生集群及应用资源的自动化管理和优化，提升资源利用效率，显著降低云成本，提高运营效率。