如何構建一個控制面來管理Envoy管理集群網絡流量

如何構建一個控制面來管理Envoy管理集群網絡流量，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

指導在服務邊緣構建控制面來管理 Envoy Proxy，讓它作為服務網關或者在服務網格中使用

Envoy 已經成為了一個非常流行的網絡組件了。Matt Klein 幾年前寫過一篇博文，就在討論 Envoy 的動態配置 API 和它如何成為 Envoy 被采用越來越多的原因之一。他在博文中說這是“統一數據面板 API”（UDPA）。隨著很多其它項目都采用 Envoy 作為其核心組件，可以毫不夸張的說 Envoy 不僅僅建立了標準 API，而且對于應用 7 層的網絡解決方案來說：“Envoy 已經變成了在云原生架構下的統一數據平面”。

而且，由于 Envoy 的統一數據平面 API，我們可以看到業界開發了很多針對基于 Envoy 技術設施進行配置管理的管理系統。本文將會深入討論為 Envoy 構建一個控制平面需要什么，大家可以通過這些信息來評估什么樣的基礎設施最適合你的組織和場景。因為這個是一個很大的話題，作者會出一個系列文章來對此進行詳細說明（后面我也會挑一些我感興趣的文章進行翻譯學習）。

在 EnvoyCon/KubeCon 論壇有很多非常好的討論，這里好多組織都分享了他們采用 Envoy 的經驗，也包括了如何構建他們自己的控制平面。下面是一些他們為什么選擇自建控制平面的原因：

1. 現有的解決方案構建在不同的數據平面上，而且已經有了控制平面，需要在這里兼容 Envoy。

2. 為不包含任何開源基礎設施來構建，或者使用其它的 Envoy 控制平面（比如：VMs， AWS，ECS 等）。

3. 不需要使用所有 Envoy 的特性，只是需要一部分。

4. 為了更好適配自己的工作流和工作視圖而需要為 Envoy 配置開發專屬領域的 API 對象模型。

5. 要線上使用，但是發現其它的控制平面并不夠成熟。

然而，僅僅因為有些早期使用者構建了他們自己的控制平面，這并不意味著你也應該做這樣的事情。首先在去年中很多為 Envoy 開發的控制平面已經相當成熟了，所以你應該在決定要重新開發另外一個控制平面之前先來研究一下這些已經存在的。其次，正如 Datawire 的人們發現，并且 Daniel Bryant 最近也發文章說，為 Envoy 構建一個控制平面并不是那么容易的。

我參與開發幾個為 Enovy 構建控制平面的開源項目。比如，Gloo 是一個功能性網關，它可以作為強大的 Kubernetes 接入服務，API 網關，或者作為從單體服務到微服務過度的功能網關。Gloo 有一個針對 Envoy 的控制平面，它可以作為我這個系列文章的例子，來說明如何在控制平面上按照需求來抽象設計，以實現插件管理和擴展性管理。其它可以參考的已經實現的控制平面如 istio 和 Heptio Contour，這些也是貫穿我這個系列文章中的好例子。如果你確定要自己開發控制平面，那么除了這些，你還可以參考其它一些已經存在的控制平面。

在這個系列文章中，我們將會關注以下一些關鍵點：

1. 采用一種機制可以動態更新 Envoy 的路由，服務發現和其它配置。

2. 識別使用哪些組件來構成你的控制平面，包括了后端存儲，服務發現 API，安全組件等等。

3. 根據場景和團隊組織以最合適的方式建立任意制定區域的配置對象和 API。

4. 思考如何在需要的地方以最好方式嵌入控制平面。

5. 部署各種控制平面組件的方式。

6. 思考如何測試控制平面。

要開始這一系列的討論，我們首先來看看如何在 Envoy 運行時，使用 Envoy 的動態配置 API 來更新 Envoy，以處理拓撲和部署中的變更。

使用 Envoy 的 xDS API 動態配置 Envoy

