背景

私有云的倒退为业务的稳定性、可拓展性、便利性带来了极大帮忙。这种用租代替买、并且提供欠缺的技术支持和保障的服务，理当为业务带来降本增效的成果。但实际上业务上云并不意味着老本肯定较少，还需适配云上业务的利用开发、架构设计、治理运维、正当应用等多方面解决方案，能力真正助力业务的降本增效。在《Kubernetes 降本增效规范指南》系列 的上一篇文章《容器化计算资源利用率景象分析》中可看到，IDC 上云后资源利用率进步无限，即便曾经容器化，节点的均匀利用率仍旧仅在 13% 左右，资源利用率的晋升任重道远。

本篇文章将带你理解：
为什么 Kubernetes 集群中的 CPU 和内存资源利用率 通常都如此之低？
现阶段在 TKE 下面有哪些产品化的办法能够轻松晋升资源利用率？

资源节约场景

为何资源利用率通常都如此之低？首先能够看看几个业务的理论应用资源场景：

1. 资源预留普遍存在 50% 以上的节约

Kubernetes 中的 Request(申请) 字段用于治理容器对 CPU 和内存资源预留的机制，保障容器至多能够达到的资源量，该局部资源不能被其余容器抢占，具体可查看。当 Request 设置过小，无奈保障业务的资源量，当业务的负载变高时有力承载，因而用户通常习惯将 Request 设置得很高，以保障服务的可靠性。但实际上，业务在大多数时段时负载不会很高。以 CPU 为例，下图是某个理论业务场景下容器的资源预留（Request）和理论使用量（CPU_Usage）关系图：资源预留远大于理论使用量，两者之间差值所对应的资源不能被其余负载应用，因而 Request 设置过大势必会造成较大的资源节约。

如何解决这样的问题？现阶段须要用户本人依据理论的负载状况设置更正当的 Request、以及限度业务对资源的有限申请，避免资源被某些业务适度占用。这里能够参考后文中的 Request Quota 和 Limit Ranges 的设置。
此外，TKE 将推出 Request 举荐产品，帮忙用户智能放大 Request 和 Usage 之间的差值，在保障业务的稳定性的状况下无效晋升资源利用率。

2. 业务资源波峰波谷景象广泛，通常波谷工夫大于波峰工夫，资源节约显著

大多数业务存在波峰波谷，例如公交系统通常在白天负载减少，夜晚负载缩小；游戏业务通常在周五早晨开始呈现波峰，在周日晚开始呈现波谷。如下图所示：同一业务在不同的时间段对资源的申请量不同，如果用户设置的是固定的 Request，f 在负载较低时利用率很低。

这时能够通过动静调整正本数以高资源利用率承载业务的波峰波谷，能够参考后文中的 HPA、HPC、CA。

3. 不同类型的业务，导致资源利用率有较大差别

在线业务通常白天负载较高，对时延要求较高，必须优先调度和运行；而离线的计算型业务通常对运行时段和时延要求绝对较低，实践上能够在在线业务波谷时运行。此外，有些业务属于计算密集型，对 CPU 资源耗费较多，而有些业务属于内存密集型，对内存耗费较多。

如上图所示，通过在离线混部能够动静调度离线业务和在线业务，让不同类型业务在不同的时间段运行以晋升资源利用率。对于计算密集型业务和内存密集型业务，能够应用亲和性调度，为业务调配更适合的节点，无效晋升资源利用率。具体形式可参考后文中的离在线混部和亲和性调度。

在 Kubernetes 上晋升资源利用率的办法

腾讯云容器服务 TKE 基于大量的用户理论业务，曾经产品化了一系列工具，帮忙用户轻松无效的晋升资源利用率。次要从两方面着手：一是利用原生的 Kubernetes 能力手动进行资源的划分和限度；二是联合业务个性的自动化计划。

1. 如何资源划分和限度

构想，你是个集群管理员，当初有 4 个业务部门应用同一个集群，你的责任是保障业务稳定性的前提下，让业务真正做到资源的按需应用。为了无效晋升集群整体的资源利用率，这时就须要限度各业务应用资源的下限，以及通过一些默认值避免业务适量应用。

现实状况下，业务应该依据理论状况，设置正当的 Request 和 Limit。（Request 用于对资源的占位，示意容器至多能够取得的资源；Limit 用于对资源的限度，示意容器至少能够取得的资源。）这样更利于容器的衰弱运行、资源的充沛应用。但实际上用户常常遗记设置容器对资源的 Request 和 Limit。此外，对于共享应用一个集群的团队 / 我的项目来说，他们通常都将本人容器的 Request 和 Limit 设置得很高以保障本人服务的稳定性。如果你应用的是 TKE 的控制台，创立负载时会给所有的容器设置如下默认值。该默认值是 TKE 依据实在业务剖析预估得出，和具体的业务需要之间可能存在偏差。

