为使节构建控制平面的指南第3部分-特定于域的配置API

这是探索为Envoy Proxy构建控制平面的系列文章的第3部分。

在本博客系列中，我们将研究以下领域：

采用一种机制来动态更新Envoy的路由，服务发现和其他配置
确定哪些组件构成了控制平面，包括后备存储，服务发现API，安全组件等。等
建立最适合您的用例和组织的任何特定于域的配置对象和API （此条目）
考虑如何最好地使控制平面可在需要的地方插入
部署各种控制平面组件的选项
通过测试平面来考虑您的控制飞机

在上一篇文章中，我们评估了控制平面可能需要的组件。在本节中，我们将探讨您的控制平面特定于域的API的外观。

建立您的控制平面交互点和API表面

一旦仔细考虑了哪些组件可能构成控制平面体系结构（请参见上一章），您将要确切考虑用户将如何与控制平面进行交互，甚至更重要的是， 用户将是谁？ 要回答这个问题，您必须决定基于Envoy的基础架构将扮演什么角色以及流量如何遍历您的体系结构。可能是

API管理网关（北/南）
简单的Kubernetes边缘负载均衡器/反向代理/入口控制（北/南）
共享服务代理（东西方）
每辆服务车（东/西）

例如，Istio项目旨在成为平台服务网格，平台操作员可以在其上构建工具来驱动对服务和应用程序之间网络的控制。用于配置Envoy的Istio的特定于域的配置对象围绕以下对象：

网关 –定义一个共享的代理组件（具有群集入口功能），该组件指定协议，TLS，端口和主机/授权，可用于负载均衡和路由流量
VirtualService –有关如何与特定服务进行交互的规则；可以指定诸如路由匹配行为，超时，重试等内容
DestinationRule –关于如何与特定服务交互的规则，包括断路，负载平衡，mTLS策略，服务的子集定义等
ServiceEntry –将服务显式添加到Istio的服务注册表中

在Kubernetes中运行，所有这些配置对象都实现为CustomResourceDefinitions 。

Heptio / VMWare Contour旨在用作Kubernetes入口网关，并具有简化的特定于域的配置模型，同时具有CustomResourceDefinition（CRD）风格和Kubernetes入口资源

IngressRoute是Kubernetes CRD，它提供一个位置来指定Contour代理的配置
入口资源支持，如果您喜欢这种事情，则可以使用它在Kubernetes入口资源上指定注释

在Gloo项目中，我们决定将可用的配置对象分为两个级别：

面向用户的配置可为用户使用案例提供最佳的人机工程学，并留有扩展性的选择（下一节将对此进行详细介绍）
提取Envoy的低层配置，但不明确打算直接用于用户操作。较高级别的对象将转换为该较低级别的表示形式，最终将其转换为Envoy xDS API。下一节将清楚说明其原因。

对于用户来说，Glo专注于拥有自己的路由配置的团队，因为路由的语义（以及可用的转换/聚合功能）在很大程度上受到API和微服务开发人员的影响。对于面向用户的API对象，我们使用：

网关 –指定特定侦听器端口上可用的路由和API端点以及每个API附带的安全性
VirtualService –将API路由分组为一组“虚拟API”，这些路由可以路由到支持的功能（gRPC，http / 1，http / 2，lambda等）；使开发人员可以控制路由如何进行不同的转换，以尝试使前端API与后端中存在的功能脱钩（以及后端可能引入的任何重大更改）

请注意，这些不同于这些对象的Istio变体。

Gloo中面向用户的API对象驱动较低级别的对象，这些对象随后用于最终派生Envoy xDS配置。例如，Gloo的较低级别的核心API对象是：

上游 –捕获有关后端群集的详细信息以及在其上公开的功能。您可以将Gloo上游与Envoy集群松散地联系起来，但有一个很大的不同：上游可以了解特定端点上可用的实际服务功能（换句话说，了解/foo/bar和/bar/wine包括它们的预期参数和参数结构，而不仅仅是hostname:port ）。一秒钟内会更多。
代理 –代理是抽象我们可以应用于Envoy的所有配置的主要对象。这包括侦听器，虚拟主机，路由和上游。较高级别的对象（VirtualService，网关等）用于驱动此较低级别的代理对象。

Gloo控件的两个配置级别之间的划分使我们能够扩展Gloo控制面板功能，同时保留用于配置Envoy的简单抽象。在本系列的第4部分中将对此进行详细说明。

在前面的三个示例（Istio，Contour，Gloo）中，每个各自的控制平面都公开了一组特定于域的配置对象，这些对象以用户为中心，但最终转换为Envoy配置并通过xDS数据平面API公开。这使Envoy与用户的预设工作方式及其工作流程脱钩。尽管我们已经看到了一些示例，这些示例创建了更多针对用户和工作流的特定于域的配置，以抽象化Envoy，但这并不是构建Envoy控制平面的唯一方法。 Booking.com上有一个很好的演讲，介绍了他们如何与Envoy配置保持更紧密的距离，并使用引擎将所有不同团队的配置片段合并到实际的Envoy配置中。

除了考虑特定于域的配置之外，您还应该考虑API /对象模型的特定接触点。例如，Kubernetes非常注重YAML和资源文件。您可以构建更特定于域的CLI工具（例如OpenShift使用oc CLI进行操作，例如Istio 使用istioctl进行处理，以及Gloo 使用glooctl进行处理

带走

当构建Envoy控制面板时，您在考虑特定意图或一组体系结构/用户时进行此操作。您应该考虑到这一点，并构建正确的，符合人体工学的，针对特定领域的API，以适合您的用户并改善操作Envoy的工作流程。 Gloo团队建议您探索现有的 Envoy控制平面实施方案，并且仅在没有其他合适的方案时才构建自己的方案。 Gloo的控制飞机奠定了扩展和定制基础。正如我们将在下一篇文章中看到的那样，可以构建一个完全可扩展的控制平面，以适应许多不同的用户，工作流和操作约束。