传统弹性伸缩的困境

弹性伸缩是 Kubernetes 中被大家关注的一大亮点，在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义，传统意义上来讲，弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。

如上图所示，蓝色的水位线表示集群的容量随着负载的提高不断的增长，红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增，而容量规划没有来得及反应的场景。


常规的弹性伸缩是基于阈值的，通过设置一个资源缓冲水位来保障资源的充盈，通常 15%-30% 左右的资源预留是比较常见的选择。换言之就是通过一个具备缓冲能力的资源池用资源的冗余换取集群的可用。


这种方式表面上看是没有什么问题的，确实在很多的解决方案或者开源组件中也是按照这种方式进行实现的，但是当我们深入的思考这种实现方案的时候会发现，这种方式存在