为了更细粒度的划分和治理资源，能够在 TKE 上设置命名空间级别的 Resource Quota 以及 Limit Ranges。

1.1 应用 Resource Quota 划分资源

如果你治理的某个集群有 4 个业务，为了实现业务间的隔离和资源的限度，你能够应用命名空间和 Resource Quota

Resource Quota 用于设置命名空间资源的应用配额，命名空间是 Kubernetes 集群外面的一个隔离分区，一个集群外面通常蕴含多个命名空间，例如 Kubernetes 用户通常会将不同的业务放在不同的命名空间里，你能够为不同的命名空间设置不同的 Resource Quota，以限度一个命名空间对集群整体资源的使用量，达到预调配和限度的成果。Resource Quota 次要作用于如下方面，具体可查看。

1. 计算资源：所有容器对 CPU 和 内存的 Request 以及 Limit 的总和
2. 存储资源：所有 PVC 的存储资源申请总和
3. 对象数量：PVC/Service/Configmap/Deployment 等资源对象数量的总和

Resource Quota 应用场景

• 给不同的我的项目 / 团队 / 业务调配不同的命名空间，通过设置每个命名空间资源的 Resource Quota 以达到资源分配的目标
• 设置一个命名空间的资源应用数量的下限以进步集群的稳定性，避免一个命名空间对资源的多度强占和耗费

TKE 上的 Resource Quota

TKE 上曾经实现对 Resource Quota 的产品化，你能够间接在控制台利用 Resource Quota 限度一个命名空间的资源使用量，具体可参考文档。

1.2 应用 Limit Ranges 限度资源

用户常常遗记设置资源的 Request 和 Limit，或者将值设置得很大怎么办？作为管理员，如果能够为不同的业务设置不同资源应用默认值以及范畴，能够无效缩小业务创立时的工作量同时，限度业务对资源的适度强占。

与 Resource Quota 对命名空间整体的资源限度不同，Limit Ranges 实用于一个命名空间下的单个容器。能够避免用户在命名空间内创立对资源申请过小或过大容器，避免用户遗记设置容器的 Request 和 Limit。Limit Ranges 次要作用于如下方面，具体可查看。

1. 计算资源：对所有容器设置 CPU 和内存使用量的范畴
2. 存储资源：对所有 PVC 能申请的存储空间的范畴
3. 比例设置：管制一种资源 Request 和 Limit 之间比例
4. 默认值：对所有容器设置默认的 Request/Limit，如果容器未指定本人的内存申请和限度，将为它指定默认的内存申请和限度

Limit Ranges 应用场景

1. 设置资源应用默认值，以防用户忘记，也能够防止 QoS 驱赶重要的 Pod
2. 不同的业务通常运行在不同的命名空间里，不同的业务通常资源应用状况不同，为不同的命名空间设置不同的 Request/Limit 能够晋升资源利用率
3. 限度容器个对资源应用的上上限，保障容器失常运行的状况下，限度其申请过多资源

TKE 上的 Limit Ranges

TKE 上曾经实现对 Limit Ranges 的产品化，你能够间接在控制台治理命名空间的 Limit Ranges，具体可参考文档。

2. 自动化晋升资源利用率的办法

下面提到的利用 Resource Quota 和 Limit Ranges 来调配和限度资源的办法依赖教训和手工，次要解决的是资源申请和调配不合理。如何更自动化的动静调整以晋升资源利用率是用户更关怀的问题，接下来从弹性伸缩、调度、在离线混部三大产品化的方向，详述如何晋升资源利用率。

2.1 弹性伸缩

2.1.1 通过 HPA 按指标弹性扩缩容

如下面资源节约场景 2 所说，如果你的业务是存在波峰波谷的，固定的资源 Request 注定在波谷时会造成资源节约，针对这样的场景，如果波峰的时候能够主动减少业务负载的正本数量，波谷的时候能够主动缩小业务负载的正本数量，将无效晋升资源整体利用率。

HPA（Horizontal Pod Autoscaler）能够基于一些指标（例如 CPU、内存的利用率）主动扩缩 Deployment 和 StatefulSet 中的 Pod 正本的数量，达到工作负载稳固的目标，真正做到按需应用。

HPA 应用场景

1. 流量突发：忽然流量减少，负载过载时会主动减少 Pod 数量以及时响应
2. 主动缩容：流量较少时，负载对资源的利用率过低时会主动缩小 Pod 的数量以避免浪费

TKE 上的 HPA

