深入浅出边缘云 | 1. 概述

随着技术的发展以及应用对时延、带宽、安全的追求，一个明显的技术趋势是越来越多的应用组件将会被部署到企业所管理的网络边缘。本系列是开源电子书Edge Cloud Operations: A Systems Approach的中文版，详细介绍了基于开源组件构建的边缘云的架构、功能及具体实现。

序

在过去一段时间，我们将应用程序迁移到云上，如今又开始将它们拆散，接下来我会解释这是什么意思。

随着市场的增长，人们赖以建立业务的功能单元会逐渐缩小，汽车工业的发展历史就是一个典型例子。当 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.

Aether Documentation.

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 种服务(不包括合作伙伴提供的服务)进行比较。

1.3 云技术

要想对云进行操作，首先要从云的构建块开始。本节总结了可用的技术，目的是确定底层系统的基线能力。然后，本书介绍的管理子系统的集合假定了这个基线。

在确定这些构建块之前，需要承认我们正在冒险进入一个灰色区域，必须处理被认为是"被管理平台的一部分"与"管理平台的子系统的一部分"之间的关系。更复杂的是，随着技术的成熟和普及，界限会随着时间的推移而变化。

例如，如果以云承载一组容器为前提，那么管理层将负责检测并重新启动失败的容器。另一方面，如果假定容器具有弹性(即能够自动恢复)，那么管理层就不需要包含该功能(尽管可能仍然需要检测自动恢复机制何时出现故障并进行纠正)。这并不是一种独特的情况，复杂系统通常包含在多个层次上解决问题的机制。出于本书的目的，我们只需要确定一条线，将"假定的技术"与"遗留的问题以及我们如何解决它们"区分开来。以下是我们假设的技术。

1.3.1 硬件平台

假设的硬件构建块很简单，从使用商用硅芯片构建的裸金属服务器和交换机开始。例如，可能分别是 ARM 或 x86 处理器芯片和 Tomahawk 或 Tofino 交换芯片。裸金属服务器还包含引导机制(例如，服务器的 BIOS 和交换机的 ONIE)和远程设备管理接口(例如，IPMI 或 Redfish)。

延伸阅读:

DMTF. Redfish.

然后，使用如图 1 所示的硬件构建块构建物理云集群: 一个或多个服务器机架通过叶脊交换结构连接。服务器显示在交换结构的上方，以强调运行在服务器上的软件控制着交换机。

图 1. 用于构建云的示例构建块组件，包括商品服务器和交换机，通过叶脊交换结构互连。

图 1 还包括假定的底层软件组件，我们将后续章节介绍。图中所示的所有硬件和软件组件共同构成了平台(platform) 。哪些内容运行在平台中，哪些内容运行在平台之上，后续章节将逐渐画出一条清晰的界限，并解释为什么如此重要。总体来说，不同机制将负责(a)启动平台并准备承载工作负载，(b)管理需要部署在该平台上的各种工作负载。

1.3.2 软件构建块

假设有四种基本的软件技术，都运行在集群中的商品处理器上:

1. Linux 为运行容器工作负载提供了隔离。

2. Docker 容器打包软件功能。

3. Kubernetes 实例化并连接容器。

4. Helm charts 指定了相关容器的集合如何相互连接以构建应用程序。

这些都是众所周知、无处不在的，所以我们在这里只做一个总结。下面为不熟悉它们的人提供了相关信息的链接(包括三个与容器相关的构建块的优秀实践教程)。

Linux 是运行在裸金属系统上的操作系统，提供了容器运行时系统用来实现隔离的底层 API，包括用于隔离文件系统和网络访问的命名空间(namespaces)，以及用于限制内存和处理器使用的 cgroup。

Docker 是容器运行时，利用操作系统隔离 API 来实例化和运行多个容器，每个容器都是由 Docker 镜像定义的一个实例。Docker 镜像通常使用 Dockerfile 来构建，它使用了一种分层的方法，允许在基本镜像的基础上共享和构建定制镜像。特定任务的最终镜像包含了运行在容器中的软件所需的所有依赖项，从而产生了一个跨服务器可移植的容器镜像，仅依赖于内核和 Docker 运行时。假设在我们的云上还有一个或多个 Docker 容器的镜像工件存储库，其中最出名的是https://hub.docker.com。

延伸阅读:

Docker Tutorial.

