2024云原生成本管理白皮书

云原生成本管理白皮书2023PAGEPAGE10目录一、背景介绍 5二、云原生成本管理模型 6资源利用率现状 7云原生成本管理模型 12成本洞察 12成本优化 13成本运营 13三、云原生资源管理能力成熟度模型 15云原生成熟度模型(CNMM)等级一 15应用架构&服务治理 15应用弹性 15编排&调度 15集群弹性 16云原生成熟度模型(CNMM)等级二 16应用架构&服务治理 16应用弹性 16编排&调度 16集群弹性 16云原生成熟度模型(CNMM)等级三 16应用架构&服务治理 16应用弹性 17编排&调度 17集群弹性 17云原生成熟度模型(CNMM)等级四 17应用架构&服务治理 17应用弹性 17编排&调度 17集群弹性 18四、最佳实践 19成本洞察 19成本采集及资源追踪 19资源使用可视化 19费用可视化 19成本分配 20账单管理 22成本优化 23设置合理的资源请求和限制 23动态调度 26多维度弹性 28在离线混部 32GPU共享 35优化矩阵 37成本运营 38建立成本优化团队 39推动成本意识文化 39数据驱动成本优化 39在流程中考虑成本 40量化成本优化交付的业务价值 40五、总结 42六、企业客户降本案例 446.1作业帮 44当前作业帮降本增效存在的问题 44解决方案 44实践价值 45QQ音乐 45QQ音乐降本增效核心痛点 45优化方案 46应用效果 46展望未来 466.3B站 47B站降本增效核心痛点 47基本方案 47典型场景 476.4更美 47云原生是什么 48云原生与更美降本增效目标的关系 48使用云原生技术降低成本最佳实践 486.5销售易 50云原生是什么 50云原生与销售易降本增效目标的关系 50使用云原生技术降低成本最佳实践 50展望未来 516.6云集 51云原生是什么 52云原生与云集增效目标的关系 52使用云原生技术降低成本最佳实践 52展望未来 54 前言云原生使组织能够在现代云环境（例如公共云、私有云和混合云）中构建和运行可扩展的应用程序,更快地创新并使企业能够更敏捷地对市场作出反应。云原生是应用程序开发的未来，具有巨大的业务影响潜力——能够快速有效地将想法转化为生产。云原生已赋能许多其他技术，例如边缘计算、人工智能、区块链、5G应用等。抓住云原生变得特别重要,你准备好了以下了没:快地生成需求。Kubernetes，一、背景介绍数字经济已成为我国经济增长的重要引擎，云计算从部分企业数字化转型的载体，转变为整个经济社会发展的基石与枢纽。万千企业数字化转型提速换挡，对云计算的使用效能提出了更高的要求，云计算迎来了全新的发展机遇。20202021云原生成本管理一是需要掌握成本支出态势，准确定位资源浪费的根源；二是需要选择适合平台架构和业务特点的资源优化策略，并规避因资源优化导致对业务稳定性的影响；三是实现成本优化后还需要保证其持久性。资源成本优化从基于账单优化的成本可视、基于资源优化的成本节约以及基于模式优化的成本运营从三方面帮助降低云原生平台成本。 二、云原生成本管理模型云原生并非一项单纯的技术，更是一种思想，是技术、企业管理方法的集合，云原生追求的是在包括公有云、私有云、混合云等动态环境中构建和运行规模化应用的能力，追求的是业务持续平滑的变更能力。KubernetesKubernetes遵循声明API，PodKubernetes以后，KubernetesKubernetesKubernetes自动化机Kubernetes资源利用率现状根据中国信息通信研究院调查数据显示，云原生技术给企业带来的价值中，提升资源利用率以节约成本连续两年排名第一，2021年，已有九成用户认可该项价值。选项2020年2021年提升资源利用率以节省成本76%90.59%提升弹性伸缩效率63%76.98%提升交付效率38%66.83%简化运维系统30%67.57%开放架构方便现有系统上的功能扩展25%48.02%12020CNCFKubernetes2019年的72%增长到了82，Kubernetes图1Kubernetes近年部署率但是，随着企业用云程度加深，越来越多的应用迁移到云原生架构上，原本天然具备降本增效特点的云原生架构如果资源配置不当也会引起大量云上资源闲置、云支出浪费。2021年CNCF《FinOpsKubernetesReport》调研报告显示，迁移至Kubernetes平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过20%，调查结果如图3所示。这都说明即使是资源利用率更高的云原生架构也需要合理的资源成本管理。图3迁移至Kubernetes平台后成本变化调查结果KubernetesKubernetes集群中，资源行Pod量6%，针对相同统计口径，腾讯云对1000多家云客户进行了资源利用情况分析，抽样超过一万计算节点，实际使用率如图3所示：42%10%72%20%15%20%-30%13%30%图3资源利用率调查将统计数据汇总，我们可以看到，计算节点的平均资源利用率在10%左右，这意味着云用户90%的计算资源成本是闲置的，这造成了高企的云成本，形成了极大的浪费。针对此种状况，下文分析了主要原因：资源预留过多，普遍存在50%以上的浪费KubernetesPod的资源需求（ResourceRequest）字段用于管理容器对CPU和内存资源预留，保证容器至少可以达到的资源量，该部分资源不能被其他容器抢占。如何设置资源需求是一个难题，若设置过小，当业务负载变高时，业务所需的计算资源无法被确保，可能会造成计算变慢、延迟过高等影响业务指标的情况。为避免此情况发生的可能性，用户通常会将Request设置得很高，以保证服务的可靠CPU4（Request）（CPU_Usage）Request图4CPU资源利用率业务资源使用率波峰波谷现象普遍，低峰时资源浪费严重5CPUCPUCPU图5资源利用率的波动现象不同类型的业务，对资源的需求不同CPU6图6负载峰值在不同时段的业务混部针对资源利用率低的现状，我们对数十个客户进行了访谈，了解到他们在成本管理时的挑战：Kubernetes7图7优化方案的决策平衡开销较大。客户需要从组织、文化、流程等多维度提升对云成本的认知，在系统设计之初就将云成本纳入考量范围之内。云原生成本管理模型基于资源利用率的现状和挑战，我们整理了三阶段云原生成本管理模型，如图8所示：图8云原生成本管理模型成本采集及资源追踪云环境下的资源使用和成本支出是比较复杂的，团队或组织需要通过一定的工具或方案对各种产品进行定义、定价、计费及统计，并对各类资源的使用率、使用量等指标进行持续追踪，能帮助团队尽可能多地搜集到云成本情况，为后边成本可视化以及成本分配提供数据基础。成本可视化和成本分配Kubernetes的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，对于任何组织、部门及职能团队，基于多维度（如云产品、环境、业务线）的资源和成本的可视化分析，能够帮助团队有效地建立起相应的问责机制，并根据获取到的实时数据快速制定优化方案及措施。账单管理云账单的繁冗性和复杂性给用户带来非常大的不便，团队或组织需要对账单进行统一高效的管理，一是根据实际的业务需求，将账单按组织、部门、项目业务维度，年、月周期维度等进行详细化的拆分。二是将各类账单进行统一分析，包括过去一段时间的使用情况、未来使用趋势分析、各部门成本使用情况等方面，并给出合理的规划及更改建议。三是将分析后账单情况按业务部门、周期、自定义等维度定期推送给团队，方便团队及时得到相应的账单。提供可靠、便利、智能的优化方案基于成本可视化和成本分配等手段，有了数据作为度量依据，团队能够围绕其业务目标及业务场景制定对应的成本优化目标。针对云原生场景，云上资源成本优化不仅仅是对云资源规格、数量的调整，也包含了对业务的架构优化、以及通过弹性能力和资源混部等手段提升资源利用率。此阶段的优化方案包括：正确评估应用容量，设置合适的资源请求通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性和混部做到按需使用对于固定资源池，对负载峰值在不同时段的在线应用、在离线应用进行混部，做到分时复用GPU资源，实现资源的池化和共享从流程、组织、文化等方面建设成本运营体系云上资源优化并非是通过一系列标准动作后得出的一个终态恒定值。如同追求系统稳定性冗余大量资源，追求极致成本而牺牲业务稳定性同样不可取。业务本身是变化的，适合的系统架构及管理方式同样如此，我们鼓励从组织、文化、流程等方面建设成本运营体系，根据目标持续不断调整和优化。此阶段的优化方案包括：建立成本优化团队推动成本优化意识数据驱动成本优化在流程中考察成本量化成本优化交付的业务价值 三、云原生资源管理能力成熟度模型云原生降本白皮书提出了云原生成熟度模型（CNMM,CloudNativeMaturityModel，主要聚焦云原生领域的资源使用、管理、优化。它描述了云原生的演进过程，涵盖一个成熟的云原生采纳方所应具备的重要功能。从应用架构&服务治理、应用弹性、编排&调度、集群弹性四个维度分析云原生使用的成熟度，并分成了四个等级，具体如下图所示：图9云原生成熟度模型CNMM云原生成熟度模型等级一&服务治理这个时候是云原生采纳的早期阶段，业务还是采用传统的单体架构的形式部署，在Kubernetes集群里面普遍采用富容器，但违反了Kubernetes容器单进程的设计初衷，不利于容器的健康检查和弹性。业务架构耦合严重，研发或发布一次，可能需要数周甚至数月的周期，回滚复杂，几乎没有灰度的能力。应用弹性几乎没有弹性的能力和配置，业务在开发之前，会提前预留大量的资源，预定资源固定且不会随业务负载峰谷变化而动态调整。编排调度在这个阶段里，业务在申请资源和调度的时候，没有弹性的能力。为了让自己的业务在波峰的时候也能平稳运行，普遍都会超配资源。业务之间也没有优先级的划分，当资源不足，业务之间有影响时，没有合理的手段有效的避免业务竞争。集群弹性几乎没有集群范围的弹性，还是以传统的IDC机房整机批量采购的形式，提前先购买大规模的集群，然后各个业务团队各自使用，没有实时灵活的集群范围的弹性功能，集群的扩缩都需要走专门的审批流程。业务之间为了降低影响性，通常都是按照传统IDC的运行模式，单独节点运行单独的业务。云原生成熟度模型等级二应用架构&服务治理等级2的时候富容器场景少了很多，业务拥抱容器化，不断的将业务模块拆分，打造微服务的架构，集群内部服务之间也有了跟多的调用关系。但缺少有效的服务的管理机制以及流量的治理方式。应用弹性开始做一些手工的弹性，例如：会人工的检测工作负载的实际负载情况，然后手工调整工作负载的副本数。会利用一些工具：例如定时调整副本数，或者使用Kubernetes原生的HPA能力，手工配置参数和副本数范围。但这些数值的设置和定义都需要大量的经验和手工，且有时候配置无法生效。编排调度这时候在编排调度层面，会有了更多的经验为工作负载设置更合适的数值，会根据不同的业务等级为不同的工作负载配置不同比例的Request/Limit数值，以达到不同的QoS的等级，这样在资源调度和资源抢占时，会保证高优先级的业务的资源能够供给充沛，低优先级的业务在面对高优先级业务的时候，资源使用被压制。集群弹性此时已经开始使用灵活的集群扩缩的机制，但还是更多的偏手工的执行，手工为集群添加、移出节点。业务之间也会共享资源池，而不是单节点运行单独业务，资源的复用能力以及利用率有一定的提升。云原生成熟度模型等级三应用架构&服务治理此时在应用架构方面已经基本上Kubernetes化了，将Kubernetes的相关能力完全应用到了实际的业务开发、架构、部署上。服务也开始使用优雅启动、优雅停机等高阶的能力，避免长连接的服务在工作负载缩容的时候流量中断，整个架构和服务治理已经趋近成熟。应用弹性开始使用更多的弹性工具：不仅仅是基于HPA原生支持的指标，也开始对接业务自己定义的一些指标做到应用的弹性扩缩容。但此时还是需要手工定义工作负载弹性扩缩容时的副本数范围，范围如果没有及时调整，就有可能造成资源浪费，或者更严重的是：无力处理波峰流量。编排调度资源配置有了很多经验，不仅仅是依据CPU和内存的用量、利用率来为工作负载配置，也会结合实际的业务指标调整工作负载对CPU和内存的请求量。设置更合理的资源Request/Limit比例，进一步保证高优业务的平稳运行。也会利用一些调度工具优化集群调度能力，例如：基于节点负载情况调度作业，可以为节点调度更多作业的同事，也能保障高优业务的资源供给。集群弹性充分利用集群的ClusterAutoscaler能力自动扩缩集群规模，自动添加、减少集群的节点数，节点几乎不需要人工接入参与运维。云原生成熟度模型等级四应用架构&服务治理单容器单进程，不会有任何多余的容器，业务的无状态服务比例上升，可以充分享受到不可变基础设施带来的优势。将服务网格引入集群，服务发现和治理得到了系统化、整体化的统筹，跨集群的服务和流量管理都得到了有效的解决方案。应用弹性基于预测的弹性扩缩容，解决Kubernetes原生弹性滞后的问题：充数据上报、到监控采集、到组件识别和计算、到触发弹性、到最终运行起来一个新的副本，流程、耗时较长，基于预测的弹性能有效降低波峰流量的及时弹性。全自动化的弹性能力，用户无需再手工配置任何弹性规则的指标，做到全自动化的弹性效果，进一步实现资源的“按需付费”。编排调度基于预测的能力调整资源的配置，用户无需再手工配置任何资源。做到完全自动化的配置能力，实现资源真正的“按需付费”。业务更多维度的分级和保证的能力，保证高优业务的平稳运行的同时，使用更少资源运行更多业务，业务之间的冲突和干扰都拥有对应的解决方案。集群弹性集群整体做到完全的Serverless化，让业务和运维团队几乎感受不到集群和节点的存在。波峰来，业务自动扩容，波峰走，业务自动缩容，无需在思考和处理集群规模的问题。周边相关资源的自动扩缩容：例如对日志、监控等系统的依赖，随着集群和业务负载的提升，对应的日志、监控等系统都能做到完全的自动扩缩容，让用户无感，把重心完全聚焦在自己的业务之上。 四、最佳实践成本洞察KubernetesKubernetesPrometheus和Grafana分析Top10Top10Kubernetes在获取资源实际用量后，对接云资源计费系统获取资源单价，即可计算出云资源的实际使用费用。相比资源用量可视化，成本视角的可视化是企业运营更关注的视角，提升资源利用率只是降低云成本的手段。下面展示费用可视化的日常应用场景：成本分配Kubernetes的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，精确分配资源成本是在Kubernetes环境中创建成本可见性和实现高效成本利用的首要步骤。下文就解决云原生架构下的费用分摊问题给出一些建议：企业往往选择公共的IT团队来支付云费用，公共的IT团队再将成本分配给业务部门或业务应用的所有者。假如在共享Kubernetes集群上运行不同业务团队的工作负载，通过云厂商本身的费用账单再分配就变得非常困难。所以，成本分配的第一步是梳理并明确共享的资源有哪些，如计算资源、存储资源、网络资源、云厂商的PaaS服务如日志等等。理清楚共享成本类型之后，就要建立可持续的公平分配的方法。基于云原生架构，用户可以为云上运行的应用添加标签来标识资源的所有者。建立合理的标签模型是成本分配最为关键的一个步骤。云原生成本分配标签设计原则成本分配是一件很有挑战的事情，不同的团队关心的成本角度是不一样的，比如：成本的标记也有多种方式，例如腾讯云提供标签帮助云用户有效分隔不同的云资源，此外还有多层级的CAM（CloudAccessManagement，腾讯云访问管理）账户结构、项目等功能帮助有效分类不同的成本。资源标签是云用户分类云资源的有效手段，不同云用户对标签的使用不尽相同，云服务商对标签的语法限制、字符集和长度等合法性进行校验。这种极大的灵活性会让云用户有相同的疑问，到底该如何定义标签呢？越早越好标签定义原则选择正确数量的标签标签原则不应该强迫团队应用太多标签。要求过多的标签只会导致对标准的抵触，从而导致不合规。最好只针对所需的核心元数据要求标签。与其根据需要定义所有标签，不如定义可选标签，明确描述团队在选择这样做时应如何实施它们。易读简化且一致标签的设计尽量易读，并且要保证简化，满足业务诉求即可。用户应该能直接从标签读懂其含义，但又不能设计得过于冗长。另外，简化的同时也要保证标签一致性，如果一个团队使用“prod”的标签值，而另一个团队使用“production”，这些标签的分组方式会有所不同。命名标准化采用标准化命名格式，使后续的API集成更加便捷。例如：统一用英文小写，单词之间用下划线隔开。值得注意的是：您可能开始使用“R&D”标记资源，但后来意识到某些服务不支持&字符，因此命名尽量考虑使用最通用标准的方式，例如此时应该使用r_and_d。最佳实践如果还是不确定如何设置标签，这里有一个使用标签的最佳实践：/成本中心？还是单独计算某种业务的具体成本？例如：可以设置类似cost_allocation=cost_center或cost_allocation=business的标签business_type=orderbusiness_type=logisticsCVM，ins-dfkjdkd，（service_layer=frontend或service_layer=backend账单管理云账单是企业获得成本支出的第一手资料，账单的可读性往往影响到企业对成本开业提高账单分析的效率，使账单更好地服务于企业，以下几个方面是账单管理的落实步骤：成本优化有了完整的成本洞察能力后，即可查看企业整体成本效率。企业进而能够围绕其业务目标及业务场景制定对应的优化方案，本小节将具体介绍成本优化的最佳实践。我们再回顾下前文分析的资源浪费的常见现象：应用设置了过大的资源配额应用波峰波谷明显，波谷时资源浪费严重存在不同类型的业务，对资源要求不同主要资源优化方向包括：正确评估应用容量，设置合适的资源请求通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性做到按需使用对应用进行混部，做到分时复用针对GPU资源，实现资源的池化和共享设想你是个集群管理员，现在有四个业务部门使用同一个集群，你的责任是保证业务稳定性的前提下，让业务真正做到资源的按需使用。为了有效提升集群整体的资源利用率，这时就需要限制各业务使用资源的上限，以及通过一些默认值防止业务过量使用。ResourceRequest和Limit。RequestLimitResourceRequest和Limit（TencentKubernetesEngineTKE）RequestLimitCPU(核)0.250.5Memory(MiB)2561024为了更细粒度的划分和管理资源，可以在腾讯云容器服务TKE上设置命名空间级别的ResourceQuota以及LimitRanges。使用资源配额（ResourceQuota）划分资源如果你管理的某个集群有四个业务，为了实现业务间的隔离和资源的限制，你可以利用命名空间和资源配额。命名空间是Kubernetes集群里面的一个隔离分区，一个集群里面通常包含多个命名空间，资源配额用于设置命名空间资源的使用配额。例如Kubernetes用户可将不同的业务部署在不同的命名空间里，再为不同的命名空间设置不同的资源配额，以限制一个命名空间对集群整体资源的使用量，达到预分配和限制的效果。资源配额主要作用于如下方面，详细信息可查看[2]。CPURequestLimit所有PVCPVC/Service/Configmap/Deployment资源配额使用场景//使用LimitRange限制资源资源需求是KubernetesPod中容器定义的可选属性，用户可以不为Pod设置资源Request和Limit，也可以将值设置得很大。集群管理员可以为不同的业务设置不同资源使用默认值以及范围，这可以有效减少业务创建时的工作量同时，限制业务对资源的过度侵占。LimitRange适用于一个命名空间下的单个容器，可以防止用户在命名空间内创建对资源申请过小或过大容器；当用户不设置容器资源需求时，LimitRange可为容器添加默认资源。LimitRanges主要作用于如下方面：CPUPVCRequestLimitRequest/LimitLimitRange使用场景QoSPodLimitRange可在一定程度上提升资源利用率Request推荐即使有了资源配额和LimitRange设置，多业务视角的资源调配依然无法做到灵活多变。例如，当用户的业务负载提升，确实需要较多资源时，配额的限制会阻止快速扩容。配额的分配通常需要申请和审批流程，这限制了弹性和创新速度。并且，资源配额限制的是同一个命名空间的应用实例，当一个命名空间里存在多个工作负载时，工作负载之间也会发生资源抢占，导致某些负载资源使用受限。LimitRange的作用范围也是针对一个命名空间下的所有业务实例，而同一命名空间里可能存在主业务容器也会存在辅助容器，如果都设置成固定的大小值也会造成资源浪费或不够的现象。因此不管是资源配额，还是LimitRanges，它们的限制范围都是命名空间级别，粒度较粗。10CPU总量为1906核，CPU的分配率接近60%CPURequestCPU总量的60%（CPU申请量CPU13.4核，CPU0.8%，CPURequest设置不合理，Request60%，0.8%。Request和Usage图10某生产集群的资源分配和实际用量Request的设置基于云用户对业务负载的深刻理解，不同业务的Request设置各不相RequestRequest81341906*60%=1143智能Request推荐基于业务的实际资源使用情况，给用户推荐更合理的Requst数值，且可以自定义冗余倍数，避免因为流量突发导致的业务不稳定性。配合上弹性集群能力（ClusteAutocale10，CPU11404001906Request将节省（1906-400）/1906=79%图11某生产集群的CPU实际用量细节节点亲和性CPUCPU被CPUCPUKubernetesCPU节点亲和性使用场景（CVM）有CPUCPU的CVMCPUCVMCPUPodCVM上，这样可以提升CVM资源的整体利用率。同理，还可以在集群中管理异构节点（比如GPU机器PUPU（负载感知）原生的KubernetesPod的LeastRequestedPriority，Request不能代KubernetesTKE12图12动态调度器动态调度器的使用场景除了降低资源浪费，动态调度器还可以很好的缓解集群调度热点的问题。Pod重调度CPUTKE13