TKE 基于 Custom Metrics API 反对许多用于弹性伸缩的指标，涵盖 CPU、内存、硬盘、网络以及 GPU 相干的指标，笼罩绝大多数的 HPA 弹性伸缩场景，具体列表请参见 主动伸缩指标阐明。此外，针对例如基于业务单正本 QPS 大小来进行主动扩缩容等简单场景，可通过装置 prometheus-adapter 来实现主动扩缩容，具体可参考文档。

2.1.2 通过 HPC 定时扩缩容

假如你的业务是电商平台，双十一要进行促销流动，这时能够思考应用 HPA 主动扩缩容。然而 HPA 须要先监控各项指标后，再进行反馈，可能扩容速度不够快，无奈及时承载高流量。针对这种有预期的流量暴增，如果能提前产生正本扩容，将无效承载流量井喷。
HPC（HorizontalPodCronscaler）是 TKE 自研组件，旨在定时管制正本数量，以达到提前扩缩容、和提前触发动静扩容时资源有余的影响，相较社区的 CronHPA，额定反对：

1. 与 HPA 联合：能够实现定时开启和敞开 HPA，让你的业务在顶峰时更弹性
2. 例外日期设置：业务的流量不太可能永远都是法则的，设置例外日期能够缩小手工调整 HPC
3. 单次执行：以往的 CronHPA 都是永恒执行，相似 Cronjob，单次执行能够更灵便的应答大促场景

HPC 应用场景

以游戏服务为例，从周五早晨到周日早晨，游戏玩家数量暴增。如果能够将游戏服务器在星期五早晨前扩充规模，并在星期日早晨后缩放为原始规模，则能够为玩家提供更好的体验。如果应用 HPA，可能因为扩容速度不够快导致服务受影响。

TKE 上的 HPC

TKE 上曾经实现对 HPC 的产品化，但你须要提前在”组件治理“外面装置 HPC，HPC 应用 CronTab 语法格局。

装置：

应用：

2.1.3 通过 CA 主动调整节点数量

下面提到的 HPA 和 HPC，都是在业务负载层面的主动扩缩正本数量，以灵便应答流量的波峰波谷，晋升资源利用率。然而对于集群整体而言，资源总数是固定的，HPA 和 HPC 只是让集群有更多空余的资源，是否有一种办法，能在集群整体较“空”时回收局部资源，能在集群整体较“满”时裁减集群整体资源？因为集群整体资源的使用量间接决定了账单费用，这种集群级别的弹性扩缩将真正帮忙你节俭应用老本。

CA（Cluster Autoscaler）用于主动扩缩集群节点数量，以真正实现资源利用率的晋升，并间接作用于用户的费用，是降本增效的要害。

CA 应用场景

1. 在业务波峰时，依据业务突增的负载扩容适合的节点
2. 在业务波谷时，依据资源的闲暇状况开释多余的节点

TKE 上的 CA

TKE 上的 CA 是以节点池的状态来让用户应用的，CA 举荐和 HPA 一起应用：HPA 负责应用层的扩缩容，CA 负责资源层（节点层）的扩缩容，当 HPA 扩容造成集群整体资源有余时，会引发 Pod 的 Pending，Pod Pending 会触发 CA 裁减节点池以减少集群整体资源量，整体扩容逻辑可参考下图：

具体的参数配置形式以及利用场景可参考《像治理 Pod 一样治理 Node》，或者可参考腾讯云容器服务官网文档。

2.2 调度

Kubernetes 调度机制是 Kubernetes 原生提供的一种高效优雅的资源分配机制，它的外围性能是为每个 Pod 找到最适宜它的节点，在 TKE 场景下，调度机制帮忙实现了应用层弹性伸缩到资源层弹性伸缩的过渡。通过正当利用 Kubernetes 提供的调度能力，依据业务个性配置正当的调度策略，也能无效进步集群中的资源利用率。

2.2.1 节点亲和性

假使你的某个业务是 CPU 密集型，不小心被 Kubernetes 的调度器调度到内存密集型的节点上，导致内存密集型的 CPU 被占满，但内存简直没怎么用，会造成较大的资源节约。如果你能为节点设置一个标记，表明这是一个 CPU 密集型的节点，而后在创立业务负载时也设置一个标记，表明这个负载是一个 CPU 密集型的负载，Kubernetes 的调度器会将这个负载调度到 CPU 密集型的节点上，这种寻找最合适的节点的形式，将无效晋升资源利用率。

创立 Pod 时，能够设置节点亲和性，即指定 Pod 想要调度到哪些节点上（这些节点是通过 K8s Label）来指定的。

节点亲和性应用场景

