1. 编排和管理（Orchestration & Management）

既然我们已经介绍了供应层和运行时层，现在我们可以深入研究编排和管理了。在这里，您将找到处理运行和连接云原生应用程序的工具。本节涵盖了从 Kubernetes 本身(云原生开发的关键推动者之一)到负责应用间和外部通信的基础设施层的所有内容。云原生应用天生可伸缩，依赖于自动化和弹性，由这些工具实现。

1.1. 调度和编排（Scheduling & Orchestration）

1.1.1. 是什么？

编排和调度指的是通过集群运行和管理容器。集群是通过网络连接的一组机器(物理的或虚拟的)(参见云原生网络)。

容器协调器(和调度器)有点类似于您的笔记本电脑上的操作系统。该操作系统管理你所有的应用程序，如 Microsoft 365、Slack和Zoom；运行它们，并安排每个应用程序何时使用笔记本电脑的硬件资源，如CPU、内存和存储。

虽然在一台机器上运行一切都很好，但今天的大多数应用程序都比一台计算机所能处理的要大得多。想想 Gmail 或 Netflix。这些庞大的应用程序分布在多台机器上，形成分布式应用程序。大多数现代应用程序都是这样构建的，需要能够管理在这些不同机器上运行的所有组件的软件。简而言之，您需要一个“集群OS”。这就是编制工具的用武之地。

你可能会注意到容器一次又一次地出现。它们是在许多不同环境中运行应用程序的能力是关键。容器编排器(在大多数情况下是 Kubernetes )提供了管理这些容器的能力。容器和 Kubernetes 都是云原生架构的核心，这就是为什么我们听到了这么多关于它们的内容。

1.1.2. 解决什么问题？

正如在“云原生网络”一节中提到的，在云原生架构中，应用程序被分解为小的组件或服务，每个组件或服务被放置在一个容器中。你可能听说过它们被称为微服务。而不是只有一个大的应用程序(通常被称为“巨石”)，你现在有几十甚至数百个(微)服务。如果出现问题，每一个服务都需要资源、监控和修复。虽然为单个服务手动完成所有这些事情可能是可行的，但在处理多个服务时，您将需要自动化的流程，每个服务都带有的容器。

1.1.3. 有什么作用？

容器编排将容器管理自动化。但这在实践中意味着什么呢?让我们用 Kubernetes 来回答这个问题，因为它实际上是容器编排器。

Kubernetes 做了一件叫做期望状态协调的事情：它将集群内容器的当前状态与期望状态相匹配。期望的状态由工程师指定(例如，服务A的十个实例运行在三个节点上，即访问数据库B的机器，等等)，并不断地与实际状态进行比较。如果期望的和实际的状态不匹配，Kubernetes会通过创建或销毁对象来调和它们。例如，如果一个容器崩溃了，Kubernetes将启动一个新的容器。

简而言之，Kubernetes 允许您将集群视为一台计算机。它只关注环境应该是什么样子，并为您处理实现细节。

1.1.4. 技术101

Kubernetes 与其他容器编排器(如Docker Swarm和Mesos)一起存在于编排和调度部分，这些编排器不太被广泛采用。它使用户能够以声明的方式将许多不同的计算机作为单个资源池来管理。Kubernetes 中的声明性配置管理是通过控制循环来处理的，在这种模式中，运行在 Kubernetes 中的进程监视 Kubernetes 存储中的特定对象类型，并确保集群中的实际状态与所需状态相匹配。

例如，用户创建了一个 Kubernetes deployment，该 deployment 声明一个 web 应用程序必须有3个副本。deployment 控制器将确保创建了这3个 web 应用程序容器，然后继续监视集群，以查看容器的数量是否正确。如果某个特定容器因任何原因被移除，将导致 deployment 控制器创建一个新实例。或者，如果将 deployment 修改为缩小到1个web应用实例，则会指示 Kubernetes 删除2个正在运行的 web 应用。

这个核心控制器模式还可以被用户或软件开发人员用来扩展Kubernetes。操作符模式允许人们为自定义资源编写自定义控制器，并将任意逻辑和自动化构建到 kubernetes 上。

虽然 Kubernetes 并不是 CNCF 托管的唯一编配器(Crossplane 和 Volcano 都是沙盒项目)，但它是最常用和最活跃的编排器。

1.2. 协调和服务发现（Coordination & Service Discovery）

1.2.1. 是什么？

