共計(jì) 3224 個(gè)字符，預(yù)計(jì)需要花費(fèi) 9 分鐘才能閱讀完成。
如何構(gòu)建一個(gè)控制面來管理 Envoy 管理集群網(wǎng)絡(luò)流量，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
指導(dǎo)在服務(wù)邊緣構(gòu)建控制面來管理 Envoy Proxy，讓它作為服務(wù)網(wǎng)關(guān)或者在服務(wù)網(wǎng)格中使用
Envoy 已經(jīng)成為了一個(gè)非常流行的網(wǎng)絡(luò)組件了。Matt Klein 幾年前寫過一篇博文，就在討論 Envoy 的動(dòng)態(tài)配置 API 和它如何成為 Envoy 被采用越來越多的原因之一。他在博文中說這是“統(tǒng)一數(shù)據(jù)面板 API”（UDPA）。隨著很多其它項(xiàng)目都采用 Envoy 作為其核心組件，可以毫不夸張的說 Envoy 不僅僅建立了標(biāo)準(zhǔn) API，而且對(duì)于應(yīng)用 7 層的網(wǎng)絡(luò)解決方案來說：“Envoy 已經(jīng)變成了在云原生架構(gòu)下的統(tǒng)一數(shù)據(jù)平面”。
而且，由于 Envoy 的統(tǒng)一數(shù)據(jù)平面 API，我們可以看到業(yè)界開發(fā)了很多針對(duì)基于 Envoy 技術(shù)設(shè)施進(jìn)行配置管理的管理系統(tǒng)。本文將會(huì)深入討論為 Envoy 構(gòu)建一個(gè)控制平面需要什么，大家可以通過這些信息來評(píng)估什么樣的基礎(chǔ)設(shè)施最適合你的組織和場景。因?yàn)檫@個(gè)是一個(gè)很大的話題，作者會(huì)出一個(gè)系列文章來對(duì)此進(jìn)行詳細(xì)說明（后面我也會(huì)挑一些我感興趣的文章進(jìn)行翻譯學(xué)習(xí)）。
在 EnvoyCon/KubeCon 論壇有很多非常好的討論，這里好多組織都分享了他們采用 Envoy 的經(jīng)驗(yàn)，也包括了如何構(gòu)建他們自己的控制平面。下面是一些他們?yōu)槭裁催x擇自建控制平面的原因：
現(xiàn)有的解決方案構(gòu)建在不同的數(shù)據(jù)平面上，而且已經(jīng)有了控制平面，需要在這里兼容 Envoy。
為不包含任何開源基礎(chǔ)設(shè)施來構(gòu)建，或者使用其它的 Envoy 控制平面（比如：VMs，AWS，ECS 等）。
不需要使用所有 Envoy 的特性，只是需要一部分。
為了更好適配自己的工作流和工作視圖而需要為 Envoy 配置開發(fā)專屬領(lǐng)域的 API 對(duì)象模型。
要線上使用，但是發(fā)現(xiàn)其它的控制平面并不夠成熟。
然而，僅僅因?yàn)橛行┰缙谑褂谜邩?gòu)建了他們自己的控制平面，這并不意味著你也應(yīng)該做這樣的事情。首先在去年中很多為 Envoy 開發(fā)的控制平面已經(jīng)相當(dāng)成熟了，所以你應(yīng)該在決定要重新開發(fā)另外一個(gè)控制平面之前先來研究一下這些已經(jīng)存在的。其次，正如 Datawire 的人們發(fā)現(xiàn)，并且 Daniel Bryant 最近也發(fā)文章說，為 Envoy 構(gòu)建一個(gè)控制平面并不是那么容易的。
我參與開發(fā)幾個(gè)為 Enovy 構(gòu)建控制平面的開源項(xiàng)目。比如，Gloo 是一個(gè)功能性網(wǎng)關(guān)，它可以作為強(qiáng)大的 Kubernetes 接入服務(wù)，API 網(wǎng)關(guān)，或者作為從單體服務(wù)到微服務(wù)過度的功能網(wǎng)關(guān)。Gloo 有一個(gè)針對(duì) Envoy 的控制平面，它可以作為我這個(gè)系列文章的例子，來說明如何在控制平面上按照需求來抽象設(shè)計(jì)，以實(shí)現(xiàn)插件管理和擴(kuò)展性管理。其它可以參考的已經(jīng)實(shí)現(xiàn)的控制平面如 istio 和 Heptio Contour，這些也是貫穿我這個(gè)系列文章中的好例子。如果你確定要自己開發(fā)控制平面，那么除了這些，你還可以參考其它一些已經(jīng)存在的控制平面。
在這個(gè)系列文章中，我們將會(huì)關(guān)注以下一些關(guān)鍵點(diǎn)：
采用一種機(jī)制可以動(dòng)態(tài)更新 Envoy 的路由，服務(wù)發(fā)現(xiàn)和其它配置。
識(shí)別使用哪些組件來構(gòu)成你的控制平面，包括了后端存儲(chǔ)，服務(wù)發(fā)現(xiàn) API，安全組件等等。
根據(jù)場景和團(tuán)隊(duì)組織以最合適的方式建立任意制定區(qū)域的配置對(duì)象和 API。
思考如何在需要的地方以最好方式嵌入控制平面。
部署各種控制平面組件的方式。
思考如何測試控制平面。
要開始這一系列的討論，我們首先來看看如何在 Envoy 運(yùn)行時(shí)，使用 Envoy 的動(dòng)態(tài)配置 API 來更新 Envoy，以處理拓?fù)浜筒渴鹬械淖兏?/p>
使用 Envoy 的 xDS API 動(dòng)態(tài)配置 Envoy
在 Envoy 之上構(gòu)建構(gòu)控制平面的主要方便支持處在于它的數(shù)據(jù)平面 API。有了數(shù)據(jù)平面 API，我們可就可以動(dòng)態(tài)的配置 Envoy 的大多數(shù)重要運(yùn)行時(shí)設(shè)置。通過 xDS API 進(jìn)行的 Envoy 配置是被設(shè)計(jì)為最終一致性的，沒有一種方法可以對(duì)集群中的所有代理進(jìn)行原子性的更新。當(dāng)控制平面上有配置更新時(shí)，它就通過 xDS API 讓數(shù)據(jù)平面代理都可以獲取到，每個(gè)代理都是相互獨(dú)立的來獲取應(yīng)用這些配置。
下面是我們可以通過 xDS 動(dòng)態(tài)配置 Envoy 的部分運(yùn)行時(shí)模型：
監(jiān)聽發(fā)現(xiàn)服務(wù)（LDS）API – LDS 用于下發(fā)服務(wù)監(jiān)聽的端口。
終端發(fā)現(xiàn)服務(wù)（EDS）API- EDS 用戶服務(wù)發(fā)現(xiàn)。
路由發(fā)現(xiàn)服務(wù)（RDS）API- RDS 用于流量路由決策。
集群發(fā)現(xiàn)服務(wù)（CDS）- CDS 用于可以路由流量過去的后端服務(wù)。
密鑰發(fā)現(xiàn)服務(wù)（SDS） – SDS 用戶分發(fā)密鑰（證書和密鑰）。
這些 API 使用 proto3 的 Protocol Buffer 來定義的，并且已經(jīng)有一些相關(guān)實(shí)現(xiàn)了，可以提供大家在構(gòu)建自己的控制平面時(shí)參考：
go-control-plane
java-control-plane
雖然每個(gè) xDS（LDS/EDS/RDS/CDS/SDS，這些統(tǒng)稱 xDS）都是可以動(dòng)態(tài)可配置的，但是這并不意味著你必須動(dòng)態(tài)配置所有內(nèi)容。你可以組合適應(yīng)，區(qū)分靜態(tài)配置和動(dòng)態(tài)配置。例如，要通過配置實(shí)現(xiàn)一種類型的服務(wù)發(fā)現(xiàn)：希望終端是動(dòng)態(tài)的，但是集群在部署的時(shí)候就是已經(jīng)知道路由信息了，所以你可以使用 Envoy 中的 Endpoint Discovery Service 來靜態(tài)的定義集群的配置。如果在部署的時(shí)候你不確定是那個(gè)上游集群，那你可以使用 Cluster Discovery Service 來動(dòng)態(tài)的配置發(fā)現(xiàn)上游。關(guān)鍵是你可以構(gòu)建一個(gè)工作流和處理流程來靜態(tài)的配置你需要的部分，而且可以使用動(dòng)態(tài) xDS 服務(wù)在運(yùn)行時(shí)發(fā)現(xiàn)你需要的部分。為什么有不同的控制平面實(shí)現(xiàn)，其中一個(gè)原因就是并不是所有人都有一個(gè)完全動(dòng)態(tài)和可替代的環(huán)境（這個(gè)環(huán)境下所有的配置都應(yīng)該是動(dòng)態(tài)的），這點(diǎn)幾乎不可能。根據(jù)現(xiàn)有條件的約束和可用工作流，要為你的系統(tǒng)采取合適級(jí)別的動(dòng)態(tài)配置，而不是全動(dòng)態(tài)配置。
在 Gloo 的實(shí)現(xiàn)中，我們基于 go-control-plane 的實(shí)現(xiàn)來構(gòu)建控制平面，實(shí)現(xiàn)了 xDS API 到 Envoy 的動(dòng)態(tài)配置。Istio 和 Heptio Contour 也是使用這種方式。這個(gè)控制平面的 API 使用 gRPC streaming 實(shí)現(xiàn)，并且留了實(shí)現(xiàn)接口，所以我們在實(shí)現(xiàn)的時(shí)候只需要實(shí)現(xiàn)這些接口就可以了。這種方式可以以非常高效的方式把 Envoy 數(shù)據(jù)平面 API 集成到控制平面中。
gRPC streaming 方式并不是唯一的更新 Envoy 配置的方法。在 Envoy 早期版本中的 xDS API，輪詢是唯一檢測是否有新配置可用的方式。雖然這也是接受的，并且也符合配置更新最終一致性的原則，但是在網(wǎng)絡(luò)和計(jì)算使用上還是不夠高效。也比較困難去調(diào)整優(yōu)化輪詢配置以減少資源浪費(fèi)。
最后，一些 Envoy 管理系統(tǒng)的實(shí)現(xiàn)采取生成靜態(tài) Envoy 配置文件和給 Envoy 周期性的覆蓋寫入磁盤上的配置文件，再執(zhí)行 Envoy 進(jìn)程的熱重啟。在高度動(dòng)態(tài)環(huán)境中（像 Kubernetes，實(shí)際上任何短暫的計(jì)算平臺(tái)都算），管理這種文件的生成，傳遞，熱重啟等等會(huì)顯得非常笨重。Envoy 最初就是在這樣操作的（Lyft 公司創(chuàng)建這個(gè)項(xiàng)目是就是這樣），但是它逐步發(fā)展到現(xiàn)在的 xDS API 了。
使用 gRPC streaming 和 xDS API 來實(shí)現(xiàn)對(duì) Envoy 的動(dòng)態(tài)配置和控制是一種比較好的方式。同樣，并不是所有的 Envoy 配置都應(yīng)該是動(dòng)態(tài)的，尤其是你不需要?jiǎng)討B(tài)配置的內(nèi)容。但是如果你是在一個(gè)高度動(dòng)態(tài)的環(huán)境（比如在 Kubernetes 中），動(dòng)態(tài)配置 Envoy 就很關(guān)鍵了。其它的環(huán)境或許也有這樣的需要。不管怎么樣，動(dòng)態(tài)配置使用 gRPC streaming API 是最理想的，主要有以下一些好處：
事件驅(qū)動(dòng)配置更新；在控制平面中配置會(huì)在可用的時(shí)候下發(fā)到 Envoy。
不需要輪詢配置變化了。
不需要熱重啟 Envoy。
不會(huì)中斷流量。
關(guān)于如何構(gòu)建一個(gè)控制面來管理 Envoy 管理集群網(wǎng)絡(luò)流量問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注丸趣 TV 行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
