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

田奇,腾讯云高级工程师,专注大规模离在线混部,弹性伸缩,云原生成本优化,熟悉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 为客户带来了丰富的降本增效产品选择,但是存在以下几个方面的不足;

  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

功能简介

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

推荐中心

推荐是整个成本管理中心的大脑,它会衡量  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 更好的扩缩容指标:

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 使用的默认优先级只有三种,未来可能会支持更多优先级。

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

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

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

资源层

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

计费模式

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

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

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

云模式

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

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

总结

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

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

  往期精选推荐  

  • 公有云上构建云原生 AI 平台的探索与实践 - GOTC 技术论坛分享回顾
  • 腾讯云TKE-基于 Cilium 统一混合云容器网络(下)
  • 如何削减 50% 机器预算?“人机对抗”探索云端之路
  • 拥抱云原生,腾讯发布TCSS容器安全服务!
  • 腾讯云原生支撑起14亿人项目背后的技术揭秘