节点亲和性非常适合在一个集群中有不同资源需要的工作负载同时运行的场景。比如说，腾讯云的 CVM（节点）有 CPU 密集型的机器，也有内存密集型的机器。如果某些业务对 CPU 的需要远大于内存，此时应用一般的 CVM 机器，势必会对内存造成较大节约。此时能够在集群里增加一批 CPU 密集型的 CVM，并且把这些对 CPU 有较高需要的 Pod 调度到这些 CVM 上，这样能够晋升 CVM 资源的整体利用率。同理，还能够在集群中治理异构节点（比方 GPU 机器），在须要 GPU 资源的工作负载中指定须要 GPU 资源的量，调度机制则会帮忙你寻找适合的节点去运行这些工作负载。

TKE 上的节点亲和性

TKE 提供与原生 Kubernetes 完全一致的亲和性应用形式，你可通过控制台或配置 YAML 的形式应用此项性能，具体可参考。

2.2.2 动静调度器

原生的 Kubernetes 调度策略偏向于调度 pod 到节点残余资源较多的节点上，比方默认的 LeastRequestedPriority 策略。然而原生调度策略存在一个问题：这样的资源分配是动态的，Request 不能代表资源实在应用状况，因而肯定会存在肯定水平的节约。因而，如果调度器能够基于节点的理论资源利用率进行调度，将肯定水平上解决资源节约的问题。

TKE 自研的动静调度器所做的就是这样的工作。动静调度器的外围原理如下：

动静调度器的应用场景

除了升高资源节约，动静调度器还能够很好的缓解集群调度热点的问题。

1. 动静调度器会统计过来一段时间调度到节点的 Pod 数目，防止往同一节点上调度过多的 Pod
2. 动静调度器反对设置节点负载阈值，在调度阶段过滤掉超过阈值的节点。

TKE 上的动静调度器

你能够在扩大组件外面装置和应用动静调度器：

更多对于动静调度器的使用指南，能够参考《TKE 重磅推出全链路调度解决方案》和官网文档。

2.3 在离线业务混部

如果你既有在线 Web 服务业务，又有离线的计算服务业务，借助 TKE 的在离线业务混部技术能够动静调度和运行不同的业务，晋升资源利用率。

在传统架构中，大数据业务和在线业务往往部署在不同的资源集群中，这两局部业务互相独立。但大数据业务个别更多的是离线计算类业务，在夜间处于业务顶峰，而在线业务恰恰相反夜间经常处于空载状态。云原生技术借助容器残缺 (CPU，内存，磁盘 IO，网络 IO 等) 的隔离能力，及 Kubernetes 弱小的编排调度能力，实现在线和离线业务混合部署，从而使在离线业务充分利用在线业务闲暇时段的资源，以进步资源利用率。

在离线业务混部应用场景

在 Hadoop 架构下，离线作业和在线作业往往分属不同的集群，然而在线业务、流式作业具备显著的波峰波谷个性，在波谷时段，会有大量的资源处于闲置状态，造成资源的节约和老本的晋升。在离线混部集群，通过动静调度削峰填谷，当在线集群的使用率处于波谷时段，将离线任务调度到在线集群，能够显著的进步资源的利用率。然而，Hadoop Yarn 目前只能通过 NodeManager 上报的动态资源状况进行调配，无奈基于动静资源调度，无奈很好的反对在线、离线业务混部的场景。

TKE 上的在离线混部

在线业务具备显著的波峰浪谷特色，而且法则比拟显著，尤其是在夜间，资源利用率比拟低，这时候大数据管控平台向 Kubernetes 集群下发创立资源的申请，能够进步大数据利用的算力，具体可参考。

如何衡量资源利用率与稳定性

在企业的运维工作中，除了老本，零碎的稳定性也是非常重要的指标。如何在两者间达到均衡，可能是很多运维人员心中的“痛点”。一方面，为了降低成本，资源利用率当然是越高越好，然而资源利用率达到肯定水位后，负载过高极有可能导致业务 OOM 或 CPU 抖动等问题。
为了减小企业老本管制之路上的顾虑，TKE 还提供了“兜底神器“– 重调度器 来保障集群负载水位在可控范畴内。
重调度器是动静调度器是一对好搭档（它们的关系能够参考下图），就像它的名字一样，它次要负责“爱护”节点中曾经负载比拟“危险”的节点，优雅驱赶这些节点上的业务。

TKE 上的重调度器

能够在扩大组件外面装置和应用重调度器：

更多对于重调度器的使用指南，能够参考《TKE 重磅推出全链路调度解决方案》。

总结

资源利用率的晋升道阻且长，如何在保障业务稳定性的前提下，无效晋升资源利用率具备较大挑战。利用上述这些 TKE 的产品化计划，能够无效帮忙用户解决资源利用率晋升过程中的种种挑战，此外 TKE 也在开发其余的工具帮忙用户升高晋升资源利用率的门槛。《Kubernetes 降本增效规范指南》系列前期文章将更加深刻解说 Kubernetes 晋升资源利用率的办法，敬请期待。

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