今年早些时候，我曾写过一篇博文，展示了Yelp内部计算集群自动伸缩器（Cluster autoscaler，CA）、Clusterman（我们的集群管理器）的一些特性。过去几个月，我们为 Clusterman 添加了另一个可支持的选择——Kubernetes 集群。与此同时，Clusterman 现在已在 GitHub 上开源。

从 Mesos 到 Kubernetes

在过去五年，我们在 Yelp 上讨论并撰写了很多关于计算堆栈的内容，我们已经从单一的 yelp_main repo 转变为一个完全分布式、面向服务的架构，运行在 Apache Mesos 和我们的内部平台即服务（PaaSTA）之上的云端中。说实话，如果没有这一举措，我们就不可能会发展成现在这样的规模。今年，我们一直在努力为基础架构的进一步增长做准备，并意识到实现这一目标的最佳途径是从 Mesos 迁移到 Kubernetes。

Kubernetes 允许我们运行在 Mesos（由于本地状态需求）下难于管理的工作负载（如 Flink、Cassandra、Spark 和 Kafka 等）。我们坚信，在一个公共平台（PaaSTA）下管理这些工作负载将会使我们的基础架构工程师的产出提高一个数量级，比如仅用几行 YAML 就能构建一个新的 Cassandra 集群。

此外，我们正在将所有微服务和批处理工作负载迁移到 Kubernetes。这是 Yelp 上讨论的一个问题，但我们最终决定采用这种方法，因为可以减少维护两个相互竞争的调度器（Mesos 和 Kubernetes）的开销，又可以利用快速发展的 Kubernetes 生态系统。借助 PaaSTA 提供的抽象，我们已经能够无缝地进行迁移，我们的部分开发人员并不知道他们的服务是在一个完全不同的计算平台上运行的。

当然，为了使这种迁移成为可能，我们需要在计算集群的所有工具中构建对 Kubernetes 的支持，包括非常重要的自动伸缩器 Clusterman。由于 Clusterman 的模块化设计，使得事情变得容易。我们只是定义了一个新的连接器类，符合自动伸缩器期望的接口。该连接器知道如何与 Kubernetes API 服务器进行通讯，以检索正在伸缩的 Kubernetes 集群状态的指标和统计信息。然后，这些指标将被保存在指标数据存储中，这些数据存储被发送到信号和自动伸缩引擎，以确定如何添加或删除计算资源。

为什么是 Clusterman？

我们是 Yelp 上开源软件的主要支持者；我们从其他许多开源项目的努力中受益，并将能够回馈社区的东西发布出去。自 Clusterman 项目创立以来，我们就一直想将其开源，现在，它已经支持 Kubernetes 了，没有比这更好的发布开源时机了。

每当这样的项目发布时，人们会问的第一个问题是：“我为什么要用你们的产品，而不是另一个已构建好的产品呢？”两个这样的产品是适用于 Spot Fleet 的 AWS Auto Scaling 和 Kubernetes Cluster Autoscaler。那么让我们将 Clusterman 与它们进行比较：

Clusterman	Auto Scaling for Spot Fleet	Kubernetes Cluster Autoscaler
支持任何类型的云资源 (ASG、spot fleet 等)	仅适用于 Spot Fleets	仅支持同构云资源（所有计算资源必须相同）
可插拔信号架构	三种不同的伸缩选择：目标跟踪、阶跃函数或基于时间	在 Pod 等待调度时伸缩集群
可主动自动伸缩以解决节点自举时间的延迟	没有主动伸缩功能	等待节点接入集群，然后继续
基本的 Kubernetes 支持	不具备 Kubernetes 的知识	支持节点和 Pod 亲和性等高级功能
可以在生产数据上模拟自动伸缩决策	没有模拟器	没有模拟器
可伸缩（开源）	闭源 API	可伸缩（开源）

我们想强调几点：首先，请注意 Clusterman 是唯一可以支持混合云资源（Spot Fleet、Auto-Scaling Group 等）的自动伸缩器，它甚至可以在同一个集群中处理这个问题！这就允许非常灵活的基础架构设计。

此外，Clusterman 的可插拔信号架构允许你编写你可以想象得到的任何类型的伸缩信号（并编写代码）。在 Yelp 中，我们通常认为 Kubernetes Cluster Autoscaler 方法（当 Pod 在等待时进行伸缩）对于大多数用例来说是适用的，但是具有创建更复杂的自动伸缩行为的灵活性对我们来说真的非常重要。我们如何从这种能力中受益的一个例子就是 Jolt，它是一个用于运行单元测试和集成测试的内部工具。Jolt 集群每天运行数以百万计的测试，并且工作负载具有非常高的可预测性；因此，我们编写了一个自定义信号，允许我们在 Pod 处于“等待”状态排队之前进行伸缩，这为开发人员节省了大量运行测试的时间！换句话说，Kubernetes Cluster Autoscaler 是被动的，但是 Clusterman 有足够的灵活性，可以在需要资源之前采取主动并进行伸缩。

公平地说，并不是每个人都需要做出复杂的自动伸缩决策的能力；许多用户使用 AWS Spot Fleet Autoscaler 或 Kubernetes Clusterman Autoscaler 等就可以了。幸运的是，对于这些用户来说，Clusterman 可以根据需要轻松地进行交换。例如，可以将其配置为读取 Kubernetes Cluster Autoscaler 所执行的所有相同的节点标签，并适当地执行操作。还要注意的是，Kubernetes Cluster Autoscaler 确实支持一些 Clusterman 还不知道的 Kubernetes 特性，比如 Pod 亲和力和反亲和力。但是，我们不断地为 Clusterman 添加新功能，当然，我们永远欢迎 Pull 请求。

作者介绍：

David R. Morrison，供职于 Yelp 的科学家和软件工程师。同时也是优化专家、数学家和摄影师。美国伊利诺伊大学香槟分校计算机科学博士。

原文链接：

https://engineeringblog.yelp.com/2019/11/open-source-clusterman.html

创作场景

Yelp 开源集群工具 Clusterman ，支持 Kubernetes