网站与网页设计教程,购物网站建设app开发,花钱人做的网站做好后算谁的,企业网站建设网站有哪些这是探索为Envoy Proxy构建控制平面的系列文章的第2部分。 在本博客系列中#xff0c;我们将研究以下领域#xff1a; 采用一种机制来动态更新Envoy的路由#xff0c;服务发现和其他配置 确定哪些组件构成了控制平面#xff0c;包括后备存储#xff0c;服务发现API我们将研究以下领域 采用一种机制来动态更新Envoy的路由服务发现和其他配置 确定哪些组件构成了控制平面包括后备存储服务发现API安全组件等。 等 此条目 建立最适合您的用例和组织的任何特定于域的配置对象和API 考虑如何最好地使控制平面可在需要的地方插入 部署各种控制平面组件的选项 通过测试平面来考虑您的控制飞机 在本系列的上一篇文章中我们探索了动态配置Envoy的过程这是在云原生环境中运行Envoy的重要组成部分。 在本条目中我们将研究支持控制平面可能需要的协作组件。 确定控制平面所需的组件 由于操作环境的范围千差万别因此为Envoy实施控制平面所需的组件也可能如此。 例如在一种极端情况下如果您在构建时静态生成了Envoy文件并将其发送到Envoy则可能需要以下组件 模板引擎 数据存储/ VCS用于进入模板的值 可能/可能不与服务/应用程序一起存储的任何特定于服务的配置 协调器将碎片拼凑在一起 将这些交付给特使的方法 一种触发配置文件的重新加载/热重启的方法 另一方面如果您选择使用gRPC流xDS实现则需要 核心xDS服务接口和实现 用于将服务注册/注销服务到服务注册表的组件 服务注册表 描述Envoy配置的抽象对象模型可选 数据存储区用于保存配置 您最可能需要支持Envoy的其他辅助组件 证书/ CA商店 统计收集引擎 分布式跟踪后端/引擎 外部认证 限速服务 通常您将需要考虑构建控制平面以便组件独立运行并可以松散协作以提供控制平面的需求。 您要做的最后一件事是通过部署整体控制平面来支持Envoy进行微服务部署。 例如在开源Gloo项目中我们具有驱动控制平面的以下组件 Gloo –一个事件驱动的组件负责为核心xDS服务生成配置并为其提供服务以及自定义Envoy过滤器的配置 Discovery –一个可选组件它知道如何与服务发现服务领事Kubernetes等一起使用以发现并发布上游集群和端点。 它还可以发现REST终结点使用swaggergRPC函数基于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 HockinKubernetes的创始人在最近的播客中说的那样 用于驱动Ingress Gateway资源的注释是一个糟糕的选择。 该系列的下一个条目实际上已经发布 为Envoy构建控制平面的指南第3部分-特定于域的配置API 翻译自: https://www.javacodegeeks.com/2019/03/control-plane-envoy-identify-components-2.html
