文献总结 - [2016] Burns_Borg, Omega, and Kubernetes

原文链接:Borg, Omega, and Kubernetes: Lessons learned from three container-management systems over a decade

一、主旨

Google内研或主导的三个集群管理/编排系统,三者各有不同的起始目标,因此其架构和特点也各有不同。但K8s作为Borg和Omega的形式后继,有着后发优势,发扬了前两者的一些优势,也吸取了前两者的一些教训,此文可从一定程度上深化我们对K8s一些decisions的理解。

Lessons learned from three container-management systems over a decade

二、内容梳理

三、重点分析

  1. 架构的扩展性和可持续性/一致性 (consistency) 对于高速发展中的系统非常重要,业务扩张必然带来需求增加,如果不能做到新功能实现与原有系统的一致/连贯,必然会对系统带来额外的复杂度,不论是开发、维护还是部署、使用。
  2. 容器技术为系统架构、云计算、数据中心、PaaS均带来突破性变革(普遍共识)。
  3. K8s的一致的控制循环——调谐:从顶层业务系统视角出发,拆分成不同的系统组件,基于容器,包装成不同的对象,每个对象有不同的控制器,但控制逻辑均为调谐,通过一个个小的控制循环达成整体业务系统的控制。
  4. 原文举例说明了一个非常实用的在生产环境在线排查问题的方法:(带入Anylearn视角)后端出问题,卡死或响应异常,定位到某个pod后,可以直接扔掉该pod的标签(该pod还在正常存续中),让上层的ReplicaSet或其他replication controller的selector过滤不到这个pod,便会再启动一个pod(因为它认为丢失了一个)。这样一来,既可以“重启”后端的副本,恢复业务,同时可以留住pod,保存现场,乃至上到pod内排查问题,两不耽误。
  5. 建模其实也非常重要。Google对于Borg最不满意的一点就是其基于index的容器组织逻辑,容器数量成规模后,中间丢一个index就可能会有问题,维护所有的index-container mapping也是个麻烦事。基于label的组织和过滤就要灵活得多。带入Anylearn视角,我们现在的数据建模可能需要三思的有:训练项目与训练任务的从属关系模型、资源与算法/数据集/模型/文件的继承关系模型、模型未拆分成细粒度对象、文件未拆分成细粒度对象,等等。

四、引申

做分布式锁(本文中提到选主相关应用)的Chubby: Burrows, M. 2006. The Chubby lock service for loosely coupled distributed systems. Symposium on Operating System Design and Implementation (OSDI), Seattle, WA.