Atlassian发布Kubernetes节点自动化扩展工具Escalator-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

Atlassian 把他们的内部工具 Escalator发布为开源项目。该工具针对 Kubernetes 节点提供了配置驱动的抢占式纵向扩容和更快地纵向缩容。

2013 到 2014 年，Atlassian 采用了容器，并构建了自己基于Docker 的PaaS ，使用它运行内部的平台和服务。除了pod 的基本调度和运行外，他们的编排还需要具有弹性，以应对云硬件故障及响应负载，快速实现纵向扩容或缩容。Kubernetes 就符合要求，团队就使用它作为他们的编排器。他们的构建工程基础设施所包含的工作负载需要配备数以百计的虚拟机——这是他们需要首先迁移的其中一个部分。

Kubernetes 有两个自动扩展器——横向的pod 自动扩展器和集群扩展器。前者实现pod——容器或一组相关容器之上的一种抽象——的横向扩容和缩容，因此，它依赖于底层计算资源（通常是虚拟机）的可用性。集群自动扩展器用于扩展计算基础设施本身。可以理解，由于虚拟机需要的配置时间更多，所以纵向扩容和缩容需要的时间都比较长。集群自动扩展器的任何延迟都会转变成pod 自动扩展器的延迟。类似地，pod 可以非常快速地缩容，但计算VM 要用更多的时间才能做到。这会导致来自空闲计算VM 的巨大成本，尤其是在Atlassian 这样的基础设施规模上。Atlassian 的问题仅限于对扩容和缩容延迟容忍度较低的批处理工作负载。他们决定编写自己的自动扩展功能，在Kubernetes 之上解决这些问题。

Escalator 是用 Go 编写的，它为计算 VM 的容量上限和下限提供了可配置的阈值。其中有些配置属性是通过修改Kubernetes 一项名为“ taint ”的特性实现的。VM 节点可以被特定的值“污染”（标记），那样，有相关标记的 pod 就不会调度到它上面。标记之后，Kubernetes 标准的集群自动扩展器就可以更快地拿下未使用的节点。纵向扩容配置参数是一个用使用率表示的阈值，通常小于 100，以便有个缓冲。当使用率达到阈值时，Escalator 会自动扩展计算 VM，为稍后可能出现的容器提供空间，使它们可以快速启动。

图片来源： https://developers.atlassian.com/blog/2018/05/introducing-escalator/

像 AWS 这样的公有云提供商试图使用类似 Fargate 这样的解决方案来解决 VM 管理问题，不过，它们没有提供 Escalator 那样的配置选项。在容器环境中，计算扩展 / 收缩是一个常见的问题。如果计算 VM 需要几分钟才能启动起来，那么容器启动的速度优势就不存在了。保持 VM 运行解决了这个问题，代价是运行可能空闲的 VM。需要注意的是，Escalator 解决了一个在两个 Kubernetes 自动扩展器的情况下非常特殊的问题，就是批处理工作负载。

Escalator 的运行需要 Kubernetes 1.8+ 和 Golang 1.8+。目前，对于云提供商，它仅支持AWS 。Atlassian 之前已经开源了另外一个Kubernetes 相关的项目 Smith 。

查看英文原文： Atlassian Releases Escalator, an Autoscaling Tool for Kubernetes Nodes