确定控制平面所需的组件
由于操作环境的范围千差万别,因此为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