Prometheus v2.47+Karpenter:轻松月省4万云成本
本文由 DevSecOps 专家 Tanat Lokejaroenlarb 撰写,将介绍 Adevinta 团队是如何发现隐藏的降本机会,最终通过一行代码的更改,让他们每月节省5000美元的开支。
一直以来,如何降低成本都是所有关注基础设施的平台团队反复讨论的话题,Adevinta 团队也不例外。关于 Adevinta 的降本实践,此前有详细介绍:
在寻找成本优化机会的过程中,我们发现了一个极具价值又容易实现的方法——它帮助我们每月减少了 5000 欧元的支出,而我们所做的,仅仅是修改了一行代码。
我们是如何发现潜在的节省机会的?
在直接给大家上“干货”之前,我想先聊聊我们是怎么发现这些省钱机会的。虽然我打算之后单独写一篇文章详细分享整个过程,但这次咱们就挑重点说,只聊和这次优化相关的内容。
我们用来识别优化机会的一个关键指标是 “资源过度配置”(over-provisioned resources) 。
很多开源项目都致力于提升对集群内部资源使用情况的可见性,比如 OpenCost:
https://github.com/opencost/opencost
不过,我们早就通过 cAdvisor 和 kube-state metrics 收集了 Kubernetes 容器的资源请求(request)、使用情况(usage) 和限制(limit) 等指标。这些数据让我们可以轻松“看到”集群中哪些资源被过度分配了。
举个例子,我们只需要计算 Pod 的实际使用量减去其资源请求量这一差值,就能算出整个集群里有多少资源是被“闲置”的,从而识别潜在的优化空间。
有了这个能力,我们就能轻松找出那些“占着资源不干活”的服务,然后根据资源浪费的程度,给这些服务进行优先级排序,该优化的优化,该调整的调整!
通过指标可视化,清晰展示过度分配的资源情况
轻松实现的优化
在定义并应用这些指标后,我们的资源使用仪表板重点标出了Prometheus 应用。Prometheus 在我们的集群中被广泛使用,用于存储和聚合系统及应用程序的指标。由于我们运营着30 多个不同规模的 Kubernetes 集群,因此 Prometheus 资源过度配置的情况并不令人意外。
在如此多样化的环境中进行精准的弹性扩缩容配置是一项不小的挑战。我们的 Prometheus 实例在资源需求上差异巨大,从最小的集群保留约 16 GB 数据到最大的集群消耗超过 100 GB 数据不等。
为了解决资源过度配置的问题,我们尝试了多种优化策略:
-
分片实例(Sharding Instances):
根据不同的域对 Prometheus 实例进行分片,以便更均衡地配置负载。这种方法虽然有效,但大大增加了系统的内部复杂性。 -
缩短数据保留时间(Reducing Retention Periods):
通过减少数据保留时长降低整体存储需求。
Prometheus 的内存使用模式很难制定一种通用适配的配置方案
尽管我们做出了诸多努力,但想要一个实现平衡的自动扩缩容配置依然没那么简单。
我们引入了 Vertical Pod Autoscaler(VPA)来帮忙,但指标数据的动态变化又给我们挖了不少坑。例如,在指标基数快速激增的情况下(如 Pod 频繁重启),Prometheus 的内存使用会突然飙升。
在这种情况下,VPA 往往无法及时扩容,导致内存溢出(Out of Memory)。如果 Prometheus 内存占用飙升得太快,它甚至可能在 VPA 配置额外资源之前,就已经被 OOM Kill了。
此外,我们的架构包含两个 Prometheus Pod,每个 Pod 都会接收所有的监控指标。如果 VPA 开始扩容其中一个 Pod,它从 EBS 卷读取数据并恢复到健康状态的这个过程至少要花 10 分钟。
而在这十分钟里,如果另一个 Prometheus Pod 的内存也顶不住了,那这两个 Pod 就可能同时被 OOM 杀死进程。
这种“双杀”局面,可能会导致严重的数据缺失和监控指标收集中断。
问题如何迎刃而解?
尽管我们已经很努力地优化资源使用,但过度配置(over-provisioning) 依然是必不可少的安全保障。不过,最近我们发现了一个很棒的解决方案,可以大幅降低资源消耗!
我们的团队成员在 Prometheus 中发现了一个有趣的改动:
https://thenewstack.io/30-pull-requests-later-prometheus-memory-use-is-cut-in-half
文章指出,在新版 Prometheus中,内存占用降低了 50%!
这是真的吗?只是升级了个版本?
不,别以为这只是个平平无奇的版本升级!这个更新对我们来说是个颠覆性的改变。
升级到最新的 Prometheus 版本后,我们观察到整个集群的内存使用量减少了 30% 到 50%。这一改进是有据可查的,并且与 Prometheus 社区解释的变化一致。
从黄色线能清晰看出了内存使用减少了一半
实际效果
通过这次调整,我们大幅降低了 VPA 配置中的资源请求量。这一优化使我们成功减少了过度配置的资源,还保持了性能和稳定性。
从数据上可以看出,我们此前为 Prometheus 过度配置了超过 1.4TB 的内存——这可不是个小数目!
最初,Prometheus 过度分配的内存接近 1.5TB
除此之外,我们还使用了另一个重要指标来衡量资源占用情况——即团队运营集群的组件所消耗的资源与客户工作负载资源之间的比率。
过度分配的内存减少量超过 1TB
所有组件的内存占用减少了 3%
经过全面部署,内存请求减少了超过 1TB ,整体内存占用减少了约 3%。
部署过程
起初,我们在 EKS 的 NodeGroup上运行 Prometheus,但下述问题阻碍了我们所需要进行的更改:
NodeGroup 的限制:
- 实例类型限制:
NodeGroup 不支持不同的实例类型,可以指定辅助实例类型,但必须与主实例大小相同 - 资源缩减的额外工作:
即使我们减少了资源请求,依然需要将Pod手动迁移到新的 NodeGroup,并重新计算合适的实例类型
因此,我们决定将 Prometheus 迁移到 Karpenter 进行调度。
- 第一步: 将 Prometheus 迁移到 Karpenter,并沿用之前的过度配置。
- 第二步: 更新版本后,无需人工干预,这些工作负载就被自动重新调度到更合适的实例类型。
实例类型自动调整,以匹配新的资源请求
节省成本
减少 1TB 内存所带来的成本节省取决于所使用的实例类型。不同的 AWS 实例价格各不相同,因此节省的金额也会有所变化。为了给出一个大致估算,我们可以参考不同实例类型的内存成本。
例如 r5 系列实例,它是我们主要用于 Prometheus 的内存优化型实例:
我们的大部分 Prometheus 节点都在内存优化型实例上运行
成本计算
在 r5 系列实例中,每 GB 内存的成本大约为 $0.007875/小时。
如果您想随时掌握不同实例类型的 Spot 最新价格 欢迎访问 Spot Insights:spot.cloudpilot.ai
1TB(1024GB)内存的成本计算:
- 每小时成本:
1024 GB × $0.007875/GB = $8.064/小时 - 每月成本(假设全天候运行):
$8.064 × 24 小时 × 30 天 = $5,814.72/月
最终结论:
在 AWS EC2 的 r5 实例系列中,内存使用减少 1TB,每月大约可节省 $5,814.72。
NOTE:此计算基于公开定价,实际成本可能因折扣、预留实例或 Spot 实例等因素有所不同,仅供参考。
总结
正如你所见,新的 Prometheus 版本带来的内存优化以及 Karpenter 为丰富的实例类型提供更灵活的调度,让我们的资源利用更高效、更精准。
当然,此类问题会随着时间的推移、业务规模的调整,会再次出现。因此,优化成本是一项持续性的工作和文化,我们会密切关注基础设施的资源使用情况,并发现一切降本的机会。
希望这篇分享能带给你一些成本优化的新思路,并从中获得一些启发!
欢迎关注「Cloud Pilot AI」,我们将持续更新各家企业进行成本优化的“骚操作”。
推荐阅读
弹性工具选Karpenter还是Cluster Autoscaler?看这篇就知道啦!
posted on 2025-02-19 10:58 CloudPilotAI 阅读(17) 评论(0) 编辑 收藏 举报
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)