envoy api 網關

最近， Envoy已成為流行的網絡組件。 馬特·克萊因（ Matt Klein ）在幾年前寫了一個博客，內容涉及Envoy的動態配置API，以及它如何成為Envoy的采用曲線向右移的部分原因。 他稱該博客為“通用數據平面API”。 由于有許多其他項目采用Envoy作為其產品的核心組件，因此可以說“ Envoy已成為應用程序/ L7網絡解決方案的云原生體系結構中的通用數據平面”，而不僅僅是建立標準化的API 。

此外，由于Envoy的通用數據平面API ，我們已經看到了許多管理層的實現，用于配置和驅動基于Envoy的基礎架構。 我們將深入研究為Envoy構建控制平面所需的內容，以便您可以使用此信息來評估哪種類型的基礎架構最適合您的組織和用例。 因為這是一個廣泛的主題，所以我們將在接下來的幾天中分多個部分討論這個問題。 跟隨（ @christianposta ， @soloio_inc ）進入下一個條目。

在EnvoyCon / KubeCon上進行了一些精彩的演講 ，一些組織分享了采用Envoy的經驗，包括他們如何構建自己的控制飛機。 人們選擇構建自己的控制平面的一些原因：

• 是否具有基于具有預先存在的控制平面的不同數據平面的現有解決方案，并且需要對Envoy進行改造
• 為不具有任何現有開源或其他Envoy控制平面（即VM，AWS ECS等）的基礎架構進行構建
• 不需要使用Envoy的所有功能； 只是一個子集
• 首選針對Envoy配置的特定于域的API /對象模型，以使其更適合其工作流程/ worldview
• 其他控制飛機在各自組織準備部署時還沒有處于成熟狀態

但是，僅僅因為某些早期采用者構建了自己的定制控制平面并不意味著您現在應該做同樣的事情。 首先，為Envoy構建控制平面的項目在去年已經相當成熟，在決定重新創建另一個控制平面之前，您應該探索使用這些平面的方法。 其次，正如Datawire的人們發現的那樣， Daniel Bryant最近也明確指出， 為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，用于我們可以將流量路由到的后端服務
• 秘密發現服務–用于分發秘密（證書和密鑰）的SDS

該API是使用proto3協議緩沖區定義的，甚至還有一些參考實現，您可以用來引導自己的控制平面：

• 去控制平面
• Java控制平面

盡管每個區域（LDS / EDS / RDS / CDS / SDS，統稱為“ xDS”）都是可動態配置的，但這并不意味著您必須動態配置所有內容。 您可以將靜態定義的部分與動態更新的部分組合在一起。 例如，要實現一種服務發現類型，其中endpoints應該是動態的，但是clusters在部署時是眾所周知的，則可以靜態定義clusters并使用Envoy的Endpoint Discovery Service 。 如果不確定在部署時將使用哪些上游群集，則可以使用“ 群集發現服務”動態查找這些群集 。 關鍵是，您可以構建一個工作流和流程，以靜態配置所需的零件，同時使用動態xDS服務在運行時發現所需的零件。 之所以看到不同的控制面板實現，原因之一不是每個人都擁有一個完全動態且可替代的環境，其中所有部分都應該是動態的。 在存在現有限制和可用工作流程的情況下，采用最適合您的系統的動態級別。

對于Gloo，我們使用基于go-control-plane的控制平面來實現xDS API，以服務于Envoy的動態配置。 Istio以及Heptio Contour也使用此實現。 該控制平面API利用gRPC流調用并將該API存根，因此您可以使用實現來填充它。 Turbine Labs的Rotor項目 ，是另一個不幸地不推薦使用但可以學到很多東西的項目 。 這是將Envoy的數據平面API與控制平面集成的一種高效方法。

gRPC流不是更新Envoy配置的唯一方法。 在早期版本的Envoy xDS API中 ，輪詢是確定新配置是否可用的唯一選項。 盡管這是可以接受的，并且滿足“最終一致”的配置更新標準，但是在網絡和計算使用方面效率較低。 適當調整輪詢配置以減少浪費的資源也可能很困難。

最后，某些Envoy管理實現選擇生成靜態Envoy配置文件并定期為Envoy替換磁盤上的配置文件，然后對Envoy進程進行熱重載 。 在高度動態的環境（例如Kubernetes，但實際上是任何基于臨時計算的平臺）中，此文件生成，傳遞，熱重啟等的管理可能會變得笨拙。 Envoy最初是在執行這樣的更新的環境中創建的（Lyft，創建它的地方），但是它們正逐步使用xDS API。

帶走

Gloo小組認為，使用gRPC流和xDS API是為Envoy實施動態配置和控制的理想方法。 同樣，如果不需要，并非所有Envoy配置都應動態提供，但是，如果您在高度動態的環境（例如Kubernetes）中運行，則動態配置Envoy的選項至關重要。 其他環境可能沒有此需求。 無論哪種方式，用于動態部件的g??RPC流API都是理想的。 這種方法的一些好處：

• 事件驅動的配置更新； 當配置在控制平面中可用時，將配置推送給Envoy
• 無需輪詢更改
• 無需熱裝特使
• 沒有交通中斷

下一步是什么

在第一部分中，我們通過介紹xDS API和為Envoy提供動態配置所需的其他選項，建立了有關如何為Envoy構建控制平面的一些基本上下文。 在接下來的幾天（將在幾天內發布）中，將介紹如何將控制平面分解為可部署的組件，確定所需的組件，特定于域的配置對象模型的外觀以及如何考慮控件的可插入性。飛機。 在Twitter（ @christianposta ， @soloio_inc ）或博客（ https://blog.christianposta.com https://medium.com/solo-io ）上關注

翻譯自: https://www.javacodegeeks.com/2019/02/control-plane-manage-envoy-proxy-edge.html

envoy api 網關

總結

以上是生活随笔為你收集整理的envoy api 网关_在边缘，作为网关或在网格中构建控制平面以管理Envoy代理的指南...的全部內容，希望文章能夠幫你解決所遇到的問題。

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