第 2 章 架构
本章将列出所有用于构建和运营能够运行各种云原生服务的子系统。我们基于 Aether 说明特定的设计选择，首先介绍为何企业可能首先安装像 Aether 这样的系统。
Aether 是基于 kubernetes 的边缘云，增强基于 5G 的连接服务，主要用户是那些希望利用 5G 连接支持可预测、低延迟关键任务的企业。简而言之，"基于 Kubernetes"意味着 Aether 能够承载基于容器的服务，而"基于 5G 连接"意味着 Aether 能够通过这些服务连接整个企业物理工厂的移动设备。支持边缘应用部署的特性组合，加上 Aether 被作为托管服务提供，意味着 Aether 完全可以被描述为平台即服务(PaaS)。
Aether 通过在预制硬件中实现 RAN 和移动核心网用户平面来支持这种组合，并部署为 Aether 集群上的云原生工作负载。通常这被称为本地分流(local breakout) ，支持移动设备和边缘应用直接通信，而数据流量不需要离开企业。图 2 描述了这个场景，虽然没有提供明确的边缘应用，但示例中的物联网(IoT)是一个很好的例子。
图 2. Aether 作为混合云，边缘应用和 5G 数据平面(称为本地分流)部署在预制硬件中，各种管理和控制相关的工作负载运行在中心云中。
工业 4.0 的 PaaS
像 Aether 这样的边缘云是工业 4.0 趋势的重要组成部分: 智能设备、健壮的无线连接和基于云的 AI/ML 能力的结合，所有这些共同努力实现基于软件的优化和创新。
将行业资产连接到云有可能带来变革性的好处。首先，通过传感器、视频反馈和设备遥测，收集资产和基础设施的深层次运营数据，包括将 ML 应用于这些数据，以获得洞察、识别模式和预测结果(例如当设备可能出现故障时)，然后实现工业流程自动化，从而最小化人工干预并实现远程操作(例如，功率优化、关闭空转设备)。一般来说，目标是创建一个能够通过软件持续改进工业操作的 IT 基础设施。
至于为什么我们将 Aether 作为此类用例的 PaaS，答案有些主观。通常，PaaS 提供的不仅仅是虚拟化计算和存储(IaaS 就是这样做的)，还包括额外的"中间件"层，使开发人员能够部署他们的应用程序，而无需处理底层基础设施的所有复杂问题。以 Aether 为例，该平台支持 5G 连接，边缘应用可以基于 API 定制连接，以更好满足其目标。也可以将 ML 平台或物联网平台加载到 Aether 上，进一步增强其对应用的支持。
该方法既包括边缘(预制)组件，也包括中心化(非预制)组件。对于边缘应用来说是这样，通常有一个中心化的对应组件运行在商品云中。5G 移动核心网也是如此，其预制用户平面(UP)与集中控制平面(CP)配对。图中显示的中心云可能是私有的(即由企业运维)，或者公共的(即由商业云提供商运维)，或者两者的某种组合(并非所有集中组件都需要运行在同一个云中)。图 2 中还显示了集中式控制和管理平台(Control and Management Platform) ，表示将 Aether 作为托管服务所需的所有功能，系统管理员可以使用该平台提供的门户来操作企业的底层基础设施和服务。本书其余部分是关于实现控制和管理平台(Control and Management Platform) 的所有内容。
2.1 边缘云
边缘云，在 Aether 中被称为 ACE(Aether Connected Edge)，是一个基于 Kubernetes 的集群，类似于第 1 章中的图 1。它是由一个或多个服务器机架组成的平台，通过叶棘交换网络相互连接，由 SDN 控制平面(SD-Fabric)管理。
图 3. Aether Connected Edge (ACE) = 云平台(Kubernetes 和 SD-Fabric)加上 5G 连接服务(RAN 和移动核心网用户平面)。虚线(例如 SD-RAN 和单个基站之间，以及网络操作系统和单个交换机之间)表示控制关系(例如，SD-RAN 控制小基站，SD-Fabric 控制交换机)。
如图 3 所示，ACE 在这个平台上托管了两个额外的基于微服务的子系统，共同实现了 5G 连接即服务(5G-Connectivity-as-a-Service) 。第一个子系统 SD-RAN 是基于 SDN 的 5G 无线接入网(RAN)实现，控制部署在整个企业中的小型蜂窝基站。第二个子系统 SD-Core，是基于 SDN 的移动核心网用户平面实现，负责在 RAN 和互联网之间转发流量。SD-Core 控制平面(CP)运行在场外，没有显示在图 3 中。这两个子系统(以及 SD-Fabric)都部署为一组微服务，但是关于这些容器实现的功能的细节对本文的讨论并不重要。就我们的目的而言，它们代表任何云原生工作负载。(感兴趣的读者可以参考我们的配套的 5G 和 SDN 书籍，以获得更多关于 SD-RAN、SD-Core 和 SD-Fabric 内部工作的信息。)
延伸阅读:
L. Peterson and O. Sunay. 5G Mobile Networks: A Systems Approach. March 2020.
L. Peterson, et al. Software-Defined Networks: A Systems Approach. November 2021.
一旦 ACE 在这种配置下运行，就可以托管一系列边缘应用程序(图 3 中没有显示)，与任何基于 Kubernetes 的集群一样，Helm Chart 是部署这些应用程序的首选方式。ACE 的独特之处在于，能够通过 SD-RAN 和 SD-Core 实现 5G 连接服务，将此类应用程序与整个企业的移动设备相连。该服务作为托管服务提供，企业系统管理员能够使用可编程 API(和相关的 GUI 门户)来控制该服务，即对设备进行授权、限制访问、针对不同设备和应用设置服务质量参数等，如何提供这样的运行时控制接口是第 5 章的主题。
2.2 混合云
虽然可以只用一个站点实例化一个 ACE 集群，但 Aether 被设计为支持多个 ACE 部署，所有这些都可以被中心云管理。这种混合云场景如图 4 所示，显示了两个运行在中心云中的子系统: (1)移动核心网控制平面(CP)的一个或多个实例，以及(2)Aether 管理平台(AMP, Aether Management Platform)。
每个 SD-Core CP 控制一个或多个 SD-Core UP，由负责 5G 的标准组织 3GPP 指定。CP 实例(集中运行)与 UP 实例(在边缘运行)的配对在运行时决定，取决于企业站点所需的隔离程度。AMP 负责管理所有集中的和边缘的子系统(在下一节中介绍)。
图 4. Aether 在混合云配置运行中，移动核心网控制平面和 Aether 管理平台(AMP)运行在中心云中。
混合云有一个重要方面在图 4 中并不明显，那就是"混合云"最好被描述为一组 Kubernetes 集群，而不是物理集群(类似于第一章图 1 中开始的那个)。这是因为，虽然每个 ACE 站点通常对应一个由裸金属组件构建的物理集群，图 4 中所示的每个 SD-Core CP 子系统实际上都部署在商品云上的一个逻辑 Kubernetes 集群中。AMP 也是如此。Aether 的集中式组件能够运行在谷歌云平台、微软 Azure 和亚马逊 AWS 上，也可以通过模拟集群的形式运行，由类似 KIND(Kubernetes in Docker)这样的系统运行，使得开发人员可以在笔记本电脑上运行这些组件。
需要说明的是，Kubernetes 采用"集群 cluster"、"服务 service"这样的通用术语，并赋予了非常具体的含义。在 Kubernetes 语言中，Cluster 是一个逻辑域，Kubernetes 在其中管理一组容器。这个"Kubernetes 集群"可能与底层物理集群有一对一的关系，但 Kubernetes 集群也可能实例化在一个数据中心中，作为潜在的数千个这样的逻辑集群中的一个。我们将在后续章节中看到，即使是 ACE 边缘站点有时也会托管多个 Kubernetes 集群，例如，一个运行生产服务，另一个用于新服务的试验部署。
2.3 利益相关方
我们的目标环境是 Kubernetes 集群的集合，一些运行在边缘站点的裸金属硬件上，一些运行在中央数据中心。这就存在一个正交问题，即如何在多个利益相关方之间共享集群的决策责任。确定利益相关方是建立云服务的重要前提，虽然我们使用的示例可能不适合所有情况，但确实说明了设计的含义。
对于 Aether 来说，主要关心两个利益相关方: (1)作为整体管理混合云的云运营商，(2)企业用户，他们决定如何利用每个站点的本地云资源(例如，运行什么边缘应用程序，以及如何在这些应用程序之间隔离连接资源)。我们有时称后者为"企业管理员"，以区别于"终端用户"，后者可能希望管理自己的个人设备。
因为需要对这些利益相关方进行身份验证和隔离，因此这是一个多组合的体系架构，从而允许每个利益相关方只访问自己负责的对象。这使得该方法无法确定所有的边缘站点是否属于某个单一组织(该组织也负责运维云)，或者存在一个单独的组织，该组织向一组不同的企业(每个企业跨越一个或多个站点)提供托管服务。该体系架构还可以容纳最终用户，并为他们提供"自助服务"门户。
此外，还有潜在的第三个利益相关方，即第三方服务提供商。这引出了一个更大的问题，即我们如何部署和管理额外的边缘应用程序。为了使讨论更加具体(但仍停留在开源领域)，我们通过 OpenVINO 作为说明示例。OpenVINO 是一个部署 AI 推理模型的框架，这在 Aether 环境中很有趣，它的一个用例是处理视频流，例如检测和统计进入 5G 摄像头视野的人。
延伸阅读:
一方面，OpenVINO 就像我们已经整合到混合云中的 5G 相关组件一样，被部署为基于 Kubernetes 的一组微服务。另一方面，我们不得不问谁会负责管理，也就是说"谁负责运营 OpenVINO?"
一个答案是，已经管理混合云剩余部分的运营商管理添加到云中的边缘应用程序集合。企业管理员可能会一个站点一个站点的激活和控制这些应用程序，但运营团队负责提供、部署和管理这些边缘云，也为 OpenVINO 和运行在该云上的任何其他应用程序做同样的事情。从一个边缘服务(5G 连接)推广到任意多个边缘服务将对控制和管理产生影响(这一点我们将在整本书中进行讨论)，但从根本上讲，对于我们已经设定好的路线没有任何改变。
让云运营商策划和管理(curate and manage) 一组边缘服务是 Aether 的假设(本书也有这样的假设)，但为了完整性，我们注意到另外两种可能。一是我们扩展了混合架构，以支持独立第三方服务提供商。每个新的边缘服务都需要从边缘云中获得自己独立的 Kubernetes 集群，然后第三方提供商将管理该集群中运行的服务的所有责任纳入其中。然而，从云运营商的角度来看，这项任务变得更加困难，因为体系架构需要支持 Kubernetes 作为托管服务，有时称为容器即服务(CaaS, Container-as-a-Servic)[1]。按需创建独立的 Kubernetes 集群比我们在本书中提出的更进一步，相对来说，第二种可能的答案似乎更有可能发生。
[1] 这并不是严格意义上的非此即彼。也可以对边缘服务进行管理，为其提供集群资源，但随后将运维责任委托给第三方服务提供商。
第二种是企业内部出现的多云。今天，大多数人将多云等同于跨多个超大规模运营商运行的服务，但随着边缘云变得越来越普遍，企业可能会部署多个边缘云到其本地站点，有些是由超大规模运营商提供的，有些则不是，每个边缘云托管不同的边缘服务子集。例如，一个边缘云可能托管 5G 连接服务，另一个可能托管 OpenVINO 这样的 AI 平台。这带来的问题是，本书中描述的云管理技术是否仍然适用于这种环境。答案是肯定的，但根本的管理挑战依然存在。主要区别在于知道什么时候直接控制 Kubernetes 集群(就像我们在这本书中所做的那样)，什么时候通过集群的管理者间接控制集群。此外还有一些多云特有的新问题，如云间服务发现等，但超出了本书的范围。
2.4 控制与管理
现在我们准备介绍 Aether 管理平台(AMP, Aether Management Platform)的架构，如图 5 所示，它管理 ACE 集群的分布式集合和运行在中心云中的其他控制集群。图示说明了其递归性质带来的管理挑战，即 AMP 也负责管理 AMP！
AMP 包括一个或多个面向不同利益相关方的门户，图 5 展示了本书中我们关注的两个示例: 一个是面向需要管理交付到本地站点的服务的企业管理员用户门户，另一个是面向负责保持 Aether 最新和平稳运行的运维团队的运维门户。此外，还有可能有其他利益相关方(用户类别)，但这种区别代表了使用云服务的人和运维云服务的人之间的自然划分。
图 5. 组成 AMP 的四个子系统: 资源配置(Resource Provisioning)，生命周期管理(Lifecycle Management)，运行时控制(Runtime Control)，以及监控和遥测(Monitoring & Telemetry)。
我们并不关注为 AMP 功能子集提供图形界面的门户，而是介绍 AMP 支持的总体功能，它由四个子系统组成:
- 资源配置(Resource Provisioning): 负责初始化和配置资源(如服务器、交换机)，为 Aether 增加、替换或升级容量。
- 生命周期管理(Lifecycle Management): 负责在 Aether 上持续集成和部署可用的软件功能。
- 运行时控制(Runtime Control): 负责对 Aether 提供的服务(如连通性)进行持续的配置和控制。
- 监控和遥测(Monitoring & Telemetry): 负责收集、归档、评估和分析 Aether 组件产生的遥测数据。
内部每个子系统都被实现为高可用的云服务，作为微服务的集合运行。该设计与云无关，因此 AMP 可以部署在公共云(如谷歌云，AWS, Azure)，运营商拥有的电信云(如 AT&T 的 AIC)，或企业拥有的私有云。对于目前试点部署的 Aether，AMP 运行在谷歌云上。
本节其余部分将介绍这四个子系统，接下来的章节将对每个子系统进行更详细的介绍。
2.4.1 资源配置(Resource Provisioning)
资源配置子系统负责配置并引导资源(包括物理和虚拟的)，使它们处于便于生命周期管理子系统可以接管并管理在这些资源上运行的软件的状态。大致对应于 Day 0 操作，包括安装和物理连接硬件的实际操作方面，以及管理物理资产所需的库存跟踪。
图 6. 资源配置高层概要。
图 6 给出了高层概要。由于运维团队将资源物理连接到云中，并在库存存储库(Inventory Repo)中记录这些资源的属性，零接触配置(Zero-Touch Provisioning)系统(a)生成一组存储在配置存储库(Config Repo)中的配置工件，并在生命周期管理期间使用，以及(b)初始化新部署的资源，以便它们处于生命周期管理子系统能够控制的状态。像其他代码模块一样，将配置指令存储在存储库中是一种被称为配置即代码(Configuration-as-Code) 的实践，本书将以不同方式应用这一实践。
回想一下，在第一章中，我们曾提到"Aether 平台"不同于托管在该平台上的云原生工作负载。这与此相关，因为资源配置子系统必须保证在生命周期管理子系统完成工作之前启动并运行这个平台。但是在循环依赖的另一个例子中，生命周期管理子系统也扮演着保持底层平台更新的角色。
显然，"安装和库存(Install & Inventory)"这一步骤需要人工参与，并且需要手动准备资源，但我们的目标是尽量减少运维人员的配置步骤(以及相关专业知识)，并最大化零接触配置系统的自动化程度。还要注意，图 6 偏向于提供一个物理集群，比如 Aether 中的边缘站点。对于还包括一个或多个运行在中心数据中心的虚拟集群的混合云，也需要提供这些虚拟资源。第 3 章从更广泛的角度介绍了配置，同时考虑了物理和虚拟资源。
2.4.2 生命周期管理(Lifecycle Management)
生命周期管理是将经过调试、扩展和重构的组件(通常是微服务)集成到一组工件(例如 Docker 容器和 Helm Chart)中，然后将这些工件部署到云上的过程。其包括全面的测试机制，通常还包括开发人员检查和评审代码的过程。
图 7. 生命周期管理高层概要。
图 7 给出高层概要，分解为集成和部署阶段是很常见的，后者将第一阶段的集成工件与前面小节中介绍的资源配置生成的配置工件相结合。图中没有显示任何人工干预(在开发之后)，这意味着任何签入代码存储库的补丁都会触发集成，而任何新的集成构件都会触发部署。这通常被称为持续集成/持续部署(CI/CD)，尽管在实际部署前，运维人员的判断力和其他因素也会被考虑在内。
生命周期管理的关键职责之一是版本控制，包括评估依赖关系，但有时也可能需要推出软件的新版本和回滚到旧版本，以及运维同时部署的多个版本。管理成功部署系统中每个组件的正确版本所需的所有配置状态是我们在第 4 章中讨论的核心挑战。
2.4.3 运行时控制(Runtime Control)
一旦部署和运行，运行时控制就会提供可编程 API，可以被各个利益相关方用来管理系统提供的任何抽象服务(例如，Aether 的 5G 连接)。如图 8 所示，运行时控制子系统部分解决了第一章中提出的"管理竖井"问题，因此用户不需要知道连接可能跨越四个不同的组件，或者如何单独控制/配置它们(例如在移动核心网的例子中，SD-Core 是分布在两个云上的，由 CP 子系统负责控制 UP 子系统)。以连通性服务为例，用户只关心是否能够对设备进行端到端授权和设置 QoS 参数。
图 8. 持续运行时控制的示例用例。
注意，图 8 关注的是"连接即服务(Connectivity-as-a-Service)"，但同样的思想也适用于云提供给终端用户的所有服务。因此，我们将这个图抽象为运行时控制子系统代理了对任何底层微服务(或微服务集合)的访问，云的设计者希望通过这一子系统向其他用户(包括 AMP)公开这些访问接口。实际上，运行时控制实现了一个可以通过可编程 API 编码的抽象层。
考虑到这一中介角色，运行时控制子系统给用户提供了抽象服务建模(表示)的机制，存储了与这些模型相关的任何配置和控制状态，并将这种状态应用于底层组件，确保它们与运维人员的意图保持同步，并授权用户试图在每个服务上调用的集合 API 调用。这些细节将在第五章中有详细说明。
2.4.4 监控和遥测(Monitoring & Telemetry)
除了控制服务功能之外，还必须对运行中的系统进行持续监控，以便运维人员能够诊断和响应故障、调优性能、进行根因分析、执行安全审计，并了解何时需要提供额外容量。这需要一些机制来观察系统行为、收集和归档结果数据、分析数据并触发各种操作，以及在仪表板中可视化数据(类似于图 9 所示的示例)。
图 9. Aether 仪表板示例，显示其中一个子系统(SD-Core)的健康状况。
从广义上讲，云管理的这方面通常由三个部分组成: 收集定量指标(例如平均负载、传输速率、每秒操作数)的监控组件；收集诊断消息(例如，解释各种事件的文本字符串)的日志组件；以及可以通过一组微服务重建工作流的跟踪组件。它们都包含时间戳，因此可以将定量分析与定性解释联系起来，以支持诊断和分析。
2.4.5 总结
通过对这一管理架构的概览可以使人得出这样的结论: 这四个子系统是以一种严格的、自顶向下的方式构建的，是完全独立的，但事实并非如此。更准确的说，该系统是自下而上发展的，每次解决一个紧迫问题，同时创建一个大型开源组件生态系统，这些组件可以在不同组合中使用。我们在本书中展示的是对最终结果的回顾介绍，分为四个子系统只是用来帮助理解。
实际上，这四个组成部分之间有许多相互作用的机会，在某些情况下，相互重叠的问题导致大量的辩论。这就是为什么云的运维是如此棘手的问题。例如，很难在资源配置结束和生命周期管理开始之间划出一条清晰的界线。人们可以将配置视为生命周期管理的"第 0 步"。另一个例子是，运行时控制和监控子系统通常组合在一个用户界面中，为运维人员提供一种读取(监控)和写入(控制)运行系统的各种参数的方法。我们建立闭环控制的方式是连接这两个子系统。
这两个"简化"允许我们将管理平台的架构概述减少到图 10 所示的二维表示。在一个维度中，位于被管理的混合云之上的是运行时控制子系统(包括关闭控制回路的监控和遥测)，用户和运维人员通过定义良好的 REST API 读写系统运行时参数。在另一个维度中，运行在混合云旁边的是生命周期管理子系统(包括作为步骤 0 的资源分配)。运营商和开发人员通过将代码(包括配置规格)签入到存储库中来指定对系统的更改，然后定期触发运行时系统的升级。
图 10. 管理平台的简化表示。
这种简化的视角让我们注意到了其中的模糊性，尤其是"对运行时系统参数的更改"与"升级正在运行的系统"之间的区别。通常，生命周期管理负责配置每个组件(包括部署每个组件的版本)，而运行时控制负责控制每个组件。但是很难在配置和控制之间划一条线。配置更改是否只在首次启动组件时才发生，或者是否可以更改正在运行的系统的配置，如果更改，这与更改控制参数有何不同？如图 10 中虚线箭头所示，让运行时控制通过生命周期管理进行更改是否有价值？这种差异通常与更改的频率有关(这又与更改对现有流量/工作负载的破坏程度有关)，但最终，如何称呼它并不重要，只要使用的机制满足我们的所有需求。
当然，一个操作系统无法容忍这样的歧义。管理的每个方面都必须以一种定义良好的、有效的和可重复的方式得到支持。这就是为什么我们提供了四个子系统的具体实现的介绍，这反映了一组特定的设计选择。随着在接下来的章节中添加更多的细节，我们将指出做出不同工程决策的机会，以及我们的选择背后的设计原理。
2.5 DevOps
前面的讨论集中在组成控制和管理平台的子系统上，但是这样的平台是供人们使用的，这意味着需要一组操作流程和程序。在云环境中，这些流程和程序现在通常围绕 DevOps 模型组织。下面给出了一个高层次总结，并对全书中提出的与运维相关的流程进行了更广泛的讨论。
DevOps 已经成为一个被滥用的术语，通常被认为是指打破开发云功能的工程师以及部署和管理云功能的运维人员之间的界限，由同一个团队同时负责两者。但这个定义太不精确了，提供不了什么帮助。有三个方面对于了解非常重要。
首先，当涉及到一组服务(或用户可见的特性)时，开发人员确实在部署和运维这些服务方面扮演了重要角色，让他们能够做到这一点正是管理平台的价值所在。以 Aether 中负责 SD-RAN 的团队为例，该团队不仅实现新的 SD-RAN 特性，而且一旦他们的补丁集被检入到代码存储库中，这些更改就会被集成并由前一节介绍的自动化工具链部署。这意味着 SD-RAN 团队还要负责:
- 将测试用例添加到生命周期管理的 CI 部分，并编写生命周期管理的 CD 部分所需的任何配置规范。
- 检测代码，使其报告到监控和遥测框架，提供所需的仪表板和告警，以排除出现的任何问题。
- 增加运行时控制的数据模型，从而使得组件内部接口可以连接到云的外部可见的北向接口。
一旦部署并投入使用，SD-RAN 团队还负责诊断任何由专门的"on call"支持人员无法解决的问题[2]。SD-RAN 团队的动机是利用平台的自动化机制(而不是利用临时变通)，并记录组件行为(特别是如何解决已知的问题)，避免自己在半夜接到支持电话。
[2] 无论是传统的还是基于 DevOps 的，都有一个典型的前线支持团队，通常被称为 Tier-1 支持团队。他们直接与客户互动，第一个对警报做出反应，根据精心编写的剧本解决问题。如果一级支持不能解决问题，就会提升到二级，并最终提升到三级，后者是最了解实现细节的开发人员。
第二，由于构建在控制和管理平台中的丰富的功能集，因此前面段落中介绍的所有活动都是可能的，这也是本书的主题[3]。必须有人构建这个平台，其中包含测试框架，可以插入单个测试；包含自动部署框架，能够在不需要人工干预的情况下，将升级扩展到数量可扩展的服务器和站点；包含监控和遥测框架，组件可以报告状态；包含运行时控制环境，可以将高级指令转换为后端组件的低级操作；等等。虽然这些框架曾经是由一个团队创建的，其任务是保持其他服务的平稳运行，但它们已经有了自己的生命。控制和管理平台现在有自己的 DevOps 团队，他们除了持续改进平台，还需要处理现场运维事件，并在必要时与其他团队(如 Aether 的 SD-RAN 团队)互动，以解决出现的问题。他们有时被称为系统可靠性工程师(SRE, System Reliability Engineer)，除了负责控制和管理平台，还要求其他人执行操作规程，这就是接下来要讨论的 DevOps 的第三个方面。
[3] 这就是我们为什么把管理系统称为"平台"的原因，AMP 就是一个例子。作为公共框架，开发人员可以插入其他云组件并利用它的能力。这就是最终解决"管理竖井"问题的方式。
谷歌的经验
我们对 DevOps 的概述是基于在谷歌中如何实践的方法，这是一个很好的例子，说明努力把辛苦降到最低是多么好的事情。随着谷歌积累了构建和运行云的经验，他们对云管理系统的逐步改进被吸收到一个名为 Borg 的系统中。
如今，开源项目 Kubernetes 广泛应用于整个行业，它就是从 Borg 中分离出来的。Kubernetes 所体现的功能随着时间的推移不断发展，以应对部署、升级和监控一组容器的运维挑战，这是"水涨船高"的一个很好的例子。如果有足够的时间，下一层云管理机制(大致对应于本书中涉及的主题)也可能会出现。正如我们将看到的，这一问题具有多维度的挑战。
最后，在遵守纪律和严格的运维操作时，所有团队都严格遵守两个定量规则。第一条规则平衡了特性开发速度和系统可靠性。每个组件都有出错预算(error budget)(即服务失效所占时间的百分比)，一旦组件出错时间超过了预算，就不能推出新特性。这个测试是 CI/CD 管道上的一个"门禁(gate)"。第二条规则平衡了花在运维上的时间(人工诊断或修复问题的时间)和花在控制和管理平台上的新功能工程开发上的时间，以减少未来的工作量。如果把太多时间花在苦干上，而把太少时间花在改善控制和管理平台上，那就意味着需要额外的工程资源。
延伸阅读:
Site Reliability Engineering: How Google Runs Production Systems, 2016.
