美股 SaaS 巨头如何用 Karpenter 节省 1/4 的 EC2 成本

Freshworks 是一家纳斯达克上市的 SaaS 巨头，其在全球范围内拥有 73,000+ 客户，预计到2028年实现13亿美元的营收目标。本文由将介绍 Freshworks 为何以及如何采用 Karpenter 以减少资源浪费，降低 AWS 成本。

Kubernetes 宣称可以帮助我们轻松实现扩缩容，优化资源利用。而在生产环境中，我们却发现 vCPUs 经常只用了35%，内存只用了54%，大量资源闲置。如果你也存在类似的问题，那么非常有必要了解我们是如何利用数据和工程优化我们的系统。

在 Freshworks，我们的应用在 AWS EKS 上运行。为应对流量波动，我们在生产环境中最初采用了 Cluster Autoscaler (集群自动扩缩容器)，而在非生产环境中则使用第三方供应商的节点自动扩缩容解决方案。

Horizontal Pod Autoscaling（HPA）负责管理我们应用 Pod 的扩缩容。但我们对资源利用率低、Spot 实例使用率不足 2% 的现状并不满意，因此正在寻求更优的优化方案。

这启发我们开始探索 Karpenter。

01/ 我们需要新的解决方案

我们的工作负载种类繁多，不同应用需要使用不同的实例配置。以下是在同一集群中不同需求的一些示例：

1. ARM 工作负载：为节点提供 ARM64 指令集、保证的网络带宽和最新的实例生成。

2. 计算和成本优化分配：需要在特定可用区域之间的按需实例和 Spot 实例之间分配资源并处理计算密集型工作负载。

3. GPU 工作负载：AI 和机器学习工作负载需要专用 GPU 节点。

随着工作负载的多样化，现有节点自动扩展器的配置也变得越来越复杂，而且它还不自带处理 Spot 实例中断的功能。复杂的配置也导致了更长的 EKS 升级时间，增加维护成本。

因此，我们需要一个解决方案，它必须能同时满足以下要求：

• 支持多种实例类型；
• 实现无缝的节点整合和滚动更新；
• 在 EKS 升级时保持平稳运行。

最关键的是——必须够省钱！

评估维度

我们将从性能、可用性、可观察性和成本四个角度评估工具。

1. 性能 (Performance)：
   新方案必须能极快地启动新服务器，并且能轻松管理大规模集群。
   
   
2. 可用性 (Availability)：
   必须能保证业务不中断。无论是在系统升级时替换服务器，还是便宜的 Spot 实例被突然回收，都不能影响线上正在运行的应用。
   
   
3. 可观测性 (Observability)：
   必须能提供丰富的监控指标和日志，这是我们能有效发现问题、排查故障的关键。
   
   
4. 成本 (Cost)：
   最终，这个方案必须得省钱，具有很高的成本效益。

总结一句话：
这篇博客就是我们按照以上这四条“硬性标准”，来评估 Karpenter 到底合不合格的过程。

02/ Karpenter ——我们的选择！

Karpenter 是一款 Kubernetes 节点自动扩缩器，目前已支持阿里云、AWS 和 GCP。

与传统扩缩器不同，Karpenter 的工作机制是：

实时监测未被调度的 Pod，分析它们的调度约束（如节点选择器、亲和性等），并基于这些需求直接创建恰好满足要求的 EC2 实例，同时管理这些节点的生命周期。它支持所有 Kubernetes 标准的调度约束。

这种方式能够实现资源的最优利用，并避免资源过度配置。

Karpenter 节点配置

图片来源：https://karpenter.sh/karpenter-overview.png

验收标准与 Karpenter 的表现

性能

我们通过一系列负载测试评估 Karpenter 控制器的性能，主要测试场景包括：

1.对 EC2 Spot 实例中断的响应速度；
2.在万级 Pod 规模集群中的表现；
3.在百级节点规模集群中的表现。

测试结果显示，Karpenter 能在2秒内响应Spot实例中断事件并快速创建替代节点。

可用性

Karpenter 通过三种管控机制（配置漂移、资源利用率低、空节点）实现可调度的节点中断管理。这使得我们能够以可控的节奏进行节点轮转和终止，同时确保客户服务零影响。

