如何構(gòu)建一個控制面來管理Envoy管理集群網(wǎng)絡(luò)流量

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

指導(dǎo)在服務(wù)邊緣構(gòu)建控制面來管理 Envoy Proxy，讓它作為服務(wù)網(wǎng)關(guān)或者在服務(wù)網(wǎng)格中使用

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

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

在 EnvoyCon/KubeCon 論壇有很多非常好的討論，這里好多組織都分享了他們采用 Envoy 的經(jīng)驗，也包括了如何構(gòu)建他們自己的控制平面。下面是一些他們?yōu)槭裁催x擇自建控制平面的原因：

1. 現(xiàn)有的解決方案構(gòu)建在不同的數(shù)據(jù)平面上，而且已經(jīng)有了控制平面，需要在這里兼容 Envoy。

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

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

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

5. 要線上使用，但是發(fā)現(xiàn)其它的控制平面并不夠成熟。

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

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

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

1. 采用一種機(jī)制可以動態(tài)更新 Envoy 的路由，服務(wù)發(fā)現(xiàn)和其它配置。

2. 識別使用哪些組件來構(gòu)成你的控制平面，包括了后端存儲，服務(wù)發(fā)現(xiàn) API，安全組件等等。

3. 根據(jù)場景和團(tuán)隊組織以最合適的方式建立任意制定區(qū)域的配置對象和 API。

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

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

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

要開始這一系列的討論，我們首先來看看如何在 Envoy 運行時，使用 Envoy 的動態(tài)配置 API 來更新 Envoy，以處理拓?fù)浜筒渴鹬械淖兏?/p>

使用 Envoy 的 xDS API 動態(tài)配置 Envoy

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

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

1. 監(jiān)聽發(fā)現(xiàn)服務(wù)（LDS）API - LDS 用于下發(fā)服務(wù)監(jiān)聽的端口。

2. 終端發(fā)現(xiàn)服務(wù)（EDS）API- EDS 用戶服務(wù)發(fā)現(xiàn)。

3. 路由發(fā)現(xiàn)服務(wù)（RDS）API- RDS 用于流量路由決策。

4. 集群發(fā)現(xiàn)服務(wù)（CDS）- CDS 用于可以路由流量過去的后端服務(wù)。

5. 密鑰發(fā)現(xiàn)服務(wù)（SDS） - SDS 用戶分發(fā)密鑰（證書和密鑰）。

這些 API 使用 proto3 的 Protocol Buffer 來定義的，并且已經(jīng)有一些相關(guān)實現(xiàn)了，可以提供大家在構(gòu)建自己的控制平面時參考：

1. go-control-plane

2. java-control-plane

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

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

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

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

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

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

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

3. 不需要熱重啟 Envoy。

4. 不會中斷流量。

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