大家好,我是马建仓。
目前,许多以“上云”为数字化转型路径的企业正面临着严重的云上超支问题。
数据库软件上市公司 Couchbase 曾发布一则报告称:一个典型的企业每年在云服务的支出超过 3300 万美元,这个数字比企业必要的支出还多出 35% ,因此导致许多企业损失超过 875 万美元,而这些钱本可以节省或花在其他地方。
尤其是伴随经济周期持续下行,正在进行数字化转型的企业比以往更加注重「精细化运营」。为了实现「降本增效」,企业决策者们开始对「上云」精打细算。新需求催化新概念,新概念应用新场景。为了让上云变得更加划算,一个新名词「FinOps」诞生了。
拆解来看,FinOps 由「Finance」&「DevOps」 组合而成,主要是开发与运维人员进行「云财务管理」或者「云成本优化」的技术解决方案。
从 FinOps 基金会的官方定义来看,FinOps 是一种不断发展的云财务管理学科,它是通过帮助工程、财务、技术和业务团队在数据驱动的支出决策上进行协作,使组织能够获得最大的业务价值。
(图源网络公开资料介绍截图)
简单说,FinOps 的核心是希望确保企业在云服务中花费的每一分钱都获得最大的价值,「不花一分冤枉钱」。
事实果真如此吗?今天,小马以在 Gitee 开源并获得 Gitee 官方推荐的 FinOps 开源项目——Crane 为例,和大家一起聊聊 FinOps 究竟能做些什么。
Crane(Cloud Resource Analytics and Economics) 是由腾讯推出的国内首个基于云原生技术的成本优化开源项目,它能够管理 Kubernetes 集群上的云端资源,令业务人员无需再为业务需要多少资源,自动扩缩容应该如何配置等问题而烦恼,它将会基于业务的时序变动数据给出最优解。
这个开源项目的设计理念源自 FinOps 概念,它是腾讯内部云资源优化流程方法和工具的系统性输出。据 Crane 项目作者表示, Crane 的核心能力构建与规划均与 FinOps 基金会提出的能力模型相契合。
项目作者: Crane
开源许可证: Apache-2.0
crane 主要控制平面
根据历史数据预测资源指标趋势
分析资源并产生相关建议
推荐 Pod 资源请求和自动缩放器
为节点创建预测预测器
用于水平缩放的高效 HPA
用于垂直缩放的高效 VPA
用于驱动扩展的度量服务器
确保基于异常检测的关键工作负载 SLO
该存储库为 Crane 平台定义了组件级 API
从云端 API 手机资源价格的财务顾问
一个 Kubernetes 调度器,可以根据实际节点负载调度 Pod
使用时间序列预测定义度量规范来预测 Kubernetes 资源
兼容原生 HorizontalPodAutoscaler,扩展自动缩放功能,方便管理应用程式的扩展
分析模组/分析工作负载并提出有关资源优化的建议 (包括 R2 資源的重新分配/R3 請求和副本的建議/高效率的Pod自動彈性化/成本最佳化)
Kubernetes 能够在同一个节点上启动多个 Pod,因此当存在资源(例如 CPU )消耗竞争时,部分用户应用程式可能会受到影响。而 Crane 允许使用者为 Pod 和QoSEnsurancePolicy 定义优先级,并检测中断确保高优先级 Pod 不受资源竞争的影响
Kubernetes 的原生调度器只能通过资源请求来调度 Pod,这样容易造成一系列负载不平衡的问题。相比 Crane-scheduler 可以从 Prometheus 获取 kubernetes 节点的实际负载,实现更高效的调度。
平台独立,通过一个 Helm 包将 Crane 安装至任意 Kubernetes 集群
用户可基于控制台查看成本分配,成本走势,并通过鼠标点击实现成本优化
Crane 可以全局扫描整体浪费情况,将隐藏浪费可视化的呈现出来,使运维人员免除拉取监控数据,编写查询脚本等重复性工作
EPA 支持可扩展的预测算法,以预测结果驱动横向和纵向弹性,确保业务能提前弹出来,彻底避免原生弹性能力未弹先死的尴尬
据项目作者表示,这个项目他们结合资源预测、智能弹性和全构混部能力,且在不牺牲稳定性的前提下,将集群峰值利用率提升到了 50 % 以上。更多操作细节与问题,欢迎大家点击下方阅读原文,前往仓库地址与作者一同探讨。
不过,新概念的诞生往往也伴随着质疑。不少人质疑 FinOps 这个新应用名词完全没有必要,毕竟国内企业都还没搞明白云原生、数字化转型,又来一个新概念都不过是云厂商们重新包装的新话术罢了。
那么初步了解与测试操作 Crane 后,你又是怎样看待这个新的技术解决方案呢?它究竟是云厂商们再造概念还是降本增效的一剂良药呢?
留言与评论(共有 0 条评论) “” |