確定控制平面所需的組件

由于操作環境的范圍千差萬別，因此為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

總結

以上是生活随笔為你收集整理的为特使建立控制平面的指南-识别组件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。