对于企业来说,理解和应用云原生和 FinOps 是实现云计算优势的关键。通过采用云原生和 FinOps 方法,企业可以更好地管理云计算资源,提高效率和效益,实现更好的业务成果。
云原生时代的成本治理
FinOps 的核心阶段主要包括:
成本洞察(Inform):提供多维度的成本和资源数据可视化,趋势预测和云原生容器场景的成本分摊。
成本优化(Optimize):着力于提供可靠便利的智能优化方案,降低用户实施成本控制的门槛。
成本运营(Operate):从组织,意识以及流程上建设一套系统的成本运营系统。
成本洞察
洞察的本质在于使用户对自身的使用量和费用数据有全面的掌握。因此,我们需要对各类资源的使用率和用量等指标进行持续追踪,并采集相关云成本数据。这些数据将被用于实现可视化和成本分摊的需求。
在追踪资源数据时,一个关键点在于持续采集资源用量数据。在获取了这些数据后,我们可以对其进行一定的处理,并最终展示在看板上。
目前,字节跳动已经构建了一套基于 Prometheus 和 Grafana 的监控解决方案,用于采集资源的数据。简单来说,我们利用一些数据采集组件在用户的集群中持续采集集群数据,然后通过平台提供的云端托管 Prometheus 定期拉取这些指标数据,最后将其展示在通用的看板上。架构图如下所示:
基于这些数据,我们可以在看板上多维度展示资源使用情况,帮助用户了解业务的集群资源分配和消耗走势等,实际的图表包括集群维度的 CPU 核数分配趋势图、容器级别的 CPU/MEM/GPU 用量趋势图,以及基于命名空间/Pod 的资源使用图等。
这些用量大盘对于业务研发来说至关重要,用户可以从这里分析资源分配、利用率、实例类型是否合理,并且做出相应的调整。
对于消费数据,我们划分了类型。一个是实际消费数据,这个数据来自于账单中心,是最真实的消费数据。与资源用量可视化的视角不同的是,这些数据对于关心实际消费的角色是很重要的,例如 IT 主管、采购角色等,他们往往需要查看整体消费情况,识别消费隐患,支出合理性等。应用的场景包括查看集群消费趋势,消费分布,多周期的观测等。
成本分摊
在云原生场景下,由于 Pod 会在计算资源中漂移,资源和 Pod 的计费单元不是一对一关系,相同的 Pod 在不同的资源价格估算有所不同。而且资源和 Pod 的生命周期与计费周期不同。基于场景,重 CPU 和重 MEM 的 Pod 估算费用模型也应该有相应的调整。
因此,我们基于持续采集的数据去按比例进行估算。简单来说,对于 pod 成本,我们基于 pod request 和 node capacity 来算出 Pod 所占资源比例,基于比例和 node 单价,我们可以算出一段时间内 Pod 的用量:
其中 node price 为节点刊例价,pod request 为 pod 资源请求量,node capacity 为节点容量。
成本优化
针对不同类型的应用和不同的业务架构,企业可以选择不同的成本优化策略。企业进行成本优化的主要目的是减少资源的浪费,提高资源的利用率。
经过分析,以下为常见的导致资源使用浪费高企、利用率低的原因:
1. 资源配置不当
Kubernetes 对 Pod 提供了资源需求 (Resource Request) 字段,该字段用于预留容器所需的 CPU 和内存资源。如何设置资源需求是一个难题,目前往往基于人工经验来填写,用户通常会将 Request 设置得远高于其实际所需的资源使用量,从而保证服务的可靠性,而这种基于人工经验的设置会导致资源在非高峰期的大部分时间被浪费,从而导致资源使用率低下,节点装箱率低等问题。
2. 业务使用量具有明显的波峰波谷
在线业务流量通常有较明显的波动周期,且波谷时间常大于波峰时间,波谷时期的资源有较多闲置, 这也成为了资源利用率较低的另一主因。举个例子,社交平台的波峰往往出现在非生产活动时间,而游戏业务在周末会出现波峰。在这个场景下,同一业务在不同的时间段对 CPU 资源的用量不同,若用户以固定资源需求申请 CPU 资源,当业务负载较低时,CPU 资源利用率就会很低。
3. 资源需求基于业务不一样
根据服务的特性和业务目的计算业务可分为在线业务和离线业务两类。一般来说在线业务通常白天负载会比较高,且对时延要求也比较高,必须优先调度和运行;而离线的计算型业务对运行时段和时延要求一般来说都相对低,可以在在线业务负载波谷时段运行。在这种场景下,如果我们对在线业务和离线业务进行混部,就可以用离线作业填补在线作业的负载低谷时段,从而提高整体的资源利用率。
Kubernetes 中可用的成本优化的手段非常多。具体来说,针对上文提到的造成利用率低下的现象的原因,我们可以使用对应的优化手段:
智能资源推荐:可以用于解决资源配置不当的问题。通过分析历史数据,推荐合理的 request 数值,以及副本数。其推荐值可以对 VPA 等对应用进行动态扩缩容带来指导意义。
多种弹性调度策略:可以有效缓解业务使用量具有明显的波峰波谷的问题。包括 HPA 水平伸缩,VPA 垂直伸缩、AHPA 智能伸缩等动态调度策略。其配合智能推荐使用效果更佳。
付费策略推荐:直接控制费用本身。简单来说就是根据用户的使用去做不同付费策略的推荐,像包年包月,按量付费,spot 实例推荐等。
混部能力:混部的理念主要在于将集群各个时段的空闲资源利用起来,如在离线混部。这个可以比较好地解决不同业务对资源的需求不一样的问题。
闲置资源扫描,通过定期巡检或者主动诊断的方式,识别出未被使用或者利用率非常低的资源,并提示出来以做一下步处理
由于篇幅问题,本文将简单介绍其中一种优化手段-规格推荐。
规格推荐是智能资源推荐的手段之一,其重点在于基于业务实际使用情况,结合算法,给出更加合理的 request 推荐值。同时,其支持一定的资源冗余度,以应对流量突发高峰。
目前用户一般基于经验去设置这个 CPU/MEM request,这个人工经验很可能就会导致配置值过大或者过小。过大的话资源浪费严重,过小又无法保障业务稳定性。而使用智能推荐,得到合理的配置值,则能消除这种基于经验的人工配置的局限性。另外就是配置值过大的话,资源利用率自然会低下。因为大部分时间我们配置的 request 值都远远大于 CPU 实际用量。也会影响到节点装箱率。
推荐算法
其实一种常见的推荐算法是依赖于历史用量的指数平滑滑动窗口算法。历史用量数据是容器资源用量数据,都是现成的,因为在成本洞察的时候我们已经提供了一套持续采集集群用量数据的方案。
我们选用了指数直方图,这事一种相对于相对于线性直方图线性分桶方式的改进,它的桶大小呈现指数级增长,目的在于捕捉到数据差异大的情况,主要就是因为这些历史用量数据的粒度往往是分钟级甚至秒级的,并且可能差异巨大。指数直方图相比线性直方图能更好地数据的集中趋势和离散程度,也能更好地适应广泛的数据范围。另外我们增加了权重因子,为了将样本数据的时效性体现在直方图中,我们通过半衰期对样本数据的权重因子进行衰减。这样新的样本数据对模型的影响会大于旧的样本数据。旧的数据对结果的影响会随着时间的流逝越来越小。
成本运营
第一步是明确成本治理目标。由于 FinOps 聚合了不同的角色,不同角色所看重的方向都不太一样。这是明确治理目标是首当其冲的,在于各个角色能达成共识,向同一个目标前进。那这里就包含了预算管理。有了预算管理,团队知道和理想的差距有多少,在于哪。例如对于预算,我们可以按一定原则分摊到各个层级团队。基于预算,我们可以制定优化目标。
第二步是完善工具和自动化。这其中包含了平台和工具的建设。比如,通过监控系统提供风险预警的能力,实现调度优化的一系列功能,以及针对不同环境的资源治理等。
未来规划
扫码咨询
火山引擎云原生团队主要负责火山引擎公有云及私有化场景中 PaaS 类产品体系的构建,结合字节跳动多年的云原生技术栈经验和最佳实践沉淀,帮助企业加速数字化转型和创新。产品包括容器服务、镜像仓库、分布式云原生平台、函数服务、服务网格、持续交付、可观测服务等。
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...