下载掌阅APP，畅读海量书库
立即打开
云提供了一组用于启动和运维可扩展服务的工具，但首先如何运维云本身呢？这二者之间并不矛盾，毕竟云是通过一组服务实现的，但以这种方式提出问题可以避免给出类似“云会为你处理这些问题”这样的答案。本书将从裸金属硬件开始介绍如何运维云，一直到为用户提供一个或多个托管服务。
很少有人有理由建设超大规模的数据中心，但是在企业中部署私有化的边缘云——并可选择地将边缘云连接到数据中心以形成混合云——正变得越来越普遍。我们使用“边缘云”（edge cloud）与“中心云”（core cloud）相区别，中心云是那些传统超大规模云厂商的领域。边缘云主要出现在企业或工厂的“物联网”环境中。边缘正好是云服务与现实世界连接的地方，例如通过传感器和执行器，以及那些延迟敏感型服务被部署的地方，从而与服务消费者靠近
。
超大规模云厂商确实愿意为我们管理边缘云，将它作为其中央数据中心的扩展。市场上有很多类似产品，比如谷歌的Anthos、微软的Azure Arc和亚马逊的ECS-Anywhere。但是运维一个云的门槛并没有高到只有超大规模的云厂商才有足够资金去做。一般企业也可以基于现成的开源软件技术栈来构建云，并提供运维它所需的所有相关生命周期管理和运行时控制。
本书介绍了这样一个云管理平台的样子。我们的方法是聚焦在必须解决的基本问题上，包括所有云都常见的设计问题，然后在运维特定的企业云时，需要将概念讨论与特定工程选择相结合。我们使用Aether [1] 作为例子，它是一个ONF项目，用于将支持5G的边缘云作为托管服务。Aether具有以下特性，使其成为有趣的研究用例：
● Aether开始时被部署在边缘站点（例如企业）的祼金属硬件（服务器和交换机）上。这种本地云的规模可以从部分机架到多机架集群不等，可以根据数据中心的最佳实践进行组装。
● Aether支持运行在本地集群上的“边缘服务”和运行在公有云数据中心上的“集中式服务”，从这个意义上来说，它就是混合云
。
● Aether通过5G连接即服务增强了边缘云，并提供了可运维的服务（除了底层云之外）。最终结果是Aether为我们提供了一个托管的平台即服务（PaaS）。
● Aether完全由开源组件构建而成。我们唯一需要增加的东西是使其可被运维所需的“胶水代码”和“规范指令”。这意味着任何人都可以通过遵循文档指示完全复制这种运维方法。
Aether成为一个有趣的例子的另一个重要原因是，它是部署在三个传统上截然不同的管理领域交汇处的系统：企业（系统管理员长期负责安装和维护专用设备）、网络运营商（其中接入技术历来是作为基于电信的解决方案提供的）和云服务提供商（可以使用商品化硬件和云原生软件）。这种情况使得我们的工作变得复杂，因为这三个领域各自都有自己的约定和术语。但是了解这三个利益相关者是如何处理运维的，可以让我们有更广阔的视野来更好地认知边缘云。我们将在本章后面介绍企业、云、接入技术的融合，这里首先需要解决术语方面的挑战。
开发人员可以发挥同等作用
本书采用以运维为中心的视角来看待云运维，但开发者也可以发挥同样的作用。这个角色反映在像DevOps（我们将在2.5节讨论）这样的实践中，也可以在底层系统设计中看到。云架构包含了一个指定了运行时接口的管理平台，服务开发人员（提供功能的开发人员）通过该接口与云运维人员（管理该功能的人员）进行交互。因为开发人员可以利用一个共享的管理平台，所以在部署、配置、控制和监控所实现的服务时，就不需要（也不应该）重新“发明轮子”。
从更广泛的角度来看，这个管理平台是应用程序构建者和服务开发者向最终用户交付功能的重要组成部分。今天，开发者开发的功能通常以托管服务的方式（而不是一堆死板的软件）交付，这意味着开发者不仅需要考虑实现应用程序或服务所需的算法和数据结构，还需要与运维（激活）其代码的平台进行交互。一种常见的观点是只关注前者并将后者视为负担（特别是当其他人负责部署和运维他们的代码时），但是针对管理平台提供的接口进行编程是交付托管服务的核心部分，理解和欣赏这个平台如何运作以及为什么这么运作对开发人员完成自己的工作至关重要。
在讨论运维云服务时，我们用到的术语混合了云原生中的“现代”概念以及来自早期系统的“传统”概念（其中许多已经被云计算领域所吸收，但仍然保留了一些传统的运维语言）。在云计算和电信行业的交汇处尤其如此，电信行业拥有极其丰富的网络运维词汇。
在使用云计算相关术语的时候，有时会让人感到困惑，而背后的原因是我们正处于从基于专用设备构建网络系统过渡到在廉价商用硬件上运行基于软件定义服务的过程中。这常常导致多个术语被用于表述同一个概念，而更麻烦的是，一个领域巧妙地重新使用了另一个领域的某个术语，但是彼此的含义不同。为了避免彼此混淆，我们首先定义几个概念并介绍相关术语。
● 运营与维护 （Operations & Maintenance，O&M，简称“运维”）：一个传统术语，用于描述网络运维的整体挑战（工作），一般来说，运营商通过运维接口来管理整个系统。
〇 FCAPS ：这是Fault（故障）、Configuration（配置）、Accounting（计费）、Performance（性能）和Security（安全）这五个词的首字母缩写，历史上用于电信行业中列举对一个操作系统的需求。运维接口必须提供故障检测和故障管理、系统配置、使用情况统计等功能。
〇 OSS/BSS ：电信行业的另一个缩略语，全称为运维支持系统（Operations Support System）和业务支持系统（Business Support System），指实现运维逻辑（OSS）和业务逻辑（BSS）的子系统，通常是整个运维架构中处于最顶层的组件。
〇 EMS ：电信行业的另一个缩略语，全称为组件管理系统（Element Management System），对应于整个运维架构中的中间层。EMS之于特定类型的设备，就像OSS/BSS之于整个网络一样。
● 编排 （Orchestration）：一个与运维类似的通用术语，起源于云计算领域，表示为某些工作负载组装（例如分配、配置、连接）一组物理或逻辑资源。如果只涉及单个资源或设备，我们会使用“配置”这一术语，而编排通常意味着跨多个组件进行“编排”。
从狭义上来说，编排器负责启动虚拟机（或容器），并通过虚拟网络将它们在逻辑上连接。从广义上来说，编排包含本书中描述的与管理相关的功能的方方面面。
如果你尝试将云计算术语映射到电信术语，则编排器通常等同于OSS/BSS的云化版本。这个最顶层的组件有时被称为 服务编排器 （Service Orchestrator），负责将一组虚拟网络功能（Virtual Network Function，VNF）组装成一个端到端的服务链。
〇 剧本/工作流 （Playbook/Workflow）：实现多步骤编排过程的程序或脚本。在UX领域中，术语“工作流”也用于描述用户使用GUI在系统上执行的多步骤操作。
● 配置 （Provisioning）：向系统中增加资源（物理或虚拟资源），通常是响应工作负载的变化，也包括初始的部署。
〇 零接触配置 （Zero-Touch Provisioning）：通常表示添加新的硬件到系统中，不需要人工配置（除了物理连接设备外）。这意味着新组件会自动完成自身相关的配置。这个术语也可应用于虚拟资源（例如虚拟机、服务），以表明不需要手动配置就可以实例化资源。
〇 远程设备管理 （Remote Device Management）：一种定义了远程管理硬件设备的标准（如IPMI、Redfish），用于支持零接触配置。主要的想法是通过局域网发送和接收带外消息，而不是通过视频或串口控制台访问设备。此外，远程设备管理系统可以与监测和其他设备健康遥测系统集成。
〇 库存管理 （Inventory Management）：规划和跟踪物理设备（机架、服务器、交换机、电缆）和虚拟资源（IP范围和地址、VLAN列表）是配置过程的一个子步骤。我们通常可以从使用简单的电子表格和文本文件开始，但随着复杂性的增加，库存专用数据库有助于提高自动化程度。
● 生命周期管理 （Lifecycle Management）：随着时间推移，不时地执行升级和替换功能（例如部署新服务以及为现有服务增加新特性等）。
〇 持续集成/持续部署 （Continuous Integration/Continuous Deployment，CI/CD）：一种生命周期管理方法，在这种方法中，从开发（开发新功能）到测试、集成和最终部署的路径是一个自动化的流水线。CI/CD通常意味着持续进行小的增量修改，而不是进行大的破坏性升级。
〇 DevOps ：一种软件工程原则与实践，融合了开发过程和运维需求，并试图打破两者壁垒，在特性开发速度和系统可靠性之间实现平衡。作为一种实践，DevOps使用了CI/CD方法，并通常与基于容器（也称为云原生）的系统相关联，典型例子是谷歌等云厂商实践的站点可靠性工程（Site Reliability Engineering，SRE）。
〇 服务不间断软件升级 （In-Service Software Upgrade，ISSU）：要求组件在升级过程中继续运行（服务不间断），从而将交付给最终用户的服务的中断降至最低。ISSU通常意味着拥有能够增量滚出（和回滚）升级的能力，但具体来说是对单个组件的需求（与用于管理一组组件的平台相反）。
● 监控和遥测 （Monitoring & Telemetry）：从系统组件收集数据用以帮助做管理决策。这包括故障诊断、性能调优、进行根因分析、执行安全审计和配置额外容量。
〇 分析 （Analytics）：从原始数据产生额外洞察（价值）的程序，通常会使用统计模型。它可以用于关闭控制回路（即基于这些洞察自动重新配置系统），也可以为随后需要采取某些行动的运维人员提供帮助。
另一种谈论运维的方式是用阶段来描述，这在传统网络设备运维中很常见：
● 第-1天 ：设备首次上电后执行的硬件配置（如通过控制台）。这些配置对应于固件（BIOS或类似的）设置，并且通常需要了解设备如何以物理方式连接到网络（例如需要使用的端口）。
● 第0天 ：在设备和可用网络服务之间建立通信连接所需的配置（例如设置设备的IP地址和默认路由）。虽然这些信息可能是手动提供的，但我们可以使用自动配置设备来实现零接触配置。
● 第1天 ：我们需要对设备做服务级别相关的配置，包括允许设备使用其他服务（如NTP、Syslog、SMTP、NFS）的参数，以及设置设备能对外提供服务所需的参数。在第-1天运维结束后，设备就应当是正常运行的，并且能够处理用户流量。这也是零接触配置的一种场景，因为预编程的剧本（工作流）应该能够自动配置设备，而不需要依赖人工干预。
● 第2天到第N天 ：支持对日常运维做持续管理，包括监控网络以检测故障和服务降级，以实现维持服务等级的目标。这可能涉及一些闭环控制，但通常仍需要大量人工操作，包括监控仪表盘和发送告警，然后根据运行状态重新配置系统。这通常被简称为“Day 2运维”。
同样，“Day x”是传统网络供应商对其销售设备运维过程的描述，这反过来又决定了网络运营商和企业系统管理员如何运行这些设备。虽然通用框架已经扩展到虚拟网络功能（VNF），但其操作视角仍然是以设备为中心。但是一旦一个系统变成云原生系统，两件事就会改变大家关注的重心。首先，所有硬件都是商品化的，因此Day 0和Day 1的配置将完全自动化，并且由于所有设备都是相同的，因此Day-1的配置工作将被最小化
。其次，Day 2的操作过程将变得更加复杂，因为基于软件的系统更加敏捷，这使得功能升级更为普遍。对特性开发速度的关注与追求是基于云计算或者云原生系统的内在价值之一（或者说是一种保证），但这也给我们的管理带来了一系列挑战。
本书旨在解决这些管理挑战，并对我们常用的两个词运维（Operating）和可运维化（Operationalizing）做了最终解释。能够运维一个云是我们的终极目标，这是一个持续改进的过程，而使云可运维化意味着我们将一组软硬件配置到一种状态，使得我们能够轻松进行日常的运维操作。这种区别是相关的，因为使云可运维化不是一次性的操作，而是日常运维的一个基本方面。快速演进是云最重要的特性之一，这使得持续可运维化成为运维边缘云的关键需求。
为了充分理解运维一个云所面临的挑战，我们必须从理解底层构建块开始：运行在商用硬件上的基于软件的微服务集合。这种构建块的出现，源自对以前那种专用软硬件捆绑方式进行解耦。从管理的角度来看，当我们进行这种转换时，需要确定什么事情会变得更加容易，以及什么事情会变得更加困难。这既是解耦带来的挑战，也是机遇。
从广义上讲，解耦是将捆绑在一起的大组件分解成一组更小的组件的过程。SDN就是一个很好的例子，它将网络的控制平面和数据平面解耦，前者以云服务方式运行，后者则运行在商品交换机中。微服务架构是解耦的另一个例子，它将单体应用分解为一组单一功能组件的网格。解耦是加快特性开发速度的关键举措，Weaveworks
很好地总结了这一点。
而这种转变的挑战在于，我们需要整合、协调和管理更多变化的部件。回到之前的术语，编排和生命周期管理成了主要挑战，因为：1）许多更小的部分必须通过编排器组装起来；2）这些独立的部分预计会被更频繁地变更。本书大部分内容都集中在这两个问题上。
好消息是，业界事实上已经将容器作为“组件打包”的通用格式，并将Kubernetes作为一级 容器编排器 （我们之所以说“一级”，是因为只有Kubernetes本身是不够的）。以此为基础，可以使得许多其他挑战更易于被我们管理：
● 监控和其他与遥测相关的系统将被实现为一组基于容器的微服务，并部署到它们所观测的云中。
● ISSU变得更容易处理，因为微服务架构鼓励使用无状态的组件，同时将持久化状态隔离在与业务功能无关的存储服务中，比如键值对存储。
● 云所用的硬件都是同构的商用硬件，因此零接触配置更容易落地。这也意味着绝大多数配置都只涉及初始化软件参数，因此更容易实现自动化。
● 云原生意味着一组用于解决许多FCAPS需求的最佳实践，尤其是与可用性和性能相关的需求，这两者都是通过水平扩展实现的。安全通信通常也内置在云RPC机制中。
另一种说法是，通过将捆绑的软硬件重构为运行在商用硬件上的水平可伸缩的微服务，过去一组一次性的运维问题，现在由分布系统中被广泛应用的最佳实践解决了。而这些最佳实践反过来又被固化到了先进的云管理框架（如Kubernetes）中。这就给我们留下了以下问题：1）提供商品化硬件；2）编排容器化构建块；3）部署微服务架构的监控系统以统一的方式收集和归档监控数据；4）随着时间的推移不断集成和部署独立微服务。
最后，由于云是无限可编程的，因此被管理的系统有可能随着时间的推移而发生巨大变化
，这意味着云管理系统本身必须是易于扩展的，以支持新特性（以及重构现有特性）。这可以通过将云管理系统以云服务方式实现来解决，这意味着读者将在本书中看到很多递归依赖关系。此外，我们还要利用好编排的声明性规范，这些规范用于说明被分解的组件如何组合在一起运行。然后我们可以使用这些规范来编排管理系统的组件，而不是手动重新编码（标准也不统一）。这是一个有趣的问题，我们将在后面的章节中讨论，但最终我们希望能够自动配置（负责自动配置系统其余部分的）子系统。
要想对云进行操作，首先要从了解云的构建块开始。本节总结了可用的技术，目的是确定底层系统的基线功能。接着，贯穿本书介绍的管理相关的子系统的集合诠释了这个基线。
在确定这些构建块之前，我们正在冒险进入一个灰色区域，在这个区域中“被管理平台的一部分”与“管理平台子系统的一部分”两者之间的关系错综复杂，相互交织。更为复杂的是，随着技术的成熟和普及，这两者的界限会随着时间的推移而变化。
例如，如果以云托管一组容器为前提，那么控制面软件将负责检测和重新启动失败的容器。另外，如果假设容器具有弹性（即能够自动恢复），那么控制面就不需要包含该功能（尽管可能仍然需要检测自动恢复机制何时出现故障并进行纠正）。这并不是一种特有的情况，复杂系统往往包含在多个层面上解决问题的机制。就本书而言，我们只需要确定一条分界线，将“假定的技术”与“仍然存在的问题以及我们如何解决它们”区分开来。以下几个小节标识了我们假设的技术。
硬件构建块相对比较简单。我们从使用商用硅基芯片构建的裸金属服务器和交换机开始。例如我们可能分别采用ARM或x86处理器芯片以及Tomahawk或Tofino交换芯片。裸金属服务器还包含引导启动机制（例如服务器的BIOS和交换机的ONIE）和远程设备管理接口（例如IPMI或Redfish
）。
我们可以使用图1-1所示的硬件构建块来搭建物理云集群：一个或多个服务器机架通过叶脊（leaf-spine）交换网络连接。服务器在交换机的上方显示，用以强调运行在服务器上的软件控制着交换机。
图1-1还包括假定的底层软件组件，我们将在后续章节展开介绍。图中所示的所有硬件和软件组件共同构成了 平台 。我们在平台上的哪个位置划出界线，用于区分在 平台中 运行组件和在 平台上 运行组件，以及它的重要性，将在后续章节中逐步阐述，从而使之清晰。但总的来说，不同机制（运行在平台中以及运行在平台上）将各自负责：1）启动平台并准备运行工作负载；2）管理需要部署在该平台上的各种工作负载。
图1-1 用于构建云的构建块组件示例，包括商用服务器和交换机，基于叶脊交换网络相互连接
我们假设有以下四种基本的软件技术，它们都运行在集群中的普通商用处理器上：
1）Linux为运行容器工作负载提供隔离。
2）Docker容器用于打包软件（功能）。
3）Kubernetes创建容器并使之相互连接，形成一个容器集群。
4）Helm Charts描述相关容器的集合如何相互连接来构建应用。
这些软件技术都是众所周知、无处不在的，所以我们在这里只对其做一个总结。下面为不熟悉它们的读者提供了相关信息链接（包括三个与容器相关的构建块的优秀实践教程）。
Linux是运行在裸机系统上的操作系统。它提供了容器运行时系统用来实现隔离的底层API，包括用于隔离文件系统和网络访问的 命名空间 （namespace），以及用于限制内存和CPU使用的cgroup。
Docker
是一种容器运行时，它利用操作系统隔离API来实例化和运行多个容器实例，每个容器都是由Docker镜像定义的实例。Docker镜像通常使用Dockerfile来构建，它使用一种分层的方法，允许在基础镜像的基础上共享和构建自定义镜像。完成特定任务的最终镜像包含了运行在容器中的软件所需的所有依赖项，从而产生了可跨服务器移植的容器镜像，仅依赖于内核和Docker运行时。我们的云上需要有一个或多个Docker容器的镜像仓库，其中最有名的是https://hub.docker.com/。
Kubernetes
是一种容器管理系统。它提供了一个编程接口，用于容器实例的横向扩容缩容、分配服务器资源、设置虚拟网络以互连这些实例，以及开放可供外部客户端访问的服务端口。在后台，Kubernetes监控这些容器的活动，并自动重启运行失败的容器。换句话说，如果要求Kubernetes启动三个微服务X的实例，Kubernetes将尽力保持实现X的容器的三个实例始终正常运行。
Kubernetes还提供了可以用于在启动时配置微服务的机制，包括ConfigMaps、Secrets和Operators。由于这些机制在云管理中起着重要作用，我们将在后续章节更详细地讨论它们。
Helm
是一个运行在Kubernetes之上的配置集管理器。它根据运维人员提供的规范（称为Helm Chart）调用Kubernetes的API。现在由一组微服务构建的云应用通常会发布一个Helm Chart，用于定义如何将该应用部署到Kubernetes集群上。可以访问https://artifacthub.io/来查看公开可用的Helm Chart。
本书介绍的云管理软件包含一组Docker镜像以及定义如何在Kubernetes集群中部署它们的Helm Chart。总之，在接下来的章节中，我们将使用20多个这样的开源软件包。我们的目标是展示如何将这些开源构建块组装成一个全面的云管理平台。我们将详细介绍每个工具，以了解所有部分如何组合在一起，从而通过连接所有的点来提供端到端覆盖，另外，还将为那些想要深入挖掘细节的读者提供完整的文档链接。
我们假设云是基于SDN的交换网络构建的，SDN控制平面以解耦的方式运行在同一个云中作为交换网络的连接器。出于本书目的，我们假设了以下SDN软件堆栈：
● 网络操作系统托管一组控制应用，包括管理叶脊交换网络的控制应用。我们使用ONOS作为开源示例网络操作系统，反过来，ONOS用来托管SD-Fabric控制应用程序。
● 运行在每台交换机上的交换机操作系统提供了北向gNMI和gNOI接口，网络操作系统则通过该接口对交换机进行配置和控制。我们使用Stratum作为开源示例交换机操作系统。
使用基于SDN的交换网络构建云是超大规模云厂商采用的最佳实践，由于这些解决方案仍然是专有的，因此我们使用ONOS和Stratum作为开源示例。值得注意的是，ONOS和Stratum都被封装为Docker容器，因此可以在服务器和交换机上被Kubernetes和Helm编排
。
为了完整起见，我们需要提一下，本书中介绍的几乎所有机制都利用了云托管存储库，如GitHub
（用于代码）、DockerHub（用于Docker镜像）和ArtifactHub（用于Helm Chart）。我们还假设有像Gerrit
这样的互补系统，它在Git仓库之上建立了一层代码审查机制，但是是否有直接使用Gerrit的经验对于理解这些材料并不重要。
有些我们没有讨论到的技术，它们与理所当然认为会被用到的构建块是同样重要的，我们会在本小节讨论其中三个。
首先，我们可能期望边缘云包含像Istio或Linkerd这样的服务网格框架。虽然在Kubernetes上运行应用的人都可能期望使用Istio或Linkerd来帮助完成服务治理（包括流量管理、可观测性、安全等）工作（由于本书介绍的大部分管理系统都是微服务，因此同样也适用），但我们最终没有采用这种技术。这主要是从工程的角度做出的选择：服务网格提供的特性超出了我们的系统的需要，因此我们希望能够使用较小的机制及代价来实现这些必要的功能。还有一个教学上的原因：细粒度组件更符合我们识别运维和管理的基本部分的目标，而不是将这些组件捆绑在一个复杂的软件包中。我们在第6章讨论可观察性的话题时，会提到服务网格。
什么是总体规划？
在本书所描述的基于云的系统中，有一个普遍的问题是我们如何从工程化的角度对软件包组合做出合理的选择，不考虑大量的商业化软件产品，仅Linux基金会和Apache基金会中可用于帮助我们构建和运维云的开源项目的数量（根据我们的统计）就接近100个。这些开源项目在很大程度上是独立的，而且在很多情况下是相互竞争的。这导致了它们在功能上的明显重叠，我们试图绘制的任何维恩（Venn）图都会随着时间不断变化。
也就是说，我们并没有关于云管理软件堆栈应该是什么样子的总体规划。即使开始使用组件X作为系统的核心组件（可能因为它解决了最直接的问题），但随着时间的推移，我们最终会添加许多其他组件以完整地完成系统构建。此外，最终完成的系统看起来可能与其他人从组件Y开始构建的系统不同。我们缺少一个统一的框架可以让我们从列A中选择一个组件，从列B中选择第二个互补组件，以此类推，完成系统构建。我们用作示例的Aether托管服务也面临同样的挑战。
因此采用第一性原理就显得格外重要，该方法首先从确定需求集合并探索设计空间开始。我们只会在最后一步才会选择一个现有的软件组件。这种选择方法会比较自然地得到一种端到端的解决方案，它将许多较小的组件组装在一起，并倾向于避免变成捆绑的/多场景的解决方案。虽然随着时间的推移系统仍然需要不断演进，但它确实有助于通过观察设计空间的全部范围及其复杂性的可见性来处理这个主题。即使某人最终采用了一个捆绑的解决方案，理解背后做出的所有的权衡也将有助于做出更明智的决定。
其次，我们假设这是一种基于容器的云平台，而另一种可能的选择是基于虚拟机。我们做出这种选择的主要原因是容器正在迅速成为部署可伸缩和高可用功能的事实标准，而在企业中运维这些功能是我们的主要场景。容器有时被部署在虚拟机上（而不是直接部署在物理机器上），但在这种情况下，虚拟机可以被视为底层基础设施的一部分（而不是提供给用户的服务）。另外，本书主要关注如何实施平台即服务（Platform as a Service，PaaS），而不是基础设施即服务（Infrastructure as a Service，IaaS），尽管后面的章节将介绍如何将虚拟机作为该PaaS底层基础设施的一种可选项。
最后，被我们作为示例的Aether边缘云与许多其他边缘云平台很相似，它现在作为一种物联网使能技术而被推广。基于Kubernetes的本地/边缘云变得越来越流行，这使得它们可以成为很好的研究案例。例如，Smart Edge Open
（原名OpenNESS）是另一个开源边缘平台，其独特之处在于它包含了多种英特尔特有的加速技术（例如DPDK、SR-IOV、OVS/OVN）。但就我们研究边缘云的目的而言，构成平台的确切组件集并不重要，更重要的是如何将云平台以及运行在平台上的所有云服务作为一个整体进行管理。以Aether为例，它允许我们具象化，但又不以牺牲普遍适用性为代价，帮助我们研究边缘云平台。
自从30多年前第一批文件服务器、客户端工作站和局域网在企业中部署以来，系统管理员一直负责运维企业网络基础设施。纵观这段历史，强大的供应商生态系统引入了日益多样化的网络设备，这大大增加了系统管理员日常工作的挑战。虚拟化技术的引入屏蔽了物理服务器，但由于单个虚拟设备都处于某个管理孤岛中，因此没有降低多少管理开销。
对于云厂商来说，由于其所构建的系统规模庞大，无法在运维孤岛中生存，因此这些云厂商引入了越来越复杂的云编排技术，其中Kubernetes和Helm就是两个影响很大的例子。这些云最佳实践现在也可供企业使用，但它们通常作为托管服务与基础设施捆绑在一起，云厂商在企业服务的运维方面发挥着越来越重要的作用。对许多企业来说，将部分IT职责外包给云厂商是一个有吸引力的方案，但也增加了对单一云厂商依赖的风险。由于移动网络运营商（Mobile Network Operator，MNO）也参与企业内云的建设与运维，并且其推出的私有5G连接作为另一种云服务部署的可能性越来越大，从而让整个云的建设与运维变得更加复杂。
本书采用的方法是探索两全其美的可能性。我们将引导读者完成运维私有云系统所需的子系统的集合以及相关管理流程来实现这一点，然后为该云及其承载的托管服务（包括5G连接）提供持续支持。我们希望通过了解云托管服务背后的工作，能够让企业更好地与云厂商以及潜在的移动网络运营商分担管理其IT基础设施的责任。
[1]
延伸阅读：Aether:5G-Connected Edge Cloud（https://opennetworking.org/aether/）。
Aether文档（https://docs.aetherproject.org/master/index.html）。