Escalator：Atlassian开源的Kubernetes自动扩展工具

上周（这说起来已经是五月初的事情了），Atlassian向开源社区开源了Escalator，它是一款经过优化的Kubernetes自动扩展工具，大家可以从我们的GitHub仓库[1]中拿到源码。

容器到Kubernetes之旅

在Atlassian内部，我们在自有平台和服务方面，已经有很长使用容器的传统。大概时间在2013年或者2014年左右，那时候我们正在基于Docker搭建公司最早的PaaS（Platform as a Service——平台即服务）平台。从微服务堆栈的容器，到构建微服务体系的CI/CD工作流程，Docker都能很方便的对过程完整打包，确保整个软件架构可以在任何需要的地方快速运行。无论是在个人笔记本上、开发阶段还是生产环境中，容器都能为我们提供可靠、准确的保障，并且我们只需要付出很少的代价。 但是容器旅行并不是一帆风顺，很快一个突显的问题出现了：容器编排。下面是四个最大的痛点：

1. 我们需要将Pod规划好并安装到用户的计算基础设施上。

2. 我们需要保证在云环境的硬件出现问题时我们的服务仍然正常。

3. 我们需要能够扩展基础设施和应用，应对弹性用户负载中的峰值压力。

4. 我们需要及时关闭不再使用的虚拟机资源，节约公司云上开支。

当我们在调研和设计基础计算平台（PaaS）时，我们惊喜的发现Kubernetes可以帮助我们解决这些挑战。基于容器丰富的开发接口、声明式的配置方式、环形配置架构和庞大的社区支持，Kubernetes可以对我们的容器进行编排。 基于此，我们创建了自己的Kubernetes平台工具，并在生产中对它千锤百炼。我们还组建了一支优秀的Kubernetes团队来管理它，将已存在的基于容器的工作流慢慢迁移到Kubernetes平台。该特别小组扮演着关键角色：它能够让我们的内部团队与Kubernetes隔离开，内部团队不必担心如何运行Kubernetes本身，这可以保证内部团队将主要精力放在原来的开发工作上。 迁移流程的第一步是迁移我们的构建引擎，该平台用于Atlassian团队的持续集成和产品构建部署，之前这些工作都运行在云提供商的私有容器管理系统，所以整个工作流程都已经容器化。我们将该服务直接迁移到Kubernetes，这其中最大的挑战是如何处理好峰值情况下申请数千个核心资源的巨大工作负载。

新问题出现：急需更好的自动扩展能力

在使用Kubernetes平台之初，我们能惊喜的感受到批量化工作负载到Kubernetes的便捷性。但是当并发数量攀升上来后，我们开始感觉的这条路走起来有些颠簸。实际感受是，集群不能足够快的扩容和缩容。 扩容：当前集群达到能力极限时，Kubernetes启动并服务于该负载需要持续几分钟时间，此时用户只能等待。这不是一个很好的解决方案，因为一些操作可能由于没有容错而失败。这个问题实际上是由于Kubernetes的集群扩展服务缺少一个关键特性：不能在集群达到能力极限之前提前做出预判并提前扩展计算节点。更简单点说，它不能为峰值负载提供一种缓冲机制。

缩容：我们也有与扩容相反的场景问题：当负载减弱时，自动扩展器不能迅速的进行缩容。当然这个问题并没有凸显出来。但是很显然，如果这些不再有用的资源没有被有效释放，无形中会造成经济损失。

更好的解决方案：Escalator

带着解决上面两个扩展问题的动机，我们团队开始审视不同的选择。我们需要扩展Kubernetes集群扩展器的现有能力吗？是否存在一个新的自动扩展器可供利用？有必要开发一套我们自己的自动扩展工具来优化现有的工作负载吗？ 经过对种种原因的分析，最终我们选择了构建一套自己的自动扩展工具的方案，这个工具称之为Escalator。我们假设了这套用于优化批量工作负载的自动扩展器的两个基础目标：提供先发制人的集群能力缓冲特性，用来防止用户直面集群负载能力达到上限的情形；对不再需要的资源执行强制缩容。此项目建立之初我们也为Ops团队做了一些考虑，通过使用Prometheus监控工具，我们只提供底层的东西，Ops团队也可以同时使用Prometheus进行其他集成工作。

项目开始一段时间后，我们看到了开发的初步成果：Escalator对Kubernetes的标准集群自动扩展器进行了功能补充，如此一来，我们可以对无用的资源节点进行浸染。以这种方式，集群自动扩展器可以从自动扩展组更快的消耗和移除这些节点。接下来，我们开发了能够先发制人的扩展功能，并给用户提供了定义缓冲能力的指标项。接下来的里程碑事件是扩展Escalator并打包所有功能，以保证它能够完全替代Kubernetes的标准自动扩展器为我们的工作负载服务。 经过几个月的努力工作后，我们达成了当初的设想，并且我们将Escalator发布到开源社区。之前我们需要用三分钟左右的时间等待EC2实例加入到集群中，现在我们仅需要几秒钟。这些通过Escalator的扩展与配置功能就可以实现。这些配置可以让用户来根据自身的情景配置百分比。过去我们每小时会因为无用的资源浪费很多云上费用，现在集群可以迅速的缩容，每天能够节约成百上千美金。同时Ops团队也可以通过Prometheus来达到以上的目的。

接下来

目前为止我们已经在内部和外部客户中进行了Escalator的应用。我们同时也关心公司其他团队在生产上如何处理Escalator在我们的环境中起到了极大的作用，所以我们将它贡献给Kubernetes社区，作为开源软件，大家可以下载并使用它。 您可以从Github account上取得源码，同时我们也很希望您能做出贡献。您可以从Git上获得Escalator的下一步路线图，如果您有一些新的想法，欢迎提交PR或者feature request给我们。 相关链接：

1. https://github.com/atlassian/escalator

原文链接：https://developer.atlassian.com/blog/2018/05/introducing-escalator/