Envoy是一個非常強大的軟件，每天都會向社區提出新的用例和新的貢獻 。 盡管Envoy的核心非常穩定，但它基于可插入的過濾器體系結構，因此人們可以為不同的L7協議編寫新的編解碼器或添加新的功能。 目前，Envoy過濾器是用C ++編寫的，可以通過Lua擴展Envoy，但是也有一些討論也支持Web Assembly的可擴展性。 除了快速發展的Envoy社區以及配置這些新功能的需求之外，還需要包括新的特定于域的對象模型，以支持希望利用Envoy的新平臺。 在本節中，我們將探索沿這兩個維度擴展Envoy控制平面。

通過編寫C ++過濾器，擴展Envoy非常簡單。 我們在Gloo項目上創建的Envoy過濾器包括：

• 壁球調試器（https://github.com/envoyproxy/envoy/tree/master/api/envoy/config/filter/http/squash）
• 緩存（目前已關閉源；應在不久的將來開源）
• 請求/響應轉換（https://github.com/solo-io/envoy-gloo/tree/master/source/extensions/filters/http/transformation）
• AWS lambda（https://github.com/solo-io/envoy-gloo/tree/master/source/extensions/filters/http/aws_lambda）
• NATS流式傳輸（https://github.com/solo-io/envoy-nats-streaming，https://github.com/solo-io/envoy-gloo/tree/master/source/extensions/filters/http/nats /流）
• Google Cloud Functions（https://github.com/solo-io/envoy-google-function）
• Azure功能（https://github.com/solo-io/envoy-azure-functions）

由于Envoy用途廣泛，并且一直在增加新功能，因此值得花一些時間考慮是否要構建可擴展的控制平面以使用這些新功能。 在Gloo項目中，我們選擇在以下級別上執行此操作：

• 在核心 Gloo配置對象之上構建更多有針對性的特定于域的配置對象
• 控制平面插件可增強控制平面的現有行為
• 創建工具以加快前兩點

讓我們看一下每個級別，以及它們如何對可擴展和靈活的控制平面作出貢獻。

核心API對象，考慮了靈活性而構建

在上一節中，我們討論了用于配置控制平面的特定于域的配置對象。 在Gloo中，我們有最底層的配置對象 Proxy 。 這是Proxy對象的示例（在此示例中為Kubernetes中的CRD）：

apiVersion: gloo.solo.io/v1 kind: Proxy metadata: clusterName: "" creationTimestamp: "2019-02-15T13:27:39Z" generation: 1 labels: created_by: gateway name: gateway-proxy namespace: gloo-system resourceVersion: "5209108" selfLink: /apis/gloo.solo.io/v1/namespaces/gloo-system/proxies/gateway-proxy uid: 771377f2- 3125 -11e9- 8523 -42010aa800e0 spec: listeners: - bindAddress: '::' bindPort: 8080 httpListener: virtualHosts: - domains: - '*' name: gloo-system. default routes: - matcher: exact: /petstore/findPet routeAction: single: destinationSpec: rest: functionName: findPetById parameters: {} upstream: name: default -petstore- 8080 namespace: gloo-system - matcher: exact: /sample-route- 1 routeAction: single: upstream: name: default -petstore- 8080 namespace: gloo-system routePlugins: prefixRewrite: prefixRewrite: /api/pets name: gateway status: reported_by: gloo state: 1

您可以看到Proxy對象指定了偵聽器，它們的類型以及路由信息。 如果您仔細觀察，您會發現它在一定程度上遵循了Envoy的配置，但是在支持其他功能方面有所不同。 在路由中，您可以看到請求已發送到“上游”。 Gloo知道如何路由到上游 ，您可以在上面的代理對象中看到這些定義。 代理對象是由Gloo的控制平面轉換為Envoy xDS API的對象。 如果我們看一下組成Gloo的組件，就會看到以下內容：

NAME READY STATUS RESTARTS AGE discovery-676bcc49f8-n55jt 1 / 1 Running 0 8m gateway-d8598c78c-425hz 1 / 1 Running 0 8m gateway-proxy-6b4b86b4fb-cm2cr 1 / 1 Running 0 8m gloo-565659747c-x7lvf 1 / 1 Running 0 8m

gateway-proxy組件是Envoy代理。 以下組成控制平面：

• gateway
• discovery
• gloo

負責此Proxy-> Envoy xDS轉換的組件是：

• gloo –事件驅動的組件，通過將Proxy對象轉換為Envoy的LDS / RDS / CDS / EDS API，負責核心xDS服務和自定義Envoy篩選器的配置

