通过预测Pod的request实现超卖，如果是java感觉容易大面积重启？

前面文章提到，我们想基于Google的论文：Autopilot: workload autoscaling at Google，实现Pod的requests预测算法，通过预测接近真实值的requests，再结合基于scheduler-plugins实现负载均衡调度器，来实现计算资源按需付费的Serverless引擎。

这里的超卖是指按limit超卖，不是按request超卖。例如，有一个16g内存的虚拟机，我可以用来部署很多个Pod，对于每个Pod来说，它们都认为自己有16G的最大内存使用。

有其它同事提问，如果是Java应用，这种超卖会不会很容易导致大面积重启？

这就要看requests的预测算法效果了，但如果预测的结果不是特别离谱，也不会出现大面积重启的情况。 如果只是突增预测不准，那也只是个别应用会重启。

举个例子：假如在一个16g内存的节点上，部署了4个request为3g内存的Pod，总共消耗12g内存。然而根据目标负载均衡调度算法，我们可以控制这个节点不会部署request总共超过12g内存的Pod，即75%的目标负载。那么有4g是可以容错算法的偏差的，以及4个Pod的个别Pod流量的正常突增。

正常request的误差假如在1g内，那么4个pod同时实际负载超过request+1g的概率是极低的。

假如有一个pod突增非常严重，那么这个pod会优先被kubelet干掉重启，同时算法会预测新的request，request会重新被预测的非常大，会被调度到资源更多的另一个节点上（或者触发申请新的节点），不会影响其它Pod。

超卖其实就是赌徒思想，堵的就是概率。一个节点上的个别Pod异常突增的概率都很小，同时很多Pod一起异常突增的概率更小。