优化Kubernetes集群负载的技术方案探讨

 

摘要：Kubernetes的资源编排调度使用的是静态调度，将Pod Request Resource与Node Allocatable Resource进行比较来决定Node是否有足够资源容纳该Pod。静态调度带来的问题是，集群资源很快被业务容器分配完，但是集群的整体负载非常低，各个节点的负载也不均衡。本文将介绍优化Kubernetes集群负载的多种技术方案。

Kubernetes为什么使用静态调度

静态调度，是指根据容器请求的资源进行装箱调度，而不考虑节点的实际负载。静态调度最大的优点就是调度简单高效、集群资源管理方便，最大的缺点也很明显，就是不管节点实际负载，极容易导致集群负载不高。

Kubernetes为什么会使用静态调度呢？因为要做好通用的动态调度几乎是不可能的，对，是通用的动态调度很难都满足不同企业不同业务的诉求，结果可能适得其反。那是不是我们就没必要去往动态调度做技术尝试呢？未必！平台根据托管的业务属性，可以适当的通过scheduler extender的方式扩展Kubernetes Scheduler来做一定权重的动态调度决策。

集群资源构成

以cpu资源为例，一个大规模Kubernetes集群的资源组成结构大致如下：

由以下几部分组成：

• 每个节点的预留资源，对应kubelet的system-reserved, kube-reserved, eviction-hard配置的资源之和，Kubernetes计算Node的Allocatable资源时会减去这部分预留资源。
• 目前我们集群的平均资源碎片大概在5%~10%左右，根据不同规格的CVM机型略有不同。这些资源碎片分散在集群中的各个节点，以1c1g, 2c2g, 3cxg为主，平台提供用户选择的容器规格都很难match到这些碎片，经常存在这这种情况：要调度某个Pod时，发现某个节点上的cpu足够，但是mem不足，或者相反。
• 剩下的就是可以被业务Pod真正分配使用的资源了，业务在选择容器规格时带有一定的主观性和盲目性，导致业务容器的负载很低，这样的业务占比一大就容易导致集群低负载的情况，但是集群按照Kubernetes静态调度策略又无法再容纳更多的业务容器了。如上图中所示的，集群分配cpu水位线很高，但是实际cpu利用率不高的情况。

提升集群负载的方案

除了借助强大的容器监控数据做一定权重的动态调度决策之外，是否还有其他方案可以用于解决静态调度带来的集群低负载问题呢？下面我将给出一整套技术方案，从多个技术维度来尝试提升Kubernetes集群负载。