背景
云原生这个词想必大家应该不陌生了，容器是云原生的重要基石，而Kubernetes经过这几年的快速迭代发展已经成为容器编排的事实标准了。越来越多的公司不论是大公司还是中小公司已经在他们的生产环境中开始使用Kubernetes, 原生Kubernetes虽然已经提供了一套非常完整的资源调度及管理方案但是在实际使用过程中还是会碰到很多问题：
- 集群节点负载不均衡的问题
- 业务创建Pod资源申请不合理的问题
- 业务如何更快速的扩容问题
- 多租户资源抢占问题
这些问题可能是大家在使用Kubernetes的过程中应该会经常遇到的几个比较典型的资源问题，接下来我们将分别介绍在腾讯内部是如果解决和优化这些问题的。
集群节点负载不均衡的问题
我们知道Kubernetes原生的调度器多是基于Pod Request的资源来进行调度的，没有根据Node当前和过去一段时间的真实负载情况进行相关调度的决策。这样就会导致一个问题在集群内有些节点的剩余可调度资源比较多但是真实负载却比较高，而另一些节点的剩余可调度资源比较少但是真实负载却比较低, 但是这时候Kube-scheduler会优先将Pod调度到剩余资源比较多的节点上（根据LeastRequestedPriority策略）。
如上图，很显然调度到Node1是一个更优的选择。为了将Node的真实负载情况加到调度策略里，避免将Pod调度到高负载的Node上，同时保障集群中各Node的真实负载尽量均衡，我们扩展了Kube-scheduler实现了一个基于Node真实负载进行预选和优选的动态调度器（Dynamic-scheduler)。
Dynamic-scheduler在调度的时候需要各Node上的负载数据，为了不阻塞动态调度器的调度这些负载数据，需要有模块定期去收集和记录。如下图所示node-annotator会定期收集各节点过去5分钟，1小时，24小时等相关负载数据并记录到Node的annotation里，这样Dynamic-scheduler在调度的时候只需要查看Node的annotation便能很快获取该节点的历史负载数据。
为了避免Pod调度到高负载的Node上，需要先通过预选把一些高负载的Node过滤掉，如下图所示（其中的过滤策略和比例是可以动态配置的，可以根据集群的实际情况进行调整）Node2过去5分钟的负载，Node3过去1小时的负载多超过了对应的域值所以不会参与接下来的优选阶段。
同时为了使集群各节点的负载尽量均衡，Dynamic-scheduler会根据Node负载数据进行打分, 负载越低打分越高。如下图所示Node1的打分最高将会被优先调度（这些打分策略和权重也是可以动态配置的）。
Dynamic-scheduler只能保证在调度的那个时刻会将Pod调度到低负载的Node上，但是随着业务的高峰期不同Pod在调度之后这个Node可能会出现高负载。为了避免由于Node的高负载对业务产生影响我们在Dynamic-scheduler之外还实现了一个Descheduler，它会监控Node的高负载情况将一些配置了高负载迁移的Pod迁移到负载比较低的Node上。
业务如何更快速的扩容问题
业务上云的一个重要优势就是在云上能实现更好的弹性伸缩，Kubernetes原生也提供了这种横向扩容的弹性伸缩能力（HPA)。但是官方的这个HPA Controller在实现的时候用的是一个Gorountine来处理整个集群的所有HPA的计算和同步问题，在集群配置的HPA比较多的时候可能会导致业务扩容不及时的问题，其次官方HPA Controller不支持为每个HPA进行单独的个性化配置。
为了优化HPA Controller的性能和个性化配置问题，我们把HPA Controller单独抽离出来单独部署。同时为每一个HPA单独配置一个Gorountine，并且每一个HPA多可以根据业务的需要进行单独的配置。
其实仅仅优化HPA Controller还是不能满足一些业务在业务高峰时候的一些需求，比如在业务做活动的时候希望在流量高峰期之前就能够把业务扩容好。这个时候我们就需要一个定时HPA的功能，为此我们定义了一个CronHPA的CRD和CronHPA Operator。CronHPA会在业务定义的时间进行扩容和缩容，同时还能和HPA一起配合工作。
业务创建Pod资源申请不合理的问题
通过Dynamic-scheduler和Descheduler来保障集群各节点的负载均衡问题。但是我可能会面临另一个比较头疼的问题就是集群的整体负载比较低但是可调度资源已经没有了，从而导致Pod Pending。这个往往是由于Pod 资源申请不合理或者业务高峰时段不同所导致的，那我们是否可以根据Node负载情况对Node资源进行一定比例的超卖呢。于是我们通过Kubernetes的MutatingWebhook来截获并修改Node的可调度资源量的方式来对Node资源进行超卖。
这里需要注意的是节点的超卖控制需要比较灵活不能一概而论，比如负载高的Node超卖比例应该要设置比较小或者不能设置超卖。
多租户资源抢占问题
当平台用户增多的时候，如果对资源不做任何控制那么各租户之间资源抢占是不可避免的。Kubernetes原生提供的ResourceQuota可以提供Namespace级别对资源配额限制。但是腾讯内部资源预算管理通常是按产品维度，而一个产品可能会包括很多Namespace的显然ResourceQuota不太适合这种场景。其次ResourceQuota只有资源限制功能不能做资源预留，当业务要做活动的时候不能保证活动期间有足够的资源可以使用。
为了实现一个产品维度且有资源预留功能的配额管理功能，我们设计了一个DynamicQuota的CRD来管理产品在各集群的配额。如下图所示产品2在各集群所占的配额资源其它产品多无法使用。
如果一个产品占用配额一直不使用就可能会导致平台资源的浪费，因此我们在产品配额预留的基础上提供了在不同产品间配额借调的功能。如下图所示产品1暂时不用的配额可以借调给产品2临时使用。
当平台有多集群的时候，产品配额需要如何分配。为了简化配下发操作，如下图所示管理员在下发产品配额的时候只需配置一个该产品的配额总量，配额下发模块会根据产品目前在各集群的使用情况按比例分配到各个集群。
产品在各集群的资源使用情况是会时刻变化的，所以产品在各集群配额也需要根据业务的使用情况进行动态的调整。如下图所示产品在集群2中的配额已经快用完的时候，配额调整模块会动态的把配额从使用不多的集群1和集群3调到集群2。
在线业务和离线业务混合部署是云平台的发展趋势，所以我们在设计配额管理的时候也把在离线配额控制考虑进去了。如下图所示我们在集群维度加了一个离线配额控制，一个集群的离线业务资源使用不能超过该集群总资源的30%（这个比例可以根据实际情况进行调整）。其次一个产品的在线业务和离线业务配额之和又不能超过产品在该集群的总配额。
总结
上面提到的方案只是简单说了一下我们的一些解决问题的思路，其实在真正运作的过程中还有很多细节需要考虑和优化。比如：上面提到的产品配额管理如果一个产品的配额不足了，这时候业务有高峰需要进行HPA扩容，这时候配额管理模块需要对这种扩容优化并放行。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！