现代应用程序由多个单独的服务组成，这些服务需要协作来为最终用户提供价值。为了协作，它们通过网络进行通信(参见云原生网络)，为了通信，它们必须首先找到彼此。服务发现就是找出如何做到这一点的过程。

1.2.2. 解决什么问题？

云原生架构是动态的、流动的，这意味着它们在不断地变化。当一个容器在一个节点上崩溃时，将在另一个节点上启动一个新容器来替换它。或者，当一款应用扩展时，它的副本会分散在整个网络中。没有一个特定的服务所在的位置 -- 所有东西的位置都在不断地变化。这类工具跟踪网络中的服务，以便服务在需要时能够找到彼此。

1.2.3. 有什么作用？

服务发现工具通过提供一个公共的位置来查找和潜在地标识单个服务，从而解决了这个问题。这类工具基本上有两种类型:

• 服务发现引擎：类似数据库的工具，它存储关于所有服务的信息以及如何找到它们。
• 名称解析工具：接收服务位置请求并返回网络地址信息的工具(例如 CoreDNS)

提示

在 Kubernetes 中，为了使一个 pod 可访问，引入了一个叫做“服务(service)”的新的抽象层。service 为动态变化的 pod 组提供一个稳定的地址。

请注意，“service” 在不同的上下文中可能有不同的含义，这可能会让人很困惑。“service” 这个术语通常是指放在容器和 POD 中的服务。它是在实际应用中具有特定功能的应用组件或微服务，例如你手机的面部识别算法。

Kubernetes service 是一种抽象的服务，它帮助 pods 找到彼此并相互连接。service 是作为一组进程（或功能）或 pod 的访问入口。在 Kubernetes 中，当您创建一个服务(抽象)时，您创建了一组 pod，这些 pod 一起提供一个服务(一个或多个容器中的功能)和一个单独的访问点(入口点)，这就是 Kubernetes 服务。

1.2.4. 技术101

随着分布式系统越来越流行，传统的 DNS 服务和传统的负载均衡器往往无法跟上后端（endpoint）信息的变化。为了弥补这些缺点，服务发现工具可以快速地处理各个应用程序实例的注册和注销。CoreDNS 和 etcd 等选项是 CNCF 项目，内置到Kubernetes 中。其他公司则拥有自定义库或工具，以允许服务有效地运行。

1.3. 远程过程调用（Remote Procedure Call）

1.3.1. 是什么？

远程过程调用(RPC)是一种特殊的技术，使应用程序能够相互通信。这是构建应用交流的一种方式。

1.3.2. 解决什么问题？

现代的应用程序由许多独立的服务组成，它们必须通过通信才能协作。RPC 是处理应用程序之间通信的一种选择。

1.3.3. 有什么作用？

RPC提供了一种紧密耦合和高度独立的方式来处理服务之间的通信。它支持带宽高效通信，并且许多编程语言支持 RPC 接口实现。

1.3.4. 技术101

RPC 有很多潜在的好处：它使编码连接更容易，它允许非常有效地使用网络层和服务之间结构良好的通信。RPC 还因创建脆弱的连接点和强制用户为多个服务进行协调升级而受到批评。gRPC 是一种特别流行的 RPC 实现，已经被 CNCF 采用。

1.4. 服务代理（Service Proxy）

1.4.1. 是什么？

服务代理是一种工具，它拦截与给定服务之间的通信，对其应用一些逻辑，然后将该通信转发给另一个服务。它本质上充当一个“中间人”，可以收集有关网络流量的信息并对其应用规则。这可以简单到充当将流量转发到单个应用程序的负载均衡器，也可以复杂到与处理所有网络连接的单个容器化应用程序并排运行的代理的互连网格。

虽然服务代理本身很有用，特别是当将流量从更广泛的网络流向到 Kubernetes 集群时，服务代理也是其他系统的构建块，例如 API网关或服务网格，我们将在下面讨论。

1.4.2. 解决什么问题？

应用程序应以受控方式发送和接收网络流量。为了跟踪流量并可能对其进行转换或重定向，我们需要收集数据。传统上，支持数据收集和网络流量管理的代码是嵌入到每个应用程序中。

服务代理将此功能“具体化”。它不再需要存在于应用程序中。相反，它嵌入了平台层（应用程序运行的地方）。这是非常强大的，因为它允许开发人员完全专注于编写产生价值的应用程序代码，允许处理流量的通用任务由平台团队管理，平台团队的职责首先应该是管理流量。将全局所需服务功能（如路由或TLS终止）的分发和管理从单个公共位置集中化，可以使服务之间的通信变得更加可靠、安全和高效。

