基于开源autoscaler二次开发的目的以及效果演示

基于开源的autoscaler二次开发，通过自部署autoscaler来替代GKE提供的节点自动扩缩容能力，获取更好的扩展性和更灵活的配置。主要增强以下特性：

1. 支持目标负载扩容
2. 更快的缩容速度
3. 支持低负载自动缩容-重调度

关于演示

(注：开头视频为效果演示视频。)

首先部署demo-web服务2个副本，集群会扩容一个节点A出来部署这两个副本。

然后将这两个副本的cpu使用率调大，使节点A的cpu总使用率大于45%。

然后增加1个副本，验证是否会扩容1个节点B来部署这个新副本。（目标负载扩容验证）

接着，将节点A上的两个副本的负载降低到10%，观察一分钟左右，节点B上的Pod是否被驱逐到已经降低负载的节点A上，然后节点B被回收。（重调度验证）

接着，将副本数减少到0，观察节点A是否在30秒后被回收。（更快的缩容速度验证）

支持目标负载扩容

为什么要做目标负载扩容？

gke提供的扩缩容能力，是计算节点上部署的所有Pod请求的cpu总和、内存总和，再加上当前待部署的Pod请求的cpu、内存，如果超过了节点的最大可用cpu、或者最大可用内存，才会扩容节点。

但因为我们是根据算法预测Pod请求的cpu和内存的，这个值非常接近真实值，如果按照这个扩容算法，只有节点的cpu或内存被撑爆的时候才会触发扩容，这是个非常严重的问题。在此之前，我们是通过给预测出来的值再往上调30%来解决这个问题，但这实际上会浪费一些资源，因为并不是每个Pod都会跑到预测值（比如预测值受流量尖刺影响计算出来的值会偏大）。

正常一个节点cpu使用率超过60%（总使用量/总核心*1000（毫核）），再把pod调度上去，性能就会很差。另外，一个节点的内存使用到80%，如果再部署Pod上去，节点上任何一个Pod出现流量小尖刺情况都会把内存撑爆。

因此，实现目标负载扩容就很有必要。

目前版本我们配置的cpu使用率阈值是45%，内存使用率阈值是75%，后期再根据效果进行调整。

更快的缩容速度

gke提供的扩缩容功能最短缩容时长为11分钟，且不支持配置。这意味着每个节点空闲之后实际还要多付费10分钟的使用费用。

autoscaler提供参数支持配置缩短这个缩容时长，例如缩短到30秒。

支持低负载自动缩容（重调度）

重调度是指将cpu和内存使用率都非常低的节点，重新调度这个节点上的Pod到其它节点，然后把这个节点空出来，然后回收释放这个节点，减少资源的浪费。 低负载自动缩容是autoscaler提供的特性支持，实际效果是跟我们理解的重调度是一样的。

低负载自动缩容节点的这个特性还是非常有必要的，因为随着时间的推移，集群中必然会出现非常多的弹性节点利用率很低的情况。尽管我们在自己实现的deployment controller上加了缩容逻辑，优先干掉部署在低负载的节点上的Pod，但这也只发生在服务缩容和滚动更新的时候。

当一个节点的cpu使用率或者内存使用率超过阈值（可配置），autoscaler就是尝试（dryrun）将这个节点上的Pod调度到其它节点，如果模拟调度成功，才会真正执行调度，最后释放节点回收。

我们基于autoscaler的改造，是为了阻止autoscaler将Pod调度到cpu或内存负载已经很高的节点上，跟【支持目标负载扩容】功能相辅，而不是相互排弃。