图13重调度器和动态调度器的关系通过HorizontalPodAutoscaler按指标弹性扩缩容RequestHPA（HorizontalPodAutoscaler）可以基于一些指标（例如CPU、内存的利用率）自动扩缩Deployment和StatefulSet中的Pod副本的数量，达到工作负载稳定的目的，真正做到按需使用。HPA使用场景PodPodHorizontalPodCronscalerHPA自动扩缩容。但是HPAHPC（HorizontalPodCronscaler）是腾讯云容器服务TKE自研组件，旨在定时控制副本数量，以达到提前扩缩容、和提前触发动态扩容时资源不足的影响，相较社区的CronHPA，额外支持：与HPAHPACronHPACronjobHPC使用场景以游戏服务为例，从周五晚上到周日晚上，游戏玩家数量暴增。如果可以将游戏服务器在星期五晚上前扩大规模，并在星期日晚上后缩放为原始规模，则可以为玩家提供更好的体验。如果使用HPA，可能因为扩容速度不够快导致服务受影响。通过VerticalPodAutoscaler垂直扩缩容KubernetesPod垂直自动扩缩（VerticalPodAutoscaler，以下简称VPA）可以自动调整Pod的CPU和内存预留，帮助提高集群资源利用率并释放CPU和内存供其它Pod使用。相较于水平自动伸缩功能HPA，VPA具有以下优势：VPAPodVPA，HPARequestHPAPodVPA使用场景VPA自动伸缩特性使容器服务具有非常灵活的自适应能力。应对业务负载急剧飙升的情况，VPA能够在用户设定范围内快速扩大容器的Request。在业务负载变小的情况下，VPA可根据实际情况适当缩小Request节省计算资源。整个过程自动化无须人为干预，适用于需要快速扩容、有状态应用扩容等场景。此外，VPA可用于向用户推荐更合理的Request，在保证容器有足够使用的资源的情况下，提升容器的资源利用率。通过ClusterAutoscaler自动调整节点数量上面提到的HPA和HPC，都是在业务负载层面的自动扩缩副本数量，以灵活应对流量的波峰波谷，提升资源利用率。但是对于集群整体而言，资源总数是固定的，HPA和HPC只是让集群有更多空余的资源，是否有一种方法，能在集群整体较“空”时回收部分资源，能在集群整体较“满”时扩充集群整体资源？因为集群整体资源的使用量直接决定了账单费用，这种集群级别的弹性扩缩将真正节省使用成本。14，CA（ClusterAutoscaler）图14ClusterAutoscaler原理CA使用场景Serverless虚拟节点并不是节点，而是一种调度能力，支持将标准Kubernetes集群中的Pod调度到集群服务器节点之外的资源中。腾讯云容器服务的虚拟节点会将开启该功能的集群中，符合调度条件的Pod调度到由弹性容器服务维护的云上计算资源中。部署在虚拟节点上的Pod具备云服务器一致的安全隔离性，具备与部署在集群既有节点上的Pod一致的网络隔离性、网络连通性，如图15所示。图15在虚拟节点部署业务16Kubernetes图16普通Kubernetes集群与支持虚拟节点的Kubernetes集群扩缩容对比虚拟节点使用场景bufferPodbufferPodPod竞价实例竞价实例（SpotInstance）是云服务器CVM的一种新实例运作模式，它最核心的特点是折扣售卖和系统中断机制。但正如它的名字一样，您和其他同时使用竞价实例的用户存在一定的竞争关系。在特定场景下，实例可能会被回收，我们官方将这种回收定义为系统主动中断（个竞价实例后，它的使用和按量计费的CVMVPC等。竞价实例使用场景在丰富的实践与探索中，我们发现，Spot非常适合容器、无状态服务、CI/CD、强化学习、离线转码、大数据分析等具有容错能力的业务应用，尤其是基于云原生框架构建的应用，在这些场景下可以在巨幅降低成本（80%以上）的前提下，保证业务的稳定性。混部概念提高集群资源利用率有几种方式，一是集群本身合理配置应用申请资源，尽量运行更多的作业。二是在波谷时段填充其他作业，运行更多的作业。第一种方式适合不同类型的应用混部，应用之间资源互补，高峰时段错开。若是同种类型的应用，应用都在同一时段处于高峰，这种情况适合第二种方式。本节主要阐述基于方式二的混部，即在线离线混部。SLO混部场景HadoopMapReduce、SparkKubernetes和MesosHadoopKubernetes图17混部场景混部架构18图18在在离线混部架构设计以Kubernetes为依托，实现了以下关键技术，如：KubernetesgangschedulingKubernetes的kubeletdaemonsetagentCephCBS（CloudBlockStorageCBS）IOCPI数据或硬件指标数GPUGPUGPUGPUKubernetesPodGPUGPUGPUGPU19图19GPU共享GPUGPUGPUbinpack、spreadGPUGPUGPUGPUGPU18TKEqGPUTKE集群上创建qGPU节点池，并在创建负载时指定qGPU算力与显存。TKEqGPUGPUGPU利用率

