为特使建立控制平面的指南第2部分-识别组件

这是探索为Envoy Proxy构建控制平面的系列文章的第2部分。

在本博客系列中，我们将研究以下领域：

• 采用一种机制来动态更新Envoy的路由，服务发现和其他配置
• 确定哪些组件构成了控制平面，包括后备存储，服务发现API，安全组件等。 等(此条目)
• 建立最适合您的用例和组织的任何特定于域的配置对象和API
• 考虑如何最好地使控制平面可在需要的地方插入
• 部署各种控制平面组件的选项
• 通过测试平面来考虑您的控制飞机

在本系列的上一篇文章中，我们探索了动态配置Envoy的过程，这是在云原生环境中运行Envoy的重要组成部分。 在本条目中，我们将介绍支持控制平面可能需要的协作组件。

确定控制平面所需的组件

由于操作环境的范围千差万别，因此为Envoy实施控制平面所需的组件也可能如此。 例如，在一种极端情况下，如果您在构建时静态生成了Envoy文件并将其发送到Envoy，则可能需要以下组件：

• 模板引擎
• 数据存储/ VCS，用于进入模板的值
• 可能/可能不与服务/应用程序一起存储的任何特定于服务的配置
• 协调器将片段组合在一起
• 将这些交付给特使的方法
• 一种触发重新加载/热重启配置文件的方法

另一方面，如果您选择使用gRPC流xDS实现，则需要：

• 核心xDS服务接口和实现
• 处理向服务注册表中注册/注销服务的组件
• 服务注册表
• 描述Envoy配置的抽象对象模型(可选)
• 数据存储区，用于保存配置

您最可能需要支持Envoy运作的其他辅助组件：

• 证书/ CA商店
• 统计收集引擎
• 分布式跟踪后端/引擎
• 外部认证
• 限速服务

通常，您将需要考虑构建控制平面，以便组件独立运行并可以松散协作以提供控制平面的需求。 您要做的最后一件事是通过部署整体控制平面来支持Envoy进行微服务部署。 例如，在开源Gloo项目中，我们具有驱动控制平面的以下组件：

• Gloo –事件驱动的组件，负责为核心xDS服务生成配置并为其提供服务以及自定义Envoy过滤器的配置
• Discovery –一个可选组件，它知道如何与服务发现服务(领事，Kubernetes等)一起使用，以发现并发布上游集群和端点。 它还可以发现REST终结点(使用swagger)，gRPC函数(基于gRPC反射)以及AWS / GCP / Azure云功能。 该组件创建配置(在Kubernetes上，用CustomResourceDefinitions表示)， Gloo组件可用于构建通过xDS表示的规范Envoy配置。 我们将在本系列博客的后续部分中看到更多内容。
• Gateway –该组件允许用户使用更舒适的对象模型根据其角色(例如，边缘网关，共享代理，本地群集入口等)配置Envoy代理。 控制平面的这一部分还生成配置， Gloo控制平面可用于通过xDS生成Envoy配置

如您所见，这些基本组件被部署为可协同工作的服务，以构建通过xDS服务的适当的Envoy配置。 Gloo通过使用这些松散协调的控制平面组件来实现Envoy配置，从而实现了其强大的发现功能，对功能的语义理解等。 当将Gloo部署到Kubernetes中时，存储和配置表示具有“ kube-native”的感觉：一切都由Custom Resource Definitions表示。 具体来说，所有面向用户的配置都是CRD以及驱动xDS端点的核心配置。 您可以只使用Kubernetes API和kubectl与Gloo进行交互。 但是，我们还提供了一个glooctl CLI工具来简化与Gloo控制平面的交互-特别是这样，如果您不想这么做，就不必大惊小怪。 这样，Gloo非常专注于开发人员的经验，并且对开发人员(或任何人？)进行YAML攻击非常繁琐。

Istio还采用了类似的方法，即使用通过Kubernetes CRD配置的松散协调控制平面组件。 Istio的控制平面由以下组成：

• Istio Pilot –核心xDS服务
• Istio Galley –配置/存储抽象
• Istio Citadel – CA /证书引擎
• Istio Telemetry –遥测信号接收器
• Istio Policy –可插拔策略引擎

Heptio Contour实际上只有两个组成其控制平面的组件，但是，由于它仅基于Kubernetes，因此它实际上利用了许多内置的Kubernetes设施，例如Kubernetes API /存储和CRD来驱动配置。

• contour服务器
• init-container引导程序

Contour使用init-container为Envoy生成一个静态引导程序配置文件，该文件指示在何处可以找到xDS服务。 xDS服务器是控制平面中的第二个组件，默认情况下与数据平面一起部署，并带有单独部署的选项。 在本系列“部署控制面板组件”的第5部分中，我们将探讨这种架构及其权衡。

带走

确定控制平面所需的核心组件。 不要尝试构建单一的整体式控制平面抽象，因为这将成为维护和更新的噩梦。 在松散耦合的体系结构中为控制平面构建所需的组件。 如果可以在Kubernetes之上构建，则可以这样做： Kubernetes为操作分布式系统(例如Envoy控制平面)提供了非常强大的集成数据平面。 如果您确实在Kubernetes上构建了控制平面，则应利用自定义资源定义来驱动控制平面的配置。 有些人选择使用Ingress定义，服务注释或配置图来构建其控制平面。 在Kubernetes CRD可用之前，这些方法可能是适当的解决方法，但此时，您应避免使用这些路径并坚持使用CRD。 就像Tim Hockin(Kubernetes的创始人)在最近的播客中说的那样，驱动Ingress Gateway资源的注释是一个糟糕的选择。

该系列的下一个条目实际上已经发布： 为Envoy构建控制平面的指南第3部分-特定于域的配置API

翻译自: https://www.javacodegeeks.com/2019/03/control-plane-envoy-identify-components-2.html