降本之源云原生成本管理白皮书

12 一、背景介绍 5二、云原生成本管理模型 62.1资源利用率现状 72.2云原生成本管理模型 122.2.1成本洞察 122.2.2成本优化 132.2.3成本运营 13三、云原生资源管理能力成熟度模型 153.1云原生成熟度模型(CNMM)等级一 153.1.1应用架构&服务治理 153.1.2应用弹性 153.1.3编排&调度 153.1.4集群弹性 163.2云原生成熟度模型(CNMM)等级二 163.2.1应用架构&服务治理 163.2.2应用弹性 163.2.3编排&调度 163.2.4集群弹性 163.3云原生成熟度模型(CNMM)等级三 163.3.1应用架构&服务治理 163.3.2应用弹性 173.3.3编排&调度 173.3.4集群弹性 173.4云原生成熟度模型(CNMM)等级四 173.4.1应用架构&服务治理 173.4.2应用弹性 173.4.3编排&调度 173.4.4集群弹性 18四、最佳实践 194.1成本洞察 194.1.1成本采集及资源追踪 194.1.2资源使用可视化 194.1.3费用可视化 194.1.4成本分配 204.1.5账单管理 224.2成本优化 234.2.1设置合理的资源请求和限制 2334.2.2动态调度 264.2.3多维度弹性 284.2.4在离线混部 324.2.4GPU共享 354.2.5优化矩阵 374.3成本运营 384.3.1建立成本优化团队 394.3.2推动成本意识文化 394.3.3数据驱动成本优化 394.3.4在流程中考虑成本 404.3.5量化成本优化交付的业务价值 40五、总结 42六、企业客户降本案例 446.1作业帮 446.1.1当前作业帮降本增效存在的问题 446.1.2解决方案 446.1.3实践价值 456.2QQ音乐 456.2.1QQ音乐降本增效核心痛点 456.2.2优化方案 466.2.3应用效果 466.2.4展望未来 466.3B站 476.3.1B站降本增效核心痛点 476.3.2基本方案 476.3.3典型场景 476.4更美 476.4.1云原生是什么 486.4.2云原生与更美降本增效目标的关系 486.4.3使用云原生技术降低成本最佳实践 486.5销售易 506.5.1云原生是什么 506.5.2云原生与销售易降本增效目标的关系 506.5.3使用云原生技术降低成本最佳实践 506.5.4展望未来 516.6云集 516.6.1云原生是什么 526.6.2云原生与云集增效目标的关系 526.6.3使用云原生技术降低成本最佳实践 526.6.4展望未来 544云原生使组织能够在现代云环境(例如公共云、私有云和混合云)中构建和运行可扩展的作出反应。计费和按使用付费模型等功能，云原生计算可帮助组织摆应用程序的一个巧妙之处在于，云原生应用程序使开发人员可以更并制降低开发过程的复杂性:开发人员可以将更多时间花在项目的细节上，而不是构建通用框模块化设计：模块化设计使外观和功能的标准化更容易。拥有多个应用程序或服务的公司具有巨大的业务影响潜力——能够快速有效地将想法转化G抓住云原生变得特别重要,你准备好了以下了没:于功能的结构，围绕特定的服务或能力组的架构。云原生意味着使用微服务和反应速度更快的架构类型。上云原生开发的步伐。业务应该能够以与技术人员相同的速度足够大多数云原生关键基础设施都是开源的，例如Kubernetes，你知道如何参与开源社区以了eithChanCNCF总监兼Linux基金会亚太区策略规划总监、腾讯云TVP5增长的重要引擎，云计算从部分企业数字化转型的载体，转变为了构，云原生具备更灵活的资源管理、更敏捷的应用迭代、更高效的模业务保障能力，云原生带动技术架构、应用效能、云化效益的全方位提深入应用，金融、政府、制造、电信、医疗等行业的云原生用户占比较2020变，云原生技术给企业带来的价值中，提升资源利用率节约成本连续两简化运维系统以及便于现有系统的功能扩展。云原生已成为企业基于度不断加深，云上支出浪费严重，云原生平台自身的成本治理成为企业按需是云原生的资源利用优势，但如果资源配置策略设置不合理可能会导云、云数智融合等模式在帮助提升工作效率、实现应用灵活部署的同时也的新挑战。因此，企业在应用云原生架构之后，需要考虑如何管理、优化生成位、路径难选择、成效难持续三大挑战，资源成本优化是云原生降本的关实其持久性。资源成本优化从基于账单优化的成本可视、基于资源优化式优化的成本运营从三方面帮助降低云原生平台成本。》将基于中国信息通信研究院与腾讯云对行业发展趋势和企业客化径，结合行业优秀案例，帮助企业改善用云成本充分发挥云原生的效能和6成本管理模型一种思想，是技术、企业管理方法的集合，云原生追求、混合云等动态环境中构建和运行规模化应用的能力，追求的是业能力。Kubernetes云原生技术栈的核心，是众多云原生项目的粘合剂。Kubernetes遵循声明管控的对象都抽象成标准API，并通过多种控制器完成云原生平台的高度自如云用户可以通过定义Pod对象，并指定需要运行的容器镜像，以及容器所需的CPU存等计算资源。该对象被提交至Kubernetes以后，Kubernetes会依据用户请求运行并按需求确保该应用进程的资源配额。量，并通过自动化横向或纵向扩缩容能力，及时调整应用的副本数量以及时回收空闲资源，提升资源使用率。生技术栈的核心目标之一，资源利用率的提升意味着以更少的计算用实例，极大的降低云用户的资源开销，也契合国家节能减排的政策号72.1资源利用率现状节省成本9%率%系统上的功能扩展02%从2019年的72%增长到了82%，越来越多的企业在云上使用基础设施资源、通过s8最主要原因。在Kubernetes集群中，资源利用率体现为运行的所有Pod消耗的资源与资源总量的比率，据麦肯锡早期报告，全球服务器资源利用率不到6%，资源利用腾讯云对1000多家云客户进行了资源利用情况分析，抽样超过一万42%的节点点资源利用率低于10%资源利用率低于20%节点资源利用率在20%-30%9极大的浪费。KubernetesPod的资源需求(ResourceRequest)字段用于管理容器对CPU和内存资源需求造成下容器的资源预留(Request)和实际使用量(CPU_Usage)关系图：资源预留远大于实际使用值所对应的资源不能被其他负载使用，因此Request设置过大势必会造成较资源利用率较低的另一主因。例如公交系统通常在白天负载增加，夜晚服务的特性和业务目的可分为在线业务和离线业务两类：在线业务通求较高，必须优先调度和运行；而离线的计算型业务通常对运行以在在线业务负载波谷时段运行。此外，有些业务属于计算密集在进而提升资源利用率。将需求不同资源的作业有效的部署在相同节源，提升总体资源利用率。Kubernetes个开放式平台，鼓励资源共享，但同时缺少有效的成本观测和分配机以被动态调度在同一个计算节点上，简单将底层云资源与应用一一映传统手段已经失效。如何发现和观测成本管理上的问题，比如针对资源闲置、应用闲置、以及前述资源利用率衡部分客户做完成本优化项目后，短期内确实节省了很多成本。但是随着时间推移，业务的统设计时，缺乏对成本的考量，这可能使业务上线后的资源2.2云原生成本管理模型：源追踪、成本可视化、成本分配和账单管理成本优化：提供可靠、便利、智能的优化方案成本运营：从组织、文化、流程等方面建设成本运营体系2.2.1成本洞察集及资源追踪云环境下的资源使用和成本支出是比较复杂的，团队或组织需要通过一定的工具或方案对各种产品进行定义、定价、计费及统计，并对各类资源的使用率、使用量等指标进行持续追踪，能帮助团队尽可能多地搜集到云成本情况，为后边成本可视化以及成本分配提供数据基础。视化和成本分配Kubernetes的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，对于任何组织、部门及职能团队，基于多维度(如云产品、环境、业务线)的资源和成本的可视化分析，能够帮助团队有效地建立起相应的问责机制，并根据获取到的实时数据快速制定优化方案及措施。账单管理云账单的繁冗性和复杂性给用户带来非常大的不便，团队或组织需要对账单进行统一高效的管理，一是根据实际的业务需求，将账单按组织、部门、项目业务维度，年、月周期维度等进行详细化的拆分。二是将各类账单进行统一分析，包括过去一段时间的使用情况、未来使用趋势分析、各部门成本使用情况等方面，并给出合理的规划及更改建议。三是将分析后账单情况按业务部门、周期、自定义等维度定期推送给团队，方便团队及时得到相应的账单。2.2.2成本优化提供可靠、便利、智能的优化方案基于成本可视化和成本分配等手段，有了数据作为度量依据，团队能够围绕其业务目标及业务场景制定对应的成本优化目标。针对云原生场景，云上资源成本优化不仅仅是对云资源规格、数量的调整，也包含了对业务的架构优化、以及通过弹性能力和资源混部等手段提升资源利用率。此阶段的优化方案包括：正确评估应用容量，设置合适的资源请求通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性和混部做到按需使用对于固定资源池，对负载峰值在不同时段的在线应用、在离线应用进行混部，做到分时复用针对GPU资源，实现资源的池化和共享2.2.3成本运营从流程、组织、文化等方面建设成本运营体系云上资源优化并非是通过一系列标准动作后得出的一个终态恒定值。如同追求系统稳定性冗余大量资源，追求极致成本而牺牲业务稳定性同样不可取。业务本身是变化的，适合的系统架构及管理方式同样如此，我们鼓励从组织、文化、流程等方面建设成本运营体系，根据目标持续不断调整和优化。此阶段的优化方案包括：建立成本优化团队推动成本优化意识数据驱动成本优化在流程中考察成本量化成本优化交付的业务价值云原生降本白皮书提出了云原生成熟度模型(CNMM,CloudNativeMaturityModel)，主要聚焦云原生领域的资源使用、管理、优化。它描述了云原生的演进过程，涵盖一个成熟的云原生采纳方所应具备的重要功能。从应用架构&服务治理、应用弹性、编排&调度、集群弹性四个维度分析云原生使用的成熟度，并分成了四个等级，具体如下图所示：图9云原生成熟度模型CNMM3.1云原生成熟度模型(CNMM)等级一服务治理这个时候是云原生采纳的早期阶段，业务还是采用传统的单体架构的形式部署，在Kubernetes集群里面普遍采用富容器，但违反了Kubernetes容器单进程的设计初衷，不利于容器的健康检查和弹性。业务架构耦合严重，研发或发布一次，可能需要数周甚至数月的周期，回滚复杂，几乎没有灰度的能力。几乎没有弹性的能力和配置，业务在开发之前，会提前预留大量的资源，预定资源固定且不会随业务负载峰谷变化而动态调整。在这个阶段里，业务在申请资源和调度的时候，没有弹性的能力。为了让自己的业务在波峰的时候也能平稳运行，普遍都会超配资源。业务之间也没有优先级的划分，当资源不足，业务之间有影响时，没有合理的手段有效的避免业务竞争。几乎没有集群范围的弹性，还是以传统的IDC机房整机批量采购的形式，提前先购买大规模的集群，然后各个业务团队各自使用，没有实时灵活的集群范围的弹性功能，集群的扩缩都需要走专门的审批流程。业务之间为了降低影响性，通常都是按照传统IDC的运行模式，单独节点运行单独的3.2云原生成熟度模型(CNMM)等级二服务治理等级2的时候富容器场景少了很多，业务拥抱容器化，不断的将业务模块拆分，打造微服务的架构，集群内部服务之间也有了跟多的调用关系。但缺少有效的服务的管理机制以及流量的治理方式。开始做一些手工的弹性，例如：会人工的检测工作负载的实际负载情况，然后手工调整工作负载的副本数。会利用一些工具：例如定时调整副本数，或者使用Kubernetes原生的HPA能力，手工配置参数和副本数范围。但这些数值的设置和定义都需要大量的经验和手工，且有时候配置无法生效。这时候在编排调度层面，会有了更多的经验为工作负载设置更合适的数值，会根据不同的业务等级为不同的工作负载配置不同比例的Request/Limit数值，以达到不同的QoS的等级，这样在资源调度和资源抢占时，会保证高优先级的业务的资源能够供给充沛，低优先级的业务在面对高优先级业务的时候，资源使用被压制。此时已经开始使用灵活的集群扩缩的机制，但还是更多的偏手工的执行，手工为集群添加、移出节点。业务之间也会共享资源池，而不是单节点运行单独业务，资源的复用能力以及利用率有一定的提升。3.3云原生成熟度模型(CNMM)等级三服务治理此时在应用架构方面已经基本上Kubernetes化了，将Kubernetes的相关能力完全应用到了实际的业务开发、架构、部署上。服务也开始使用优雅启动、优雅停机等高阶的能力，避免长连接的服务在工作负载缩容的时候流量中断，整个架构和服务治理已经趋近成熟。开始使用更多的弹性工具：不仅仅是基于HPA原生支持的指标，也开始对接业务自己定义的一些指标做到应用的弹性扩缩容。但此时还是需要手工定义工作负载弹性扩缩容时的副本数范围，范围如果没有及时调整，就有可能造成资源浪费，或者更严重的是：无力处理波峰流量。资源配置有了很多经验，不仅仅是依据CPU和内存的用量、利用率来为工作负载配置，也会结合实际的业务指标调整工作负载对CPU和内存的请求量。设置更合理的资源Request/Limit比例，进一步保证高优业务的平稳运行。也会利用一些调度工具优化集群调度能力，例如：基于节点负载情况调度作业，可以为节点调度更多作业的同事，也能保障高优业务的资源供给。充分利用集群的ClusterAutoscaler能力自动扩缩集群规模，自动添加、减少集群的节点数，节点几乎不需要人工接入参与运维。3.4云原生成熟度模型(CNMM)等级四服务治理单容器单进程，不会有任何多余的容器，业务的无状态服务比例上升，可以充分享受到不可变基础设施带来的优势。将服务网格引入集群，服务发现和治理得到了系统化、整体化的统筹，跨集群的服务和流量管理都得到了有效的解决方案。基于预测的弹性扩缩容，解决Kubernetes原生弹性滞后的问题：充数据上报、到监控采集、到组件识别和计算、到触发弹性、到最终运行起来一个新的副本，流程、耗时较长，基于预测的弹性能有效降低波峰流量的及时弹性。全自动化的弹性能力，用户无需再手工配置任何弹性规则的指标，做到全自动化的弹性效果，进一步实现资源的“按需付费”。基于应用组的弹性，解决应用之间互相依赖的问题，做到整体的弹性，防止应用依赖导基于预测的能力调整资源的配置，用户无需再手工配置任何资源。做到完全自动化的配置能力，实现资源真正的“按需付费”。业务更多维度的分级和保证的能力，保证高优业务的平稳运行的同时，使用更少资源运行更多业务，业务之间的冲突和干扰都拥有对应的解决方案。集群整体做到完全的Serverless化，让业务和运维团队几乎感受不到集群和节点的存在。波峰来，业务自动扩容，波峰走，业务自动缩容，无需在思考和处理集群规模周边相关资源的自动扩缩容：例如对日志、监控等系统的依赖，随着集群和业务负载的提升，对应的日志、监控等系统都能做到完全的自动扩缩容，让用户无感，把重心完全聚焦在自己的业务之上。、成本优化、成本运营三个维度展开，结合企业实际落地情况提供4.1成本洞察的成本维度的数据。成本洞察的重点在于从成本的角度观察集群的成4.1.1成本采集及资源追踪跟对企业私有云进行资源的定义、定价、计费、统计，然后对私有云成本使用情况账单进行采集对企业资源使用情况进行持续追踪，包括资源使用量、资源使用方式、资源利用率等。4.1.2资源使用可视化Grafana成为了云原生领域监控的标准。成本的管理实际上就是资源的使用管理，展示业务的资源分配、消耗，资源使用效率分析Top10资源消耗的业务，分析Top10资源利用率低的业务展示资源消耗的走势图展示不同维度的资源使用情况，包含Kubernetes概念的维度：例如命名空间、工作负4.1.3费用可视化后，对接云资源计费系统获取资源单价，即可计算出云资源的实际使化，成本视角的可视化是企业运营更关注的视角，提升资源利用率手段。分析集群的下月预估成本，分析每个资源对象的下月预估成本查看集群成本曲线查看业务增长曲线和成本曲线对比，评估成本增长是否过快节省，为执行动作做成本角度的建议算资源维度以及用户自定义的业务维度保存历史重要数据，定期生成报告，回顾和对比Kubernetes的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，精确分配资源成本是在Kubernetes环境中创建成本可见性和实现高效成本利用的首要步骤。下文就解决云原生架构下的费用分摊问题给出一些建议： 类型IT队来支付云费用，公共的IT团队再将成本分配给业务部门或分配就变得非常困难。所以，成本分配的第一步是梳理并明确共享的资源S配置就要建立可持续的公平分配的方法。基于云原生架构，用户可标签模型是成本分配最为关键配标签设计原则的成本。对于管理着来说，想知道到底是什么业务驱动了成本的上涨，即时发现不合理的商业还有多层级的CAM(CloudAccessManagement，腾讯云访问管理)账户结构、项目等功能帮本。资源标签是云用户分类云资源的有效手段，不同云用户对标签的使用语法限制、字符集和长度等合法性进行校验。这种极大的灵活性的疑问，到底该如何定义标签呢？键是：尽早且始终如一的执行某种分配策略。例如在月初创标签，那有一个月的成本没有分配。标签设置的策略也应该尽早进的执行下去，否则每次标签的改动实际上都会导致历史数据的丢原则的标公司有很多没有被标记的存量业务，但不必担心，梳理业务标签为时未的扩队必择正确数量的标签队应用太多标签。要求过多的标签只会导致对标准的抵触，从而导对所需的核心元数据要求标签。与其根据需要定义所有标签，不如定义可使prod值，而另一个团队使用“production”，这些标签的分组方式会有所不准化注意的是：您可能开始使用“R&D”标记资源，但后来意识到某些服务一个成本中心/业务标签，它清楚地定义了资源成本应在组织的位置。是属于固定的、集的似costallocationcostcentercostallocationbusiness签标识资源属于哪个服务，允许组织区分团队正在运行的服务之间的成本。是订单服务的成business_type=logistics的标签帮助识别负责资源的个人/团队。例如：可以设置类似resourceownerxiaomingresource_owner=wechat的标签insdfkjdkd了方便资源的统计，可以给这些云资源加上一个cloudresourcecomputer计算资源帮助确定开发、测试和生产之间的成本差异的环境标签。例如：可以设置类似ironmentdevelopmentenvironmentproduction用于标识资源所属的服务层部分的层标签(例如，前端、网络、后端)。例如：可以设置类servicelayerfrontendservice_layer=backend的标签云账单是企业获得成本支出的第一手资料，账单的可读性往往影响到企业对成本开况，并能及时给到部门或组织反馈。因此对于企业的云账单体系要提高管理水平，帮助企业提高账单分析的效率，使账单更好地服务于企业，以下几个方面是账单管理的落实步对企业账单按云产品维度进行账单的拆分。对企业账单按组织、部门、项目等业务维度进行账单的拆分。对企业账单按包年、包月等周期维度进行账单的拆分。对企业账单按自定义维度进行账单拆分。提供业务维度包括组织、部门、项目等方面的账单推送。度包括年度、季度、月度等方面的账单推送。4.2成本优化有了完整的成本洞察能力后，即可查看企业整体成本效率。企业进而能够围绕其业务目标及业务场景制定对应的优化方案，本小节将具体介绍成本优化的最佳实践。我们再回顾下前文分析的资源浪费的常见现象：应用设置了过大的资源配额应用波峰波谷明显，波谷时资源浪费严重存在不同类型的业务，对资源要求不同主要资源优化方向包括：正确评估应用容量，设置合适的资源请求通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性做到按需使用对应用进行混部，做到分时复用针对GPU资源，实现资源的池化和共享4.2.1设置合理的资源请求和限制有四个业务部门使用同一个集群，你的责任是保证业务稳定资源的按需使用。为了有效提升集群整体的资源利用率，这时就理想情况下，业务应该根据实际情况，设置合理的ResourceRequest和Limit。Request的占位，表示容器至少可以获得的资源；Limit用于对资源的限制，表示的资源。这样的设置有利于容器的健康运行，资源的充分使用。此外，当多业务部署到同一个共享集群以后，每个团队都倾向将自己容器的ResourceRequestesttUMemory(MiB)EResourceQuotaLimitRanges使用资源配额(ResourceQuota)划分资源业务，为了实现业务间的隔离和资源的限制，你可以利用命Kubernetes里面的一个隔离分区，一个集群里面通常包含多个命名空设置命名空间资源的使用配额。例如Kubernetes用户可将不同的业务部署达到预分配和限制的效果。资源配额主要作用于如下方面，详细信息可查计算资源存储资源对象数量配不同的命名空间，通过设置每个命名空间资源的资源配额以配的目的设置一个命名空间的资源使用数量的上限以提高集群的稳定性，防止一个命名空间对资源KubernetesPod选属性，用户可以不为Pod设置资源RequestLimit设置得很大。集群管理员可以为不同的业务设置不同资源使用业务对资源的过度侵占。LimitRange名空间下的单个容器，可以防止用户在命名空间内创建对资源计算资源：对所有容器设置CPU和内存使用量的范围存储资源：对所有PVC能申请的存储空间的范围Request和Limit之间比例默认的Request/Limit，如果容器未指定自己的内存请求和限认的内存请求和限制以防用户遗漏，也可以避免QoS驱逐重要的Pod将不同特征的业务部署在不同的命名空间中，且为不同命名空间设置不同的LimitRange资源利用率限，保证容器正常运行的情况下，限制其请求过多资源能Request推荐配额一个源抢大小空间级别，粒度较粗。U60%，即集群中所有容器的CPURequest之和占集群CPU总量的60%(CPU申请体资源的60%，而实际使用量仅占不到0.8%。Request和Usage之间存在较Request及时调整。业务部门户的Request核。数，避免因为流量突发导致的业务不稳定性。配合上弹性集群能力 (1906-400)/1906=79%。4.2.2动态调度性么用，会造成较大的资源浪费。如果能为此类节点设置一个标记，标明运行。Kubernetes的调度器会将这个负载调度到CPU密集型的节点上，这种寻找亲和性使用场景腾讯云的云虚拟机(CVM节点)有CPU密集型，也有内存密集型。如果某些业务对CPU的存，此时使用普通的CVM机器，势必会对内存造成较大浪费。此时可以在集群CPU密集型的CVM，并且把这些对CPU有较高需求的Pod调度到这些CVM上，这样可以提升CVM资源的整体利用率。同理，还可以在集群中管理异构节点(比如GPUGPU资源的工作负载中指定需要GPU资源的量，调度机制则会帮助你寻找合动态调度(负载感知)LeastRequestedPriority原生调度策略的资源分配是静态的，Request不能代s差。如果调度器可以基于节点的实际资源利用率进行调度，将一定程度上KE调度器的使用场景动态调度器会统计过去一段时间调度到节点的Pod数目，避免往同一节点上调度过多的动态调度器支持设置节点负载阈值，在调度阶段过滤掉超过阈值的节点维人员心中的“痛点”。一方面，为了降低成本，资源利用率当然是越高动驱4.2.3多维度弹性通过HorizontalPodAutoscaler按指标弹性扩缩容t动减HPA(HorizontalPodAutoscaler)可以基于一些指标(例如CPU、内存的利用率)自动扩缩DeploymentStatefulSet中的Pod副本的数量，达到工作负载稳定的目的，真正做到按HPA使用场景流量突发：突然流量增加，负载过载时会自动增加Pod数量以及时响应自动缩容：流量较少时，负载对资源的利用率过低时会自动减少Pod的数量以避免浪费通过HorizontalPodCronscaler定时扩缩容电商平台，双十一要进行促销活动，这时可以考虑使用HPA自动扩缩的流量暴增，如果能提前发生副本扩容，将有效承载流量井喷。HPC(HorizontalPodCronscaler)是腾讯云容器服务TKE自研组件，旨在定时控制副本扩容时资源不足的影响，相较社区的CronHPA，额与HPA结合：可以实现定时开启和关闭HPA，让你的业务在高峰时更弹性不太可能永远都是规律的，设置例外日期可以减少手工调整C单次执行：以往的CronHPA都是永久执行，类似Cronjob，单次执行可以更灵活的应对大HPC使用场景戏服务器在星期日晚上后缩放为原始规模，则可以为玩家提供更好的体验。通过VerticalPodAutoscaler垂直扩缩容KubernetesPod垂直自动扩缩(VerticalPodAutoscaler，以下简称VPA)可以自动调PodCPU预留，帮助提高集群资源利用率并释放CPU和内存供其它Pod使用。缩功能HPA，VPA具有以下优势：VPA扩容不需要调整Pod副本数量，扩容速度更快。VPAHPA容。Request设置过大，使用HPA水平缩容至一个Pod时集群资源利用率仍然很低，此时可VPA使用场景VPA缩特性使容器服务具有非常灵活的自适应能力。应对业务负载急剧飙升的情缩小Request节省计算资源。整个过程自动化无须人为干预，适用于需要应用扩容等场景。此外，VPA可用于向用户推荐更合理的Request，在保证通过ClusterAutoscaler自动调整节点数量HPAHPC，都是在业务负载层面的自动扩缩副本数量，以灵活应对流量的升资源利用率。但是对于集群整体而言，资源总数是固定的，HPA和HPC只是资源，是否有一种方法，能在集群整体较“空”时回收部分资源，能在集集群整体资源？因为集群整体资源的使用量直接决定了账单费用，这种扩缩将真正节省使用成本。CA景突增的负载扩容合适的节点的空闲情况释放多余的节点通过虚拟节点获得Serverless能力资源中。腾讯云容器服务的虚拟节点会将开启该功能的集群中，符合odPod具备云服务器一致的安全隔离性，具备与部署在集群既有节点建流程更快，有效应对流量突发场景；虚拟节点瞬时缩容，有效避免浪景减少集群资源buffer，应对长期运行服务波峰O到短期运行任务O这些O行任务运行结束Pod退出会自动退还资源并停止计费，不需要人力或程竞价实例(SpotInstance)是云服务器CVM的一种新实例运作模式，它最核心的特点是制。但正如它的名字一样，您和其他同时使用竞价实例的用户存在一定定场景下，实例可能会被回收，我们官方将这种回收定义为系统主动中断 讯云的竞价实例模型下，仅会因为竞价实例资源池库存不足而统会自动根据实时库存变化回收这些折扣售卖的实例。当您成功购买一数据分析等具有容错能力的业务应用，尤其是基于云原生框架构建的应用，的前提下，保证业务的稳定性。4.2.4在离线混部填充其他作业，运行更多的作业。第一种方式适合不同类型的应高。充，需要保证在线作业不受影响，保证其SLO在可接受范围内，同时离线，当在线作业需要资源的时候，及时出让。另外，离线运行起来之线作业和离线作业，混部要解决的问题是如何通过集群各个时段的在线空闲资源利用起来。集群每个时段的空闲资源会发生变包括行时间短、计算需求大、容错率高、时延不敏感，允许重运行，典型的是HadoopMapReduce、Spark作业。于Kubernetes和Mesos的。离线场景主要也有两类，分别是Hadoop类的大Kubernetes各种离线应用虑。由于场景比较多，混部也确定了两个主要目的前提下，尽可能提升资源使用率。技术路线有几个原则：一是通用技太多要生态。Kubernetes现了以下关键技术，如：任务级别标准，用于对应不同优先级资源。(2)调度增强：因离线任务量大，运行时间短，原生的Kubernetes调度器无法满足大批量调器进行协调，防止资源被重复调度。(3)资源复用：每个Kubernetes的kubelet节点通过daemonset部署一个agent组件，置资源回收、离线资源配额分配和资源隔离等功能。(4)资源画像：预测在线作业的各类资源使用情况，指导离线作业调度和隔离。(5)存算分离：通过Ceph或腾讯云云硬盘CBS(CloudBlockStorage，简称CBS)分布式解决离线作业需要大量存储空间及磁盘IO问题。(6)任务避让：解决节点负载不均衡问题，重新调度离线作业到低负载节点和实现负载升高功能。作业的时延数据，如本身暴露的时延指标、CPI数据或硬件指标数4.2.4GPU共享GPU的并行算力已经非常普遍。很多厂商基于费。随着GPU卡越来越多，独占GPU卡带来的资源浪费会越来越严重。大家的诉求很自然GPU包含两个关键技术点：精细调度与GPU隔离。前者在保证业务负载可被调度到GPU卡上的同时，通过诸如binpack、spread或负载感知等调度策略，保证负载按照的最大性能。而后者则保证在共享GPU资源时，业务互相之间不受干扰，这也PU的提升，你也无需担心共享带来的资源竞争会损害业务。4.2.5优化矩阵注释：(EKS，腾讯云弹性容器服务ElasticKubernetesService)4.3成本运营成本优化都是项目制，做完项目后效果很好，但是很快反弹了。所以我、文化、流程等方面建设成本运营体系，这已经成为业界共识，FinOps应运而价值。”FinOps践整理了成本运营五大关键步骤：建立成本优化团队推动成本优化意识数据驱动成本优化在流程中考虑成本量化成本优化交付的业务价值4.3.1建立成本优化团队可以是一个现有的个人或者团队，也可以是整个组织中由财成本举行方法，并具备项目管理、数据科学、财务分析和软件/基础设施开发的能力。他们可以执行成本优化(集中式方法)、影响技术团队执行优化(分散式)或将两者相结合(混合式)，从而推进完成成本优化的目标。可以对照成本优化目标(例如资源利用率)来衡量团队的执行和交付能力。导者，他们会为此按组织确定的优先级开展成本优化活动。此部门及其支持者会共同确4.3.2推动成本意识文化以员的成本意识是较长时期的任务，我们需要营造有利于提高成本意在培训中强调成本的重要性和控制成本的必要性积极倡导成本是企业的核心竞争力，成本优化能够带来真正意义上的商业价值。4.3.3数据驱动成本优化0的的目标。4.3.4在流程中考虑成本，需要在软件生命周期全过程中去考虑成本，可成本优化左移(DevFinOps)，通过工具或者自动化加快成本优化，工程师在架构设计时需保证能够和业务目标保持一致。确保变更管理包含成本度量，以量化变更对成本的影响，这样有助于解决与成本相关的问成本优化是运维或者说运营能力的核心组成部分；例如我们可以采用目前的故障管理流程在组织中开展成本意识的培训和认证，有助于建立自我管理成本的组织。4.3.5量化成本优化交付的业务价值概念，成本优化的最终目标是将成本追溯到业务收益，这不是在云用户1如果我的商品订单数在那段时间内翻了一番怎么办？那么它是中性的。如果我的商品订单数在那段时间内增加了三倍怎么办？然后，我们只涨了100万就是非常的结果。2那么波谷时资源利用率就会很低，长时间的低资源利用率也会导致资源浪业务很难实现总体资源利用率的最优化。到成本浪费的根源。定位到问题根源后，选择成本优化的路径需要综合考虑成本、性能、稳定性营更关注成本，需要建立合理的计量计费方法，将资源利率可视化转换为费用可视化，并延资源配额推荐和动态弹性伸缩，防止不同团队为保证业务稳定性过度侵占和消耗资源。二是动态治本之法。成本运营包含五大关键步骤，包括建立成本优化团队、推动成本优化意识、数据成本优化、在流程中考虑成本、量化成本优化交付的业务价值。成功的云原生成本管理非一时34客户降本案例6.1作业帮人工智能、大数据等前沿技术，为学生提供更高效的学习解决方案。随着业务需求的发展，作业帮平台、提升计算资源利用率等需求迫在眉睫。企业成本管控的常规做法是将各项计算、存储、网络资源归口到具体业务单元，然后由系统运。6.1.1当前作业帮降本增效存在的问题1.应用性能有待提升2.应用部署模式差，带来计算资源的浪费a)单应用服务机器负载率低业务一般代表着公司核心业务，一方面为了稳定性的考虑，整体水位不能控制的过低。另b时间不均，且真正的最高峰只有不到一个小时。企业不得不为这一个小时的用量而付出一天的成本。c)空间不均衡量计算资源，另一方面是大数据离线计算需要大量计算资从整个公司视角来看，资源使用极不均衡。3.资源性能有待提升。受硬件带来的成本优化红利。6.1.2解决方案用率的最大化。1.大幅提升应用性能5d源。提升。碎片化问题也得到彻底解决。3.使用新硬件，大幅提升单位计算的性价比使用有限数量的机型，做一些机型更换时减少了业务研发适配的6.1.3实践价值速扩缩容，服务运行态规范落地和统一的运维环境，多云的环境统一，Q时找特殊机型的机器不好找，没有buffer。大部分都是混部多个服务，传统的VM扩容需要涵盖所有服务(权限/一致性)，整体的流等问题经常发生。每年甚至要花费几个月的时间搞裁撤。费严重66.2.2优化方案6.2.3应用效果6.2.4展望未来有不小的提升。目前对于现有业务迁移成本来是比较高，我们在接入之前做了很多针对音乐特性的7取代掉，尽最大的可能发挥云原生的能力。上6.3.2基本方案6.3.3典型场景上。的机型做转码处理，Pod挂载高IOPS的SSD云盘高写缓存；云上24000核弹性Pod助6.4更美86.4.1云原生是什么服务的部署、运行、弹性伸缩，都更加简便、智能。使得部署、维护流程中的节点、接口都模块化，可以通用的自动化接入譬如监控、日志、测试、发布等，而不需要过多6.4.2云原生与更美降本增效目标的关系了近乎无限数量的多需求同时开发和提测的能力，同时减少对一些基础服务的多环境运行维无介入。6.4.3使用云原生技术降低成本最佳实践简单分为架构实现的资源成本、支持和人力时间成本。提测时的资源浪费测的需求。单一的测试环境难以满，而搭建多套测试环境的架构成本会非产研测团队，不再等待测试环境占用、释放的排队中浪费时间，有效提升开发迭源。各个环境的数据管理、配置管理，也难以统一。在微服务架构模式下，虽然有模块化、易接入、易开发等诸多优点，但是在开发人员看难以支撑运行基础开发环境。9案了满足开发和测试团队的多feature、多分支并行提测的需求，架构运维组人工搭建多套测试环开发人员的困境，尝试在一套测试环境中，将所有底层微服务的接口都通过负载均衡暴露。果2.开发人员构建开发环境难度大。案、多feature并行测试的需求，在测试环境引入了ServiceMesh工具务，可以在根据命名规范切出对应分支后，部署对应分