1.3 云技术
要想对云进行操作，首先要从云的构建块开始。本节总结了可用的技术，目的是确定底层系统的基线能力。然后，本书介绍的管理子系统的集合假定了这个基线。
在确定这些构建块之前，需要承认我们正在冒险进入一个灰色区域，必须处理被认为是"被管理平台的一部分"与"管理平台的子系统的一部分"之间的关系。更复杂的是，随着技术的成熟和普及，界限会随着时间的推移而变化。
例如，如果以云承载一组容器为前提，那么管理层将负责检测并重新启动失败的容器。另一方面，如果假定容器具有弹性(即能够自动恢复)，那么管理层就不需要包含该功能(尽管可能仍然需要检测自动恢复机制何时出现故障并进行纠正)。这并不是一种独特的情况，复杂系统通常包含在多个层次上解决问题的机制。出于本书的目的，我们只需要确定一条线，将"假定的技术"与"遗留的问题以及我们如何解决它们"区分开来。以下是我们假设的技术。
1.3.1 硬件平台
假设的硬件构建块很简单，从使用商用硅芯片构建的裸金属服务器和交换机开始。例如，可能分别是 ARM 或 x86 处理器芯片和 Tomahawk 或 Tofino 交换芯片。裸金属服务器还包含引导机制(例如，服务器的 BIOS 和交换机的 ONIE)和远程设备管理接口(例如，IPMI 或 Redfish)。
延伸阅读:
DMTF. Redfish.
然后，使用如图 1 所示的硬件构建块构建物理云集群: 一个或多个服务器机架通过叶脊交换结构连接。服务器显示在交换结构的上方，以强调运行在服务器上的软件控制着交换机。
图 1. 用于构建云的示例构建块组件，包括商品服务器和交换机，通过叶脊交换结构互连。
图 1 还包括假定的底层软件组件，我们将后续章节介绍。图中所示的所有硬件和软件组件共同构成了平台(platform) 。哪些内容运行在平台中，哪些内容运行在平台之上，后续章节将逐渐画出一条清晰的界限，并解释为什么如此重要。总体来说，不同机制将负责(a)启动平台并准备承载工作负载，(b)管理需要部署在该平台上的各种工作负载。
1.3.2 软件构建块
假设有四种基本的软件技术，都运行在集群中的商品处理器上:
- Linux 为运行容器工作负载提供了隔离。
- Docker 容器打包软件功能。
- Kubernetes 实例化并连接容器。
- Helm charts 指定了相关容器的集合如何相互连接以构建应用程序。
这些都是众所周知、无处不在的，所以我们在这里只做一个总结。下面为不熟悉它们的人提供了相关信息的链接(包括三个与容器相关的构建块的优秀实践教程)。
Linux 是运行在裸金属系统上的操作系统，提供了容器运行时系统用来实现隔离的底层 API，包括用于隔离文件系统和网络访问的命名空间(namespaces)，以及用于限制内存和处理器使用的 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 Charts 集合。
延伸阅读:
本书介绍的云管理软件以 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 有直接的经验对理解这些材料并不重要。
延伸阅读:
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 托管服务也是如此。
因此，采用第一性原理就变得更加重要，该方法从确定需求集和探索设计空间开始，只在最后一步才会选择某个现有的软件组件。这种方法自然会产生端到端解决方案，它将许多较小的组件组装在一起，并倾向于避免绑定并提供多场景解决方案。虽然随着时间的推移仍然需要演进系统，但确实有助于基于整个设计空间和复杂性来处理这个主题。即使某人最终采用了一个绑定的解决方案，理解底下所有的利弊，也将有助于做出更明智的决定。
延伸阅读:
1.4 系统管理员的未来
自从 30 多年前部署了第一个文件服务器、客户机工作站和局域网以来，系统管理员一直负责运营企业网络。在这段历史中，强大的供应商生态系统引入了日益多样化的网络设备，增加了系统管理员工作的挑战。虚拟化技术的引入整合了服务器，但由于每个虚拟设备都处于某个管理竖井中，并没有减少多少管理开销。
对于云供应商来说，由于其所构建系统的规模，无法依靠运营竖井生存，所以引入了越来越复杂的云编排技术，Kubernetes 和 Helm 就是两个极具影响力的例子。现在企业也可以使用这些云最佳实践，通常它们被捆绑为托管服务，云提供商在企业服务的运营中扮演着越来越重要的角色。对许多企业来说，将 IT 责任的一部分外包给云提供商是一个有吸引力的价值主张，但随之而来的风险是增加了对单一供应商的依赖。移动网络运营商(MNO)也会参与其中，其在企业内部推出专用 5G 连接的可能性越来越大，并且会部署为另一种云服务，从而让这个等式变得更加复杂。
本书采用的方法是探索一个两全其美的机会。我们将引导你浏览运维云原生系统所需的子系统集合和相关管理流程，然后为该云及其承载的服务(包括 5G 连接)提供持续支持来实现这一点。我们希望，了解云管理服务背后的内涵将有助于企业更好的与云提供商(可能还有跨国公司)分担管理其 IT 基础设施的责任。
