kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)

作者 田奇,腾讯云高级工程师,专注大规模离在线混部,弹性伸缩,云原生成本优化,熟悉Kubernetes,关注云原生大数据、AI。
王孝威,腾讯云容器产品经理,热衷于为客户提供高效的 Kubernetes 使用方式,为客户极致降本增效服务。
前言 随着 Kubernetes 的普及,企业已经普遍接受了容器,正在向云原生演进。但是当前的 Kubernetes 只解决云原生的第一步(Day 1),就是利用容器编排调度和声明式API等,来解决资源获取、应用部署、高可用容灾、基础运维等难题。但是目前采纳 Kubernetes 的企业也遇到了前往高级阶段的问题,运营庞大复杂的 Kubernetes 集群是非常困难的,例如:

  • 如何评估资源需求?例如:原生 Kubernetes 的调度需要根据容器对资源的请求(Request),一个容器到底需要多少资源量?集群整体的资源量该设置成多少?节点数多少才合适?
  • 如何达到真正的智能扩缩?如何灵活处理具有波峰波谷的变换流量?如果要设置 HPA,到底该用哪个指标?副本数的变换范围如何设置?
  • 如何查看容器的成本状况?目前集群本身可以查看资源使用量、利用率情况,但这些资源对应的账单具体是多少?Kubernetes 集群里面可能有节点、硬盘、网络、LB 等多种资源,如何聚合这些离散的资源账单,并以不同维度展示?
  • 如何提高资源使用效率?如何识别无效和不合理的资源申请负载?如何最合理的选择节点的规格和计费类型?
  • ...
    以上这些问题都需要在运营 Kubernetes 的第二步(Day 2)来解决:
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

降低用户的运营复杂度,为 Kubernetes 插上智能引擎,减轻客户的运营负担,是 TKE 一直以来致力的事情。在前几期的“降本增效”系列文章中,我们谈到了成本控制系统、常用的利用率提升工具、资源利用率现象剖析、理解和应用弹性。TKE 在用户需求的基础上,提出容器智能 ProphetPilot,本文将从背景现状、产品功能、分层模型阐述 ProphetPilot 相关概念。
背景和现状 当前 TKE 上有很多关于弹性、资源利用率、成本节约、负载感知调度组件,比如 HPA、HPC、VPA、CA、在离线混部等产品,更多可查看资源利用率提升工具大全。虽然目前 TKE 为客户带来了丰富的降本增效产品选择,但是存在以下几个方面的不足;
  1. 用户面对这么多伸缩组件,往往难以抉择,当前应用最为广泛的也是有 HPA 和 CA,其他的组件往往不敢使用或者不知道何时该使用,以及为什么需要采用
  2. 有些组件是社区组件或 Kubernetes 原生能力,功能往往还不够强大,比如 HPA,扩缩容感知不够及时和准确,并不一定满足客户的需求
  3. 组件之间缺乏协调一致的体验,各自拥有各自的功能,甚至一起使用会发生冲突,例如 VPA 和 HPA 不能同时使用 CPU 或内存的指标
下图对比了各个组件之间的联系,主要从 Observer、Analyzer、Action 来说明各个维度的关系:
  • Observer(观测):监控和收集工作负载的运行状态
  • Analyzer(分析):分析它的运行模式。例如:
    例1. 负载的 CPU 使用量是否是周期性的变化?
    例2. 负载是否在某些固定时刻流量会上升或下降?
    例3. 负载里容器的 Request 是否设置合理?等等
  • Action(动作):根据分析负载的运行模式,执行最佳的策略。以 Analyzer 维度的例子来看,例1可以推荐使用 HPA,例2可以推荐使用 HPC,例3可以推荐使用 VPA
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

功能简介 ProphetPilot 主要解决 Observer 和 Analyzer 两大部分,其功能可贯穿弹性和混部所有组件,针对开源组件无法满足需求的场景,TKE 采用自研 Executor,来满足快速发展的业务需求:
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

