作者 Dmall Talker·陈鹏 多点Dmall-新业务与共享平台研发部
介绍
Kubernetes 是用于自动部署、扩展和管理容器化应用程序的开源系统。Kubernetes 之所以能够在云原生领域快速成长，离不开容器一次编译到处运行（CO-RE）的特性，也让 Kubernetes 最终成为了云原生领域的“操作系统”。多点Dmall的容器平台也是基于的 Kubernetes 做的包装，所以容器平台天生具备快速扩容缩容的能力。在公司降本增效的长远目标的指导下，我们需要更加智能的自动扩缩容能力。
原理
“自动”扩缩容代表容器平台需要一个“智能”的组件，根据“某些条件”来判断什么时候需要扩容，什么时候需要缩容。接下来，我们一起探索一下这个“智能”的组件（HPA）是如何工作的：
如上图所示，HPA 组件判断扩缩容的条件是一些指标：Resource Metrics 和 Custom Metrics，所以上面说的“某些条件”就是业务运行的各种 CPU、内存等 Metrics，同时也预留了用于扩展的自定义 Metrics。有了这些“条件”之后，再根据下面的公式计算出期望的运行实例数：
期望运行实例数 = ceil[当前运行实例数 * (当前指标 / 期望指标)]
为了避免频繁的自动扩缩容给服务带来的影响，所以 HPA 还设计了一个快速扩容、缓慢缩容的策略。默认情况下：Metrics 每 10s 计算一次当前指标，然后执行上面的公式，计算出一个当前指标下期望运行的实例数，并放入一个样本池中（样本池会自动丢弃 5 分钟之前的数据）；然后获取样本池中最大的值作为最终的运行实例数。这样一来，如果指标比较高，那么会在下一个计算周期把实例数调整上来，一旦扩容了，下次需要缩容的时候就要等到至少 5 分钟之后（等待最大值在样本池中过期）。正是因为这样的策略，才能让业务波动更加平滑。
期望运行的实例数也受最大实例数和最小实例数限制， 有了最终期望运行的实例数之后，接下来就依靠 Kubernetes 自身的快速扩容缩容能力，来完成业务实例的扩缩容。结合我们内部的容器平台的发布组件（symphony：基于 CRD 扩展的一个 Controller）的 Reconcile 逻辑，最终架构如下图所示：
所以只需要单独配置最小实例数、最大实例数(当前容器平台的实例数)、资源使用百分比（目前只支持 CPU 使用百分比）就可以体验自动扩缩容了。
收益
如果使用了自动扩缩容，能带来什么收益呢？上面说到的最小实例数、最大实例数、资源使用百分比应该如何配置呢？ 首先，我们有自动扩缩容的记录，可以根据每天的数据调整为最适合自己的配置。如果扩缩容比较频繁，可能是资源使用率的值还可以再优化；如果扩缩容的时间段很明显且使用率很低，那可以适当调整最小实例数，节约更多的成本。有了这些调整之后，业务方能够更加明确自己的单个业务实例能支撑多少业务量，并且随着业务量的增长，也可以提前扩展资源，做到未雨绸缪，在新的环境中也能根据业务量配置合理的资源。
接入须知
非常适合开启自动扩缩容的项目：
- 通过扩容可以提升服务并发量、流量波谷明显：服务网关、查询搜索等；
- 通过扩容可以提升任务执行效率：调度任务。
开启之后效果不明显或有影响的项目：
- 扩容之后任务还是跑在单一节点；
- 有瞬时高并发的请求：秒杀（扩容有一定的延迟）。
未来规划
当大量的项目开启了自动扩缩容之后，容器平台才能腾出更多的空闲资源，如果空闲资源达到一定的比例，我们可以把集群节点进行自动扩缩容，真正的做到资源合理利用。在不影响业务的正常运行的大前提下，空闲的资源会被及时回收，节约服务器成本，从而达到容器平台降本增效的长远目标。
