关于腾讯云: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/Cb…

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 的指标状态，让业务无需治理和配置任何资源的同时，保障服务的稳定性，实现“用完即走，随用随取”。如果您有任何倡议或诉求，欢送通过小助手与咱们分割。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！