评估集群休眠节省成本
集群休眠概述
资源闲置和利用率低是用户使用云原生集群时的痛点之一。例如，开发、测试和演示环境等线下运行的集群通常在工作时间之外的利用率很低，但企业仍需为这些资源支付费用。
集群休眠能够自动或手动控制集群的休眠和恢复，释放和恢复集群中的节点来降低集群的资源占用，提高资源利用率，节约成本。例如， 通过合理配置集群休眠策略，在非工作时间段（如夜间或周末）自动关闭集群，企业可以显著减少不必要的资源消耗，实现显著的成本节约。因此，集群休眠是一种有效的成本管理策略，特别适用于线下非生产环境。
集群休眠策略
集群休眠在休眠期间逐步释放集群中的节点，存储集群中负载（例如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是云智优本公司研发的一站式云原生优化平台，致力于帮助客户降低云原生集群和应用的成本，提升运营效率。它是一个基于数据驱动的智能决策平台，是基于云资源、应用以及用户、云厂商行为数据，利用深度学习、序列决策等算法，结合云、微服务、云原生等实践经验，构建的一套技术解决方案。此平台能够全面深入分析云资源、应用、用户行为及服务商数据及使用情况，预测未来资源需求，精准识别成本优化的机会，并提供个性化的优化建议。此外，平台采用全链路闭环的自动化优化机制，提高了优化效率，减少了人为错误，使客户能够轻松实现云原生集群及应用资源的自动化管理和优化，提升资源利用效率，显著降低云成本，提高运营效率。