在Kubernetes集群中，原生调度器只能通过资源请求来调度pod，这很容易导致一系列的负载不均问题。很多情况下，业务方都会超额申请资源，因此我们需要根据业务特性和评估等级来设置Requests/Limit比例，以提升资源利用效率。然而，依然存在一些问题：
- 节点负载不均：原生Kubernetes Scheduler仅根据Requests和节点可分配总量来调度pod，既不考虑实时负载，也不估计使用量。这种纯静态的调度导致节点资源利用率分配不均。在流量波动性业务的场景下，在流量高峰时，部分节点利用率突破安全阈值，但很多节点的利用率特别低，导致节点利用率相差很大。
- 业务周期性：在离线集群分离的情况下，在线集群底峰存在巨大的资源浪费。
本文将主要讨论如何解决节点负载不均问题，以提升在线集群内部的资源利用率。
在线集群的CPU离散系数为0.45，整个集群在高峰时CPU利用率仅约25%。下图为CPU使用率离散图：
解决方法
基于上述情况，高峰时CPU利用率仅25%显然不是合理的情况，业界通常达到50%以上的利用率。为了继续提升利用率，必须解决节点负载不均问题：
- 感知节点真实负载：要解决节点负载不均问题，必须要上报节点当前真实的负载。
- 基于负载的正向调度插件：在默认调度器的基础上增加基于负载的调度插件，尽量保证节点间负载平均。
- 基于负载的重调度组件：当业务不断波动时，节点可能会因为应用负载变化导致负载差异，需要重调度迁移Pod以实现负载平均。
实践
我们关注了两个开源项目：
Koordinator: https://koordinator.sh/
Crane: https://gocrane.io/
相对于Koordinator专门为混部而生的软件，Crane以Finops为出发点。二者相比，Crane更适合我们，并且在离线混部也是下一步计划。
在上线之后，出现了下图所示的情况：
遇到的问题
- 热点节点问题：在业务高峰时，节点负载升高，会出现热点节点。这时需要重调度组件介入，将Pod重新调度到其他节点上。
解决热点节点问题需要对应用进行资源画像，在调度中分散这种类型的应用，避免业务高峰时产生热点节点。在这种情况下，扩容部分节点缓解集群压力时，新加入的节点会迅速被热点Pod占满，导致节点负载升高，再次触发重调度。
为了解决以上问题，可以调整调度插件中负载均衡打分插件的权重，使节点负载更加均衡，避免热点节点问题。此外，还需要找到合适的节点规格，小规格节点更容易出现热点节点。在我们的业务场景下，目前来看48核节点出现热点节点的几率小于32核节点。
标签：游戏攻略