Kubernetes 是容器管理系统。它提供了一个编程接口，用于容器实例的扩容缩容、分配服务器资源、设置连接实例的虚拟网络，以及开放服务端口，外部客户端可以使用这些端口访问这些实例。在幕后，Kubernetes 监控这些容器的活动，并自动重启任何失败的容器。换句话说，如果要求 Kubernetes 启动三个微服务 X 的实例，Kubernetes 将尽力保持实现 X 的容器的三个实例一直运行。

Kubernetes 还提供了一些机制，可以用来在微服务启动时进行配置，包括 ConfigMaps、Secrets 和 Operators。由于它们在云管理中所扮演的角色，我们将在后续章节更详细的讨论这些机制。

延伸阅读:

Kubernetes Tutorial.

Helm 是运行在 Kubernetes 上的配置集管理器。它根据运维人员提供的规范(称为 Helm Chart)对 Kubernetes API 发出调用。现在，从一组微服务构建的云应用程序通常会发布一个 Helm Chart，定义如何将应用程序部署到 Kubernetes 集群上。查看https://artifacthub.io/获取公开可用的 Helm Charts 集合。

延伸阅读:

Helm Tutorial.

本书介绍的云管理软件以 Docker 容器的形式提供，包含相关的 Helm Charts，用于指定如何在 Kubernetes 集群中部署。总之，在接下来的章节中，我们使用了超过 20 个这样的开源软件包。我们的目标是展示如何将所有这些开放构件组装成一个全面的云管理平台。我们对每个工具进行了足够详细的介绍，以欣赏所有部分是如何组合在一起的，从而通过连接所有的点来提供端到端覆盖，另外还为那些想要深入挖掘细节的人提供了完整的文档链接。

1.3.3 交换网络

假设云是基于 SDN 的交换网络构建的，解耦的控制平面运行在同一个云中作为交换网络的连接器。为了本书的目的，我们假设基于以下 SDN 软件栈:

• 托管一组控制应用程序的网络操作系统，包括管理叶棘交换网络的控制应用程序。我们使用 ONOS 作为开源网络操作系统范例，用来托管 SD-Fabric 控制应用程序。

• 运行在每台交换机上的交换机操作系统，提供北向 gNMI 和 gNOI 接口，网络操作系统通过该接口对每台交换机进行控制和配置。我们使用 Stratum 作为开源交换机操作系统范例。

使用基于 SDN 的交换网络构建云是超大规模云提供商采用的最佳实践。他们的解决方案仍然是私有的，所以我们使用 ONOS 和 Stratum 作为开源示例。值得注意的是，ONOS 和 Stratum 都被封装为 Docker 容器，因此可以被 Kubernetes 和 Helm 编排(在服务器和交换机上)[5]。

[5] 除了实现数据平面的交换芯片外，交换机通常还包括商用处理器(通常运行 Linux 和托管控制软件)。Stratum 运行在此处理器上，并导出 ONOS 用于配置和控制交换机的北向 API。

1.3.4 存储库

为了完整起见，我们需要提到本书中介绍的几乎每一种机制都利用了云托管存储库，如 GitHub(用于代码)、DockerHub(用于 Docker 镜像)和 ArtifactHub(用于 Helm Chart)。我们还假设有像 Gerrit 这样的互补系统，在 Git 仓库之上建立了一层代码审查机制，但是对 Gerrit 有直接的经验对理解这些材料并不重要。

延伸阅读:

GitHub Tutorial.

Gerrit Code Review.

1.3.5 其他选项

有些我们没有覆盖的技术与我们认为理所当然的构建块同样重要，在这里我们讨论其中三个。

首先，你可能期望包含像 Istio 或 Linkerd 这样的服务网格框架。虽然在 Kubernetes 上运行应用程序的任何人都可能决定使用 Istio 或 Linkerd 来帮助完成这项工作(由于本书介绍的大部分管理系统都是微服务，因此也包括我们)，但我们碰巧没有采用这种方法。这主要是工程选择: 服务网格提供了比我们需要的更多的特性，相应的，我们希望能够使用更小的特定机制来实现必要的功能。还有一个教学上的原因: 细粒度组件更符合我们确定运维和管理的基本部分的目标，而不是将这些组件捆绑在一个全面的包中。然而，在第 6 章对可观察性的讨论中，我们确实会提到服务网格。

