如何看待 k8s 的 HPA

​ 最近被问到如何理解 k8s 弹性伸缩的这样的问题，而我最初的回答很简单也很肤浅，我说：k8s 是 HPA 根据定义的 metric 阈值 （简单的 cpu 值或者用户自定义）来对应用进行扩缩容的。

   今天和微博的朋友也聊到了这个话题，他说在他们的场景下 k8s 的弹性扩容是不起作用的，因为在某些热点新闻的高流量下2分钟内就需要扩容上千台机器，k8s 默认的弹性扩容是解决不了这个问题的 (因为默认的调度机制是串行的，需要做 hack 才可以)。 
  这让我意识到我想简单了，其实脱离了场景讨论技术都是不靠谱的。

  让我们回到这个问题的原点 “弹性伸缩”， 那先看看它是如何定义的，

Elastic scaling is the ability to automatically add or remove compute or networking infrastructure based on changing application traffic patterns.

弹性伸缩是一种系统能力，它可以根据应用的流量变化自动的增加或者删减资源。
说到这里，脑海里会出现几个问题：

1. 这里面的一个关键词是“自动的”，那如何实现自动呢？
   根据 cpu 可以吗？这个就区分场景了，绝大多少的线上应用不会简单的依赖 cpu 指标来衡量是否需要扩容，因为这是一个非常复杂的决策过程，

2. 弹性伸缩这种能力哪种场景需要？我们的场景需要吗？
   根据定义，只有流量会有突增的场景才会有这个需求，比如几年前微博的例子，经常几个明显绯闻就把系统搞挂了。但这种场景毕竟是很少的， 而我们自己公司内部是用不到的。而对应微博来说，这个功能还比较鸡肋，因为它扩容的太慢了，而且如何判断更是个大难题，超出了 k8s 的管理范畴。

 听完微博朋友介绍了他们的场景，想到了之前蚂蚁的人介绍他们的双十一架构，可以很短的时间扩容几千个机器，怎么做到的呢？ 把 k8s 默认的调度算法从原来的顺序的调度改为了批量的调度，满足了这个大促的场景。

   另外最重要的一点是如何判断触发扩容缩容的时机，今天从网上的一个 2015 年的论文里找到了一个方法论，介绍了如何用工业界的 质量控制图 和 区间法则找出了异常的数据波段，并进行扩容或缩容。大体上微博的做法也和这个类似，因此了解下这个论文还是很有帮助的。


 总之，k8s HPA 的这个功能只能处理非常简单的场景，距离真正线上应用使用还很遥远，而且这个功能和 k8s 平台关系不大，应该在非 k8s 环境下就要能够做到甄别出应用的异常流量。

反思：技术问题一定要优先考虑使用场景，使用场景

论文地址：https://www.sciencedirect.com/science/article/pii/S1877050915030239