背景

云原生这个词想必大家应该不生疏了，容器是云原生的重要基石，而Kubernetes通过这几年的疾速迭代倒退曾经成为容器编排的事实标准了。越来越多的公司不论是大公司还是中小公司曾经在他们的生产环境中开始应用Kubernetes, 原生Kubernetes尽管曾经提供了一套十分残缺的资源调度及治理计划然而在理论应用过程中还是会碰到很多问题：

1. 集群节点负载不平衡的问题
2. 业务创立Pod资源申请不合理的问题
3. 业务如何更疾速的扩容问题
4. 多租户资源抢占问题

这些问题可能是大家在应用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扩容，这时候配额治理模块须要对这种扩容优化并放行。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！