1、云原生成本管理挑战和解决之道云原生成本管理挑战和解决之道刘建刘建2023年7月29日刘建刘建曾工作于腾讯、搜狗&IBM中国研究院，曾任腾讯专家工程师，Tech Leader&搜狗资深架构师。10+年基础架构领域相关经验。曾主导搜狗容器云平台研发&规模化落地，带领搜狗商业广告团队完成从单体、到微服务和云原生架构的迁移。曾担任QCon、全球运维技术大会等专业会议联席主席和专题出品人。云智优本 创始人嘉宾照片目录目录CONTENTS云原生成本管理面临的挑战1 精细化成本度量2 智能成本优化方案3 总结&展望4 0101云原生成本管理面云原生成本管理面临的挑战及问题临的挑战及问题云原生已成为未来主流云

2、原生已成为未来主流架构架构云原生是未来IT主流架构。Gartner估计：到2025年，超过95%的新数字工作负载将被部署在云原生平台。云原生（2018）=可弹性扩展的应用可弹性扩展的应用+松耦合系统松耦合系统+开源生态开源生态可弹性扩展的应用可弹性扩展的应用：有利于在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。松耦合系统松耦合系统：能构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，使工程师能够轻松地对系统作出频繁和可预测的重大变更。开源生态开源生态：致力于培育和维护厂商中立的开源生态系统

3、用户对云原生的成本顾虑越来越强烈用户对云原生的成本顾虑越来越强烈20212023迁移至 Kubernetes 平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过 20%。-2021 CNCF FinOps Kubernetes ReportCNCF 发布的云原生 2023 年趋势预测报告中，10 个热点趋势中有 4 个与 FinOps 相关，分别是 FinOps、GreenOps、GitOps 和削减成本。阿姆斯特丹2023年4月 KubeCon会议中，成本也是广为关注的话题之一。云原生应用成本经常超支，难以管理和优化云原生应用成本经常超支，难以管理和优化应

4、用成本无法精确度量，管理难资源池化&应用动态性导致应用和IT资源不再对应，传统成本度量方式不再适用，无法度量应用级别的成本，难以下钻分析云环境中资源价格动态变化，成本度量精确性不足应用成本容易超支，追踪难资源闲置&未及时释放配置不当/不合理缺乏应用级的实时预警机制，账单一般按月手工处理，实时性&自动化能力不足应用成本优化难缺乏工具，自研成本高云厂商提供的成本优化机制有限（多在节点维度），且不支持多云自研需要云原生平台专业能力，成本高、ROI低。多数企业不具备深度优化能力（例如资源超卖，离在线混部等）云原生成本云原生成本管理管理云原生成本管理是云财务管理（FinOps）在云原生场景下的应用。Fi

5、nOps 基金会建议采用迭代方法来管理云服务的可变成本，最佳实践包括三个环节：通知、优化和运营。通知：关注数据可视化和成本分配，可将资源精细和准确的分配到相应团队，便于后续优化。优化：基于使用率、价格等指标进行成本优化。运营：通过自动化流程等机制，使成本优化长期可持续。0202精细化成本度量精细化成本度量成本度量的成本度量的必要性必要性应用成本度量是成本优化的基础。洞察现状 优化基线“It you cant measure it,you cant manage it”-彼得.德鲁克容器特性导致成本度量变得容器特性导致成本度量变得复杂复杂静态-动态节点1节点2节点N.Pod1容器1容器2Pod2

6、容器1容器2Pod3容器1容器2Pod4容器1Pod5容器1应用1应用2集群成本成本公式公式成本(t1,t2)=单位价格资源1(t1,t2)用量资源1(t1,t2)+单位价格资源2(t1,t2)用量资源2(t1,t2)+.单位价格资源N(t1,t2)用量资源N(t1,t2)应用成本应用成本公式公式单位价格cpuPodi(t1,t2)用量cpuPodi(t1,t2)+单位价格gpuPodi(t1,t2)用量gpuPodi(t1,t2)+单位价格MemPodi(t1,t2)用量MemPodi(t1,t2)+.单位价格NetworkPodi(t1,t2)用量NetworkPodi(t1,t2)+单位