Gloo知道如何路由到上游以及上游上存在的功能。 上游也是Gloo的核心配置對象。 我們需要這個Upstream對象的原因是，要封裝比Envoy所能了解的更多有關上游功能的保真度。 特使了解“集群”，但是格洛（在特使之上）了解功能。 這些知識可以啟用功能級路由 ，這是用于組成新應用程序和API的更強大的路由結構。 Envoy通過“ host：port”終結點了解群集，但是使用Gloo，我們可以將附加上下文附加到這些群集，以便它們理解“功能”，這些功能可以是REST方法/路徑，gRPC操作或Lambda等云功能。 例如，這是一個名為default-petstore-8080的Gloo上游：

--- discoveryMetadata: {} metadata: labels: discovered_by: kubernetesplugin service: petstore sevice: petstore name: default -petstore- 8080 namespace: gloo-system status: reportedBy: gloo state: Accepted upstreamSpec: kube: selector: app: petstore serviceName: petstore serviceNamespace: default servicePort: 8080 serviceSpec: rest: swaggerInfo: url: http: //petstore.default.svc.cluster.local:8080/swagger.json url: http: //petstore.default.svc.cluster.local:8080/swagger.json transformations: addPet: body: text: '{ "id" : {{ default (id, "" ) }}, "name" : "{{ default(name, " ")}}" , "tag" : "{{ default(tag, " ")}}" }' headers: :method: text: POST :path: text: /api/pets content-type: text: application/json deletePet: headers: :method: text: DELETE :path: text: /api/pets/{{ default (id, "" ) }} content-type: text: application/json findPetById: body: {} headers: :method: text: GET :path: text: /api/pets/{{ default (id, "" ) }} content-length: text: "0" content-type: {} transfer-encoding: {} findPets: body: {} headers: :method: text: GET :path: text: /api/pets?tags={{ default (tags, "" )}}&limit={{ default (limit, "" )}} content-length: text: "0" content-type: {} transfer-encoding: {}

請注意，就此上游公開的功能而言，我們更具保真度。 在這種情況下，上游恰好是REST服務，公開了Open API Spec / Swagger文檔。 Gloo自動發現此信息，并使用可以在Proxy對象中使用的信息來豐富此Upstream對象。

如果回頭參考Gloo控制平面中的組件，您將看到一個discovery組件，它通過添加“上游發現服務”（UDS）和“功能發現服務”（FDS）來增強Envoy的發現API。 上游發現服務使用一組插件（請參閱下一節）自動發現上游。 最簡單的示例是在Kubernetes中運行時，我們可以自動發現Kubernetes Services 。 Gloo還可以發現Consul，AWS 等公司的上游產品。

Gloo控制平面中的discovery組件僅使用其UDS和FDS服務來發現上游對象并將其寫入Kuberentes CRD。 從那里，用戶可以創建從Envoy代理上的特定API路徑到上游特定功能的路由規則。 Envoy代理不會直接與此控制平面組件進行交互（回想一下，Envoy僅使用gloo組件公開的xDS API）。 取而代之的是， discovery組件有助于創建上游，然后可由代理對象使用。 這是使用支持的微服務（在此示例中為discovery服務）為控制平面的整體功能做出貢獻的一個很好的示例。

代理和上游是上一節中提到的較低級別的特定于域的配置對象。 更有意思的是，我們如何在此基礎上分層配置對象集，以更自以為是的工作流程滿足用戶特定的用例。

擴展特定于域的配置層

在Gloo的控制平面中，還有另一個組件稱為gateway組件。 該組件實現了最終將與用戶進行交互的更高級別的特定于域的配置（直接通過YAML文件或通過glooctl CLI工具間接進行）。 gateway組件知道兩個特定于域的對象：

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

這些對象允許與Proxy對象分離。 當用戶使用更符合人體工程學或自以為是的API創建新的Gateway或VirtualService對象時，Gloo的gateway組件將使用這些對象（Kubernetes中的CRD，Consul中的配置條目）并更新基礎的Proxy對象。 這是擴展Gloo的常見模式：更喜歡控制平面組件的可組合性。 這使我們能夠為更自以為是的領域特定對象構建更專業的控制器，以支持不同的用法。 例如， Solo.io團隊還為Gloo構建了一個名為Sqoop的開源控制器，該控制器遵循相同的模式，并擴展了Gloo API，以聲明基于具有GraphQL模式的GraphQL引擎構建的路由規則。 在Sqoop中，我們引入了Schemas和ResolverMaps對象，這些對象最終對Proxy對象有所貢獻，然后將其轉換為Envoy xDS。

基于基本Gloo對象構建的特定于域的配置分層的另一個示例是我們最近的貢獻，即使用Knative Serving中的 Gloo代理替代Istio 。 Knative有一個用于聲明集群入口資源的特定對象，稱為ClusterIngress對象，如下所示：

