envoy_为Envoy构建控制平面的指南-特定于域的配置API

envoy

建立您的控制平面交互点和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。 下一节将清楚说明其原因。

对于用户而言，Gloo专注于拥有其路由配置的团队，因为路由的语义(以及可用的转换/聚合功能)在很大程度上受到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控制平面实施方案，并且仅在没有其他合适的方案时才构建自己的方案。 正如我们将在下一节中看到的那样，可以构建一个完全可扩展的控制平面，以适应许多不同的用户，工作流和操作约束。

翻译自: https://www.javacodegeeks.com/2019/02/envoy-domain-specific-configuration-api.html

envoy