7、价格其他Podi(t1,t2)用量其他Podi(t1,t2)Podi(i in(1.n)(t1,t2)()应用成本(t1,t2)=价格价格价格（CPU、内存.）怎么计算？Serverless 基于Pod计算 集群（容器服务）Pod与节点的关系？Pod单位价格=节点单位价格 节点单位价格？自定义静态价格 基于云厂商提供了包年包月，按量付费，竞价实例，节省计划等机制计算动态价格。静态价格静态价格 vs vs 动态动态价格价格静态价格 用户/平台指定（简单，不反应真实价格，特别是在同一实例在不同计费模式下价格存在差异的时候）动态价格 基于订单、计费等信息推算（复杂，能尽可能贴近真实价格）存在基于实例

8、价格反推每核CPU、每GB内存单位时间价格的情况。用户操作对价格存在影响（计费方式转换、升级、节省计划、Spot实例等），价格与时间相关联，且存在滞后性。4-205-206-087-02实例：i1包月（1月）CPU：0.1元/核/小时4-20 5-20实例：i1包月（1月）CPU：0.101元/核/小时5-20 6-20实例：i1包月-按量付费价格：CPU：0.2元/核/小时时间：6-08 实例：i1包月-按量付费（节省计划）价格：CPU：0.13元/核/小时时间：7-02 （8-02）用量用量用量怎么计算？使用时间 使用量（对于CPU、内存等来说）使用次数（对于发送短信等服务来说）使用量（对

9、于按流量计费的网络来说）主流技术方案主流技术方案技术技术方案方案优缺点优缺点分析分析典型典型代表代表Prometheus-Only优点：能够利用Prometheus生态，拥有较多开箱即用的展示手段（例如：Grafana）。OpenCost缺点：1、性能较低，优化难度较高；2、成本计算失真：用户折扣、竞价实例、包年包月、节省计划等计费策略会导致应用成本和实际账单偏差较大。Prometheus-Hybrid优点：1、能尽可能贴近应用真实成本2、性能优化相对简单Wisecost缺点：1、难以完全利用Prometheus生态2、存在自定义展示方式WisecostWisecost成本成本计算技术计算技术

10、架构架构阿里云腾讯云AWS.价格度量/监控PrometheusThanos成本计算成本聚合/过滤/缓存成本API.Kubernetes集群Web管理控制台第三方数据集成WisecostWisecost用户用户界面界面0303智能成本优化智能成本优化主要技术主要技术维度维度主要技术主要技术说明说明应用资源推荐为用户设置应用资源提供指导，避免资源不足或过量。智能扩缩容基于多个指标（CPU、内存、流量等）进行扩缩容。节点节点超卖基于节点资源使用情况及已分配应用情况，提升节点可分配资源量，便于集群额外调度应用到该节点。节点费用优化基于节点资源使用情况调整节点规格或变更计费模式，降低费用。集群在离线混部

11、在线&离线业务对资源分时共享，提升利用率。集群扩缩容在节点水位过高或者过低时对集群进行整体扩容和缩容。智能选择合适费用的节点。跨云资源调度评估各个应用在不同云上的使用成本，协助客户将应用调度到低成本的云上，降低成本。资源推荐资源推荐目标：帮助用户设置资源的合理值，避免资源浪费或者资源不足（导致OOM）。资源推荐架构资源推荐PodMetrics APIPrometheusWebAlertPod资源推荐核心算法资源推荐核心算法基于半衰期指数直方图的资源推荐 半衰指数直方图是Goole Autopilot垂直伸缩关键算法之一 可对容器CPU、Memory等的百分位数（例如p95、p90）预测组距频数

12、17315资源推荐核心算法资源推荐核心算法组距（桶大小）指数直方图桶大小以指数速率逐步提升 首桶大小：BucketSize1 第n个桶大小：BucketSize1(1+ratio+ratio2+.+ratio(n1)=BucketSize1(ration1)/(ratio1)资源推荐核心算法资源推荐核心算法频数 半衰期半衰指数直方图增加了半衰期和样本“年龄”的参考时间针对CPU、Memory 资源使用等，若半衰期为24小时，即每过24小时，直方图中所有样本的权重（重要性）衰减为原来的一半。半衰期可保证较新的样本被赋予更高的权重，而较老的样本随时间推移权重逐步衰减。权重系数：CPU：权重是基于容

13、器 CPU Request 值确定当 CPU Request 增加时，对应的权重也随之增加。旧的样本数据权重将相对减少，有助快速应对 CPU 使用“尖刺”问题。Memory：一般固定为 1.0频数：权重系数 x 2(sampleTime-referenceTimestamp)/halfLife)资源资源推荐推荐计算推荐值基于半衰指数直方图的百分位数，比如p95,p90,p50，计算方式同直方图不同类型负载可使用不同的百分位数作为推荐值批处理作业：p50，批处理作业可以承受一定的 CPU 压制而正常运行在线服务：根据负载对延迟的敏感度分别为 p95或 p90推荐值微调基于安全边际系数、全局最小值

14、等进行微调，避免推荐值过小最终推荐值：max(p90(1+safetyMarginFraction),podMinCPUMillicores0.0011.0/N)其中：安全边际系数：safetyMarginFraction 全局最小值：podMinCPUMillicores Pod容器数：N节点超卖节点超卖目标 缓解集群中Pod无法正常调度问题 保证集群稳定性前提下，提升集群整体资源利用率节点超卖节点超卖原理原理容量可分配资源Pod资源请求总和使用量节点可重用资源使用量节点（超卖）容量可分配资源（超卖）可分配资源Pod资源请求总和可分配容量可分配容量可重用资源超卖率超卖率超卖率=可分配资源（超

15、卖）/可分配资源 =（可分配资源+Pod资源请求总和-使用量）/可分配资源预留部分资源超卖率=（可分配资源+Pod资源请求总和-使用量-预留比例*Pod资源请求总和）/可分配资源整体架构整体架构节点超卖PrometheusKubelet APIAPIServeretcd 节点CPU用量 节点Request总量kubelet PatchNodeStatus节点调整器 更新节点超卖率节点超卖节点超卖节点超卖组件：动态调整超卖比例：基于Promethous获取Node历史与当前负载情况，动态调整超卖比例，以控制节点资源利用率在合理水位，维持集群状态稳定。超卖管控策略：可设置超卖节点、单节点超卖上限、超卖步长等。节点调整器 PatchNodeStatus：基于Mutating Admission Controller机制，拦截并修改Kubelet的Node Patch，成比例的扩大可分配资源，增加节点可用资源，达到节点资源超卖效果。0404总结总结&展望展望总结总结用户痛点 应用成本无法精确度量，管理难 应用成本容易超支，追踪难 应用成本优化难成本精准度量 成本度量公式 动态价格成本优化 从应用、节点&集群三个维度优化 资源推荐&基于半衰指数直方图的推荐算法 节点超卖展望展望自动化能力的提升更先进的预测算法更便捷的产品和服务感谢聆听感谢聆听关注QECon公众号