Borg（谷歌内部的k8s）∶仓库规模计算机的诞生
理解我们对自动化的态度的演变，以及何时何地部署自动化是最佳的另一种方式，就是考虑我们的集群管理系统发展的历史。正如前文"MySQL On Borg"体现了手动操作到自动化的成功转变，集群上线流程则体现了不仔细考虑在哪里以及如何实现自动化所带来的不足。集群管理的研发也展示了另一个关于如何实行自动化的教训。和我们之前提过的两个例子一样，一个复杂的东西诞生于简单初始环境的不断演变。Google的集群最初与其他人当时的小型网络部署方式很类似∶具有特定用途和异构配置的很多机柜服务器。工程师将登录到一些知名的"主"机来执行管理任务;"黄金"二进制文件和配置保存在这些主机上。当时我们只有一个托管供应商，大多数的命名逻辑隐含地假定了位置信息。随着生产环境的增长，我们开始使用多个集群，多个域（集群名称）也变得有必要了。现在就需要一个文件来描述每个机器做了什么，以一些松散命名策略将机器编组。这个描述文件，加上一个并行化的SSH，允许我们一次重新启动（例如有的搜索机器。在当时，收到类似"搜索团队已经用完x1 这台机器，爬虫团队现在可以使用了"的工单是很普通的。
自动化研发开始了。最初的自动化包括简单的 Python 脚本，执行如下操作。
● 服务管理∶ 保障服务运行（例如，在段错误后重新启动）。
● 跟踪哪些服务应该运行在哪些机器上。
● 日志消息解析∶SSH进入每一台机器，用正则表达式过滤日志。
自动化最终成长为使用一个数据库来跟踪机器状态，并且采用了更先进的监控工具。随着自动化系统的成长，我们现在可以自动管理机器的大部分生命周期∶当机器坏了，移除服务，送去修理并且在它们修好后恢复配置。
但是退一步说，这种自动化是有用的，但是限制非常多，因为该系统的抽象对象与物理机紧密相关。我们需要一个新的方法，因此 Borg（参见文献【ver15】）诞生了∶从相对静态的主机/端口/作业分配，到将一系列机器看作受管理的海量资源的创新。Borg 成功的核心——以及它的核心理念——是把集群管理变成了一个可以发送 API的中央协调主体。这从另外一个维度解放了效率、灵活性以及可靠性∶对比以前的机器的"独占"模式，Borg能够让机器来调度任务，例如在同一台机器上同时进行批处理和面向用户的任务。
此功能最终使得连续性的、自动的操作系统升级只需要很少的持续"'工作——这种工作不会根据生产部署的总规模而增加。当机器状态略有偏差时，可以自动进行修补;对SRE 来说，机器的损坏和生命周期管理基本上已经不需要任何操作了。成千上万的机器加入系统，或者出现问题，被修复，这一切都不需要SRE的任何操作。回应 Ben TreynorSloss 曾说过的话∶通过将问题看作是一个软件问题的方法，最初的自动化努力给我们争取了足够的时间，把集群管理转化为自治系统，而不是自动化系统。我们通过相关的数据分布、API、集中式架构，以及经典的分布式软件系统研发进入了基础设施管理领域。
这里有一个有趣的比喻∶我们可以将单机环境与集群管理抽象的发展之间直接映射。用这个方法、在另一台机器上重新调度某个程序与进程从一个CPU 移动到另一个CPU的过程十分相似∶当然，这些计算资源其实是在网络链接的另一端，但是这又有多重要呢?从这个视角出发，重新调度看起来像是系统的一个固有特征，而不是可以"自动化"的——不管怎样，人类的反应速度肯定是不够快。在集群上线这个例子中也类似∶在这个比喻中，集群上线仅仅是增加额外的调度能力，有点像在一台电脑上添加磁盘或内存。然而，一个单一节点的计算机在大量组件出现问题时，是不会继续运行的。一旦全球计算机的增长超过了一定规模时，它必须是自我修复的，因为根据统计学来说，每秒它都会发生大量故障。这意味着，随着系统的层次结构不断上升，从手动触发，到自动触发，到自主化，一些自我检查的能力是必需的。
页:
[1]