序
在过去一段时间，我们将应用程序迁移到云上，如今又开始将它们拆散，接下来我会解释这是什么意思。
随着市场的增长，人们赖以建立业务的功能单元会逐渐缩小，汽车工业的发展历史就是一个典型例子。当 20 世纪 20 年代末建设福特荣格河综合体(Ford River Rouge Complex)时，量产汽车相对还是新事物，市场也比较小，因此像荣格河综合体这样的工厂必须制造所有组件。大致说来，工厂一边输入水、橡胶和铁矿石，另一边则输出汽车。当然，随着汽车市场的增长，庞大的汽车零部件供应商生态系统也成长了起来，为汽车配套制造车轮、座椅、脚垫等等。如今，大型汽车公司更像是集成商，而不是汽车零部件生产商。
应用程序领域也发生了同样的动态发展过程。在 20 世纪 70 年代，同一家制造商制造芯片、电路板、系统组件、操作系统和各种应用程序。随着时间的推移以及市场的增长，已经没有哪家公司能够独自提供所有软硬件组件了。硬件和软件分离并催生了多家独立公司，然后又有很多公司围绕独立的应用程序建立起来。
这个市场一直在持续增长，过去的几年里，我们又看到了应用程序自身的解体。应用程序的通用子组件正在被提取出来，公司和项目正在围绕这些通用组件构建。今天如果需要构建一个应用程序，可以通过第三方 API 完成用户身份验证、发送文本或电子邮件、流媒体视频、授权访问资源以及许多其他有用的功能。
这和本书有什么关系？虽然上一个十年我们看到应用程序大规模向云迁移，但下一个十年我们很有可能看到应用程序及其组件大规模远离云。由于工作负载子组件已经在很大程度上与应用程序分离，因此可以在任何地方运行，特别是可以运行在专门为它们构建和优化的基础设施上！事实上，我们开始看到一种只能被描述为反云(anti-cloud)的趋势，即大公司选择将一些工作负载从大型云拉回到自己优化的基础设施中。我们甚至看到创业公司从一开始就选择建立自己的基础设施，因为他们了解这样做的成本和性能优势。
在"深入浅出边缘云"中，作者不仅提供了云运维的详细介绍(这已经是过去十年的事情了)，而且还介绍了新时代分布式云的运维。在许多方面，云时代是系统的低潮期，因为在应用程序层之下有太多东西深埋在三家大型云提供商的工程组织之中。但这种情况正在发生改变，要想与之一起改变，需要了解它是如何运作的，这就是为什么你需要读这本书。
Martin Casado, a16z 合伙人
前言
云无处不在。每个人都通过云来访问或交付服务，但不是每个人都将构建和运维云。那么，为什么我们需要要关心如何把一堆服务器和交换机变成全天候服务交付平台呢？这是谷歌、微软、亚马逊和其他云提供商为我们做的事情，而且做得非常好。
我们相信，由于分布式应用程序不仅运行在大型中央数据中心，而且运行在边缘，因此这一问题的答案是云正在以另一种形式变得无处不在。随着应用程序的解耦，云正从数百个数据中心扩展到数万个企业。虽然商品云提供商显然渴望把这些边缘云作为其数据中心的逻辑扩展来管理，但他们并没有垄断实现这一目标的专有技术。
这本书列出了一个小型工程师团队在一年的时间里建立并且全天候运维一个边缘云的路线图。这种边缘云跨越了十几家企业，承载重要的云原生服务，在我们的例子里是 5G 连接。该团队通过利用 20 多个开源组件来实现这一点，但选择这些组件只是一个开始。在这个过程中，有几十个技术决策要做，还有几千行配置代码要写。我们认为这是一个可重复的练习，这些配置文件代码是开源的，提供给那些想要更详细了解这个主题的人。
我们所说的边缘云是什么意思？我们需要区分由超大规模云提供商在其大规模数据中心运行的云(我们认为是核心云)以及由处于边缘的企业运行(或管理)的云。边缘是真实物理世界与云相遇的地方，例如，可以是收集和处理传感器数据的地方，也可以是交付由于时延或带宽需求需要让服务靠近终端用户的地方。
我们的路线图可能不适用于所有情况，但确实揭示了云运维过程中涉及的基本挑战和权衡。根据我们的经验，这是一个复杂的设计空间，有太多术语和业务情节需要理清。
目标读者
希望本书对任何尝试建立和运维自己的边缘云基础设施的人来说都有价值，但我们也希望至少为两个主要群体提供有用的信息。
首先是需要评估可用选项的读者，特别需要在使用大规模云服务或构建自己的边缘云(或两者的某种组合)之间做出决定的读者。我们希望为读者揭开边缘云的神秘面纱，帮助他们做出决定。
其次是需要在组织选择使用的任何云基础设施上构建应用程序和服务的开发人员。我们相信，对于开发人员来说，至少在高层次上了解云的"幕后"是什么是很重要的事情，这样就可以开发出更易于管理、更可靠的应用程序。开发和运维之间的互动越来越密切(DevOps 运动证明了这一点)，我们的目标是促进这种合作。监控和可观察性等主题对这类用户尤其重要。
开放源码
好消息是，有大量开源组件可供选择，以帮助管理云平台和构建在这些平台上的可伸缩应用程序。不过这也是坏消息，因为在 Linux 基金会、云原生计算基金会、Apache 基金会和开放网络基金会等开源联盟中，有几十个与云相关的项目，在这么大的项目空间中进行选择是我们构建云管理平台面临的最大挑战之一。很大程度上是因为这些项目都在争夺人们的注意力，它们提供的功能有很大的重叠，而且彼此之间有额外的依赖。
阅读本书的一种方法是将其作为云控制和管理在开源领域的导览。本着这种精神，我们不会复制那些优秀的项目文档，而是包含特定项目文档的链接(通常包括我们鼓励尝试的教程)，也包含这些项目的代码片段，但选择这些例子是为了帮助巩固我们试图就整个管理平台提出的要点，而不应被解释为试图记录个别项目的内部工作。我们的目标是解释如何利用各个拼图组合在一起构建端到端管理系统，并且在这样做的过程中，确定各种工具如何发挥作用，并且提出当前任何工具都无法消除的困难问题。
毫无疑问，我们需要解决的是一些具有挑战性的技术问题(尽管市场宣传与此相反)。毕竟，如何管理一个计算系统是一个和操作系统本身同样古老的问题。对云进行运维管理只是这个基本问题的现代版本，随着从设备管理升级到服务管理，这个问题变得更加有趣，这是个既新潮又基本的话题。
致谢
本书介绍的软件要归功于 ONF 工程团队及其合作开源社区的辛勤工作，感谢他们的贡献，特别感谢 Hyunsun Moon, Sean Condon 和 HungWei Chiu 对 Aether 控制管理平台的重要贡献，以及 Oguz Sunay 对 Aether 整体设计的影响。Suchitra Vemuri 对测试和质量保证提供了无价的见解。
这本书在很大程度上仍处于制作阶段，感谢每个提供反馈的人。请使用问题链接向发送意见，还可以在Wiki上查看目前的待办事项列表。
Larry Peterson, Scott Baker, Andy Bavier, Zack Williams, and Bruce Davie
2022 年 6 月
第 1 章 概述
云提供了一组用于启动和运维可伸缩服务的工具，但第一个问题是，如何运维云呢？这两个问题并不互相排斥，毕竟云是作为一组服务实现的，但是以这种方式提出问题可以避免给出"云会为您解决这些问题"这样的答案。本书将从裸金属硬件开始介绍如何运维云，一直到向用户提供一个或多个托管服务。
很少有人有理由实例化超大规模数据中心，但是在企业中部署私有边缘云(以及选择将边缘连接到数据中心以形成混合云)，正变得越来越普遍。我们使用"边缘云(edge cloud)"这个术语来区分关注点以及"核心云(core)"(即传统超大规模运营商领域)。这种优势更可能出现在企业或"物联网"环境中，比如工厂。边缘是指云服务与现实世界连接的地方，例如通过传感器和执行器，以及部署延迟敏感型服务以接近消费者的地方[1]。
[1] 托管在公共设施中的服务器集群也可以被认为是边缘云，并受益于本书介绍的技术和实践，但我们以企业部署作为范例，从而引入更广泛的需求集。
超大规模运营商确实愿意为我们管理边缘云，并作为其核心数据中心的扩展。有很多此类产品，比如谷歌的 Anthos、微软的 Azure Arc 和亚马逊的 ECS-Anywhere。但是对云进行运维的门槛并不高，并不是只有超大规模运营商才有这么做的必要。其他企业也可以基于现成开源软件包构建云，并提供运维云所需的所有相关生命周期管理和运行时控制。
本书将介绍这样的云管理平台。我们的方法是将重点放在必须解决的基本问题上，即所有云都常见的设计问题，但是在运维特定的企业云时，需要将概念讨论与特定工程选择相结合。我们将采用 Aether 作为例子，它是 ONF 项目，支持将 5G 边缘云作为托管服务。Aether 有以下特性，使它成为有趣的研究用例:
- Aether 部署在边缘站点(如企业)的裸金属硬件(服务器和交换机)中。这种预制云的规模从若干机架到多机架集群不等，可以根据数据中心最佳实践进行组装。
- Aether 支持运行在内部集群上的"边缘服务"和运行在商品云数据中心上的"集中服务"，从这个意义上来说，它是混合云(hybrid cloud)[2]。
- Aether 通过 5G 连接即服务(5G-Connectivity-as-a-Service)增强边缘云，提供了可运维的服务(基于底层云)。最终结果是，Aether 提供了托管的平台即服务(PaaS, Platform-as-a-Service)。
- Aether 完全由开源组件构建，添加的唯一东西是使其可运维所需的"粘合代码"和"规范指令"，从而意味着任何人都可以完全复制这个方法。
[2] 从技术上来说，Aether 也是多云(multi-cloud)，被设计用来利用多个公共云提供的服务，但最相关的是私有/公共(边缘/中心)方面，所以我们在本书中使用混合云这一术语。
Aether 能成为一个有趣的例子的另一个重要原因是，这是部署在三个在传统上截然不同的管理领域的组合系统: 企业(系统管理员长期负责安装和维护专用设备)、网络运营商(接入技术一直以基于电信的解决方案交付)和云提供商(商品硬件和云原生软件现在很容易获得)。这使我们的工作变得复杂，因为这三个领域都有各自的惯例和术语。但是，了解这三个利益相关者是如何操作的，可以让我们用更广阔的视角看待这一问题。本章后面将回到企业、云、接入技术的融合，但我们首先要解决术语方面的挑战。
开发者应该扮演平等的角色
本书以运营商为中心视角来看待云运维，但开发者也可以扮演同样的角色。这个角色反映在像 DevOps(在 2.5 节讨论)这样的实践中，也可以在底层系统设计中看到。云架构包括指定了运行时接口的管理平台，服务开发人员(提供功能的人员)通过该接口与云运维人员(管理该功能的人员)进行交互。因为可以利用共享的管理平台，所以在部署、配置、控制和监控服务时，开发人员不需要(也不应该)另起炉灶。
从更广泛的角度来看，这个管理平台是应用程序构建者和服务开发人员向最终用户交付功能的重要组成部分。今天，功能通常是作为托管服务(而不是一堆死板的软件)交付，意味着开发者不仅需要考虑实现应用或服务所需的算法和数据结构，还需要与运维(激活)代码的平台交互。一种常见误区是关注前者并将后者视为负担(特别是当其他人负责部署和运维他们的代码时)，但是对管理平台接口进行编码是交付托管服务的核心部分，理解和欣赏这个平台如何工作以及为什么这么工作对开发人员完成自己的工作至关重要。
延伸阅读:
Aether: 5G-Connected Edge Cloud.
1.1 术语
讨论运维云服务的术语混合了云原生的"现代"概念以及来自早期系统的"传统"概念(许多被云领域所吸收，但仍然保留了一些传统运维语言)。在云计算和电信公司(Telcos)的交汇处尤其如此(比如斯堪的纳维亚的 Sámi，有超过 180 个表示雪的单词)，电信公司拥有极其丰富的网络运维词汇。
我们正处于过渡阶段，即网络系统从基于专用设备构建过渡到运行在商用硬件上的基于软件的服务，这是令人困惑的一个主要原因。这常常导致同一个概念使用多个术语，更麻烦的是，一个领域从另一个领域巧妙的借用了某个术语。为了避免彼此混淆，我们首先定义几个概念并介绍相关术语。
- 运营与维护(O&M, Operations & Maintenance): 一个传统术语，用来描述网络运营的整体挑战，一般来说，运营商通过运维接口来管理系统。
- FCAPS: 故障 Fault、配置 Configuration、计费 Accounting、性能 Performance、安全 Security 的首字母缩写，历史上用于电信行业，用来列举操作系统的需求。运维接口需要提供故障检测和管理、系统配置、帐号使用等功能。
- OSS/BSS: 电信公司的另一个缩写，表示运营支持系统(Operations Support System)和业务支持系统(Business Support System)，指实现运营逻辑(OSS)和业务逻辑(BSS)的子系统，通常是整个运维层次结构中最顶层的组件。
- EMS: 这是电信公司的另一个首字母缩略词，表示组件管理系统(Element Management System)，对应于整个运维层次结构中的中间层。EMS 之于特定类型的设备，就像 OSS/BSS 之于整个网络一样。
- 编排(Orchestration): 一个与运维类似的通用术语，起源于云环境，表示为某些工作负载组合(例如，分配、配置、连接)一组物理或逻辑资源。如果只涉及单个资源或设备，可能会使用"配置(configuration)"这一术语，因此编排通常意味着跨多个组件进行"编排"。
- 狭义上来说，编排器负责调度虚拟机(或容器)并通过虚拟网络将它们在逻辑上互联。更广泛的说，编排包括本书介绍的所有与管理相关的功能。
- 如果你试图将云术语映射到通信术语，编排器通常等同于 OSS/BSS 的云化版本。这一最上面的层有时被称为服务编排器(Service Orchestrator) ，负责将虚拟网络功能(VNFs, Virtual Network Functions)集合成端到端服务链。
- 剧本/工作流(Playbook/Workflow): 实现多步骤编排过程的程序或脚本。(术语工作流在 UX 上下文中也用于描述用户使用图形界面在系统上执行的多步骤操作。)
- 准备(Provisioning): 向系统添加资源(物理或虚拟资源)，通常是响应工作负载的变化，包括初始部署。
- 零接触配置(Zero-Touch Provisioning): 通常表示不需要人工配置(除了物理连接设备)添加新的硬件。这意味着新组件会自动配置自身，这个术语也可用于虚拟资源(例如，虚拟机、服务)，以表明实例化资源不需要手动配置步骤。
- 远程设备管理(Remote Device Management): 一种定义了远程管理硬件设备的标准(如 IPMI、Redfish)，以支持零接触配置。主要想法是通过局域网发送和接收带外消息，而不是通过视频或串口控制台访问设备。此外，可以与监测和其他设备健康遥测系统集成。
- 设备管理(Inventory Management): 规划和跟踪物理资源(机架、服务器、交换机、布线)和虚拟资源(IP 范围和地址，VLAN)，是配置过程的一个子步骤。一开始这个过程通常使用简单的电子表格和文本文件，但随着复杂性的增加，专用的设备数据库有助于更多自动化操作。
- 生命周期管理(Lifecycle Management): 随着时间的推移，升级和替换功能(例如部署新服务以及现有服务的新特性等)。
- 持续集成/持续部署(CI/CD): 生命周期管理的一种方法，在这种方法中，从开发(产生新功能)到测试、集成和最终部署的路径是自动化的流水线。CI/CD 通常意味着持续进行小的增量更改，而不是执行大的破坏性升级。
- DevOps: 一种工程学科，融合了开发过程和运营需求，在功能开发速度和系统可靠性之间取得平衡。作为一种实践，DevOps 利用了 CI/CD 方法，通常与基于容器的(也称为云原生)系统相关联，典型例子是谷歌等云提供商实践的站点可靠性工程(Site Reliability Engineering, SRE) 。
- 服务内软件升级(ISSU, In-Service Software Upgrade): 要求组件在升级部署过程中继续运行，对交付给终端用户服务的干扰最小。ISSU 通常意味着能够增量滚动(和回滚)升级，但具体来说是单个组件的需求(与用于管理一组组件的平台相反)。
- 监控和遥测(Monitoring & Telemetry): 从系统组件收集数据，以帮助管理决策。包括故障诊断、性能调优、进行根因分析、执行安全审计和提供额外容量。
- 分析(Analytics): 从原始数据产生额外见解(价值)的程序(通常使用统计模型)。可以用于关闭控制回路(即基于这些见解自动重新配置系统)，也可以为随后采取某些行动的运维人员提供帮助。
另一种谈论运维的方式是用阶段来描述，这在传统网络设备中很常见:
- Day(-1): 设备首次上电时的硬件配置(如通过控制台)。这些配置对应于固件(BIOS 或类似的)设置，通常需要了解设备如何物理连接到网络(例如，正在使用的端口)。
- Day 0: 连接配置需要建立设备和可用的网络服务之间的通信(例如，设置设备的 IP 地址和默认路由)。虽然这些信息可能是手动提供的，当也是支持零接触配置(ZTP)的一个自动配置设备的机会。
- Day 1: 设备需要的服务级别配置，包括允许设备利用其他服务(如 NTP, Syslog, SMTP, NFS)的参数，以及设置设备执行任何服务所需的参数。在 Day 1 运维结束时，设备被认为是正常运行的，并且能够支持用户流量。这也是 ZTP 的一个机会，在这个意义上，预先编程的剧本(工作流)应该能够自动配置设备，而不是依赖于人工干预。
- Day 2..N: 支持日常运维的持续管理，以及监测网络以检测故障和服务退化，目的是维持服务。这可能涉及到一些闭环控制，但通常需要大量人力，包括监控仪表板和发送警报，然后根据需要重新配置系统。这通常被简单称为"Day 2 运维"。
同样，"Day x"是传统网络供应商对其销售设备操作过程的描述，这反过来又决定了网络运营商和企业系统管理员如何将这些设备上线。虽然一般框架已经扩展到虚拟网络功能(VNF)，但仍然是以设备为中心的操作视图。但是，一旦一个系统变成云原生系统，有两件事就会改变这种平衡。首先，所有硬件都是商品化的，因此 Day 0 和 Day 1 的配置将完全自动化(并且由于所有设备都是相同的硬件，因此 Day -1 被最小化)[3]。第二，Day 2 的操作过程变得更加复杂，因为基于软件的系统更加灵活，使得功能升级更加普遍。对新特性开发速度的关注是基于云的系统的内在价值之一，但不出意外的是，也给管理带来了一系列挑战。
[3] 打个比方，这就像是从照顾宠物转变为放养。
本书解决了这些管理挑战，并带来了最后两个词作为注解: 运维(Operating) 和实施(Operationalizing) 。能够运维云是最终目标，这意味着一个持续的过程，而对云进行实施意味着将一组硬件和软件组件带入一种状态，使其易于维持正在进行的运维过程。这种区别很重要，因为对云进行运维不是一次性的，而是日常实施的一个重要方面。快速演化是云最重要的特性之一，这使得持续运维成为运维边缘云的关键需求。
1.2 解耦
为了充分理解云运维的挑战，必须从底层构建块开始: 在商用硬件上运行的基于软件的微服务集合。这些构建块是对以前那种捆绑在专用硬件上的网络设备进行分解的结果。从管理的角度来看，进行这种转换时，需要确定有什么事情会变得更容易，以及什么会变得更难。这既是挑战，也是机遇。
广义来说，解耦是将大组件分解成一组更小的组成部分的过程。SDN 是解耦的一个例子，将网络的控制平面和数据平面解耦，前者作为云服务运行，后者运行在商品交换机中。微服务体系架构是解耦的另一个例子，将单体云应用程序分解为单一功能组件的网状结构。解耦被广泛认为是加快特性开发速度的关键步骤，这是机遇的一面，Weaverworks 很好的总结了这一点。
延伸阅读:
Weaveworks. What You Need to Know for Cloud Native.
这一转变的挑战在于，需要整合、协调和管理更多的活动部件。回到之前的术语，编配和生命周期管理成为了主要问题，因为(a)许多更小的部分必须组装起来，(b)这些单独的部分预计会被更频繁的更改。本书大部分内容都集中在这两个问题上。
好消息是，业界似乎已经将容器作为"组件包装"的通用格式，而 Kubernetes 则作为一级容器编排器(我们说"一级"是因为只有 Kubernetes 本身是不够的)。以此为基础反过来又使许多其他挑战更易于管理:
- 监控和其他与遥测相关的机制本身是作为一组基于容器的微服务实现的，部署在所观察的云中。
- ISSU 变得更容易处理，因为微服务体系架构鼓励无状态组件，持久化状态隔离在单个功能无关的存储服务中，比如键值存储。
- 因为硬件是商品化的，几乎都相同，因此零接触配置更容易操作。这也意味着绝大多数配置都涉及初始化软件参数，更容易实现自动化。
- 云原生意味着一组最佳实践，用于解决许多 FCAPS 需求，尤其是与可用性和性能相关的需求，两者都是通过水平扩展实现的。安全通信通常也内置在云 RPC 机制中。
另一种说法是，通过将绑定的应用和设备重新架构为运行在商用硬件上的水平可伸缩的微服务，过去的运维问题现在由分布系统中广泛应用的最佳实践解决了，这些实践反过来又被编入了最先进的云管理框架(如 Kubernetes)。这就给我们留下了(a)提供商品硬件，(b)编排容器构建块，(c)部署微服务以统一的方式收集和归档监控数据，以及(d)随着时间的推移不断集成和部署单个微服务的问题。
最后，由于云是无限可编程的，被管理的系统有可能随着时间的推移而发生实质上的变化[4]，这意味着云管理系统本身必须易于扩展，以支持新特性(以及现有特性的重构)。这部分是通过将云管理系统实现为云服务来解决的，这意味着我们将在本书中看到相当多的递归依赖关系。此外，还要利用声明性规范来说明所有被解耦的部分如何组合在一起。然后可以使用这些规范来生成管理系统的组件，而不必手动对它们进行重新编码。这是一个微妙的问题，我们将在后面的章节中讨论，但最终我们希望能够自动配置负责自动配置系统其余部分的子系统。
[4] 例如，将十年前亚马逊提供的两种服务(EC2 和 S3)与现在 AWS 控制台上超过 100 种服务(不包括合作伙伴提供的服务)进行比较。
