這是探索為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

總結

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

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