apiVersion: networking.internal.knative.dev/v1alpha1 kind: ClusterIngress metadata: labels: serving.knative.dev/route: helloworld-go serving.knative.dev/routeNamespace: default name: helloworld-go-txrqt spec: generation: 2 rules: - hosts: - helloworld-go. default .example.com - helloworld-go. default .svc.cluster.local - helloworld-go. default .svc - helloworld-go. default http: paths: - appendHeaders: knative-serving-namespace: default knative-serving-revision: helloworld-go- 00001 retries: attempts: 3 perTryTimeout: 10m0s splits: - percent: 100 serviceName: activator-service serviceNamespace: knative-serving servicePort: 80 timeout: 10m0s visibility: ExternalIP

為了在Gloo中支持該用例，我們要做的就是構建一個新的控制器，該控制器監視ClusterIngress對象并將其轉換為Gloo的Proxy 。 有關在Knative中使用Gloo來簡化Knative Serving安裝以將Gloo用作集群入口的安裝的更多信息，請參見此博客 。

控制平面插件可增強控制平面的現有行為

在上一部分中，我們研究了如何通過在核心對象之上分層特定于域的配置對象來擴展控制平面的功能。 擴展的另一點是直接在控制面板核心對象本身中。 在Istio中將是VirtualService和DestinationRule ，在Contour中將是IngressRoute ，在Gloo中將是Proxy和Upstream對象。 例如，Gloo的Proxy對象包含Listeners ， Virtualhosts和Routes的擴展點。 這意味著在Proxy配置中有定義明確的位置，我們可以向配置中引入新功能（即，如果我們希望公開新的Envoy功能，或者如果我們要為Envoy編寫新的過濾器，而我們想為其公開配置，等等） ）。 大驚小怪。 例如，我們編寫了一些插件，這些插件豐富了 Envoy 的路由和轉換功能 。 例如，要轉換進入Envoy并發往名為foo-service的服務的請求，我們可以使用Inja模板處理標頭或正文。 有關更多信息，請參見Gloo文檔中的功能路由指南 。

routes: - matcher: prefix: / routeAction: single: upstream: name: foo-service namespace: default routePlugins: transformations: requestTransformation: transformationTemplate: headers: x-canary-foo text: foo-bar-v2 :path: text: /v2/canary/feature passthrough: {}

要查看Gloo Proxy和Upstream對象上可用的插件的完整列表，請參閱此處的文檔

將新插件添加到控制平面后，可以擴展面向用戶的特定于域的配置對象，以利用這些新功能。 您可以擴展現有的控制器來執行此操作或添加新的控制器（遵循微服務彼此松散地協調的原則）。 我們已經編寫了廣泛的示例，以幫助您編寫控制器來增強控制面板的功能，或者在Slack上尋求更多有關此方面的指導。

利用工具加快前兩個項目符號

在前面的部分中，我們了解了如何考慮控制平面的可擴展性和靈活性。 我們看到了使用多層特定于域的配置對象如何通過添加新對象和控制器來實現可擴展性。 在Solo.io，我們創建了一個名為solo-kit的開源項目，該項目通過從protobuf對象開始并代碼生成正確的類型安全客戶端以與其進行交互，從而加快為控制平面構建新的，聲明性的，自以為是的API對象的速度。平臺上的對象。 例如，在Kubernetes上， solo-kit會將這些原型轉換為CustomResourceDefinitions，并生成Golang Kubernetes客戶端以觀看和與這些資源進行交互。 如果您不在Kubernetes上，還可以使用Consul，Vault和其他許多存儲作為后端存儲。

創建資源并生成類型安全客戶端后，您將需要檢測用戶何時創建新資源或對現有資源進行更改。 使用solo-kit，您只需指定要觀看的資源或稱為“快照”的資源組合，然后客戶端運行事件循環以處理所有通知。 在事件循環中，您可以更新協作對象或核心對象。 實際上，這就是Gloo的分層特定于域的配置對象的工作方式。 有關更多信息，請參見Gloo聲明性模型文檔 。

帶走

控制平面可以根據需要簡單或復雜。 Gloo團隊建議將重點放在控制平面的簡單核心上，然后通過可組合性將其擴展到插件和微服務控制器。 Gloo的體系結構是這樣構建的，并使Gloo團隊能夠快速添加任何新功能，以支持出現的任何平臺，配置，過濾器等。 這就是為什么盡管Gloo是Kubernetes原生的，但它卻可以在任何云上的任何平臺上運行。 核心控制平面設計可以做到這一點。

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

總結

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

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