可观测性

除节点部署指标外，Karpenter 还提供了资源整合、节点中断、终止等操作的监控指标。通过这些指标，可以实时掌握集群状态。具体指标和仪表盘配置将在"可观测性"章节详述。

成本效益

对 Karpenter 节点整合能力的分析明确显示出其降低基础设施成本的潜力。此外，此前使用的 Spot 实例服务会从节省金额中抽取分成，而采用开源 Karpenter 后，这部分成本直接降为零。

但 Karpenter 在企业级稳定性方面存在不足，例如无法保障单副本工作负载的高可用，会在替代节点尚未完全就绪的情况下，提前终止原有节点。

此外，Karpenter 在选择实例类型时，更偏好“把鸡蛋放在一个篮子里”，即选取同 AZ 的单一实例类型，倾向于将大量工作负载集中调度到少量大型节点上。当这些节点被回收时，会造成大规模的服务中断。

关于 Karpenter 稳定性的详细信息可点击此处阅读：
https://mp.weixin.qq.com/s/kIaoqo-A6F7KEFMFunyItw

Karpenter 的安装与配置

我们的云工程团队采用以下方式管理 EKS 集群和 Karpenter：

1.使用 Terraform 实现基础设施即代码（IaC）部署
2.通过 ArgoCD 实现持续交付

为确保高可用性，我们在每个集群的EKS节点组上均部署两个 Karpenter 副本。具体部署结构如下图所示：

Karpenter 部署架构

Karpenter 的配置主要围绕两个核心概念：NodePool 和 EC2NodeClass（均为自定义资源CRD）。通过它们来定义实例类型、可用区（AZ）及其他扩展参数。

为简化配置并确保公司内部统一性，我们为NodePool和EC2NodeClass提供了基础模板。这些模板覆盖了Freshworks大多数业务场景，包含预定义的优化配置，并通过一些限制规则实现成本管控。

在实际部署时，我们使用 Kustomize 工具为不同集群叠加特定配置（如集群名称、子网、安全组等），以补丁（patch）方式生成最终的部署清单。这种方案既保证了全公司 Kubernetes 集群的统一规范，又保留了适应不同需求的灵活性。

以下是我们的基础模板清单：

如上文所示的 NodePool 模板主要用于支持 AMD 实例系列，同时排除某些特定实例类型。我们通过层级化的清单目录结构实现不同维度的模块化管理。
上文展示的 NodePool 模板主要支持 AMD 实例系列，同时会排除成本较高的实例类型（例如：EBS 优化型、网络优化型或高核数规格）。该模板旨在实现计算资源需求与成本效率的最佳平衡。我们通过层级化的清单目录结构，支持不同维度的模块化配置管理。

发挥 Karpenter 性能的重要前提

在采用 Karpenter 前，我们已落实以下 Kubernetes 最佳实践，为自动扩缩提供安全高效的基础环境，这些是发挥 Karpenter 性能的关键前提：

1.高可用与冗余
通过部署多副本应用并结合 Pod 中断预算（PDBs），确保在节点中断期间应用仍保持可用。

2.调度与约束
精细管理拓扑分布约束，并为应用配置准确的资源请求和限制。

3.优雅终止处理
通过处理 SIGTERM 信号、配置 preStop 钩子和 terminationGracePeriodSeconds 参数，实现 Pod 的可控优雅终止。

4.扩缩与容量管理
优化水平 Pod 扩缩（HPA），并配置节点预热池以加速 Pod 扩容。

5.工作负载分级管理
通过节点亲和性（nodeAffinity）、污点（taints）和容忍度（tolerations）对工作负载分类，确保其调度到合适的节点。

Karpenter 推荐配置

以下是为实现最优资源调配的推荐实践：

1.实例类型选择
在配置中通过 node.kubernetes.io/instance-type标签排除不需要的实例类型，避免资源浪费，优化成本。

2.慎用 AWS 节点终止处理器（NTH）
Karpenter 目前不支持基于 Spot 重新平衡（Rebalance）建议的节点排空和终止。如需此功能，需单独安装 NTH，但通常不建议对 Spot 重新平衡建议做出响应。

