kubernetes 降本增效标准指南｜ProphetPilot：容器智能成本管理引擎

腾讯云原生

发布于 2021-07-27 11:40:31

1.3K0

田奇，腾讯云高级工程师，专注大规模离在线混部，弹性伸缩，云原生成本优化，熟悉Kubernetes，关注云原生大数据、AI。

王孝威，腾讯云容器产品经理，热衷于为客户提供高效的 Kubernetes 使用方式，为客户极致降本增效服务。

前言

随着 Kubernetes 的普及，企业已经普遍接受了容器，正在向云原生演进。但是当前的 Kubernetes 只解决云原生的第一步（Day 1），就是利用容器编排调度和声明式API等，来解决资源获取、应用部署、高可用容灾、基础运维等难题。但是目前采纳 Kubernetes 的企业也遇到了前往高级阶段的问题，运营庞大复杂的 Kubernetes 集群是非常困难的，例如：

如何评估资源需求？例如：原生 Kubernetes 的调度需要根据容器对资源的请求（Request），一个容器到底需要多少资源量？集群整体的资源量该设置成多少？节点数多少才合适？
如何达到真正的智能扩缩？如何灵活处理具有波峰波谷的变换流量？如果要设置 HPA，到底该用哪个指标？副本数的变换范围如何设置？
如何查看容器的成本状况？目前集群本身可以查看资源使用量、利用率情况，但这些资源对应的账单具体是多少？Kubernetes 集群里面可能有节点、硬盘、网络、LB 等多种资源，如何聚合这些离散的资源账单，并以不同维度展示？
如何提高资源使用效率？如何识别无效和不合理的资源申请负载？如何最合理的选择节点的规格和计费类型？
...

以上这些问题都需要在运营 Kubernetes 的第二步（Day 2）来解决：

降低用户的运营复杂度，为 Kubernetes 插上智能引擎，减轻客户的运营负担，是 TKE 一直以来致力的事情。在前几期的“降本增效”系列文章中，我们谈到了成本控制系统、常用的利用率提升工具、资源利用率现象剖析、理解和应用弹性。TKE 在用户需求的基础上，提出容器智能 ProphetPilot，本文将从背景现状、产品功能、分层模型阐述 ProphetPilot 相关概念。

背景和现状

当前 TKE 上有很多关于弹性、资源利用率、成本节约、负载感知调度组件，比如 HPA、HPC、VPA、CA、在离线混部等产品，更多可查看资源利用率提升工具大全。虽然目前 TKE 为客户带来了丰富的降本增效产品选择，但是存在以下几个方面的不足；

用户面对这么多伸缩组件，往往难以抉择，当前应用最为广泛的也是有 HPA 和 CA，其他的组件往往不敢使用或者不知道何时该使用，以及为什么需要采用
有些组件是社区组件或 Kubernetes 原生能力，功能往往还不够强大，比如 HPA，扩缩容感知不够及时和准确，并不一定满足客户的需求
组件之间缺乏协调一致的体验，各自拥有各自的功能，甚至一起使用会发生冲突，例如 VPA 和 HPA 不能同时使用 CPU 或内存的指标

下图对比了各个组件之间的联系，主要从 Observer、Analyzer、Action 来说明各个维度的关系：

Observer（观测）：监控和收集工作负载的运行状态
Analyzer（分析）：分析它的运行模式。例如：例1. 负载的 CPU 使用量是否是周期性的变化？例2. 负载是否在某些固定时刻流量会上升或下降？例3. 负载里容器的 Request 是否设置合理？等等
Action（动作）：根据分析负载的运行模式，执行最佳的策略。以 Analyzer 维度的例子来看，例1可以推荐使用 HPA，例2可以推荐使用 HPC，例3可以推荐使用 VPA

功能简介

ProphetPilot 主要解决 Observer 和 Analyzer 两大部分，其功能可贯穿弹性和混部所有组件，针对开源组件无法满足需求的场景，TKE 采用自研 Executor，来满足快速发展的业务需求：

成本分析

成本分析重点在于从成本的角度观察集群的成本使用情况，因为现有的 Kubernetes 集群中，只能看到资源的使用情况，而无法分析和观察更具体的成本维度的数据。主要功能点包含：

负责展示业务的成本消耗，资源消耗，资源使用效率
分析 Top10 资源消耗的业务，推动业务进行资源优化、改造
分析集群的下月预估成本，每个资源对象的下月预估成本
查看成本曲线、业务增长曲线和成本曲线对比
根据推荐中心推荐的方案预估的成本节省
多维度的观测：节点/命名空间/工作负载/Pod/Container
多周期的观测：日/周/月/自定义
定期生成报告
保存历史重要数据

告警通知

不管是否自动执行策略，在 ProphetPilot 发现集群中某些配置不合理，或某些动作需要执行时，都会提供相关的提示和告警。此外，每一次策略推荐，动作执行，都会进行数据保存，方便用户查看历史事件，以及事件触发的原因，方便进行历史回溯。