其次，我们假设这是基于容器的云平台，而另一种选择是基于虚拟机。做出这种选择的主要原因是，容器正在迅速成为部署可伸缩和高可用功能的事实标准，而在企业中运维这些功能是我们的主要用例。容器有时部署在虚拟机上(而不是直接部署在物理机器上)，但在这种情况下，虚拟机可以被视为底层基础设施的一部分(而不是提供给用户的服务)。另外，本书主要关注如何运维平台即服务(PaaS)，而不是基础设施即服务(IaaS)，尽管后面的章节将介绍如何引入虚拟机作为可选方式为 PaaS 提供底层基础设施。

最后，被我们作为示例的 Aether 边缘云与许多其他边缘云平台类似，现在被作为一种物联网实现技术而推广。基于 kubernetes 的预制/边缘云越来越受欢迎，这是它们成为如此好的案例研究的原因之一。例如，Smart Edge Open(原名 OpenNESS)是另一个开源边缘平台，其独特之处在于包含了几种英特尔特有的加速技术(如 DPDK、SR-IOV、OVS/OVN)。然而就我们的目的而言，组成平台的确切组件集并不重要，重要的是如何将平台以及运行在平台上的所有云服务作为一个整体进行管理。以 Aether 为例允许我们具象化，但又不以牺牲通用适用性为代价。

总体规划是什么？

一个普遍问题是，如何像本书介绍的那样，在基于云的系统中通过软件包组合做出工程选择。不考虑大量的商业产品，仅 Linux 基金会和 Apache 基金会中用于帮助我们构建和运维云的开源项目的数量(根据我们的统计)就接近 100 个。这些项目在很大程度上是独立的，而且在很多情况下是相互竞争的。这导致了功能上的大量重叠，随着项目添加和取消特性，我们试图绘制的任何维恩(Venn)图都会随着时间不断变化。

也就是说，对于云管理栈应该是什么样子，并没有总体计划。即使开始使用组件 X 作为方法的核心(可能因为它解决了最直接的问题)，也将随着时间的推移最终添加几十个其他组件以完全完成系统。此外，最终结果可能看起来与其他人从组件 Y 开始构建的系统不同。这不像从列 A 中选择一个组件，从列 B 中选择第二个补充组件这么简单，根本没有一致的框架。对于我们用作范例的 Aether 托管服务也是如此。

因此，采用第一性原理就变得更加重要，该方法从确定需求集和探索设计空间开始，只在最后一步才会选择某个现有的软件组件。这种方法自然会产生端到端解决方案，它将许多较小的组件组装在一起，并倾向于避免绑定并提供多场景解决方案。虽然随着时间的推移仍然需要演进系统，但确实有助于基于整个设计空间和复杂性来处理这个主题。即使某人最终采用了一个绑定的解决方案，理解底下所有的利弊，也将有助于做出更明智的决定。

延伸阅读:

Smart Edge Open.

1.4 系统管理员的未来

自从 30 多年前部署了第一个文件服务器、客户机工作站和局域网以来，系统管理员一直负责运营企业网络。在这段历史中，强大的供应商生态系统引入了日益多样化的网络设备，增加了系统管理员工作的挑战。虚拟化技术的引入整合了服务器，但由于每个虚拟设备都处于某个管理竖井中，并没有减少多少管理开销。

对于云供应商来说，由于其所构建系统的规模，无法依靠运营竖井生存，所以引入了越来越复杂的云编排技术，Kubernetes 和 Helm 就是两个极具影响力的例子。现在企业也可以使用这些云最佳实践，通常它们被捆绑为托管服务，云提供商在企业服务的运营中扮演着越来越重要的角色。对许多企业来说，将 IT 责任的一部分外包给云提供商是一个有吸引力的价值主张，但随之而来的风险是增加了对单一供应商的依赖。移动网络运营商(MNO)也会参与其中，其在企业内部推出专用 5G 连接的可能性越来越大，并且会部署为另一种云服务，从而让这个等式变得更加复杂。

本书采用的方法是探索一个两全其美的机会。我们将引导你浏览运维云原生系统所需的子系统集合和相关管理流程，然后为该云及其承载的服务(包括 5G 连接)提供持续支持来实现这一点。我们希望，了解云管理服务背后的内涵将有助于企业更好的与云提供商(可能还有跨国公司)分担管理其 IT 基础设施的责任。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind