原文链接：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
二、内容梳理
三、重点分析
- 架构的扩展性和可持续性/一致性 (consistency) 对于高速发展中的系统非常重要，业务扩张必然带来需求增加，如果不能做到新功能实现与原有系统的一致/连贯，必然会对系统带来额外的复杂度，不论是开发、维护还是部署、使用。
- 容器技术为系统架构、云计算、数据中心、PaaS均带来突破性变革（普遍共识）。
- K8s的一致的控制循环——调谐：从顶层业务系统视角出发，拆分成不同的系统组件，基于容器，包装成不同的对象，每个对象有不同的控制器，但控制逻辑均为调谐，通过一个个小的控制循环达成整体业务系统的控制。
- 原文举例说明了一个非常实用的在生产环境在线排查问题的方法：（带入Anylearn视角）后端出问题，卡死或响应异常，定位到某个pod后，可以直接扔掉该pod的标签（该pod还在正常存续中），让上层的ReplicaSet或其他replication controller的selector过滤不到这个pod，便会再启动一个pod（因为它认为丢失了一个）。这样一来，既可以“重启”后端的副本，恢复业务，同时可以留住pod，保存现场，乃至上到pod内排查问题，两不耽误。
- 建模其实也非常重要。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.