在 Envoy 之上構建構控制平面的主要方便支持處在于它的數據平面 API。有了數據平面 API，我們可就可以動態的配置 Envoy 的大多數重要運行時設置。通過 xDS API 進行的 Envoy 配置是被設計為最終一致性的，沒有一種方法可以對集群中的所有代理進行原子性的更新。當控制平面上有配置更新時，它就通過 xDS API 讓數據平面代理都可以獲取到，每個代理都是相互獨立的來獲取應用這些配置。

下面是我們可以通過 xDS 動態配置 Envoy 的部分運行時模型：

1. 監聽發現服務（LDS）API - LDS 用于下發服務監聽的端口。

2. 終端發現服務（EDS）API- EDS 用戶服務發現。

3. 路由發現服務（RDS）API- RDS 用于流量路由決策。

4. 集群發現服務（CDS）- CDS 用于可以路由流量過去的后端服務。

5. 密鑰發現服務（SDS） - SDS 用戶分發密鑰（證書和密鑰）。

這些 API 使用 proto3 的 Protocol Buffer 來定義的，并且已經有一些相關實現了，可以提供大家在構建自己的控制平面時參考：

1. go-control-plane

2. java-control-plane

雖然每個 xDS（LDS/EDS/RDS/CDS/SDS，這些統稱xDS）都是可以動態可配置的，但是這并不意味著你必須動態配置所有內容。你可以組合適應，區分靜態配置和動態配置。例如，要通過配置實現一種類型的服務發現：希望終端是動態的，但是集群在部署的時候就是已經知道路由信息了，所以你可以使用 Envoy 中的 Endpoint Discovery Service 來靜態的定義集群的配置。如果在部署的時候你不確定是那個上游集群，那你可以使用Cluster Discovery Service來動態的配置發現上游。關鍵是你可以構建一個工作流和處理流程來靜態的配置你需要的部分，而且可以使用動態 xDS 服務在運行時發現你需要的部分。為什么有不同的控制平面實現，其中一個原因就是并不是所有人都有一個完全動態和可替代的環境（這個環境下所有的配置都應該是動態的），這點幾乎不可能。根據現有條件的約束和可用工作流，要為你的系統采取合適級別的動態配置，而不是全動態配置。

在 Gloo 的實現中，我們基于 go-control-plane 的實現來構建控制平面，實現了 xDS API 到 Envoy 的動態配置。Istio 和 Heptio Contour 也是使用這種方式。這個控制平面的 API 使用 gRPC streaming 實現，并且留了實現接口，所以我們在實現的時候只需要實現這些接口就可以了。這種方式可以以非常高效的方式把 Envoy 數據平面 API 集成到控制平面中。

gRPC streaming 方式并不是唯一的更新 Envoy 配置的方法。在Envoy 早期版本中的 xDS API，輪詢是唯一檢測是否有新配置可用的方式。雖然這也是接受的，并且也符合配置更新最終一致性的原則，但是在網絡和計算使用上還是不夠高效。也比較困難去調整優化輪詢配置以減少資源浪費。

最后，一些 Envoy 管理系統的實現采取生成靜態 Envoy 配置文件和給 Envoy 周期性的覆蓋寫入磁盤上的配置文件，再執行Envoy 進程的熱重啟。在高度動態環境中（像 Kubernetes，實際上任何短暫的計算平臺都算），管理這種文件的生成，傳遞，熱重啟等等會顯得非常笨重。Envoy 最初就是在這樣操作的（Lyft公司創建這個項目是就是這樣），但是它逐步發展到現在的 xDS API了。

使用 gRPC streaming 和 xDS API 來實現對 Envoy 的動態配置和控制是一種比較好的方式。同樣，并不是所有的 Envoy 配置都應該是動態的，尤其是你不需要動態配置的內容。但是如果你是在一個高度動態的環境（比如在 Kubernetes 中），動態配置 Envoy 就很關鍵了。其它的環境或許也有這樣的需要。不管怎么樣，動態配置使用 gRPC streaming API 是最理想的，主要有以下一些好處：

1. 事件驅動配置更新；在控制平面中配置會在可用的時候下發到 Envoy。

2. 不需要輪詢配置變化了。

3. 不需要熱重啟 Envoy。

4. 不會中斷流量。

關于如何構建一個控制面來管理Envoy管理集群網絡流量問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。