编排和管理层是 CNCF 云原生全景图的第三层。在使用这一层的工具之前，工程师大概已经按照安全合规标准自动配置了基础设施，并为应用程序设置了运行时（运行时层）。现在，他们必须弄清楚如何将所有应用程序组件作为整体来编排和管理。这些组件必须相互识别以进行通信，并通过协调实现共同的目标。编排和管理层的工具可实现自动化和弹性伸缩，基于此云原生应用程序天然具有可扩展性。
K8sMeetup
编排和调度
是什么
编排和调度是指在集群中运行和管理容器（一种打包和运送应用的新方式）。集群是通过网络连接的一组机器（物理机或虚拟机均可）。
容器编排器（和调度器）与电脑上管理所有应用程序（如微软 360、Zoom、Slack 等）的操作系统类似。操作系统执行你想使用的应用程序，并规划哪个应用程序该在何时使用电脑的 CPU 和其他硬件资源。
虽然在一台机器上运行所有东西很棒，但如今大多数应用程序的大小远非一台机器所能处理，大多数现代的应用程序都是分布式的，这就需要一种软件能够管理在不同机器上运行的组件。简单来说，你需要一个“集群操作系统”。这就是编排工具。
你可能已经注意到了，在本系列的前几篇文章中，容器频繁出现。容器可以让应用程序运行在不同的环境中，这种能力是关键。容器编排器（大多数情况下是指 Kubernetes）也是如此。容器和 Kubernetes 是云原生架构的核心，所以我们总是听到别人提起它们。
解决的问题
在云原生架构中，应用程序被分解成很多小的组件或服务，每个组件或服务都放在一个容器里。你可能已经听说过微服务，指的就是这种情况。现在，你拥有的不再是一个大型的应用程序，而是多个小型的服务，每个服务都需要资源、要被监控，在出现问题的时候也需要修复。对单个服务来说手动执行这些操作是可行的，但当你有上百个容器时，你就需要自动化的流程。
如何解决
容器编排器自动化了容器管理的过程。这在实际操作中意味着什么？让我们以 Kubernetes 来回答这个问题，因为 Kubernetes 是事实上的容器编排器。
Kubernetes 做的事情是“期望状态协调”：将集群中容器的当前状态与期望状态匹配。工程师在文件中指定所需状态，例如：服务 A 的 10 个实例在三个节点（即：机器）上运行，可访问 B 数据库，等等。该状态需持续与实际状态进行比较。如果预期状态与实际状态不匹配，Kubernetes 会通过创建或销毁对象来进行协调（例如：如果某个容器崩溃了，Kubernetes 会启动一个新的容器）。
简而言之，Kubernetes 允许你将集群视为一台计算机。它仅关注环境并为你处理实现细节。
对应工具
Kubernetes 与其他容器编排器（Docker Swarm，Mesos 等）都是编排调度工具，其基本目的是允许将多个不同的计算机作为一个资源池进行管理，并以声明式的方式管理它们，即不必告诉 Kubernetes 如何做，而是提供要完成的工作的定义。这样可以在一个或多个 YAML 文件中维护所需的状态，并将其应用于其他 Kubernetes 集群。然后，编排器本身会创建缺失的内容或删除无需存在的东西。
虽然 Kubernetes 不是 CNCF 托管的唯一编排器（Crossplane 和 Volcano 是另外两个孵化项目），但它是最常用的，项目也有大量积极的维护者。
K8sMeetup
协调和服务发现
是什么
现代应用程序由多个单独的服务组成，这些服务之间需要相互协作才能为最终用户提供价值。要进行协作，这些服务通过网络进行通信（我们在运行时层已经讨论过）。要通信，服务需要能相互定位。服务发现就是解决这个问题的。
解决的问题
云原生架构是动态的，总是在不断变化。当一个节点上的某个容器崩溃时，一个新的容器会在另一个节点上启动来替代它。或者，当一个应用程序扩展时，它的副本会散布在整个网络中。没有一个地方可以提供特定服务，一切的位置在不断变化。此类别的工具跟踪网络中的服务，以便服务在需要时可以相互查找。
如何解决
服务发现工具可提供一个公共的位置来查找和识别单个的服务。该类别中有两种工具：
- 服务发现引擎：类似数据库的工具，存储的信息包括：存在什么哪些服务以及如何定位它们；
- 名称解析工具（如 Core DNS）：接收服务位置请求并返回网络地址信息。
注：在 Kubernetes 中，为了使 Pod 可达，引入了一个称为“Service”的新抽象层。Service 为动态变化的 Pod 组提供了单一稳定的地址。 请注意，“Service” 在不同的语境中有不同的含义，可能会造成混淆。“services” 通常指位于容器/Pod 中的服务，是实际应用程序中具有特定功能的应用组件或微服务（例如：iPhone 的面部识别算法）。 而 Kubernetes 的 Service 是一种抽象，可帮助 Pod 相互查找和定位。它是服务（功能上的）作为进程或 Pod 的入口点。在 Kubernetes 中，当你创建了一个 Service （抽象），你就创建了一组 Pod，这些 Pod 一起通过单一 endpoint （入口）提供一个服务（功能）。
对应工具
随着分布式系统变得越来越普遍，传统的 DNS 流程和负载均衡器已经无法跟上不断变化的 Endpoint 信息，因此有了服务发现工具。它们可用来处理快速对自身进行注册和注销的各个应用程序实例。一些服务发现工具（例如 etcd 和 CoreDNS）是 Kubernetes 原生的，其他一些工具有自定义的库或工具让服务有效运行。CoreDNS 和 etcd 是 CNCF 项目，并且内置在 Kubernetes 中。
K8sMeetup
远程进程调用
是什么
远程进程调用（RPC, Remote Procedure Call）是一种使应用程序相互通信的特殊技术。它代表了应用程序相互之间构建通信的一种方法。
解决的问题
现代应用程序由众多单独的服务组成，这些服务必须通过通信才能进行协作。RPC 是应用程序之间进行通信的一种方法。
如何解决
RPC 可以一种紧耦合且高度自觉的方式处理服务之间的通信。它允许带宽高效的通信，并且许多语言支持 RPC 接口实现。RPC 不是解决此问题的唯一方法，也不是最常见的方法。
对应工具
RPC 为服务之间的通信提供了高度结构化且紧密耦合的接口。gRPC 是非常流行的 RPC 实现，已被 CNCF 采用。
K8sMeetup
服务代理
是什么
服务代理工具用于拦截进出某个服务的流量，对其应用一些逻辑，然后转发该流量到另一个服务。服务代理的本质是一种“中间人”，收集网络流量的信息并对其应用规则。简单如充当负载均衡器将流量转发到单个应用程序，也可复杂如并排运行的代理网格，由单个的容器化应用程序处理所有网络连接。
服务代理本身很有用，尤其是在将流量从更广泛的网络引到 Kubernetes 集群时。服务代理同时也为其他系统（如 API 网关或服务网格）搭建了基础，我们将在下文讨论。
解决的问题
应用程序应以受控方式发送和接收网络流量。为了跟踪流量并对其进行转换或重定向，我们需要收集数据。传统上，开启数据收集和网络流量管理的代码嵌入在每个应用程序中。服务代理可以使我们“外部化”该功能，使其无需再存在于应用程序中，而是嵌入到平台层（应用程序运行的地方）。
这是非常强大的功能，因为它使开发人员可以完全专注于编写应用程序逻辑，而处理流量的通用任务由平台团队管理（这是平台团队的首要职责）。通过从单个公共位置集中分配和管理全局所需的服务功能（例如路由或 TLS 终止），服务之间的通信将更加可靠，安全和高效。
如何解决
代理充当用户和服务之间或不同服务之间的守门员。通过这种独特的定位，他们可以洞悉正在发生的通信类型。根据洞察，他们可以确定将特定请求发送到哪里，甚至完全拒绝该请求。
代理收集关键数据，管理路由（在服务之间平均分配流量或在某些服务发生故障时重新路由），加密连接和缓存内容（减少资源消耗）。
对应工具
服务代理的工作原理是拦截服务之间的流量，对它们执行一些逻辑，然后可能会允许流量继续前进。通过将一组集中控制的功能放入此代理，管理员可以完成几件事。他们可以收集有关服务间通信的详细指标，防止服务过载，并将其他通用标准应用于服务。服务代理是服务网格等其他工具的基础，因为它们提供了对所有网络流量实施更高级别策略的方法。
请注意，CNCF 将负载均衡器和 ingress provider 包括在此类别中。Envoy，Contour 和 BFE 都是 CNCF 项目。
K8sMeetup
API 网关
是什么
人们通常通过网页或（桌面）应用程序之类的 GUI（图形用户界面）与计算机程序进行交互，计算机则通过 API（应用程序编程接口）相互进行交互。但是，请勿将 API 与 API 网关混淆。
API 网关允许组织将关键功能（例如授权或限制应用程序之间的请求数量）移动到集中管理的位置。它还用作（通常是外部的）API 使用者的通用接口。
通过 API 网关，组织可以集中控制（限制或启用）应用程序之间的交互并跟踪它们，从而实现 拒绝请求、身份验证之类的功能，并防止服务被过度使用（也称为速率限制）。
解决的问题
尽管大多数容器和核心应用程序都具有 API，但 API 网关不仅仅是 API。API 网关简化了组织管理规则和将规则应用于所有交互的方式。
API 网关允许开发人员编写和维护较少的自定义代码。他们还使团队能够查看和控制用户与应用程序本身之间的交互。
如何解决
API 网关位于用户和应用程序之间。它充当中介，将来自用户的消息（请求）转发给适当的服务。但是在交出请求之前，它会评估用户的请求是否被允许，并详细记录发出请求的人以及发出的请求数量。
简而言之，API 网关为应用程序用户提供了具有通用用户界面的单入口点。它还可以将原本在应用程序中实现的任务移交给网关，从而为开发人员节省时间和金钱。
对应工具
像该层中的许多类别一样，API 网关从应用程序中删除自定义代码，并将其带入中央系统。API 网关的工作原理是拦截对后端服务的调用，执行某种增值活动，例如验证授权、收集指标或转换请求，然后执行它认为适当的操作。API 网关是一组下游应用程序的通用入口点，同时为团队提供了可以注入业务逻辑以处理授权，速率限制和拒绝请求的地方。它们使应用开发者可以从客户那里提取对下游 API 的更改，并将添加新客户之类的任务交给网关。
K8sMeetup
服务网格
是什么
如果你已经了解了一些云原生相关的知识，则“服务网格”这个术语可能已经听说过。最近服务网格引起了很多关注。TNS 的长期贡献者 Janakiram MSV 表示，“在 Kubernetes 之后，服务网格技术已成为云原生技术栈中最关键的部分。” 服务网格管理服务之间的流量（即通信）。它们使平台团队能够无需更改任何代码即可在集群内运行的所有服务之间统一添加可靠性，可观察性和安全性功能。
解决什么问题
在云原生环境中，我们要处理很多服务，这些服务都需要通信。这意味着在本来不可靠且通常很慢的网络上需要来回传输更多流量。为了应对这些新挑战，工程师必须实施额外的功能。在服务网格之前，必须将该功能编码到每个单独的应用程序中。这些代码通常会成为技术债，并导致失败或漏洞。
如何解决
服务网格在平台层的所有服务之间统一增加了可靠性，可观察性和安全性，而无需触及应用程序代码。它们与任何编程语言兼容，使开发团队可以专注于编写业务逻辑。
注：传统上必须将这些服务网格功能编码到每个服务中，因此每次发布或更新新服务时，开发人员都必须确保这些功能也能使用，会导致很多人为错误。事实上，开发人员更喜欢专注于业务逻辑（产生价值的功能），而不是建立可靠性，可观察性和安全性功能。但对于平台所有者来说，可靠性、可观察性和安全是核心功能，对于他们所做的一切至关重要。让开发人员负责添加平台所有者需要的功能本身很难。服务网格和 API 网关解决了这个问题，因为它们是由平台所有者实现并普遍应用于所有服务的。
对应工具
服务网格通过服务代理将集群上运行的所有服务绑定在一起，从而创建了服务的网格。这些是通过服务网格控制平面进行管理和控制的。服务网格允许平台所有者在不要求开发人员编写自定义逻辑的情况下执行常见操作或在应用程序上收集数据。本质上，服务网格是通过向服务代理的网络或网格提供命令和控制信号来管理服务间通信的基础结构层。它的能力在于无需修改应用程序即可提供关键系统功能。
某些服务网格将通用服务代理（请参见上文）用于其数据平面。另外一些则使用专用代理。例如，Linkerd 使用 Linkerd2-proxy “微型代理”来获得性能和资源消耗方面的优势。这些代理通过边车（sidecar) 统一地附加到每个服务上。Sidecar 是指代理在自己的容器中运行但存在于同一个 Pod 中，就像摩托车边车一样，它是一个单独的模块，附着在摩托车上。
服务网格提供了许多有用的功能，包括显示详细指标，加密所有流量，限制服务可授权的操作，为其他工具提供额外插件等等。更多详细信息，请查看服务网格接口规范：https://smi-spec.io/
K8sMeetup
总结
编排和管理层的工具旨在将独立的容器化应用作为一个组进行管理。编排和调度工具可以看作是集群操作系统，用于管理整个集群中的容器化应用程序。协调和服务发现，服务代理和服务网格确保服务可以找到彼此并进行有效通信，彼此协作以成为一个流畅的应用程序。API 网关是一个附加层，可对服务通信加以更多控制，尤其是对外部应用程序之间的通信。在下一篇文章中，我们将讨论应用程序定义和开发层——CNCF 全景图的最后一层。它涵盖数据库、数据流和消息传递、应用程序定义和镜像构建，以及持续集成和交付。