推荐中心
推荐是整个成本管理中心的大脑,他会衡量和计算 Cost(成本) 和 Efficiency(效率,主要指的是资源利用率)、Reliability(可用性、稳定性) 的关系。例如:
  • 当前的集群是不是适合使用在离线混部。为什么适合使用在离线混部?原因可能是因为它观察到大部分容器的指标是周期高低峰,但是又没有稳定的离线高负载容器,因此建议用户执行混部,从而提升资源使用效率;
  • 当前的集群中,有些容器的资源利用率一直是平稳型,且资源较低,则推荐进行 VPA 操作,变更 Request 和 Limit,如果用户是“富容器”,不愿意接受显示的 Request Limit 变更,则直接进行混部建议,因为混部会修改CGroup,这个对用户不可见,但是可以提高资源利用率,且调度更多 Pod;
  • 当前的集群负载情况,是不是需要进行 CA操作?传统的 CA 只是简单感知 Pod Pending,基于 Request 计算资源不足。然而此时集群的资源使用率可能是非常低的,此时更合适的操作是 VPA。由于目前很多企业无法接受 VPA 变更 Pod 的 Request 时会重建 Pod,TKE也即将支持原地更新;
  • 当前是否能够进行 HPA?传统的 HPA 只是简单的从监控定期更新数据。突发流量时,感知缓慢,而推荐中心能够协同本地感知,联合其他副本一起协同,快速进行 HPA 的动作,从而做到秒级 HPA 快速突发扩容;采用 eBPF,在感知到某种系统调用过度时候,直接配置事件触发扩容;
  • 针对传统的 PaaS 平台,比如 DBA 集群,这部分集群的应用特征都具备数据库的特性,而经验丰富的 DBA 对数据库的特征、参数调优具备更多的优化经验,我们允许 PaaS 平台自定义推荐中心的推荐策略,从而让 PaaS 平台方做到极致的业务资源优化,成本控制,稳定性保证;
  • 针对传统的各类通用 Web 服务,计算服务等非中间件、DBA 业务,这部分客户,一般都是尽量减少其运维量,为了降低这部分客户的管理复杂度,运维成本,TKE 会结合真实的监控数据,根据分层模型,推荐以下内容:
    1. 智能推荐 Workload 的 Request 和 Limit;
    2. 集群资源评估,根据集群历史负载水平,评估资源量;
    3. 根据当前 Workload 的 QPS 和负载情况,推荐合理的副本数;
    4. 预测当前 Node 和 Pod 的资源使用量,反馈给调度器,做智能调度;
    5. 推荐组合购买的云实例,以最低价格、最合理的配置基于用户购买建议。
成本分析
成本分析重点在于从成本的角度观察集群的成本使用情况,因为现有的 Kubernetes 集群中,只能看到资源的使用情况,而无法分析和观察更具体的成本维度的数据。主要功能点包含:
  1. 负责展示业务的成本消耗,资源消耗,资源使用效率
  2. 分析 Top10 资源消耗的业务,推动业务进行资源优化、改造
  3. 分析集群的下月预估成本,每个资源对象的下月预估成本
  4. 查看成本曲线、业务增长曲线和成本曲线对比
  5. 根据推荐中心推荐的方案预估的成本节省
  6. 多维度的观测:节点/命名空间/工作负载/Pod/Container
  7. 多周期的观测:日/周/月/自定义
  8. 定期生成报告
  9. 保存历史重要数据
告警通知
不管是否自动执行策略,在 ProphetPilot 发现集群中某些配置不合理,或某些动作需要执行时,都会提供相关的提示和告警。此外,每一次策略推荐,动作执行,都会进行数据保存,方便用户查看历史事件,以及事件触发的原因,方便进行历史回溯。
策略
策略是推荐中心推荐的方案执行的方式,ProphetPilot 将提供多种策略,主要分成四种类型:
  1. 自动执行策略:完全的自定义执行策略,包括自定义设置一些触发标准,例如:电商里的订单业务对稳定性要求很高,可以设置比较大的资源使用冗余,及时资源利用率很低也被判断为正常情况。但一些离线批处理任务优先级不高,对时延不敏感,可以设置较高的资源利用率标准;
  2. 计划执行策略:在未来的某一时刻点执行某种策略;或者是当推荐动作产生后,延迟一定时间执行动作。例如当节点数缩容、工作负载水平缩容时,可以尽量慢一些,防止流量再次飙升;
  3. 周期策略:类似 CronJob,定时按周期执行某些策略;
  4. 人工确认策略:完全手工的行为,ProphetPilot 不会自动执行这些策略,当推荐动作产生后,会通过告警通知客户手工执行策略。
执行引擎
执行引擎就是执行的具体动作,例如 HPA、VPA、在离线混部等动作,更多可查看资源利用率提升工具大全。
容器智能分层模型 应用层
随着云原生、微服务架构的普及,一套企业应用往往涉及到多个微服务,服务之间存在微妙的依赖关系,理解应用的微服务之间的关系,可以让弹性伸缩拥有更加全面的视角,防止单一的局部视角,导致扩容了 Workload 也没有达到真实的效果,从而浪费了资源和成本。
比如下图中,传统的弹性伸缩往往只根据资源使用率,当 CPU 使用率很高的时候,触发该 Workload 的扩容,但是 CPU 使用率高,可能只是假象,在下述列子中,NGINX 日志写的速率,Kafka 生产者写入 Kafka 集群的速率,日志偏移更改速率,消费速率,以及 ES 索引计算效率都有关联性;找到更关键的指标比如 Kafka 的生产速率就是比 CPU 更好的扩缩容指标:
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

