云原生成本管理白皮书_36页_2mb.pdf

云原生成本管理白皮书云原生成本管理白皮书编写单位腾讯云计算（北京）有限责任公司中国信息通信研究院-3er0408010203100808091014101011141719222527目录 CONTENTS前言一、背景介绍二、云原生成本管理模型2.1 资源利用率现状2.2 云原生成本管理模型2.2.1 成本洞察2.2.2 成本优化2.2.3 成本运营三、最佳实践3.1 成本洞察3.1.1 成本采集及资源追踪3.1.2 资源使用可视化3.1.3 费用可视化3.2 成本优化3.2.1 设置合理的资源请求和限制3.2.2 动态调度3.2.3 多维度弹性3.2.4 在离线混部3.2.5 GPU 共享3.2.6 优化矩阵3.3 成本运营3.3.1 建立成本优化团队3.3.2 推动成本意识文化3.3.3 数据驱动成本优化3.3.4 在流程中考虑成本四、总结五、企业客户降本案例113.1.4 成本分配133.1.5 账单管理27282829293.3.5 量化成本优化交付的业务价值 293132Keith ChanCNCF 中国区总监兼 Linux 基金会亚太区策略规划总监、腾讯云 TVP前言云原生使组织能够在现代云环境（例如公共云、私有云和混合云）中构建和运行可扩展的应用程序, 更快地创新并使企业能够更敏捷地对市场作出反应。凭借弹性计算、自动扩展、计量计费和按使用付费模型等功能，云原生计算可帮助组织摆脱昂贵的永远在线的基础架构，并将这些节省用于新功能开发。 冗余、容错、松散耦合的服务和云原生架构自动化的自动恢复导致的弹性增加和停机时间减少也可能导致间接成本节约。使用容器和微服务构建应用程序的一个巧妙之处在于，云原生应用程序使开发人员可以更轻松地访问和重用为早期项目创建的组件。 这有几个云原生的优点，可以降低开发成本并制作更好的应用程序：云原生是应用程序开发的未来，具有巨大的业务影响潜力能够快速有效地将想法转化为生产。云原生已赋能许多其他技术，例如 边缘计算、人工智能、区块链、5 G 应用等。抓住云原生变得特别重要, 你准备好了以下了没:1. 创建一个更加面向服务的组织。而不是传统的基于功能的结构，围绕特定的服务或能力组织您的团队。2. 使用现代和最新的架构。云原生意味着使用微服务和反应速度更快的架构类型。3. 重新组织您的架构以跟上云原生开发的步伐。业务应该能够以与技术人员相同的速度足够快地生成需求。4. 大多数云原生关键基础设施都是开源的，例如 Kubernetes，你知道如何参与开源社区以了解云原生的最新发展，甚至成为贡献者的一份子吗？降低开发过程的复杂性：开发人员可以将更多时间花在项目的细节上，而不是构建通用框架上。它还允许在更短的时间内开发更复杂的应用程序。 缩短上市时间：更快的交付意味着更快的客户更满意，这也意味着抓住时间敏感机会的潜力。简化测试：经过审查的微服务出现的问题更少，减轻了管道后期的负载。当开发人员知道服务有效时，他们所要做的就是设计兼容性。 模块化设计：模块化设计使外观和功能的标准化更容易。拥有多个应用程序或服务的公司可以利用这一点来降低客户的学习曲线。1数字经济已成为我国经济增长的重要引擎，云计算从部分企业数字化转型的载体，转变为整个经济社会发展的基石与枢纽。万千企业数字化转型提速换挡，对云计算的使用效能提出了更高的要求，云计算迎来了全新的发展机遇。相较于传统云计算架构，云原生具备更灵活的资源管理、更敏捷的应用迭代、更高效的模块协同以及更稳定的业务保障能力，云原生带动技术架构、应用效能、云化效益的全方位提升，为企业数字化转型提供了有效的实践工具和方法论。根据中国信息通信研究院调查数据显示，云原生已进入黄金发展期，其核心技术开始在大规模生产环境中深入应用，金融、政府、制造、电信、医疗等行业的云原生用户占比较 2020 年均有显著提升，云原生化开始从业内的头部企业逐步下沉到中小企业，从领先企业的尝鲜变为主流企业的必备。同时，云原生技术给企业带来的价值中，提升资源利用率节约成本连续两年排名第一，2021 年已有九成用户认可该项价值，排名前五的另外四项价值分别是：提升弹性效率、提升交付效率、简化运维系统以及便于现有系统的功能扩展。云原生已成为企业基于云实现降本增效的最佳实践。但随着企业用云程度不断加深，云上支出浪费严重，云原生平台自身的成本治理成为企业上云突出诉求。弹性按需是云原生的资源利用优势，但如果资源配置策略设置不合理可能会导致资源的浪费；云原生资源利用的计量方式如果不够灵活，会使得企业难以准确调控用云成本；云边缘、混合多云、云数智融合等模式在帮助提升工作效率、实现应用灵活部署的同时也带来了异构资源管理的新挑战。因此，企业在应用云原生架构之后，需要考虑如何管理、优化和使用云原生服务，如何通过降低云原生成本，进一步提升业务的数字化转型效果。云原生成本管理面临问题难定位、路径难选择、成效难持续三大挑战，资源成本优化是云原生降本的关键路径。云原生成本管理一是需要掌握成本支出态势，准确定位资源浪费的根源；二是需要选择适合平台架构和业务特点的资源优化策略，并规避因资源优化导致对业务稳定性的影响；三是实现成本优化后还需要保证其持久性。资源成本优化从基于账单优化的成本可视、基于资源优化的成本节约以及基于模式优化的成本运营从三方面帮助降低云原生平台成本。云原生成本管理白皮书将基于中国信息通信研究院与腾讯云对行业发展趋势和企业客户诉求的准确把握、对云原生优化的技术研究与实践经验，提出一套体系化的云原生成本优化方法论和最佳实践路径，结合行业优秀案例，帮助企业改善用云成本充分发挥云原生的效能和价值，为企业的数字化转型提供可靠的保障。一、背景介绍2云原生并非一项单纯的技术，更是一种思想，是技术、企业管理方法的集合，云原生追求的是在包括公有云、私有云、混合云等动态环境中构建和运行规模化应用的能力，追求的是业务持续平滑的变更能力。Kubernetes 是云原生技术栈的核心，是众多云原生项目的粘合剂。Kubernete s 遵循声明式系统原则，将其管控的对象都抽象成标准 API，并通过多种控制器完成云原生平台的高度自动化。比如云用户可以通过定义 Pod 对象，并指定需要运行的容器镜像，以及容器所需的 CPU、内存等计算资源。该对象被提交至 Kubernetes 以后，Kubernetes 会依据用户请求运行容器进程，并按需求确保该应用进程的资源配额。这使得应用可以以较低成本接入到 Kubernetes 平台中来，并依靠 Kubernetes 自动化机制实现低运维乃至免运维。基于监控平台收集的数据，Kubernete s 可根据应用的实时指标数据，预测应用资源用量，并通过自动化横向或纵向扩缩容能力，及时调整应用的副本数量以及资源用量，及时回收空闲资源，提升资源使用率。提升资源利用率是云原生技术栈的核心目标之一，资源利用率的提升意味着以更少的计算节点用承载更多的应用实例，极大的降低云用户的资源开销，也契合国家节能减排的政策号召。二、云原生成本管理模型32.1 资源利用率现状根据中国信息通信研究院调查数据显示，云原生技术给企业带来的价中，提升资源利用率以节约成本连续两年排名第一，2021 年，已有九成用户认可该项价值。如图1所示，2020 年 CNCF 中国云原生调查报告中指出，生产系统中使用 Kubernetes 的比例已从 2019 年的 72% 增长到了 82%，越来越多的企业在云上使用基础设施资源、通过 Kubernetes 平台来管理应用，Kubernetes 已经无处不在。图1 Kubernete s 近年部署率提升资源利用率以节省成本提升弹性伸缩效率提升交付效率简化运维系统开放架构方便现有系统上的功能扩展选项 2020年 2021年76% 90.59%63% 76.98%38% 66.83%30% 67.57%25% 48.02%4图3 资源利用率调查但是，随着企业用云程度加深，越来越多的应用迁移到云原生架构上，原本天然具备降本增效特点的云原生架构如果资源配置不当也会引起大量云上资源闲置、云支出浪费。2021 年 CNCFFinOps Kubernetes Report调研报告显示，迁移 至 Kubernetes 平台后，68 % 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%，调查结果如图 2 所示。这都说明即使是资源利用率更高的云原生架构也需要合理的资源成本管理。Kubernetes 集群的成本主要集中在工作节点的运行成本，资源利用率过低是计算成本高企的最主要原因。 在 Kubernetes 集群中，资源利用率体现为运行的所有 Pod 消耗的资源与集群上可用资源总量的比率，据麦肯锡早期报告，全球服务器资源利用率不到 6%，资源利用率低下导致了大量的资源浪费。针对相同统计口径，腾讯云对 1000 多云客户进行了资源利用情况分析，抽样超过一万计算节点，实际使用率如图 3 所示：图2 迁移 至 Kubernetes 平台后成本变化调查结果42% 的节点资源利用率低于 10% 72% 的节点资源利用率低于 20%15% 的节点资源利用率在 20%-30% 只有不到13%的客户点利用率大于 30%5在线业务流量通常有较明显的波动周期，且波谷时间常大于波峰时间，波谷时期的资源有较多闲置，这也成为了资源利用率较低的另一主因。例如公交系统通常在白天负载增加，夜晚负载减少；游戏业务通常在周五晚上开始出现波峰，在周日晚开始出现波谷。如图 5 所示，同一业务在不同的时间段对CPU 资源的用量不同，若用户以固定资源需求申请 CPU 资源，当业务负载较低时，CPU 资源利用率就会很低。将统计数据汇总，我们可以看到，计算节点的平均资源利用率在 10% 左右，这意味着云用户 90% 的计算资源成本是闲置的，这造成了高企的云成本，形成了极大的浪费。针对此种状况，下文分析了主要原因：Kubernetes Pod 的资源需求（Resource Request）字段用于管理容器对 CPU 和内存资源预留，保证容器至少可以达到的资源量，该部分资源不能被其他容器抢占。如何设置资源需求是一个难题，若设置过小，当业务负载变高时，业务所需的计算资源无法被确保，可能会造成计算变慢、延迟过高等影响业务指标的情况。为避免此情况发生的可能性，用户通常会将 Request 设置得很高，以保证服务的可靠性。但实际上，业务在大多数时段时负载不会很高。以 CPU 为例，图4是某个实际业务场景下容器的资源预留（Request）和实际使用量（CPU_Usage）关系图：资源预留远大于实际使用量，两者之间差值所对应的资源不能被其他负载使用，因此 Request 设置过大势必会造成较大的资源浪费。资源预留过多，普遍存在 50% 以上的浪费图4 CP U 资源利用率业务资源使用率波峰波谷现象普遍，低峰时资源浪费严重图5 资源利用率的波动现象6计算作业依据其提供服务的特性和业务目的可分为在线业务和离线业务两类：在线业务通常白天负载较高，且对时延要求较高，必须优先调度和运行；而离线的计算型业务通常对运行时段和时延要求相对较低，可以在在线业务负载波谷时段运行。此外，有些业务属于计算密集型，对 CPU 资源消耗较多，而有些业务属于内存密集型，对内存消耗较多。如图 6 所示，将负载峰值在不同时段的业务，或者将在线和离线作业混部在一起，可有效的以离线作业填补在线作业的负载低谷时段，进而提升资源利用率。将需求不同资源的作业有效的部署在相同节点，可充分利用各种资源，提升总体资源利用率。不同类型的业务，对资源的需求不同图6 负载峰值在不同时段的业务混部部分客户做完成本优化项目后，短期内确实节省了很多成本。但是随着时间推移，业务的变迁，旧的成本优化方案可能会失效，云成本又开始上升，这个持续成本优化带来很大挑战。业务开发团队在系统架构、系统设计时，缺乏对成本的考量，这可能使业务上线后的资源开销较大。客户需要从组织、文化、流程等多维度提升对云成本的认知，在系统设计之初就将云成本纳入考量范围之内。图7 优化方案的决策平衡相比于传统云服务器，Kubernetes 的动态性为资源计量和成本分摊变得更复杂，Kubernetes 作为一个开放式平台，鼓励资源共享，但同时缺少有效的成本观测和分配机制。多个容器应用可以被动态调度在同一个计算节点上，简单将底层云资源与应用一一映射并评估成本的传统手段已经失效。如何发现和观测成本管理上的问题，比如针对资源闲置、应用闲置、以及前述资源利用率过低等问题，如何能快速有效的发现并分析。定位到问题后，如何制定优化方案，这些方案会不会对现有的架构带来挑战，如何在权衡成本、性能、稳定性、业务价值后作出最佳决策，如图 7 所示。针对资源利用率低的现状，我们对数十个客户进行了访谈，了解到他们在成本管理时的挑战：7图8 云原生成本管理模型基于资源利用率的现状和挑战，我们整理了三阶段云原生成本管理模型，如图 8 所示：成本洞察：成本采集及资源跟踪、成本可视化、成本分配和账单管理成本优化：提供可靠、便利、智能的优化方案成本运营：从组织、文化、流程等方面建设成本运营体系 云环境下的资源使用和成本支出是比较复杂的，团队或组织需要通过一定的工具或方案对各种产品进行定义、定价、计费及统计，并对各类资源的使用率、使用量等指标进行持续追踪，能帮助团队尽可能多地搜集到云成本情况，为后边成本可视化以及成本分配提供数据基础。2.2.1 成本洞察成本采集及资源追踪Kubernetes 的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，对于任何组织、部门及职能团队，基于多维度（如云产品、环境、业务线）的资源和成本的可视化分析，能够帮助团队有效地建立起相应的问责机制，并根据获取到的实时数据快速制定优化方案及措施。成本可视化和成本分配云账单的繁冗性和复杂性给用户带来非常大的不便，团队或组织需要对账单进行统一高效的管理，一是根据实际的业务需求，将账单按组织、部门、项目业务维度，年、月周期维度等进行详细化的拆分。二是将各类账单进行统一分析，包括过去一段时间的使用情况、未来使用趋势分析、各部门成本使用情况等方面，并给出合理的规划及更改建议。三是将分析后账单情况按业务部门、周期、自定义等维度定期推送给团队，方便团队及时得到相应的账单。账单管理2.2 云原生成本管理模型8对于固定资源池，对负载峰值在不同时段的在线应用、在离线应用进行混部，做到分时复用针对 GPU 资源，实现资源的池化和共享云上资源优化并非是通过一系列标准动作后得出的一个终态恒定值。如同追求系统稳定性冗余大量资源，追求极致成本而牺牲业务稳定性同样不可取。业务本身是变化的，适合的系统架构及管理方式同样如此，我们鼓励从组织、文化、流程等方面建设成本运营体系，根据目标持续不断调整和优化。此阶段的优化方案包括：2.2.3 成本运营从流程、组织、文化等方面建设成本运营体系建立成本优化团队 推动成本优化意识数据驱动成本优化 在流程中考察成本量化成本优化交付的业务价值基于成本可视化和成本分配等手段，有了数据作为度量依据，团队能够围绕其业务目标及业务场景制定对应的成本优化目标。针对云原生场景，云上资源成本优化不仅仅是对云资源规格、数量的调整，也包含了对业务的架构优化、以及通过弹性能力和资源混部等手段提升资源利用率。此阶段的优化方案包括：2.2.2 成本优化提供可靠、便利、智能的优化方案正确评估应用容量，设置合适的资源请求通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性和混部做到按需使用9三、最佳实践本章内容将从成本洞察、成本优化、成本运营三个维度展开，结合企业实际落地情况提供成本管理的最佳实践。 帮助企业上云、云原生改造时兼顾成本优化， 助力企业数字化转型。成本洞察是成本管理的第一步，现有的 Kubernetes 集群中，只能看到资源的使用情况，而无法分析和观察更具体的成本维度的数据。成本洞察的重点在于从成本的角度观察集群的成本使用情况，主要包含资源使用可视化、费用可视化，以及成本分配。3.1 成本洞察随着云计算的发展，云上各种的产品和资源也是日益复杂，要想实现对成本的可视，那么必须要有专业的方案以及统一的标准对云成本进行定量、定价及采集，并对资源进行持续跟踪，从而做到云成本使用心中有数，以下是实现成本采集及资源追踪具体的要求：对各类公有云成本产品进行收集，并详细记录账单情况。对企业私有云进行资源的定义、定价、计费、统计，然后对私有云成本使用情况账单进行采集对企业资源使用情况进行持续追踪，包括资源使用量、资源使用方式、资源利用率等。3.1.1 成本采集及资源追踪得益于云原生的发展，Kubernetes 周边的生态已经相对完善。监控方面，Prometheus 和 Grafana 的组合已经成为了云原生领域监控的标准。成本的管理实际上就是资源的使用管理，如何快速并且准确的识别出资源的分配、消耗、以及浪费，是成本优化的前提条件。因此成本洞察首先要做到的是资源消耗和资源利用率的可视化，这里举几个资源使用情况可视化的例子：展示业务的资源分配、消耗，资源使用效率分析 Top10 资源消耗的业务，分析 Top10 资源利用率低的业务展示资源消耗的走势图展示不同维度的资源使用情况，包含 Kubernetes 概念的维度：例如命名空间、工作负载、Pod 等；也包含用户自定义的维度：例如部门、组织、团体、项目等3.1.2 资源使用可视化10成本分配是一件很有挑战的事情，不同的团队关心的成本角度是不一样的，比如：对于开发来说，他们希望能够区分开发环境的成本和生产环境的成本。对于管理着来说，想知道到底是什么业务驱动了成本的上涨，即时发现不合理的商业逻辑。云原生成本分配标签设计原则Kubernetes 的成本分配比传统的云环境面临更多挑战，团队需要定义一致的标签和命名空间来改善分配，精确分配资源成本是在 Kubernetes 环境中创建成本可见性和实现高效成本利用的首要步骤。以下是成本分配的建议：明确业务云资源费用类型企业往往选择公共的 IT 团队来支付云费用，公共的 IT 团队再将成本分配给业务部门或业务应用的所有者。假如在共享 Kubernetes 集群上运行不同业务团队的工作负载，通过云厂商本身的费用账单再分配就变得非常困难。所以，成本分配的第一步是梳理并明确共享的资源有哪些，如计算资源、存储资源、网络资源、云厂商的 PaaS 服务如日志等等。云原生架构业务标签配置理清楚共享成本类型之后，就要建立可持续的公平分配的方法。基于云原生架构，用户可以为云上运行的应用添加标签来标识资源的所有者。建立合理的标签模型是成本分配最为关键的一个步骤。3.1.4 成本分配在获取资源实际用量后，对接云资源计费系统获取资源单价，即可计算出云资源的实际使用费用。相比资源用量可视化，费用视角的可视化是企业财务和采购角色更关注的视角，他们更加关注费用支出的合理性、费用归属是否明确等等，提升资源利用率的本质就是控制和减少费用支出，从而节约成本。3.1.3 费用可视化下面展示费用可视化的日常应用场景：分析集群的下月预估成本，分析每个资源对象的下月预估成本查看集群成本曲线查看业务增长曲线和成本曲线对比，评估成本增长是否过快根据推荐的方案预估的成本节省，为执行动作做成本角度的建议多维度的成本观测：从计算资源维度以及用户自定义的业务维度多周期的观测：支持不同时长的周期定义，如日、周、月、或由用户自定义保存历史重要数据，定期生成报告，回顾和对比11标签的设计尽量易读，并且要保证简化，满足业务诉求即可。用户应该能直接从标签读懂其含义，但又不能设计得过于冗长。另外，简化的同时也要保证标签一致性，如果一个团队使用 “prod” 的标签值，而另一个团队使用 “production”，这些标签的分组方式会有所不同。成本的标记也有多种方式，例如腾讯云提供标签帮助云用户有效分隔不同的云资源，此外还有多层级的 CAM（Cloud Access Management，腾讯云访问管理）账户结构、项目等功能帮助有效分类不同的成本。资源标签是云用户分类云资源的有效手段，不同云用户对标签的使用不尽相同，云服务商对标签的语法限制、字符集和长度等合法性进行校验。这种极大的灵活性会让云用户有相同的疑问，到底该如何定义标签呢？易读简化且一致采用标准化命名格式，使后续的 API 集成更加便捷。例如：统一用英文小写，单词之间用下划线隔开。值得注意的是：您可能开始使用“R&D”标记资源，但后来意识到某些服务不支持 & 字符，因此命名尽量考虑使用最通用标准的方式，例如此时应该使用 r_and_d。命名标准化如果还是不确定如何设置标签，这里有一个使用标签的最佳实践：最佳实践获得较好的成本分配方式的关键是：尽早且始终如一的执行某种分配策略。例如在月初创建一个资源，到月底才打标签，那有一个月的成本没有分配。标签设置的策略也应该尽早进行，也应该尽量保证始终如一的执行下去，否则每次标签的改动实际上都会导致历史数据的丢失。越早越好该原则应该明确如何定义标签的键，以及标签可能包含的适当值，这些键值对将应用于所有资源。工程师开始开发应用程序之前，就应该将标签定义原则传达给工程师以确保良好的标签覆盖率。虽然许多公司有很多没有被标记的存量业务，但不必担心，梳理业务标签为时未晚。 标签标准在开始制定时越深思熟虑，未来修订的可能性就越小。随着企业在云上的扩展，它将产生数千甚至数百万个资源，每个资源都有自己的标签，更改标记策略意味着团队必须更新所有这些资源。标签定义原则标签原则不应该强迫团队应用太多标签。要求过多的标签只会导致对标准的抵触，从而导致不合规。最好只针对所需的核心元数据要求标签。与其根据需要定义所有标签，不如定义可选标签，明确描述团队在选择这样做时应如何实施它们。选择正确数量的标签12一个成本中心/业务标签，它清楚地定义了资源成本应在组织的位置。是属于固定的、集的成本中心？还是单独计算某种业务的具体成本？例如：可以设置类似 cost_allocation=cost_center 或 cost_al-location=business 的标签标识资源属于哪个服务，允许组织区分团队正在运行的服务之间的成本。是订单服务的成本？还是物流服务的成本？ 例如：可以设置类似 business_type=order 或 business_type=logistics 的标签资源所有者标签，用于帮助识别负责资源的个人/团队。例如：可以设置类似 resource_owner=xiao-ming 或 resource_owner=wechat 的标签资源名称标签，可以理解成自定义资源名称。例如云厂商定义的云服务器的名字为 CVM，某个实例名为 ins-dfkjdkd，为了方便资源的统计，可以给这些云资源加上一个 cloud_resource=computer 的标签，表明这是个计算资源帮助确定开发、测试和生产之间的成本差异的环境标签。例如：可以设置类似 environment=devel-opment 或 environment=production 的标签用于标识资源所属的服务层部分的层标签（例如，前端、网络、后端）。例如：可以设置类似 service_layer=frontend 或 service_layer=backend 的标签云账单是企业获得成本支出的第一手资料，账单的可读性往往影响到企业对成本开支的判断，一个完备的云账单体系应满足各部门精细化的需求，能摸清各种云产品的支出情况，并能及时给到部门或组织反馈。因此对于企业的云账单体系要提高管理水平，帮助企业提高账单分析的效率，使账单更好地服务于企业，以下几个方面是账单管理的落实步骤：3.1.5 账单管理对企业账单按云产品维度进行账单的拆分。对企业账单按组织、部门、项目等业务维度进行账单的拆分。对企业账单按包年、包月等周期维度进行账单的拆分。对企业账单按自定义维度进行账单拆分。对企业账单的使用情况进行分析，包括过去支出、浪费情况，未来支出趋势，优化建议等方面。提供业务维度包括组织、部门、项目等方面的账单推送。提供周期维度包括年度、季度、月度等方面的账单推送。13理想情况下，业务应该根据实际情况，设置合理的 Resource Request 和 Limit。Request 用于对资源的占位，表示容器至少可以获得的资源；Limit 用于对资源的限制，表示容器至多可以获得的资源。这样的设置有利于容器的健康运行，资源的充分使用。此外，当多个团队将业务部署到同一个共享集群以后，每个团队都倾向将自己容器的 Resource Request 和 Limit 设置得很高，以保证自己负责的业务的稳定性。如果你使用的是腾讯云容器服务 TKE（Tencent Kubernetes Engine，简称TKE）的控制台，创建负载时会给所有的容器设置如下默认值。CPU（核）Request0.25256Limit0.51024CPU（核）设想你是个集群管理员，现在有四个业务部门使用同一个集群，你的责任是保证业务稳定性的前提下，让业务真正做到资源的按需使用。为了有效提升集群整体的资源利用率，这时就需要限制各业务使用资源的上限，以及通过一些默认值防止业务过量使用。3.2.1 设置合理的资源请求和限制有了完整的成本洞察能力后，即可查看企业整体成本效率。企业进而能够围绕其业务目标及业务场景制定对应的优化方案，本小节将具体介绍成本优化的最佳实践。我们再回顾下前文分析的资源浪费的常见现象：主要资源优化方向包括：正确评估应用容量，设置合适的资源请求 通过动态调度解决资源碎片的问题，提高装箱率回收业务波谷时的冗余，通过弹性做到按需使用 对应用进行混部，做到分时复用针对 GPU 资源，实现资源的池化和共享3.2 成本优化应用设置了过大的资源配额 应用波峰波谷明显，波谷时资源浪费严重存在不同类型的业务，对资源要求不同14资源需求是 Kubernetes Pod 中容器定义的可选属性，用户可以不为 Pod 设置资源Request 和 Limit，也可以将值设置得很大。集群管理员可以为不同的业务设置不同资源使用默认值以及范围，这可以有效减少业务创建时的工作量同时，限制业务对资源的过度侵占。Limit Range 适用于一个命名空间下的单个容器，可以防止用户在命名空间内创建对资源申请过小或过大容器；当用户不设置容器资源需求时，Limit Range 可为容器添加默认资源。Limit Ranges 主要作用于如下方面：计算资源：对所有容器设置 CPU 和内存使用量的范围存储资源：对所有 PVC 能申请的存储空间的范围比例设置：控制一种资源 Request 和 Limit 之间比例默认值：对所有容器设置默认的 Request/Limit，如果容器未指定自己的内存请求和限制，将为它指定默认的内存请求和限制使用Limit Range限制资源为了更细粒度的划分和管理资源，可以在腾讯云容器服务 TKE 上设置命名空间级别 的 Resource Quota 以及 Limit Ranges。如果你管理的某个集群有四个业务，为了实现业务间的隔离和资源的限制，你可以利用命名空间和资源配额。命名空间是 Kubernetes 集群里面的一个隔离分区，一个集群里面通常包含多个命名空间，资源配额用于设置命名空间资源的使用配额。例如 Kubernetes 用户可将不同的业务部署在不同的命名空间里，再为不同的命名空间设置不同的资源配额，以限制一个命名空间对集群整体资源的使用量，达到预分配和限制的效果。资源配额主要作用于如下方面，详细信息可查看2。计算资源：所有容器对 CPU 和 内存的 Request 以及 Limit 的总和存储资源：所有 PVC 的存储资源请求总和对象数量：PVC/Service/Configmap/Deployment 等资源对象数量的总和使用资源配额（Resource Quota） 划分资源资源配额使用场景给不同的项目/团队/业务分配不同的命名空间，通过设置每个命名空间资源的资源配额以达到资源分配的目的设置一个命名空间的资源使用数量的上限以提高集群的稳定性，防止一个命名空间对资源的过度侵占和消耗15即使有了资源配额和 Limit Range 设置，多业务视角的资源调配依然无法做到灵活多变。例如，当用户的业务负载提升，确实需要较多资源时，配额的限制会阻止快速扩容。配额的分配通常需要申请和审批流程，这限制了弹性和创新速度。并且，资源配额限制的是同一个命名空间的应用实例，当一个命名空间里存在多个工作负载时，工作负载之间也会发生资源抢占，导致某些负载资源使用受限。Limit Range 的作用范围也是针对一个命名空间下的所有业务实例，而同一命名空间里可能存在主业务容器也会存在辅助容器，如果都设置成固定的大小值也会造成资源浪费或不够的现象。因此不管是资源配额，还是 Limit Ranges，它们的限制范围都是命名空间级别，粒度较粗。图 9 是一个实际生产集群的资源使用情况，该集群的 CPU 总量为 1906 核，CPU 的分配率接近 60%，即集群中所有容器的 CPU Request 之和占集群 CPU 总量的 60%（CPU 申请量）。但实际集群中所有容器的 CPU 使用量之和仅为 13.4 核，CPU总体利用率不到 0.8%，CPU 的利用率非常低。出现这种现象的根本原因在于容器的 Request 设置不合理，Request 的设置占集群整体资源的 60%，而实际使用量仅占不到 0.8%。Request 和 Usage 之间存在较大的优化空间。智能 Request 推荐设置资源使用默认值，以防用户遗漏，也可以避免 QoS 驱逐重要的 Pod将不同特征的业务部署在不同的命名空间中，且为不同命名空间设置不同的Limit Range可在一定程度上提升资源利用率限制容器对资源使用的上下限，保证容器正常运行的情况下，限制其请求过多资源Limit Range使用场景Request 的设置基于云用户对业务负载的深刻理解，不同业务的 Request 设置各不相同，并且同一业务在不同时间段的 Request 设置也应该随业务负载波动及时调整。业务部门通常习惯将 Request 设置较大，以锁定资源保证业务工作负载的稳定性。但从图 9 可以看出，即使设置使用量十倍的冗余，集群总体核数也仅需要 134 核左右，但实际用户的 Request 为 1906*60%=1143 核。图9 某生产集群的资源分配和实际用量16智能 Request 推荐基于业务的实际资源使用情况，给用户推荐更合理的 Requst 数值，且可以自定义冗余倍数，避免因为流量突发导致的业务不稳定性。配合上弹性集群能力（Cluster Autoscaler），可以在负载低谷期及时缩减集群的整体规模，以达到降本的目的。以 图 9 为例，CPU 的实际使用量细节如图 10 所示，没有超过 40 核，即使设置十倍的 Requst 的冗余，此时集群规模仅需 400 核，相较之前的 1906 核，使用智能推荐的 Request 将节省（1906-400）/1906= 79%。若某个 CPU 密集型业务实例，被调度到内存密集型的节点上，导致内存密集型的 CPU 被占满，但内存几乎没怎么用，会造成较大的资源浪费。如果能为此类节点设置一个标记，标明该类节点是 CPU 密集型，随后在创建业务负载时也设置一个标记，标明这个负载需要在CPU密集型节点运行。Kuberne-tes 的调度器会将这个负载调度到 CPU 密集型的节点上，这种寻找最合适的节点的方式，将有效提升资源利用率。3.2.2 动态调度图10 某生产集群的CPU实际用量细节节点亲和性动态调度（负载感知）原生的 Kubernetes 调度策略倾向于调度 Pod 到节点剩余资源较多的节点上，比如默认的 LeastRe-questedPriority 策略。但是原生调度策略的资源分配是静态的，Reques t 不能代表资源真实使用情况，因此当业务负载降低时，Kubernetes 调度器的可用资源与集群的实际闲置资源会有较大偏差。如果调度器可以基于节点的实际资源利用率进行调度，将一定程度上解决资源浪费的问题。腾讯云容器服务TKE自研的动态调度器所做的就是这样的工作。动态调度器的核心原理如下图 11 所示：节点亲和性非常适合在一个集群中有不同资源需求的工作负载同时运行的场景。比如说，腾讯云的云虚拟机（CVM节点）有 CPU 密集型，也有内存密集型。如果某些业务对 CPU 的需求远大于内存，此时使用普通的 CVM 机器，势必会对内存造成较大浪费。此时可以在集群里添加一批 CPU 密集型的 CVM，并且把这些对 CPU 有较高需求的 Pod 调度到这些 CVM 上，这样可以提升 CVM 资源的整体利用率。同理，还可以在集群中管理异构节点（比如 GPU 机器），在需要 GPU 资源的工作负载中指定需要 GPU 资源的量，调度机制则会帮助你寻找合适的节点去运行这些工作负载。节点亲和性使用场景17图12 重调度器和动态调度器的关系除了降低资源浪费，动态调度器还可以很好的缓解集群调度热点的问题。动态调度器会统计过去一段时间调度到节点的 Pod 数目，避免往同一节点上调度过多的 Pod动态调度器支持设置节点负载阈值，在调度阶段过滤掉超过阈值的节点在企业的运维工作中，除了成本，系统的稳定性也是十分重要的指标。如何在两者间达到平衡，可能是很多运维人员心中的“痛点”。一方面，为了降低成本，资源利用率当然是越高越好，但是资源利用率达到一定水位后，负载过高极有可能导致节点资源过载而触发的主动驱离或因 CPU 竞争导致的业务指标抖动等问题。为了减小企业成本控制之路上的顾虑，腾讯云容器服务 TKE 还提供了“兜底神器” 重调度器 来保障集群负载水位在可控范围内。重调度器是动态调度器是一对好搭档，它们的关系可以参考下图 12，就像它的名字一样，它主要负责“保护”节点中已经负载比较“危险”的节点， 优雅驱逐这些节点上的业务。图11 动态调度器动态调度器的使用场景重调度18以游戏服务为例，从周五晚上到周日晚上，游戏玩家数量暴增。如果可以将游戏服务器在星期五晚上前扩大规模，并在星期日晚上后缩放为原始规模，则可以为玩家提供更好的体验。如果使用 HPA，可能因为扩容速度不够快导致服务受影响。HPC 使用场景Kubernetes Pod 垂直自动扩缩（Vertical Pod Autoscaler，以下简称 VPA）可以自动调整 Pod 的 CPU 和内存预留，帮助提高集群资源利用率并释放 CPU 和内存供其它 Pod 使用。相较于水平自动伸缩功能 HPA，VPA 具有以下优势：VPA 扩容不需要调整 Pod 副本数量，扩容速度更快。VPA 可为有状态应用实现扩容，HPA 则不适合有状态应用的水平扩容。Request 设置过大，使用 HPA 水平缩容至一个 Pod 时集群资源利用率仍然很低，此时可以通过 VPA 进行垂直缩容提高集群资源利用率。通过 VerticalPodAutoscaler 垂直扩缩容如果你的业务是存在波峰波谷的，固定的资源 Request 注定在波谷时会造成资源浪费，针对这样的场景，如果波峰的时候可以自动增加业务负载的副本数量，波谷的时候可以自动减少业务负载的副本数量，将有效提升资源整体利用率。HPA（Horizontal Pod Autoscaler）可以基于一些指标（例 如 CPU、内存的利用率）自动扩缩 Deployment 和 StatefulSet 中的 Pod 副本的数量，达到工作负载稳定的目的，真正做到按需使用。3.2.3 多维度弹性通过 HorizontalPodAutoscaler 按指标弹性扩缩容流量突发：突然流量增加，负载过载时会自动增加 Pod 数量以及时响应自动缩容：流量较少时，负载对资源的利用率过低时会自动减少 Pod 的数量以避免浪费假设你的业务是电商平台，双十一要进行促销活动，这时可以考虑使用 HPA 自动扩缩容。但是 HPA 需要先监控各项指标后，再进行反应，可能扩容速