策略

策略是推荐中心推荐的方案执行的方式，ProphetPilot 将提供多种策略，主要分成四种类型：

自动执行策略：完全的自定义执行策略，包括自定义设置一些触发标准，例如：电商里的订单业务对稳定性要求很高，可以设置比较大的资源使用冗余，及时资源利用率很低也被判断为正常情况。但一些离线批处理任务优先级不高，对时延不敏感，可以设置较高的资源利用率标准；
计划执行策略：在未来的某一时刻点执行某种策略；或者是当推荐动作产生后，延迟一定时间执行动作。例如当节点数缩容、工作负载水平缩容时，可以尽量慢一些，防止流量再次飙升；
周期策略：类似 CronJob，定时按周期执行某些策略；
人工确认策略：完全手工的行为，ProphetPilot 不会自动执行这些策略，当推荐动作产生后，会通过告警通知客户手工执行策略。

执行引擎

执行引擎就是执行的具体动作，例如 HPA、VPA、在离线混部等动作，更多可查看：资源利用率提升工具大全。

容器智能分层模型

应用层

随着云原生、微服务架构的普及，一套企业应用往往涉及到多个微服务，服务之间存在微妙的依赖关系，理解应用的微服务之间的关系，可以让弹性伸缩拥有更加全面的视角，防止单一的局部视角，导致扩容了 Workload 也没有达到真实的效果，从而浪费了资源和成本。

比如下图中，传统的弹性伸缩往往只根据资源使用率，当 CPU 使用率很高的时候，触发该 Workload 的扩容，但是 CPU 使用率高，可能只是假象，在下述列子中，NGINX 日志写的速率，Kafka 生产者写入 Kafka 集群的速率，日志偏移更改速率，消费速率，以及 ES 索引计算效率都有关联性；找到更关键的指标比如 Kafka 的生产速率就是比 CPU 更好的扩缩容指标：

ProphetPilot 理解应用层不同的应用特征，市面上的这些中间件、数据库等基础产品都可以作为应用划分，而服务本身也可以根据重要程度，为应用划分出不同的等级，微服务之间的调用关系，则可以通过 ServiceMesh 进行获取，从而在应用层建立起 Workload 的相关性依赖图，做到业务的整体扩缩，而不是 Workload 的单独扩缩。

调度层

分布式资源调度

当前的 Kubernetes 只解决企业云原生的第一步（Day 1），让企业能够利用容器以及 Kubernetes 编排调度，来解决资源获取、应用部署、高可用容灾、运维等难题，但是它在资源模型上，还处在初级阶段，比如研发需要评估服务到底需要多少资源，然后填写 Request，最终 Kubernetes 按照 Request 做静态资源调度，将 Pod 调度到合适的Node 上。

这样做将面临以下问题：

研发为了服务稳定性，往往过度评估资源，造成浪费；
研发根本不知道怎么评估，甚至是没有评估资源，相信大部分研发没有办法一眼看穿自己的服务需要多少资源，造成资源不足，或者是资源浪费；
Kubernetes 是按照静态的资源调度的，实际容器运行后资源的使用状态和调度的静态资源决策是不一致的，造成资源浪费，或者资源争抢严重。

当前的普遍做法是做超售，一般是两个维度：

Node 维度超售，给节点设置超售，比如节点本身只有48核，但是可以设置超售2倍，让他给调度器造成一种假象，按照96核调度；因为不同的节点计算能力和内存不匹配，计算能力强的节点，我们可以让其 CPU 超售，从而能够调度更多的 Pod，提高资源的分配效率；
Pod 维度超售，其实是配置 Limit 和 Request 之间的比例，同时在用户心里模型上，对于用户声明的资源到底保证的是 Limit 还是 Request，其实不同的企业有不同的方案；比如在某些企业就是以 Limit 来作为研发资源保证，研发在申请资源的时候填写 Limit，容器平台做 Limit 和 Request 的超售转换，从而提高资源的分配效率；而在云原生的模式中，Limit 和 Request 的概念直接暴露给了用户，在 Kubernetes 中，Request 指的是可以保证的资源（因为 Kubernetes 按照 Request 调度分配资源）最少可以使用多少资源，而 Limit 指的是资源限制，最多使用多少资源。

而要解决这个问题，根本原因就在于当前的体系是按照静态资源调度，而非动态资源调度，如果我们按照容器的 Usage（可以加上一定的缓冲区间）资源去调度，而不是按照容器的 Request 资源去调度，那么我们就能做到真实的按量付费，就是真实的 Serverless 所宣称的按量计费。

ProphetPilot 会统一进行数据计算，准确推荐出容器的资源消耗，并给出合适的资源配置建议；让容器的 Request 逼近 Usage，从而让调度器按照 Usage 调度资源。

单机容器调度