ProphetPilot 理解应用层不同的应用特征,市面上的这些中间件、数据库等基础产品都可以作为应用划分,而服务本身也可以根据重要程度,为应用划分出不同的等级,微服务之间的调用关系,则可以通过 ServiceMesh 进行获取,从而在应用层建立起 Workload 的相关性依赖图,做到业务的整体扩缩,而不是 Workload 的单独扩缩。
调度层
分布式资源调度 当前的 Kubernetes 只解决企业云原生的第一步(Day 1),让企业能够利用容器以及 Kubernetes 编排调度,来解决资源获取、应用部署、高可用容灾、运维等难题,但是它在资源模型上,还处在初级阶段,比如研发需要评估服务到底需要多少资源,然后填写 Request,最终 Kubernetes 按照 Request 做静态资源调度,将 Pod 调度到合适的Node 上。
这样做将面临以下问题:
  1. 研发为了服务稳定性,往往过度评估资源,造成浪费;
  2. 研发根本不知道怎么评估,甚至是没有评估资源,相信大部分研发没有办法一眼看穿自己的服务需要多少资源,造成资源不足,或者是资源浪费;
  3. Kubernetes 是按照静态的资源调度的,实际容器运行后资源的使用状态和调度的静态资源决策是不一致的,造成资源浪费,或者资源争抢严重。
当前的普遍做法是做超售,一般是两个维度:
  1. Node 维度超售,给节点设置超售,比如节点本身只有48核,但是可以设置超售2倍,让他给调度器造成一种假象,按照96核调度;因为不同的节点计算能力和内存不匹配,计算能力强的节点,我们可以让其 CPU 超售,从而能够调度更多的 Pod,提高资源的分配效率;
  2. 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 使用的默认优先级只有三种,未来可能会支持更多优先级。
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

(图片来源 https://mp.weixin.qq.com/s/Cb...
ProphetPilot 允许用户定义多种负载优先级,从而能够针对不同优先级应用采取不同的服务保证;值得注意的是,过多的优先级,会导致 容器驱逐产生级联效应,所谓级联效应是指,一个容器因为在当前节点资源不足被驱逐,然后被调度到另一个节点,结果导致另一个节点上更低优先级的Pod被驱逐,要避免这种情况,ProphetPilot 将采取弹性实例,从而防止级联驱逐发生。
同时,有些客户希望在离线混部的时候,离线应用不能无限制被驱逐,要求离线应用必须有一定的 SLA,保证其在规定时间内跑完,对于这种需求,我们采用动态优先级调度和弹性实例结合的方式,在离线 Pod 被第一次驱逐后,就会考虑其驱逐次数和计算时间,如果计算发现继续驱逐的话,无法保障 SLA,则进行优先级提高调度,如果还是没有资源,则进行弹性公有云实例。
资源层
在云计算普及的今天,云厂商提供了一系列可供选择的 IaaS 计算资源、存储资源、网络资源,比如就腾讯云的CVM来说,就有几百种产品规格,智能容器模型在资源层应该选择出最适合的 IaaS 资源,从而保证容器能够稳定、高效、最低成本的方式运行。
计费模式 腾讯云云服务器提供了按量付费、预付费、竞价实例三种计费模式,不同的计费模式有不同的使用场景;ProphetPilot 能够分析客户集群历史的实例计费模式,结合集群资源的未来走势和用户对于成本的诉求,推荐不同的计费实例;
  1. 按量计费:比如在集群中,如果用户设置了电商大促等策略,则可以在规定时间开启使用按量计费的实例,在时间结束则下掉;
  2. 包年包月:比如在集群中,如果观察有服务长期运行超过1个月甚至更长,但是却选择了按量计费,此时如果更换为包年包月将会更加划算;
  3. 竞价实例:比如集群资源不足,同时当前可能只是需要短时间运行离线任务,对于服务保证要求不高,但是对于成本有控制,则此时可以采用弹性竞价实例的模式;
机型配置 机型主要是CPU、内存、磁盘等配置,包括硬件型号以及规格大小,ProphetPilot 通过评估集群节点资源,以及业务规模,未来增长趋势,在满足业务资源需求的前提下,通过搜索不同机型配置和价格空间,最后推荐出合理的机型配比;
云模式 云的当前演进模式是 混合云,而客户 IDC 和 公有云的弹性资源拉通,评估 IDC 资源是否充足,是否需要开启弹性到公有云,以及弹出何种 IaaS 资源实例,是企业目前的难题,当前的模式往往还是传统的提前按规划批量采购模式,企业一部分资源是 IDC,一部分资源在公有云,还是存在资源闲置问题;打通混合云网络后,企业将能够实现真实的随时按需弹性。
总之,在资源层面,ProphetPilot 会分析用户集群的节点规格分布,资源使用效率,最终推荐客户最合适的计费模式、节点规格配置。
总结 【kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)】Kubernetes 集群资源利用率低的本质是 Request 机制,即资源的预留和占位机制。业务为了保证自己服务的稳定性,通常习惯申请较大的 Request,势必会造成较大的资源浪费。如果能按照 Usage 来调度资源、调整负载,甚至是按照 Usage 来付费,做到真正的按需使用,这是成本管理终极形态,也是 ProphetPilot 的目标状态,让业务无需管理和配置任何资源的同时,保障服务的稳定性,实现“用完即走,随用随取”。如果您有任何建议或诉求,欢迎通过小助手与我们联系。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!
kubernetes 降本增效标准指南|ProphetPilot(容器智能成本管理引擎)
文章图片

    推荐阅读