作者：Christian Posta
譯者：殷龍飛
審閱：孫海洲
[編者案]
Envoy 作為最受歡迎的早期網路元件，現在已經可以說是雲原生架構中的通用資料平面。本文作者指引我們更方便的使用Envoy，及其定製控制平面，作者通過收集到的資料給出定製控制平面不同的意見，非常中肯，後續系列會更深入，歡迎關注該系列文章。
Envoy Proxy構建控制平面指南
Envoy 最近成為一個受歡迎的網路元件。 幾年前 Matt Klein 寫了一篇部落格 ，討論了Envoy的動態配置API，以及Envoy發展的歷史和動機。 他稱該部落格為“通用資料平面API”。 由於許多其他專案採用Envoy 作為其產品的核心元件，因此對於應用程式/L7網路解決方案而言，毫不誇張地說，“Envoy已成為雲原生架構中的通用資料平面”，而不僅僅是簡單建立了API標準。
此外，由於 Envoy的通用資料平面API ，我們已經看到了許多
在EnvoyCon/KubeCon上 有一些 精彩的演講 ，一些組織分享了他們採用Envoy的經驗，包括他們如何構建自己的控制平面。 人們選擇自己建立控制平面的一些原因：
現有的解決方案，建立在已有不同資料平面的控制平面，需要改造Envoy（與已有方案且衝突）
為沒有任何現有開源或其他Envoy控制平面（即VM，AWS ECS等）的基礎架構構建（商業公司必須重新建方案）
不需要使用Envoy的所有功能; 只是一個子集（功能太多，需要精簡）
首選適用於Envoy配置的特定於域的API/物件模型，以更好地適應其工作流程/世界觀（與已有方案衝突）
當其組織準備部署時，暫時沒有成熟的控制平面（走的太快）
若是因為一些早期採用者建立了他們自己的定製控制平面，並不意味著你現在也要自己重新開發控制平面。 因為Envoy構建控制平面的專案在去年已經成熟了很多，若你決定重新開發另一個控制平面前你應該探索使用它們。 其次，正如Datawire的人們發現的那樣，丹尼爾·布萊恩特 最近明確表示， 為Envoy建造一個控制平面並不適合膽小的人 。
我參與 了 幾個為Envoy構建控制平面的開源專案 。 例如， Gloo 是 一個功能閘道器 ，可以充當非常強大的Kubernetes入口，API閘道器或功能閘道器，以簡化單體應用到微服務的過渡。 Gloo 有一個Envoy的控制平面 ，我們可以在這一系列的帖子中作為一個例子來說明如何構建一個簡單的抽象，允許在你需要的控制點上實現可插拔性和可擴充套件性。 您可以用作參考的其他可靠的控制平面實現是 Istio 和 Heptio Contour 我們將在整個系列部落格中使用這些作為很好的例子。 如果不出意外，您可以瞭解Envoy控制平面存在哪些選項，並使用它來指導您的實施，如果您必須走這條路。
在這個部落格系列中，我們將看看以下幾個方面：
採用動態更新機制的Envoy路由、服務發現和其他配置
確定構成控制平面的元件，包括後端儲存、服務發現API、安全元件等。
為您和組織最適合的用例，建立任何特定於域的配置物件和API
考慮如何最好地將控制平面插入您需要的地方
部署各種控制平面元件的選項
通過控制平面的測試工具進行思考
為了開始這個系列，我們來看看使用Envoy的動態配置API在執行時更新Envoy以處理拓撲和部署的變化。
使用xDS API動態配置Envoy
構建在Envoy之上的主要優勢之一是它的資料平面API。 使用資料平面API，我們可以 動態配置Envoy的大部分重要執行時設定 。 Envoy通過其xDS API的配置 最終一致的 - 即無法影響叢集中所有代理的“原子更新”。 當控制平面具有配置更新時，它通過xDS API使它們可用於資料平面代理，並且每個代理將彼此獨立地應用這些更新。
以下是我們可以通過xDS動態配置的Envoy執行時模型的部分：
監聽器發現服務API - 用於釋出監聽流量的埠的 LDS
端點發現服務API- 用於服務發現的 EDS ，
路由發現服務API-RDS 用於流量路由決策
secret發現服務 - 用於分發Secret的 SDS （證照和金鑰）
API使用 proto3 Protocol Buffers 定義， 甚至還有一些參考實現可用於引導您自己的控制平面：
雖然這些領域（LDS/EDS/RDS/CDS/SDS，一起“xDS”）中的每一個都是動態可配置的，但這並不意味著您必須動態配置所有內容。 您可以擁有靜態定義的部分組合以及動態更新的部分組合。 例如，要實現一種 endpoints 預期為動態但 clusters 在部署時眾所周知 的服務發現型別 ，您可以靜態定義 clusters 並使用 Envoy中 的 端點發現服務 。 如果您不確定在部署時將使用哪些 上游群集， 則可以使用 群集發現服務 動態地找到那些。 關鍵是，您可以構建一個工作流程和流程，靜態配置您需要的部分，同時使用動態xDS服務來發現執行時所需的部分。 您看到不同的控制平面實現的原因之一併不是每個人都有一個完全動態和可互換的環境，其中所有部分都應該是動態的。 在給定現有約束和可用工作流程的情況下，採用最適合您系統的動態級別。
在Gloo的情況下，我們使用基於go-control-plane的控制平面 來實現xDS API以服務Envoy的動態配置。 與Heptio Contour一樣，Istio也使用此實現。 此控制平面API利用 gRPC流 呼叫和存根API，因此您可以使用實現填充它。 Turbine Labs’ Rotor專案 是另一個不幸被棄用但可以用來學習的專案 。 這是將Envoy的資料平面API與控制平面整合的高效方法。
gRPC流不是更新Envoy配置的唯一方式。 在以前版本的Envoy xDS API中 ，輪詢是確定新配置是否可用的唯一選項。 雖然這是可以接受的，並且符合“最終一致”配置更新的標準，但它在網路和計算使用方面效率都較低。 也可能難以適當地調整輪詢配置以減少浪費的資源。
最後，一些Envoy管理實施選擇生成 靜態Envoy配置檔案， 並定期替換Envoy磁碟上的配置檔案，然後執行 Envoy程式 的 熱重新載入 。 在高度動態的環境中（如Kubernetes，但實際上是任何基於ephemeral-compute的平臺），此檔案生成，交付，熱重啟等的管理可能變得難以處理。 Envoy最初是在一個執行此類更新的環境中執行的（Lyft，它是在哪裡建立的），但它們逐漸轉向使用xDS API。
Takeaway
Gloo團隊 認為使用gRPC流和xDS API是實現Envoy動態配置和控制的理想方式。 同樣，如果您不需要，並非所有Envoy配置都應動態提供，但是如果您在高度動態的環境中執行（例如，Kubernetes），則動態配置Envoy的選項至關重要。 其他環境可能沒有這種需求。 無論哪種方式，動態的gRPC流API都是理想的選擇。 這種方法的一些好處：
事件驅動的配置更新; 當配置在控制平面中可用時，配置被推送到Envoy
無需輪詢更改
沒有必要熱載入Envoy
沒有中斷流量
下一步是什麼
在第一部分中，我們通過介紹xDS API以及為Envoy提供動態配置的不同選項，為如何為Envoy構建控制平面建立了一些基本背景。 在接下來的部分中，將在幾天內釋出，將涵蓋將您的控制平面分解為可部署元件，確定您需要哪些部分，特定於域的配置物件模型，以及如何考慮控制元件的可插拔性平面。 關注twitter（ @christianposta ， @ solio_in ）或部落格（ medium.com/solo-io ）