共计 3776 个字符，预计需要花费 10 分钟才能阅读完成。
作者
王孝威，FinOps 认证从业者，腾讯云容器服务产品经理，热衷于为客户提供高效的 Kubernetes 应用形式，为客户极致降本增效服务。
余宇飞，FinOps 认证从业者，腾讯云专家工程师，从事云原生可观测性、资源管理、降本增效产品的开发。
资源利用率为何都如此之低？
尽管 Kubernetes 能够无效的晋升业务编排能力和资源利用率，但如果没有额定的能力撑持，晋升的能力非常无限，依据 TKE 团队之前统计的数据：Kubernetes 降本增效规范指南 | 容器化计算资源利用率景象分析，如下图所示：TKE 节点的资源均匀利用率在 14% 左右。
为什么 Kubernetes 集群的资源利用率仍旧不高？
这里一个很重要的起因是因为 Kubernetes 的资源调度逻辑，在创立 Kubernetes 工作负载的时候，通常须要为工作负载配置适合的资源 Request 和 Limit，示意对资源的占用和限度，其中对利用率影响最大的是 Request。
为避免本人的工作负载所用的资源被别的工作负载所占用，或者是为了应答顶峰流量时的资源耗费诉求，用户个别都习惯将 Request 设置得较大，这样 Request 和理论应用之间的差值，就造成了节约，而且这个差值的资源，是不能被其它工作负载所应用的。
Request 数值不合理的过大，是造成 Kubernetes 集群资源利用率低一个很广泛的景象。另外，每个节点的资源很难被充沛调配，如下图所示，节点广泛会存在一些资源的碎片（Leftover），这些都是导致集群整顿资源利用率不高的起因。
资源理论利用率到底有多低？
如何设置更正当的资源 Request，首先须要剖析业务对资源的耗费状况。在腾讯云原生 Kubernetes 降本增效规范指南 | 资源利用率晋升工具大全资源常见节约场景局部，有对繁多的工作负载进行剖析，工作负载设置的 Request 中至多有一半的资源没有被应用，而且这部分资源不能被其余的工作负载应用，节约景象重大。这时把视角回升到集群维度，下图是某一 TKE 集群的 CPU 分配率和使用率。
分配率是用所有容器对 CPU 的 Request 之和除以集群所有节点的 CPU 数量，使用率是所有容器对 CPU 的 Usage 之和除以集群所有节点的 CPU 数量：
可见集群整体的 CPU 分配率在 60% 左右，但 CPU 理论的利用率最高不超过 10%。能够了解成用户在云上花了一百元，实际上 90 多元都被节约掉了。
如何设置 Request？
晋升资源利用率有很多种办法，详见 Kubernetes 降本增效规范指南 | 资源利用率晋升工具大全。本文次要探讨 Request 的设置。
既然设置了 Request 导致资源利用率如此之低，那是不是罗唆不要设置 Request 了，而后间接把集群的规模缩减到原来的十分之一，就能够解决上图中的问题？这的确看似是一种简略高效的办法，但存在几个较为重大的问题：
- Kubernetes 会主动配置 Pod 的服务质量 QoS，对于没有设置 Request 数值的 Pod，当资源比拟缓和时，比拟容易被驱赶，业务稳定性受到影响。
- 集群的整顿资源实际上并不是一个残缺的整体，集群是由很多节点形成的，理论的 CPU 和内存的资源都是节点的属性，每个节点的容量大小有下限，例如 64 核 CPU，对于比拟大的业务来说，可能须要一个数千核乃至数万核的集群，这样集群里的节点数量就会变多，节点数量越多，每个节点的碎片资源越多，碎片资源都无奈无效被利用。
- 业务自身可能会有较大稳定，例如地铁零碎白天忙碌、夜晚闲暇，设置固定的 Request 数值必须依照峰值思考，此时节约景象仍旧突出。
能够看出，Request 的设置对于运维开发来说始终是个很大难题，Request 设置过小容易导致业务运行时性能受到影响，设置过大势必造成节约。
Request 智能举荐
是否存在一个无效的工具，能基于业务自身的个性主动举荐甚至设置 Request 数值？
这样无疑对开发运维来说极大的加重了累赘。为解决这样的问题，TKE 老本巨匠推出了 Request 智能举荐的工具。用户能够通过规范 Kubernetes API（例如：/apis/recommendation.tke.io/v1beta1/namespaces/kube-system/daemonsets/kube-proxy）拜访相应的推荐值。
该性能启动后，Request 智能举荐的相干组件会从腾讯云监控（将来反对 Prometheus，InfluxDB，或第三方云厂商）拉取集群中所有 Deployment、DaemonSet、StatefulSet 在过来一段时间存在过的容器的 CPU 和 内存的监控指标，计算相应的 P99 值，再乘以一个安全系数（例如：1.15），当作举荐的 Request。
对于 Limit，Request 智能举荐性能举荐的 Limit，以初始 Request 智能举荐性能设置的 Request 与 Limit 之比计算。例如初始设置的 CPU 的 Request 数值为 1000m，Limit 为 2000m，Request 与 Limit 之比为 1:2。若新举荐的 CPU 的 Request 数值为 500m，则会举荐 Limit 为 1000m。
更多对于 Request 智能举荐的应用请参考：Request 智能举荐产品文档。
Request 举荐参考利用的历史资源耗费峰值，给出一个绝对「正当」并且「平安」的资源申请值，能够很大水平上缓解因为业务 Request 设置不合理导致的资源节约或者业务不稳固。
例如在上面的集群中利用 Request 举荐，业务资源使用量在 10 核左右，但手工配置的 Request 是 60 核，实际上 Request 设置在 17 核就足够了，利用率从之前的 16.7%（=10/60）左右 晋升到 58.8%（=10/17），晋升了 252%（=（58.8-16.7）/16.7），CPU 节俭了 71.7%(=(60-17)/60)。
AHPA
当然，Request 智能举荐不是银弹，因为利用的资源耗费并不是变化无穷的，大量的利用都存在潮汐景象，业务顶峰和低谷所须要的资源存在着几倍甚至几十倍的差距。以高峰期资源需要为准设置的 Request，使得业务在闲暇时段占有大量并不应用的资源，导致利用的均匀资源利用率仍然不高。此时，想要做进一步优化，就须要借助弹性伸缩的伎俩。
现阶段，HPA 是 Kubernetes 畛域最罕用的弹性工具，尽管 HPA 能够肯定水平上解决周期性业务流量资源应用弹性的问题，然而 HPA 是有滞后性的。具体表现在：通常 HPA 须要先定义监控的指标，例如 CPU 利用率 60%，而后相干的监控组件监控到负载压力变大，触达了这个使用率的阈值，HPA 才会扩缩容正本数。
通过对大量运行在腾讯云上的外部和内部用户的理论利用的察看，咱们发现许多业务的资源应用在工夫序列上是具备周期性的，特地是对于那些间接或间接为“人”服务的业务。这种周期是由人们日常流动的规律性决定的。例如：
- 人们习惯于中午和早晨点外卖
- 早上和早晨是交通高峰期
- 即便对于没有显著模式的服务，如搜寻，夜间的申请量也远低于白天
对于与此类相干的应用程序，从过来几天的历史数据中推断第二天的指标，或从上周一的数据推断下周一的拜访流量是一个天然的想法。通过对将来的指标预测，能够更好地管理应用程序实例，稳固零碎，同时降低成本。
CRANE 是 TKE 老本巨匠的技术底座，专一于通过多种技术，优化资源利用，进而升高用户的云上老本。CRANE 中的 Predictor 模块能够自动识别出 Kubernetes 集群中利用的各种监控指标（例如 CPU 负载、内存占用、申请 QPS 等）的周期性，并给出将来一段时间的预测序列。在此基础上，咱们开发了 AHPA（advanced-horizontal-pod-autoscaler)，它可能辨认适宜程度主动缩放的应用程序，制订缩放打算，并主动进行缩放操作。它利用了原生 HPA 机制，但它基于预测，并被动提前扩容应用程序，而不是被动地对监测指标做出反馈。 与原生 HPA 相比，AHPA 打消了手动配置和主动缩放滞后的问题，彻底解放运维。 次要有如下特点：
- 可靠性—- 保障可伸缩性和可用性
- 响应能力——扩大快，疾速应答高负载
- 资源效力——降低成本
下图是该项目标理论运行成果：
- 红线是工作负载的理论资源使用量
- 绿线是预测该工作负载的资源使用量
- 蓝线是给出的弹性举荐的资源使用量
CRANE 和 AHPA 行将开源，敬请期待。
更多对于云原生的老本优化原理和理论案例可参考《降本之源 - 云原生老本治理白皮书》，是腾讯基于内外云原生老本治理最佳实际，并联合行业优良案例，提出的一套体系化的云原生老本优化方法论和最佳实际门路。旨在帮忙企业改善用云老本，充分发挥云原生的效力和价值。
更多白皮书细节内容，在【腾讯云原生】公众号回复“白皮书”下载理解。
对于咱们
更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~
福利：
①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~
②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。
③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
