为Envoy构建控制平面的指南-特定于域的配置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與后端中存在的功能脫鉤（以及后端可能引入的任何重大更改）
Gloo中面向用戶的API對象驅動較低級別的對象，這些對象隨后用于最終派生Envoy xDS配置。 例如，Gloo的較低級別的核心API對象是：
- 上游 –捕獲有關后端群集的詳細信息以及在其上公開的功能。 您可以將Gloo上游與Envoy集群松散地聯系起來，但有一個很大的不同：上游可以了解特定端點上可用的實際服務功能（換句話說，了解/foo/bar和/bar/wine包括它們的預期參數和參數結構，而不僅僅是hostname:port ）。 一秒鐘內會更多。
- 代理 –代理是抽象我們可以應用于Envoy的所有配置的主要對象。 這包括偵聽器，虛擬主機，路由和上游。 較高級別的對象（VirtualService，網關等）用于驅動此較低級別的代理對象。
Gloo控件的兩個配置級別之間的劃分使我們能夠擴展Gloo控制面板功能，同時保留用于配置Envoy的簡單抽象。 下一節將對此進行說明。
在前面的三個示例（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控制平面實施方案，并且僅在沒有其他合適的方案時才構建自己的方案。 正如我們將在下一節中看到的那樣，可以構建一個完全可擴展的控制平面，以適應許多不同的用戶，工作流和操作約束。
翻譯自: https://www.javacodegeeks.com/2019/02/envoy-domain-specific-configuration-api.html
總結
以上是生活随笔為你收集整理的为Envoy构建控制平面的指南-特定于域的配置API的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Apache Commons Array
- 下一篇： 建筑商和机械手