图20TKEqGPU上面的章节概述了成本优化的各种手段，那么在何种场景下应该用何种技术手段，每种手段的效果和实现难度如何评估呢？我们将这些能力归入四个象限，横坐标为成本，纵坐标为难度，如图21所示。图21优化方案的难度和效果注释：(EKS，腾讯云弹性容器服务ElasticKubernetesService)成本运营云成本优化并非是通过一系列标准动作后得出的一个终态恒定值，而是一个持续迭代和优化的过程。很多企业做成本优化都是项目制，做完项目后效果很好，但是很快反弹了。所以我们需要从组织、文化、流程等方面建设成本运营体系，这已经成为业界共识，FinOps应运而生。FinOps基金会的定义很好的涵盖了它的本质：“FinOps是云的运营模式。FinOps实现了一种转变——系统、最佳实践和文化的组合—DevOpsFinOps我们结合FinOps和客户实践整理了成本运营五大关键步骤：建立成本优化团队推动成本优化意识数据驱动成本优化在流程中考虑成本量化成本优化交付的业务价值/（（）（（同时必须确保团队获得高级管理层的支持。支持者即成本优化理念的倡导者，他们会为此部门提供升级支持，确保按组织确定的优先级开展成本优化活动。此部门及其支持者会共同确保组织在有效利用云资源并继续创造业务价值。成本意识是指节约成本和控制成本的观念，成本管理需要大家共同参与，只有团队具备了良好的成本意识，才能建立降低成本的主动性，才能让各种成本优化的举措、方法和要求得以很好的贯彻和执行。提高全员的成本意识是较长时期的任务，我们需要营造有利于提高成本意识的氛围和推动成本意识的管理。可以有如下方式推动成本意识文化：所有成本优化都是由指标驱动的，所有指标都需要可实现的目标。数据驱动是指将采集的数据有效组织，并对相关的信息进行整合和提炼，在数据的基础上经过训练和拟合形成自动化的决策模型。ITCPU/IP需要注意的是：目标是可衡量的，能够驱动团队采取下一步行动的，目标会受多方面的因素影响，明确目标之后就是要建立能够准确获取当前值与目标值的差距的途径，并能够持续的观察当前值的变化，通过不断优化问题，做出正向的反馈，逐步靠近并达到目标值，进而制定下一阶段的目标。具体的落地可以借助云厂商或开源社区提供的各种可观测性仪表盘，目前行业内的仪表盘的能力能够覆盖90%以上的场景，如果需要更精细化且结合业务的数据，则需要企业自身投入研发。在新的和现有的组织流程中建立成本意识，需要在软件生命周期全过程中去考虑成本，可以包括以下方案：evFins由于成本优化是一项必要的投资，因此量化业务价值之后，您就可以向利益相关者说明投资回报。如果能够量化业务价值，在未来的成本优化投资中，就可以从利益相关者那里得到更多支持，并获得一个框架来衡量组织成本优化活动的成果。这里有个单位经济学的概念，成本优化的最终目标是将成本追溯到业务收益，这不是在云上花费的美元，而是每次预订、每可用座位里程、每张机票、每笔客户交易、每百万活跃用户所花费的美元。如果云成本在6个月内从100万上升到200万是不是很糟糕？100万就是非常 五、总结资源配置不当是引起云原生成本浪费的主要原因。Kubernetes成本洞察是定位云原生成本管理问题的基础。一是成本采集及资源追踪，需要针对复杂的云上资源提出统一的成本定量、定价和采集标准，并对资源进行持续跟踪。二是资源使用可视化，基于完善的云原生监测工具建立多维细粒度的资源利用率观测体系。三是费用可视化，相比资源利用率企业运营更关注成本，需要建立合理的计量计费方法，将资源利率可视化转换为费用可视化，并延展到费用历史分析、趋势预测等。四是成本分配，合理的资源标签模型是建立可持续的公平的成本分配方法的关键。五是账单管理，完备的云账单体系应满足各部门精细化的需求，能摸清各种云产品的支出情况，并能及时给到部门或组织反馈。GPUGPUGPUGPU成本运营是实现云原生成本持续优化的长远之道。云原生成优化并不是成本管理的重点，因为成本优化的成效并不是恒定的，而是需要持续的迭代和优化。所以建立成熟的成运营体系才是成本管理的治本之法。成本运营包含五大关键步骤，包括建立成本优化团队、推动成本优化意识、数据驱动成本优化、在流程中考虑成本、量化成本优化交付的业务价值。成功的云原生成本管理非一时之功，需要从组织、文化、流程等多个方面来共同推动。 六、企业客户降本案例作业帮2015IT2019TKE。当前作业帮降本增效存在的问题PHPGolang能往往有很大10%-20%30%-40%一方面是在线集群波谷空闲了大量计算资源，另一方面是大数据离线计算需要大量计算资源。从整个公司视角来看，资源使用极不均衡。1-2解决方案SRE关注KubernetesKubernetes原PHP43%通过使用fluid，完成检索服务计算和存储的分离，极大提升了运维效率。过程中对内存基带的使用进行了优化，带来30%性能提升，节省万核级别计算资源。容器服务使用统一的集群，常态在40%左右，在保障业务稳定的情况下极限可达60%。机器利用率大幅度提升。碎片化问题也得到彻底解决。容器环境下集群底层计算资源使用有限数量的机型，做一些机型更换时减少了业务研发适配的成本，更换效率大幅度提升。10%QQQQ2005为了满足业务上云需求，及业务不断发展，质量、效率的提升，QQ音乐上云的需求越来越迫切。QQIDCbuffer/IDC节点M（IDCIDC的设备，每年的裁撤是必然的，对于服务来说裁一次伤一次。老旧服务找不到负责人，相关源码丢失等问题经常发生。每年甚至要花费几个月的时间搞裁撤。音乐目前VM420优化方案图22QQ音乐降本增效优化方案pkg，复用GitlabTKEPodNodeNodeTKE应用效果目前音乐从TKE版本上线以来，开发自主迁移了2000+Pod，几十个服务稳定运行。业务扩容更加方便及时，有效应对流量高峰。与此同时，资源碎片率降低，资源利用率上升。展望未来BBbilibiliB3282021329B站主站业务在IDC机房，暑假期间业务规模快速增长，IDC服务器算力不足。基本方案采用混合云的方案，结合IDC和腾讯云上资源。优先使用线下IDC算力，业务高峰期溢出的计算资源使用腾讯云EKS弹性集群方案，调度到云上。图23B站降本增效基本方案典型场景612IDC机房与PodAMD高计PodIOPS的SSD24000Pod助更美更美App提供整形、微整形、齿科、眼科、抗衰老等消费医疗服务。更美App已入驻数千家正300更美认为：云原生，首先定义的是环境。云——为一切程序运行的基本环境。云原生——原生为云而设计，能充分发挥云平台的优势与特点。DevOps和CICD基于云原生搭建的开发、测试环境，使得多功能同时开发提测时，不再受限于测试环境的承载性。实现了近乎无限数量的多需求同时开发和提测的能力，同时减少对一些基础服务的多环境运行的依赖。实现随用随建，用完即销的模式。大大提高企业的开发迭代效率，降低测试环境搭建、运行和维护的支出。云产生架构的实现，大大提升多环境的自动化能力，基本实现整个开发、测试、生产多发经发布流程的运维无介入。成本洞察核心痛点成本可以简单分为架构实现的资源成本、支持和人力时间成本。开发任务紧，多任务并行开发，同一个微服务可能会有不同的团队开发不同的需求，会有多多分支同时提测的需求。单一的测试环境难以满，而搭建多套测试环境的架构成本会非常的高。3所以，多需求并行开发和并行提测是之前的开发架构中，造成资源成本浪费的一个主要原因。基本方案了满足开发和测试团队的多feature面对开发人员的困境，尝试在一套测试环境中，将所有底层微服务的接口都通过负载均衡暴露出来。使得开发人员在开发调试时，可以访问到测试集群中的微服务接口。但是这也仅仅只能保障一些最底层的服务接口可以不需要在本地运行，其他请求链路中间环境的微服务，还是都需要在跑服务才可以。应用效果在这套测试环境的架构形式下，只能基本满足多分支并行提测的需求。但是还是有个别阶段，需求或者hotfix数量过多时，还是出显现因为提测环境占用导致上线需求排队的情况。成本优化核心痛点基本方案featureServiceMesh工具IstiobasebaseIstio、IngressGatewayfeature构建基于ServiceMesh实现的流量分发的多分支测试环境。实现以下功能：基础环境同步当前线上最新代码，自动触发部署。确保base环境永远与生产环境相同。feature环境feature各featurefeaturebase环境。实现code只需要运行一下当前开发中服务的代码即可。整体的接口测试，都可以在云端，在自己专属的独立测试环境中完成。当然我们也通过一系列的webhook、crontab等工具，来清理一些没有实际使用的环境，保障集群资源不浪费。成本运营CICDCICD体系中，所有feature销售易销售易是唯一一家连续五年入选GartnerSFA全球魔力象限的中国CRM企业。销售易认为云原生是指业务能够依靠云的能力，如：高性能、高可用、弹性伸缩、即开即用等特性，满足业务个性化需求或快速增长的特性。广义上的云原生是指能够满足相关云原生特性的基础设施和相关技术规范；狭义上的云原生是指云厂商提供的云相关基础设施或产品能力（云厂商在这方面有天然优势，另外大多数企业也逐渐习惯使用云产品）云原生的技术思想对企业信息化建设有很大帮助，首先云原生可以在很大程度上帮助企业，降低在某些技术方向的研发成本，通过现有的、成熟的、面向未来化的云原生方案，能够让企业信息化走的更稳健。（总的来说，云原生可以为企业带来效率上的提升和降低信息化建设成本。成本洞察核心痛点基本方案企业销售云、平台等产品线，所包含的资源可清晰的进行汇总。成本优化核心痛点应用效果企业可以根据业务线、项目、环境等维度对资源成本进行核算，并能及时了解到相对空闲的资源，进行资源合并或回收。成本运营核心痛点项目上线运营后，项目年收入和成本如何核算?基本架构方案通过对项目的资源标签，来对资源成本进行汇总。应用效果企业CDP业务已经上线运营了2年，每年或每季度都可以对资源的消耗情况进行清晰统计。云原生是一种技术形态，也是一种技术思想。企业引入云原生会对研发效率、系统稳定性、成本管理等