3.按团队划分 NodePool
当多团队共享集群且对节点有不同需求时，应为每个团队创建独立的 NodePool，避免资源冲突。

4.确保 NodePool 调度一致性
为 NodePool 配置互斥规则或权重值。若多个 NodePool 同时匹配 Pod 需求，未加权将导致随机调度，造成实例类型选择不可控。

5.避免过度限制实例类型
不要过度约束 Karpenter 可选的实例类型，否则可能影响其成本优化能力甚至导致调度失败。

6.成本监控与限制
启用自动扩缩时，设置费用告警并在 NodePool 中定义资源上限，防止意外开销。

7.准确配置资源请求
为所有工作负载设置准确的资源请求值。Karpenter 依此调配节点，不准确的值会导致节点分配效率低下。

8.节点中断管理
Karpenter 支持主动管理节点中断，中断可能由以下三种情况触发：
a. 配置漂移
b. 资源整合
c. 节点健康问题

通过中断预算（Disruption Budget）可控制节点终止速率，保障服务可用性。我们在 Freshworks 的应用场景包括：
a. 空节点整合
b. 受控的配置漂移节点轮转
c. 低流量时段整合低利用率节点

我们的中断预算配置如下（共5条规则，按利用率和时间段控制节点中断）：

1.全天允许整合所有空节点
2.禁止配置漂移导致的整合（仅当配置在非生产环境充分验证后手动启用）
3.工作日凌晨（00:00-06:00）：允许每次整合1个低利用率节点
4.周末低流量时段：仅允许每次整合1个低利用率节点（其他时段不执行）

节点符合整合条件后延迟10分钟执行，避免过早中断。同时配置20分钟优雅终止期，确保 Pod 安全驱逐。

disruption:budgets:## Empty Node Consolidation (allow empty node consolidation all the time)- nodes: 100%reasons:- Empty## Drifted Node Restriction (no nodes to be disrupted if there is configuration drift identified)- nodes: "0"reasons:- Drifted## Underutilized Node Consolidation (Weekday Daytime, Low Traffic Period)- duration: 6hnodes: "1"reasons:- Underutilizedschedule: 0 12 * * 1-4## Underutilized Node Consolidation (Weekend, Low Traffic Period)- duration: 52hnodes: "1"reasons:- Underutilizedschedule: 0 12 * * 5## Prevent Underutilized Node Disruption (Peak Traffic Period)- duration: 18hnodes: "0"reasons:- Underutilizedschedule: 0 18 * * 1-4## Wait 10m before consolidating. Pods with large images may take time to start, so this prevents premature disruption.consolidateAfter: 10mconsolidationPolicy: WhenEmptyOrUnderutilized## Wait 20 minutes for Pod Disruption Budgets (PDBs) to be honored before forcefully evicting pods.terminationGracePeriod: 20m 

通过遵循这些最佳实践，我们成功优化了 Karpenter 的部署，提升了资源利用率，并显著增强了 Kubernetes 集群的可靠性。

Karpenter 的可观测性

Karpenter 提供日志和 Prometheus 指标，具备完善的可观测能力（具体指标详见官方文档）。我们基于这些数据为不同角色定制了专属监控看板：

1. 开发者看板
定位：为开发者提供应用粒度的可视化监控
功能：展示特定应用的 Pod 在节点间的分布情况，帮助开发者排查调度问题并优化部署策略
获取方式：可通过 karpenter-dashboard-developer 导入看板

2. 集群运维看板
定位：为运维人员提供集群级扩缩与资源效率洞察
功能：全景展示 Karpenter 活动，包括节点供给、中断事件、NodePool 限额使用率及集群健康状态，助力运维保障稳定性、优化成本与资源利用
获取方式：可通过 karpenter-dashboard-cluster-operator 导入看板

看板功能示例

资源供给总览：

从容量类型、可用区分布、实例类型、NodePool 等维度展示节点分布，并统计节点声明创建/中断/终止数量及错误信息

Karpenter 控制器健康状态：

下图展示了控制器在一段时间内的资源定义和使用情况统计。

节点状态与节点活动：

下图展示了节点活动的历史记录及 AWS API 接口的延迟变化趋势。

告警配置

