服務網格入門從閘道器開始 - Christian Posta

banq發表於2019-08-31

兩年多來，我一直在幫助宣傳服務網格和Envoy Proxy。看到社群是如何發展的，更重要的是組織如何開始使用它來解決困難的生產和運營問題，這真是令人驚喜。憑藉我在Red Hat和現在的Solo.io的時間經歷，我很幸運能夠與各組織密切合作，共同開展服務網路採用之旅。
在這段實際，我開發了下面方法來成功地在生產中採用服務網格：
  1. 深入熟悉最終服務網格的資料平面技術
  2. 首先使用共享閘道器理想地使用較小部分的流量來運算元據平面
  3. 選擇應用程式的子集以啟用網狀（基於邊車）網路
  4. 慢慢啟用提供最大價值的服務網格功能
  5. 沖洗並重復步驟2-4

我離開Red Hat加入Solo.io的一個重要原因是我們對服務網格的看法，包括這個簡單的採用列表，非常好。本部落格的其餘部分是我們目前如何幫助客戶使用閘道器和資料平面優先方法來採用服務網格。

瞭解Envoy代理

Envoy特使已成為許多服務網格技術的基礎資料平面。像Istio，Consul Connect，AWS App Mesh，Grey Matter（以及其他來自現有API管理供應商的網站）的網格都基於Envoy。
它是一種極其強大，多功能，複雜的技術。過去在訊息傳遞基礎設施上工作的原理就是：將訊息（或位元組）從一個管道傳遞到另一個管道，表面上似乎很容易，但實際上它比你想象的要難得多。理解Envoy的工作方式非常重要，包括各種過濾器，收集的遙測技術以及配置API的工作原理。透過在您的環境中運維Envoy獲得經驗，才是獲得理解它的最好方式。

(banq注：基於K8s的服務網格比訊息系統其實更復雜，同步呼叫服務雖然方便請求響應模型，但是嚴重忽視分散式系統的網路不可靠性，為了防止網路不可靠，各種遙測技術都是事後諸葛亮。但是服務網格作為API閘道器還是值得期待的，可以替代將訊息系統作為API閘道器的模式，但是內部服務之間呼叫還是有同步和非同步之分)

理想情況下，您可以從單個Envoy部署（邏輯單一）開始，部署在您的應用程式前面。

使用基於Envoy的閘道器作為踏腳石
在採用服務網格時，使用Envoy作為共享閘道器是一個很好的起點。在我的書“ Istio in Action”中，我在本書的開頭附近介紹了Istio Gateway資源及其相關配置，因為這是開始使用Istio的最佳方式。Gateway是在Envoy的基礎上構建的，可以在不需要構建完整網格的情況下使用微服務（即，在所有應用程式旁邊注入sidecars）。
使用閘道器來引導您的應用程式意味著您可以獲得執行Envoy的運營體驗以及獲得“service-mesh lite”體驗。當閘道器到位時，您可以獲得一些強大的流量路由控制（包括基於百分比的路由，基於頭/方法的路由，以及影子流量等），TLS終止/直通，TCP控制等。
像Istio Gateway這樣的簡單閘道器可能是一種很好的方式，可以在啟動時為您的群集提供基本流量入口，但是基於Envoy構建的功能更全面的API閘道器可能會帶來更多好處。

基於Envoy的更好的閘道器
現實情況是，當將叢集/未來服務網格之外的客戶端連線到叢集/服務網格中執行的服務時，必須考慮到一個嚴峻的現實：現有組織已經知道流量如何流動並且應該受到保護。
例如，當透過閘道器將流量引入群集或新服務網格時，我們需要解決以下問題：

  • 快取記憶體
  • 尖峰捕獲/限速
  • 終端使用者/客戶端oauth流
  • HMAC /訊息簽名
  • jwt驗證（包括與現有JWT發行人或身份管理整合）
  • Web應用程式防火牆（WAF）
  • 訊息轉換
  • API編排

還有很多其他，換句話說，這個入口點需要比基本的Envoy閘道器（即Istio的閘道器）更強大和更強大。它需要處理API閘道器中常見的熟悉的邊緣功能。
Solo.io的Gloo是一個基於Envoy Proxy的API閘道器，它提供了兩全其美的優勢：
  1. 透過簡化採用單個前端閘道器的體驗以及服務網格的墊腳石
  2. 能夠處理熟悉的API閘道器功能。

（省略Solo營銷介紹....）

總結
如果您正在使用服務網格，請記住上述這種簡單、經過驗證的真實採用方法。特使Envoy是事實上的服務網格資料平面（Linkerd除外 - 至少在此時）並且圍繞Envoy構建策略是重要的第一步。如果您正在探索不是基於Envoy構建的API管理或閘道器L7網路技術，您可能希望重新審視一下，特別是如果您正在尋找一個簡單的服務網格入口通道時。

相關文章