首页 > 极客资料 博客日记

kubernetes负载感知调度

2024-08-14 16:00:03极客资料围观23

文章kubernetes负载感知调度分享给大家,欢迎收藏极客之家,专注分享技术知识

背景

kubernetes 的原生调度器只能通过资源请求来调度 pod,这很容易造成一系列负载不均的问题,
并且很多情况下业务方都是超额申请资源,因此在原生调度器时代我们针对业务的特性以及评估等级来设置 Requests/Limit 比例来提升资源利用效率。
在这种场景下依然存在很多问题:

  1. 节点负载不均:原生 Kubernetes Scheduler 根据 Requests 和节点可分配总量来调度 Pod,既不考虑实时负载,也不估计使用量,这种纯静态的调度导致节点资源利用率分配不均。
    在流量波动性业务的场景下,在流量高峰时,部分节点利用率突破安全阈值,但是很多节点的利用率特别点,节点利用率相差特别大
  2. 业务周期性:在离线集群分离,在线集群底峰存在巨大资源浪费

本文主要讨论如果解决问题一,在线集群内部提升资源利用率

在线集群 Cpu 离散系数0.45,整个集群高峰时 Cpu 利用率仅25%左右;下图 Cpu 使用率离散图:

file

破局

基于上述情况,高峰时 Cpu 利用率仅25%肯定不是合理的情况,业界做的好的50%+。想要继续提升利用率,必须解决节点负载不均问题:

  1. 感知节点真实负载:要解决节点负载不均问题,必须要上报节点当前真实的负载
  2. 基于负载的正向调度插件:在默认调度器的基础上增加基于负载的调度插件,在正向调度是尽量保证节点间水位平均
  3. 基于负载的重调度组件:当业务不断波动,节点可能会因为应用负载变化导致节点负载出现差别,需要重调度迁移 Pod 重新达到平均

实践

关注的两个开源项目:

Koordinator: https://koordinator.sh/

Crane: https://gocrane.io/

相对于 Koordinator 专门为混部而生的软件,Crane以 Finops 为出发点,二者相比Koordinator更适合我们,在离线混部也是下一步计划。

调研测试

上线之后:
file

遇到的问题

  1. 热点节点问题:在业务高峰时,节点负载变高,会出现热点节点,这个时候需要重调度组件介入,把 Pod 重新调度到其他节点上

需要前置打散热点节点,这就需要对应用进行资源画像,在调度中分散这种类型的应用,避免业务高峰热点节点的产生
2. 在1中的情况下,扩容部分节点缓解集群压力时,新上的节点会迅速被热点Pod占满,导致节点负载升高,再次触发重调度

调整调度插件中负载均衡打分插件的权重,让节点负载更均衡,避免热点节点问题
3. 找到合适的节点规格,小规格节点,更容器出现热点节点

在我们的业务场景下下,当前来看48c节点热点节点出现几率小于32c


版权声明:本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!

标签:

相关文章

本站推荐

标签云