容器在单机层面，会根据分配的资源 Request 和 Limit 来做资源分配调度和资源隔离，虽然可以在一定程度上做到资源的隔离，做到资源的共享和复用，但是 Kubernetes 提供的这个资源模型目前还是比较基础和简单的模型；

Kubernetes 直接使用 Request 来调度，对 Node 进行装箱，在单机层面，Linux 采用 Cgroup 的 CPU Share 模式来为容器分配 CPU 资源，按照 CPU Share 权重划分 CPU 时间片，如果将一个 Node 按照 Request 装满，则 Node 的 CPU 资源将按照 CPU Share 加权划分给所有的容器；看起来是一个完美的计算模型，但是其实内核并不能完美的处理所有场景下的资源争抢。

比如，在离线混部场景下，离线业务利用多核并行计算提高计算资源利用率，若没有进行独占绑核划分，此时在线业务如果有流量高峰，就会受到离线业务的干扰，从而影响在线业务的SLA；内核层解决这个问题，需要非常雄厚的技术实力，往往还是得进行应用优先级划分，进行取舍，才能让资源利用率提升的同时，高优保证高优先级应用，而丢弃低优先级应用，所以，划分应用优先级，或许是未来的方向，这个不仅仅是应用层，从应用层，到 Kubernetes，再到内核层，这个体系需要疏通，当前的 Kubernetes 使用的默认优先级只有三种，未来可能会支持更多优先级。

（图片来源 https://mp.weixin.qq.com/s/Cbck85WmivAW0mtMYdeEIw)

ProphetPilot 允许用户定义多种负载优先级，从而能够针对不同优先级应用采取不同的服务保证；值得注意的是，过多的优先级，会导致容器驱逐产生级联效应，所谓级联效应是指，一个容器因为在当前节点资源不足被驱逐，然后被调度到另一个节点，结果导致另一个节点上更低优先级的 Pod 被驱逐，要避免这种情况，ProphetPilot 将采取弹性实例，从而防止级联驱逐发生。

同时，有些客户希望在离线混部的时候，离线应用不能无限制被驱逐，要求离线应用必须有一定的 SLA，保证其在规定时间内跑完，对于这种需求，我们采用动态优先级调度和弹性实例结合的方式，在离线 Pod 被第一次驱逐后，就会考虑其驱逐次数和计算时间，如果计算发现继续驱逐的话，无法保障 SLA，则进行优先级提高调度，如果还是没有资源，则进行弹性公有云实例。

资源层

在云计算普及的今天，云厂商提供了一系列可供选择的 IaaS 计算资源、存储资源、网络资源，比如就腾讯云的CVM来说，就有几百种产品规格，智能容器模型在资源层应该选择出最适合的 IaaS 资源，从而保证容器能够稳定、高效、最低成本的方式运行。

计费模式

腾讯云云服务器提供了按量付费、预付费、竞价实例三种计费模式，不同的计费模式有不同的使用场景；ProphetPilot 能够分析客户集群历史的实例计费模式，结合集群资源的未来走势和用户对于成本的诉求，推荐不同的计费实例；

按量计费：比如在集群中，如果用户设置了电商大促等策略，则可以在规定时间开启使用按量计费的实例，在大促活动结束则停止；
包年包月：比如在集群中，如果观察有服务长期运行超过1个月甚至更长，但是却选择了按量计费，此时如果更换为包年包月将会更加划算；
竞价实例：比如集群资源不足，同时当前可能只是需要短时间运行离线任务，对于服务保证要求不高，但是对于成本有控制，则此时可以采用弹性竞价实例的模式；

机型配置

机型主要是CPU、内存、磁盘等配置，包括硬件型号以及规格大小，ProphetPilot 通过评估集群节点资源，以及业务规模，未来增长趋势，在满足业务资源需求的前提下，通过搜索不同机型配置和价格空间，最后推荐出合理的机型配比；

云模式

云的当前演进模式是混合云，而客户 IDC 和公有云的弹性资源拉通，评估 IDC 资源是否充足，是否需要开启弹性到公有云，以及弹出何种 IaaS 资源实例，是企业目前的难题，当前的模式往往还是传统的提前按规划批量采购模式，企业一部分资源是 IDC，一部分资源在公有云，还是存在资源闲置问题；打通混合云网络后，企业将能够实现真实的随时按需弹性。

总之，在资源层面，ProphetPilot 会分析用户集群的节点规格分布，资源使用效率，最终推荐客户最合适的计费模式、节点规格配置。

总结

Kubernetes 集群资源利用率低的本质是 Request 机制，即资源的预留和占位机制。业务为了保证自己服务的稳定性，通常习惯申请较大的 Request，势必会造成较大的资源浪费。如果能按照 Usage 来调度资源、调整负载，甚至是按照 Usage 来付费，做到真正的按需使用，这是成本管理终极形态，也是 ProphetPilot 的目标状态，让业务无需管理和配置任何资源的同时，保障服务的稳定性，实现“用完即走，随用随取”。

如果您有任何建议或诉求，欢迎通过小助手与我们联系。