最近， Envoy已成为流行的网络组件。 马特·克莱因（ Matt Klein ）在几年前写了一个博客，内容涉及Envoy的动态配置API，以及它如何成为Envoy的采用曲线向右移的原因之一。 他称该博客为“通用数据平面API”。 由于有许多其他项目采用Envoy作为其产品的核心组件，因此可以说“ Envoy已成为应用程序/ L7网络解决方案的云原生架构中的通用数据平面”，而不仅仅是建立标准化的API 。
此外，由于Envoy的通用数据平面API ，我们已经看到了许多管理层的实现，用于配置和驱动基于Envoy的基础架构。 我们将深入研究为Envoy构建控制平面所需的内容，以便您可以使用此信息来评估哪种类型的基础架构最适合您的组织和用例。 因为这是一个广泛的主题，所以我们将在接下来的几天中分多个部分讨论这个问题。 跟随（ @christianposta ， @soloio_inc ）进入下一个条目。
在EnvoyCon / KubeCon上进行了一些精彩的演讲，其中一些组织分享了采用Envoy的经验，包括如何构建自己的控制飞机。 人们选择构建自己的控制平面的一些原因：
- 是否具有基于具有预先存在的控制平面的不同数据平面的现有解决方案，并且需要对Envoy进行改造
- 为不具有任何现有开源或其他Envoy控制平面（即VM，AWS 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