Karpenter 是我们 Kubernetes 生态的核心组件，保障其稳定性和可靠性至关重要。为此我们配置了一套完整的告警规则，并根据问题的影响程度进行了分级。

这些告警能及时通知 Karpenter 的运行异常，确保我们快速响应并避免服务中断。以下是已配置的告警列表：

严重级别 / P0

若未立即处理以下告警，将导致服务中断。

高影响级别 / P1

若未及时处理以下告警，可能在数分钟至数小时内导致服务中断。

中低影响级别 / P2

以下为低影响告警，若持续存在超过2-3小时则需关注。

其他监控措施

我们还实施了覆盖 Kubernetes 全栈的基础监控与告警，包括部署（Deployment）、Pod 及容器级别的指标追踪。

Karpenter 带来的收益

采用 Karpenter 作为 Kubernetes 扩缩器后，Freshworks 获得了以下显著收益：

1.成本节约

此前依赖第三方工具实现 Spot 实例供给，需支付高达节省金额20%的服务费。采用 Karpenter 后立即省去这笔开支。通过工作负载整合实现了额外成本优化（如下文案例）。

2.Spot 实例采用率提升

Spot 实例使用率从2%提升至8%，降低了对预留实例/节省计划的依赖。

3.资源分配优化

Karpenter 根据应用 Pod 的精确需求调配节点，显著减少了资源过度配置。

目前我们仅迁移了部分工作负载到 Karpenter，随着使用范围的扩大，预计将实现更大幅度的成本节约。完整节约数据仍在计算中，但早期结果已非常乐观。

03/ Karpenter的典型实践案例

以下是 Karpenter 带来实际效益的具体场景（截图来自 AWS 配置，成本与使用数据已脱敏）：

案例一：

● 通过实例规格优化实现成本降低

某集群原计划使用24台机器，但内存和 vCPU 利用率普遍偏低。 Karpenter 自动识别该情况并推荐了更匹配集群实际使用规律的实例类型。

原配置方案

为集群配置了24台 m5.2xlarge 规格实例。

总供给容量

最终配置总量约为500个 CPU 核心与1.4 TB 内存。

未分配资源量

在已配置的资源中，约有167个 CPU 核心和 1.09TB 内存处于闲置状态。

Karpenter 节点配置优化

采用 Karpenter 后，控制器自动识别到资源浪费问题，并将实例类型从原来的 M 系列切换为更合适的 C 系列。优化后的资源利用率变化如下图所示。

成本降低成效

该方案使集群成本下降超50%，同时减少了 EC2 实例的使用数量。

案例二：

● 通过采用 Spot 实例实现成本降低

在某个集群中，Karpenter 凭借其原生的中断处理能力，使我们能够顺利采用 Spot 实例。这一改进为该集群降低了33%的成本。

04/ Karpenter 适用边界在哪里？

与可预测型 StatefulSets 的配合

Freshworks 中少数平台服务组件以 Kubernetes StatefulSets 形式运行。

对于这类负载稳定且可预测的工作负载，Karpenter 并不能带来显著收益。

典型场景包括：

• 内存使用可预测的缓存层
（如 Redis/Memcached）：数据集规模和访问模式相对固定，直接选择内存容量匹配的实例类型即可，Karpenter 动态配置特定内存节点的能力并非核心需求。

• 负载稳定的数据库集群
（如 PostgreSQL/MySQL）：事务率和数据增长量高度可预测，通过历史数据分析即可确定固定规格的实例类型，足以平稳支撑全时段业务负载。

细节优势

不过 Karpenter 对 StatefulSets 仍有一些细节优势：

尤其在 EKS 原地升级时，可通过节点滚动更新实现服务最小中断——其节点中断管理功能支持按计划可控的节点轮转。

05/ 总结

通过精细配置 Kubernetes 特性（包括 Pod中断预算、水平扩缩、拓扑分布约束、节点亲和/反亲和以及污点容忍机制），我们最终实现了：

• EC2 费用降低 15-25%；
• Spot 实例采用率提升 6%。

在保障高效且高可用扩缩的同时，彻底避免了资源浪费与服务中断。

一起来体验Karpenter在云成本优化上的魅力吧！