确定控制平面所需的组件

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

• 模板引擎
• 数据存储/ VCS
• 每服务配置
• 协调器将碎片拼凑在一起
• 将这些交付给Envoy并热重启的方法

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

• 核心xDS服务
• 发现注册表+您需要的任何集成
• 描述您的Envoy配置的抽象对象模型

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

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

通常，您将需要考虑构建控制平面，以便组件独立运行并可以松散协作以提供控制平面的需求。 例如，在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 –可插拔策略引擎

带走

确定控制平面所需的核心组件。 不要尝试构建单一的整体式控制平面抽象，因为这将成为维护和更新的噩梦。 在松耦合架构中构建控制平面所需的组件。 如果您可以在Kubernetes之上构建，请这样做： Kubernetes为运行分布式系统（例如Envoy控制平面） 提供了非常强大的集成数据平面。 如果您确实在Kubernetes上构建了控制平面，则应该利用自定义资源定义来驱动控制平面的配置。 一些人选择使用Ingress定义 ， 服务注释或配置图来构建其控制平面。 在Kubernetes CRD可用之前，这些可能是适当的解决方法，但此时您应该避免使用这些路径并坚持使用CRD。

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