1.4.3. 有什么作用？

代理充当用户和服务之间或不同服务之间的网关守卫。通过这种独特的定位，他们可以洞察正在发生的通信类型，然后确定在哪里发送特定请求，甚至完全拒绝。

代理收集关键数据、管理路由（在服务之间均匀分布流量或在某些服务出现故障时重新路由）、加密连接和缓存内容（减少资源消耗）。

1.4.4. 技术101

服务代理的工作方式是拦截服务之间的流量，对其应用逻辑，并允许其在允许的情况下移动。嵌入到代理中的集中控制功能允许管理员完成多项任务。他们可以收集关于服务间通信的详细指标，保护服务不过载，并将其他通用标准应用于服务，如相互TLS。服务代理是其他工具（如服务网格）的基础，因为它们提供了一种对所有网络流量实施更高级别策略的方法。

请注意，CNCF在这一类别中包括负载均衡和提供商。

1.5. API网关（API Gateway）

1.5.1. 是什么？

虽然人类通常通过 GUI（图形用户界面），如网页或桌面应用程序与计算机程序交互，但计算机之间是通过 API（应用程序编程接口）相互交互。不应将 API 与 API 网关概念混淆。

API 网关允许组织将关键功能（如授权或限制应用程序之间的请求数）移动到集中管理的位置。它还充当（通常是外部）API使用者的通用接口。

1.5.2. 解决什么问题？

虽然大多数容器和核心应用程序都有 API，但 API 网关不仅仅是 API。API网关简化了组织对所有接口的管理和规则应用的方式。

API 网关允许开发人员编写和维护更少的定制代码(还记得将系统功能被编码到 API 网关中的情况吗?)它们还使团队能够查看和控制应用程序用户和应用程序本身之间的交互。

1.5.3. 有什么作用？

API网关位于用户和应用程序之间。它充当一个中间人，从用户获取消息(请求)并将它们转发给适当的服务。但在关闭请求之前，它会评估用户是否被允许做他们试图做的事情，并记录谁发出了请求以及他们发出了多少请求的详细信息。

简单地说，API 网关为应用程序用户提供了一个具有通用用户界面的单一入口点。它还允许您将应用程序中以其他方式实现的任务移交给网关，从而节省开发人员的时间和金钱。

例子 销售亚马逊商店的卡片。为了提供这些服务，亚马逊与一家将发行和管理所有亚马逊商店卡的银行合作。作为回报，比方说，银行将保留每笔交易1美元佣金。银行将使用 API 网关授权零售商申请新卡，跟踪账单交易数量，甚至可能限制每分钟申请的卡数。所有这些功能都编码到网关中，而不是使用它的服务。服务部门只关心发卡。

1.5.4. 技术101

像代理和服务网格（见下文）一样，API 网关将自定义代码从我们的应用程序中提取出来，并将其引入中央系统。API网关的工作方式是拦截对后端服务的调用，执行某种增值活动，如验证授权、收集指标或转换请求，然后执行它认为合适的任何操作。

API网关作为一组下游应用程序的公共入口点，同时提供一个位置，让团队可以注入业务逻辑来处理授权、速率限制和计费。它们允许应用程序开发人员从客户那里抽象出对下游 API 的更改，并将新客户登录到网关等任务卸载。

1.6. 服务网格（Service Mesh）

1.6.1. 是什么？

服务网格管理服务之间的流量（即通信）。它们使平台团队能够在集群内运行的所有服务中统一添加可靠性、可观察性和安全特性，而无需任何代码更改。

与 Kubernetes 一样，服务网格已经成为云原生技术栈中最关键的基础设施组件。

1.6.2. 解决什么问题？

在云原生世界中，我们正在处理所有需要通信的多个服务。这意味着在一个固有的不可靠且通常速度较慢的网络上，有更多的流量在来回传输。为了解决这一新的挑战，工程师必须实现额外的功能。在服务网格之前，该功能必须编码到每个应用程序中。这种定制代码常常成为技术债务的来源，并为失败或漏洞提供了新的途径。

1.6.3. 有什么作用？

服务网格可以在平台层的所有服务中统一添加可靠性、可观察性和安全性功能，而不涉及应用程序代码。它们与任何编程语言兼容，允许开发团队专注于编写业务逻辑。

