建设银行网站的目的,附近做广告招牌的,密云住房和城乡建设部网站首页,东莞建站模板这是探索为Envoy Proxy构建控制平面的系列文章的第3部分。 在本博客系列中#xff0c;我们将研究以下领域#xff1a; 采用一种机制来动态更新Envoy的路由#xff0c;服务发现和其他配置 确定哪些组件构成了控制平面#xff0c;包括后备存储#xff0c;服务发现API我们将研究以下领域 采用一种机制来动态更新Envoy的路由服务发现和其他配置 确定哪些组件构成了控制平面包括后备存储服务发现API安全组件等。 等 建立最适合您的用例和组织的任何特定于域的配置对象和API 此条目 考虑如何最好地使控制平面可在需要的地方插入 部署各种控制平面组件的选项 通过测试平面来考虑您的控制飞机 在上一篇文章中我们评估了控制平面可能需要的组件。 在本节中我们将探讨您的控制平面特定于域的API的外观。 建立您的控制平面交互点和API表面 一旦仔细考虑了哪些组件可能构成控制平面体系结构请参见上一章您将要确切考虑用户将如何与控制平面进行交互甚至更重要的是 用户将是谁 要回答这个问题您必须决定基于Envoy的基础架构将扮演什么角色以及流量如何遍历您的体系结构。 可能是 API管理网关北/南 简单的Kubernetes边缘负载均衡器/反向代理/入口控制北/南 共享服务代理东西方 每辆服务车东/西 例如Istio项目旨在成为平台服务网格平台操作员可以在其上构建工具来驱动对服务和应用程序之间网络的控制。 用于配置Envoy的Istio的特定于域的配置对象围绕以下对象 网关 –定义一个共享的代理组件具有群集入口功能该组件指定协议TLS端口和主机/授权可用于负载均衡和路由流量 VirtualService –有关如何与特定服务进行交互的规则 可以指定诸如路由匹配行为超时重试等内容 DestinationRule –关于如何与特定服务交互的规则包括断路负载平衡mTLS策略服务的子集定义等 ServiceEntry –将服务显式添加到Istio的服务注册表中 在Kubernetes中运行所有这些配置对象都实现为CustomResourceDefinitions 。 Heptio / VMWare Contour旨在用作Kubernetes入口网关并具有简化的特定于域的配置模型同时具有CustomResourceDefinitionCRD风格和Kubernetes入口资源 IngressRoute是Kubernetes CRD它提供一个位置来指定Contour代理的配置 入口资源支持 如果您喜欢这种事情则可以使用它在Kubernetes入口资源上指定注释 在Gloo项目中我们决定将可用的配置对象分为两个级别 面向用户的配置可为用户使用案例提供最佳的人机工程学并留有扩展性的选择下一节将对此进行详细介绍 提取Envoy的低层配置但不明确打算直接用于用户操作。 较高级别的对象将转换为该较低级别的表示形式最终将其转换为Envoy xDS API。 下一节将清楚说明其原因。 对于用户来说Glo专注于拥有自己的路由配置的团队因为路由的语义以及可用的转换/聚合功能在很大程度上受到API和微服务开发人员的影响。 对于面向用户的API对象我们使用 网关 –指定特定侦听器端口上可用的路由和API端点以及每个API附带的安全性 VirtualService –将API路由分组为一组“虚拟API”这些路由可以路由到支持的功能gRPChttp / 1http / 2lambda等 使开发人员可以控制路由如何进行不同的转换 以尝试使前端API与后端中存在的功能脱钩以及后端可能引入的任何重大更改 请注意这些不同于这些对象的Istio变体。 Gloo中面向用户的API对象驱动较低级别的对象这些对象随后用于最终派生Envoy xDS配置。 例如Gloo的较低级别的核心API对象是 上游 –捕获有关后端群集的详细信息以及在其上公开的功能。 您可以将Gloo上游与Envoy集群松散地联系起来但有一个很大的不同上游可以了解特定端点上可用的实际服务功能换句话说了解/foo/bar和/bar/wine包括它们的预期参数和参数结构而不仅仅是hostname:port 。 一秒钟内会更多。 代理 –代理是抽象我们可以应用于Envoy的所有配置的主要对象。 这包括侦听器虚拟主机路由和上游。 较高级别的对象VirtualService网关等用于驱动此较低级别的代理对象。 Gloo控件的两个配置级别之间的划分使我们能够扩展Gloo控制面板功能同时保留用于配置Envoy的简单抽象。 在本系列的第4部分中将对此进行详细说明。 在前面的三个示例IstioContourGloo中每个各自的控制平面都公开了一组特定于域的配置对象这些对象以用户为中心但最终转换为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的控制飞机奠定了扩展和定制基础。 正如我们将在下一篇文章中看到的那样可以构建一个完全可扩展的控制平面以适应许多不同的用户工作流和操作约束。 翻译自: https://www.javacodegeeks.com/2019/03/domain-specific-configuration-api.html
