这是探索为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