做茶道网站,电商平台开发报价,郑州公司网页,违法网站建设国外服务器最近#xff0c; Envoy已成为流行的网络组件。 马特克莱因#xff08; Matt Klein #xff09;在几年前写了一个博客#xff0c;内容涉及Envoy的动态配置API#xff0c;以及它如何成为Envoy的采用曲线向右移的原因之一。 他称该博客为“通用数据平面API”。 由于有许多其他… 最近 Envoy已成为流行的网络组件。 马特·克莱因 Matt Klein 在几年前写了一个博客内容涉及Envoy的动态配置API以及它如何成为Envoy的采用曲线向右移的原因之一。 他称该博客为“通用数据平面API”。 由于有许多其他项目采用Envoy作为其产品的核心组件因此可以说“ Envoy已成为应用程序/ L7网络解决方案的云原生架构中的通用数据平面”而不仅仅是建立标准化的API 。 此外由于Envoy的通用数据平面API 我们已经看到了许多管理层的实现用于配置和驱动基于Envoy的基础架构。 我们将深入研究为Envoy构建控制平面所需的内容以便您可以使用此信息来评估哪种类型的基础架构最适合您的组织和用例。 因为这是一个广泛的主题所以我们将在接下来的几天中分多个部分讨论这个问题。 跟随 christianposta soloio_inc 进入下一个条目。 在EnvoyCon / KubeCon上进行了一些精彩的演讲其中一些组织分享了采用Envoy的经验包括如何构建自己的控制飞机。 人们选择构建自己的控制平面的一些原因 是否具有基于具有预先存在的控制平面的不同数据平面的现有解决方案并且需要对Envoy进行改造 为不具有任何现有开源或其他Envoy控制平面即VMAWS ECS等的基础架构进行构建 不需要使用Envoy的所有功能 只是一个子集 对于Envoy配置最好使用特定于域的API /对象模型以使其更适合其工作流程/ worldview 其他控制平面在各自组织准备部署时还没有处于成熟状态 但是仅仅因为某些早期采用者构建了自己的定制控制平面并不意味着您现在应该做同样的事情。 首先为Envoy构建控制平面的项目在去年已经相当成熟在决定重新创建另一个控制平面之前您应该探索使用这些平面的方法。 其次正如Datawire的人们发现的那样 Daniel Bryant最近也明确指出 为Envoy建造一架控制飞机并不是出于胆小 。 我参与 了几个为Envoy构建控制平面的开源项目 。 例如 Gloo是一个功能网关 可以充当功能非常强大的Kubernetes入口API网关或功能网关以简化从整体到微服务的过渡。 Gloo 有一个Envoy的控制面板我们可以在本系列文章中引用它作为如何构建一个简单抽象的示例该抽象允许您需要的控制点具有可插拔性和可扩展性。 您可以参考的其他固态控制面板实现是Istio和Heptio Contour 我们将在整个博客系列中将其用作示例。 如果没有其他问题您可以了解Envoy控制平面存在哪些选项并在必须走这条路的情况下使用它来指导您的实现。 在本博客系列中我们将研究以下领域 采用一种机制来动态更新Envoy的路由服务发现和其他配置 确定哪些组件构成了控制平面包括后备存储服务发现API安全组件等。 等 建立最适合您的用例和组织的任何特定于域的配置对象和API 考虑如何最好地使控制平面可在需要的地方插入 部署各种控制平面组件的选项 通过测试平面来考虑您的控制飞机 首先让我们看一下使用Envoy的动态配置API在运行时更新Envoy来处理拓扑和部署中的更改。 使用xDS API动态配置Envoy 在Envoy之上进行构建的主要优势之一是其数据平面API。 借助数据平面API我们可以动态配置Envoy的大多数重要运行时设置 。 Envoy通过其xDS API进行的配置最终在设计上是一致的 -也就是说无法影响群集中所有代理的“原子更新”。 当控制平面具有配置更新时它将通过xDS API使它们可供数据平面代理使用并且每个代理将彼此独立地应用这些更新。 以下是我们可以通过xDS动态配置的Envoy运行时模型的各个部分 侦听器发现服务API – LDS发布用于侦听流量的端口 端点发现服务API-用于服务发现的EDS 路由发现服务API- RDS用于流量路由决策 群集发现服务-CDS用于我们可以将流量路由到的后端服务 秘密发现服务–用于分发秘密证书和密钥的SDS 该API是使用proto3协议缓冲区定义的甚至还有一些参考实现您可以用来引导自己的控制平面 去控制平面 Java控制平面 尽管每个区域LDS / EDS / RDS / CDS / SDS统称为“ xDS”都是可动态配置的但这并不意味着您必须动态配置所有内容。 您可以将静态定义的部分与动态更新的部分组合在一起。 例如要实现一种服务发现类型其中endpoints应该是动态的但是clusters在部署时是众所周知的则可以静态定义clusters并使用Envoy的Endpoint Discovery Service 。 如果您不确定在部署时将使用哪些上游群集则可以使用“ 群集发现服务”动态查找这些群集 。 关键是您可以构建一个工作流和流程以静态配置所需的零件同时使用动态xDS服务在运行时发现所需的零件。 之所以看到不同的控制平面实现原因之一不是每个人都拥有一个完全动态且可替代的环境其中所有部分都应该是动态的。 在存在现有约束和可用工作流程的情况下采用最适合您的系统的动态级别。 对于Gloo我们使用基于go-control-plane的控制平面来实现xDS API以服务于Envoy的动态配置。 Istio以及Heptio Contour也使用此实现。 该控制平面API利用gRPC流调用并对API进行存根处理以便您可以在其中填充实现。 Turbine Labs的Rotor项目是另一个不幸地不推荐使用但可以学到很多东西的项目 。 这是将Envoy的数据平面API与控制平面集成的一种高效方法。 gRPC流并不是更新Envoy配置的唯一方法。 在早期版本的Envoy xDS API中 轮询是确定新配置是否可用的唯一选项。 尽管这是可以接受的并且满足“最终一致”配置更新的条件但是它在网络和计算使用方面均效率较低。 适当调整轮询配置以减少浪费的资源也可能很困难。 最后某些Envoy管理实现选择生成静态Envoy配置文件并定期为Envoy替换磁盘上的配置文件然后对Envoy进程进行热加载 。 在高度动态的环境例如Kubernetes但实际上是任何基于临时计算的平台中此文件生成传递热重启等的管理可能会变得笨拙。 Envoy最初是在执行这样的更新的环境中创建的Lyft创建它的地方但是它们正逐步使用xDS API。 带走 Gloo小组认为使用gRPC流和xDS API是为Envoy实施动态配置和控制的理想方法。 同样如果不需要并非所有Envoy配置都应动态提供但是如果您在高度动态的环境例如Kubernetes中运行则动态配置Envoy的选项至关重要。 其他环境可能没有此需求。 无论哪种方式用于动态部件的gRPC流API都是理想的。 这种方法的一些好处 事件驱动的配置更新 当配置在控制平面中可用时将配置推送到Envoy 无需轮询更改 无需热装特使 没有交通中断 下一步是什么 在第一部分中我们通过覆盖xDS API和为Envoy提供动态配置所需的其他选项建立了有关如何为Envoy构建控制平面的一些基本上下文。 在接下来的几天将在几天内发布中将介绍如何将控制平面分解为可部署的组件确定所需的组件特定于域的配置对象模型的外观以及如何考虑控件的可插入性。飞机。 在Twitter christianposta soloio_inc 或博客 https://blog.christianposta.com https://medium.com/solo-io 上关注 翻译自: https://www.javacodegeeks.com/2019/02/control-plane-manage-envoy-proxy-edge.html
