envoy api 网关_为Envoy构建控制平面的指南-特定于域的配置API

envoy 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与后端中存在的功能脱钩（以及后端可能引入的任何重大更改）

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

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

Gloo控件的两个配置级别之间的划分使我们能够扩展Gloo控制面板功能，同时保留用于配置Envoy的简单抽象。下一节将对此进行说明。

在前面的三个示例（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控制平面实施方案，并且仅在没有其他合适的方案时才构建自己的方案。正如我们将在下一节中看到的那样，可以构建一个完全可扩展的控制平面，以适应许多不同的用户，工作流和操作约束。