作者：Christian Posta?

譯者：殷龍飛?

審閱：孫海洲?

原文：medium.com/solo-io/gui…

[編者案]

Envoy 作為最受歡迎的早期網絡組件，現在已經可以說是云原生架構中的通用數據平面。本文作者指引我們更方便的使用Envoy，及其定制控制平面，作者通過收集到的數據給出定制控制平面不同的意見，非常中肯，后續系列會更深入，歡迎關注該系列文章。

Envoy Proxy構建控制平面指南

Envoy 最近成為一個受歡迎的網絡組件。 幾年前 Matt Klein 寫了一篇博客 ，討論了Envoy的動態配置API，以及Envoy發展的歷史和動機。 他稱該博客為“通用數據平面API”。 由于許多其他項目采用Envoy 作為其產品的核心組件，因此對于應用程序/L7網絡解決方案而言，毫不夸張地說，“Envoy已成為云原生架構中的通用數據平面”，而不僅僅是簡單建立了API標準。

此外，由于 Envoy的通用數據平面API ，我們已經看到了許多

管理層 的實現， 用于配置和驅動基于Envoy的基礎架構。 我們將深入探討為Envoy構建控制平面所需的內容，以便您可以使用此信息來評估哪種類型的基礎架構最適合您的組織和使用情況。 因為這是一個廣泛的主題，我們將在未來幾天發布的多部系列博客中解決它。

在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 用于流量路由決策

• 集群發現服務 - 用于后端服務的 CDS ，我們可以將流量路由到該服務

• secret發現服務 - 用于分發Secret的 SDS （證書和密鑰）

API使用 proto3 Protocol Buffers 定義， 甚至還有一些參考實現可用于引導您自己的控制平面：

• go控制平面

• java的控制平面

雖然這些領域（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的選項至關重要。 其他環境可能沒有這種需求。 無論哪種方式，動態的g??RPC流API都是理想的選擇。 這種方法的一些好處：

• 事件驅動的配置更新; 當配置在控制平面中可用時，配置被推送到Envoy

• 無需輪詢更改

• 沒有必要熱加載Envoy

• 沒有中斷流量

下一步是什么

在第一部分中，我們通過介紹xDS API以及為Envoy提供動態配置的不同選項，為如何為Envoy構建控制平面建立了一些基本背景。 在接下來的部分中，將在幾天內發布，將涵蓋將您的控制平面分解為可部署組件，確定您需要哪些部分，特定于域的配置對象模型，以及如何考慮控件的可插拔性平面。 關注twitter（ @christianposta ， @ solio_in ）或博客（ medium.com/solo-io ）

總結

以上是生活随笔為你收集整理的Envoy Proxy构建控制平面指南的全部內容，希望文章能夠幫你解決所遇到的問題。

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