這是探索為Envoy Proxy構建控制平面的系列文章的第3部分。

在本博客系列中，我們將研究以下領域：

• 采用一種機制來動態更新Envoy的路由，服務發現和其他配置
• 確定哪些組件構成了控制平面，包括后備存儲，服務發現API，安全組件等。 等
• 建立最適合您的用例和組織的任何特定于域的配置對象和API （此條目）
• 考慮如何最好地使控制平面可在需要的地方插入
• 部署各種控制平面組件的選項
• 通過測試平面來考慮您的控制飛機

在上一篇文章中，我們評估了控制平面可能需要的組件。 在本節中，我們將探討您的控制平面特定于域的API的外觀。

建立您的控制平面交互點和API表面

一旦仔細考慮了哪些組件可能構成控制平面體系結構（請參見上一章），您將要確切考慮用戶將如何與控制平面進行交互，甚至更重要的是， 用戶將是誰？ 要回答這個問題，您必須決定基于Envoy的基礎架構將扮演什么角色以及流量如何遍歷您的體系結構。 可能是

• API管理網關（北/南）
• 簡單的Kubernetes邊緣負載均衡器/反向代理/入口控制（北/南）
• 共享服務代理（東西方）
• 每輛服務車（東/西）

例如，Istio項目旨在成為平臺服務網格，平臺操作員可以在其上構建工具來驅動對服務和應用程序之間網絡的控制。 用于配置Envoy的Istio的特定于域的配置對象圍繞以下對象：

• 網關 –定義一個共享的代理組件（具有群集入口功能），該組件指定協議，TLS，端口和主機/授權，可用于負載均衡和路由流量
• VirtualService –有關如何與特定服務進行交互的規則； 可以指定諸如路由匹配行為，超時，重試等內容
• DestinationRule –關于如何與特定服務交互的規則，包括斷路，負載平衡，mTLS策略，服務的子集定義等
• ServiceEntry –將服務顯式添加到Istio的服務注冊表中

在Kubernetes中運行，所有這些配置對象都實現為CustomResourceDefinitions 。

Heptio / VMWare Contour旨在用作Kubernetes入口網關，并具有簡化的特定于域的配置模型，同時具有CustomResourceDefinition（CRD）風格和Kubernetes入口資源

• IngressRoute是Kubernetes CRD，它提供一個位置來指定Contour代理的配置
• 入口資源支持 ，如果您喜歡這種事情，則可以使用它在Kubernetes入口資源上指定注釋

在Gloo項目中，我們決定將可用的配置對象分為兩個級別：

• 面向用戶的配置可為用戶使用案例提供最佳的人機工程學，并留有擴展性的選擇（下一節將對此進行詳細介紹）
• 提取Envoy的低層配置，但不明確打算直接用于用戶操作。 較高級別的對象將轉換為該較低級別的表示形式，最終將其轉換為Envoy xDS API。 下一節將清楚說明其原因。

對于用戶來說，Glo專注于擁有自己的路由配置的團隊，因為路由的語義（以及可用的轉換/聚合功能）在很大程度上受到API和微服務開發人員的影響。 對于面向用戶的API對象，我們使用：

• 網關 –指定特定偵聽器端口上可用的路由和API端點以及每個API附帶的安全性
• VirtualService –將API路由分組為一組“虛擬API”，這些路由可以路由到支持的功能（gRPC，http / 1，http / 2，lambda等）； 使開發人員可以控制路由如何進行不同的轉換 ，以嘗試使前端API與后端中存在的功能脫鉤（以及后端可能引入的任何重大更改）

請注意，這些不同于這些對象的Istio變體。

Gloo中面向用戶的API對象驅動較低級別的對象，這些對象隨后用于最終派生Envoy xDS配置。 例如，Gloo的較低級別的核心API對象是：

• 上游 –捕獲有關后端群集的詳細信息以及在其上公開的功能。 您可以將Gloo上游與Envoy集群松散地聯系起來，但有一個很大的不同：上游可以了解特定端點上可用的實際服務功能（換句話說，了解/foo/bar和/bar/wine包括它們的預期參數和參數結構，而不僅僅是hostname:port ）。 一秒鐘內會更多。
• 代理 –代理是抽象我們可以應用于Envoy的所有配置的主要對象。 這包括偵聽器，虛擬主機，路由和上游。 較高級別的對象（VirtualService，網關等）用于驅動此較低級別的代理對象。

Gloo控件的兩個配置級別之間的劃分使我們能夠擴展Gloo控制面板功能，同時保留用于配置Envoy的簡單抽象。 在本系列的第4部分中將對此進行詳細說明。

在前面的三個示例（Istio，Contour，Gloo）中，每個各自的控制平面都公開了一組特定于域的配置對象，這些對象以用戶為中心，但最終轉換為Envoy配置并通過xDS數據平面API公開。 這使Envoy與用戶的預設工作方式及其工作流程脫鉤。 盡管我們已經看到了一些示例，這些示例創建了更多針對用戶和工作流的特定于域的配置，以抽象化Envoy，但這并不是構建Envoy控制平面的唯一方法。 Booking.com上有一個很好的演講，介紹了他們如何與Envoy配置保持更緊密的距離，并使用引擎將所有不同團隊的配置片段合并到實際的Envoy配置中。

除了考慮特定于域的配置之外，您還應該考慮API /對象模型的特定接觸點。 例如，Kubernetes非常注重YAML和資源文件。 您可以構建更特定于域的CLI工具（例如OpenShift使用oc CLI進行操作 ，例如Istio 使用istioctl進行處理，以及Gloo 使用glooctl進行處理

帶走

當構建Envoy控制面板時，您在考慮特定意圖或一組體系結構/用戶時進行此操作。 您應該考慮到這一點，并構建正確的，符合人體工學的，針對特定領域的API，以適合您的用戶并改善操作Envoy的工作流程。 Gloo團隊建議您探索現有的 Envoy控制平面實施方案，并且僅在沒有其他合適的方案時才構建自己的方案。 Gloo的控制飛機奠定了擴展和定制基礎。 正如我們將在下一篇文章中看到的那樣，可以構建一個完全可擴展的控制平面，以適應許多不同的用戶，工作流和操作約束。

翻譯自: https://www.javacodegeeks.com/2019/03/domain-specific-configuration-api.html

總結

以上是生活随笔為你收集整理的为使节构建控制平面的指南第3部分-特定于域的配置API的全部內容，希望文章能夠幫你解決所遇到的問題。

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