Twine: A Unified Cluster Management System for Shared Infrastructure

[linxuyalun]

Ref: Facebook 集群调度管理系统 · OSDI '20

[linxuyalun]

Twine 的出现解决了不同资源池中机器配置不同的问题，提供了动态配置机器的功能，这样可以合并原本独立的资源池，提高资源整体的利用率，在业务申请资源时可以根据需要配置机器，例如：改变内核版本、启用 HugePages 以及 CPU Turbo 等特性。

[linxuyalun]

分配器（Allocator）：对应 Kubernetes 中的调度器，负责为工作负载分配机器，它在内存中维护了所有机器的索引和属性并使用多线程处理资源的调度分配；
调度器（Scheduler）：对应 Kubernetes 中的控制器，它负责管理工作负载的生命周期，当集群出现硬件故障、日常维护等情况时会推动系统做出响应；
应用程序调度器（Application-Level Schedulers）：对应 Kubernetes 中的 Operator，如果我们想使用特殊的逻辑管理有状态服务，需要实现自定义的调度器；

这里我们围绕文章开头提出的动态集群和自定义配置展开讨论 Twine 的设计。

[linxuyalun]

动态集群

Twine 的动态集群建立在其抽象出的权利（Entitlement）上，每个权利集群都包含一组动态分配的机器、属于特定业务的伪集群。数据中心中的机器和任务之间建立其的这层抽象使机器的分配变得更加动态：

分配器不仅会将机器分配给权利集群，还会把同一个权利集群中的工作负载调度到特定的机器上。

可以理解为在集群的基础上继续加了一层抽象，这层抽象是动态配置的，具体的实现可以利用虚拟网络进行隔离。关键是，Twine 利用这种方法去构建一个属于特定业务的集群。

[linxuyalun]

自定义配置

私有的节点池很不利于机器的共享，但是确实有很多业务对机器的内核版本和配置有要求，例如：很多机器学习或者数据统计的任务都需要使用 Linux 的 HugePages 优化性能，但是 HugePages 可能会损害在线服务的性能。

Twine 由此引入了主机配置的概念，为每个权利集群绑定独立的主机配置，当数据中心的机器被分配到某个伪集群时，会根据集群的配置更新机器，为工作负载提供最符合需求的运行环境，这在 Facebook 内将 Web 层的服务性能提高了 11%，也是目前的 Kuberentes 无法满足的。

这点的优化也是很关键的，相当于去利用伪集群的概念进行异构配置的隔离。反过来说，k8s 想做到这一点的话可能需要配置繁杂的 label，同时各个 Pod 的部署都需要有进行亲和性和污点相关的配置，肯定会繁琐很多。

[linxuyalun]

在 Kubernetes 大行其道的今天，能够看到 Facebook 分享其内部集群管理系统的不同设计还是有很大意义的，这让我们重新思考 Kubernetes 中设计带来的潜在问题，例如：中心化的 etcd 存储，很多使用 Kubernetes 的大公司为了让其能够管理更多节点，都会选择修改 etcd 的源代码或者替换存储系统。

Kubernetes 对于集群规模较小的公司还是有很大好处的，而其本身确实能够解决集群管理中 95% 的问题，Kubernetes 也不是银弹，它没法做到解决场景内的全部问题。在应用 Kubernetes 时，中小规模的公司可以全盘接收 Kubernetes 的架构和设定，而大公司可以在 Kubernetes 的基础上做一些定制，甚至参与到标准的制定中增加技术影响力、提高话语权并且帮助支撑公司业务成长。