![envoy](https://i-blog.csdnimg.cn/blog_migrate/7f215ae2433a595801eca5b9a83f0a97.png)
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