提示：

由于传统上，这些服务网格特性必须编码到每个服务中，每次发布或更新新服务时，开发人员都必须确保这些特性也是功能性的，这会导致很多人为错误。这里有一个肮脏的小秘密，开发人员更喜欢关注业务逻辑（价值生成功能），而不是构建可靠性、可观察性和安全特性。

另一方面，对于平台所有者来说，这些是核心功能，是他们所做一切的核心。让开发人员负责添加平台所有者所需的功能是一个固有的问题。顺便说一下，这也适用于上面提到的通用代理和 API 网关。服务网格和API网关解决了这个问题，因为它们是由平台所有者实现的，并且普遍应用于所有服务。

1.6.4. 技术 101

服务网格通过服务代理将集群上运行的所有服务绑定在一起，从而创建服务网格。这些是通过服务网格控制平面进行管理和控制的。服务网格允许平台所有者在应用程序上执行常见操作或收集数据，而无需开发人员编写自定义逻辑。

本质上，服务网格是一个基础设施层，它通过向服务代理网络（您的网格）提供命令和控制信号来管理服务间通信。它的强大之处在于能够提供关键的系统功能，而无需修改应用程序。

某些服务网格使用通用服务代理（见上文）作为其数据平面。其他人使用专用代理；例如，Linkerd 使用 Linkerd2 代理“微代理”来获得性能和资源消耗方面的优势。这些代理通过所谓的 Sidecar 统一连接到每个服务。Sidecar 指的是代理在自己的容器中运行，但位于同一个pod中。就像摩托车侧车一样，它是一个单独的模块，连接到摩托车上，无论它走到哪里都跟着它。

示例

采取断路措施。在微服务环境中，单个组件通常会出现故障或开始缓慢运行。如果没有服务网格，开发人员将不得不编写自定义逻辑来优雅地处理下游故障，并可能设置冷却计时器，以避免上游服务不断请求降级或失败的下游服务的响应。通过服务网格，可以在平台级别处理该逻辑。

服务网格提供了许多有用的功能，包括显示详细指标、加密所有流量、限制由哪个服务授权的操作、为其他工具提供附加插件等。有关更多详细信息，请查看服务网格接口规范。

1.7. 总结：编排和管理

正如我们所看到的，这一层中的工具处理如何将所有这些独立的容器化服务作为一个组进行管理。编排和调度工具可以看作是一个集群操作系统，用于管理集群中的容器化应用程序。协调和服务发现、服务代理和服务网格确保服务可以相互发现并有效通信，以便作为一个内聚应用程序进行协作。API网关是一个附加层，提供对服务通信的更多控制，特别是在外部应用程序之间。接下来，我们将讨论应用程序定义和开发层--CNCF环境的最后一层。它涵盖数据库、流媒体和消息传递、应用程序定义和图像构建，以及持续集成和交付。

1.8. 经验推荐

在编排调度分类中虽然早期具有三剑客 Mesos、Docker Swarm 和 Kubernetes，但当前 Kubernetes 已经成为事实上标准，如果你是新业务建议直接使用 Kubernetes，如果不是建议迁移到 Kubernetes。

在协调和服务发下分类中，目前在云原生场景下 CoreDNS 和 Etcd 都已经具有大量是实践案例，是靠谱的选择。但是根据实际业务和技术框架的不同 Zookeeper 和 Nacos 也是不错的选择；由于 Consul 也具有注册发现的功能，也有较多的使用实践。对于 Eureka 由于社区目前并不活跃，建议慎重考虑。

远程 RPC 调用目前主流推荐 gRPC，对于国内很多用户更偏向于 Dubbo，Apache thrift 也是不错的选择。

服务代理中目前主流的选择是 Envoy，Contour 也是基于 Envoy 建设的。传统的 nginx、OpenRestry、haproxy 在云原生场景下任然具有一定的生命力，也是可选的。一些业务系统由于历史原因选择 Zuul，这和业务的特性以及历史包袱有关，保持中立的观点。对于一些资金充裕的客户，商业化的 F5 也是不错的选择。

API网关部分中，目前 Emissary-Ingress 是个不错的选择。实际业务中，Kong、APISIX也有很多用户在使用。

而服务网格 ServiceMesh 是和 Kubernetes 同样核心的云原生基础设施。目前虽然 Linkerd 已经成熟毕业，但 Istio 显然影响力更大。