容器環境中的代理模型

內聯、 側臂 side-arm 、反向和前向。這些曾經是我們用來描述網路代理架構布局的術語。

如今，容器使用一些相同的術語，但它們正在引入新的東西。這對我是個機會來闡述我最愛的所有主題：代理。

雲的主要驅動之一（我們曾經有過成本控制的白日夢）就是可擴展性。在過去五年中，擴展在各種調查中面臨著敏捷性的挑戰（有時甚至獲勝），因為這是機構在雲計算環境中部署應用的最大追求。

這在一定程度上是因為在（我們現在運營的）數字經濟中，應用已經成為像實體店的「營業/休息」的標牌和導購一樣的東西。緩慢、無響應的應用如同商店關燈或缺少營業人員一樣。

應用需要隨時可用且能夠滿足需求。擴展是實現這一業務目標的技術響應。雲不僅提供了擴展的能力，而且還提供了自動擴展的能力。要做到這一點，需要一個負載均衡器。因為這就是我們擴展應用程序的方式 ：使用代理來負載均衡流量/請求。

容器在擴展上與預期沒有什麼不同。容器必須進行擴展（並自動擴展）這意味著使用負載均衡器（代理）。

如果你使用的是原有的代理機制，那就是採用基於 TCP/UDP 進行基本的負載平衡。一般來說，基於容器的代理的實現在 HTTP 或其他應用層協議中並不流暢，並不能在舊式的負載均衡（POLB）之外提供其他功能。這通常足夠了，因為容器擴展是在一個克隆的、假定水平擴展的環境中進行的：要擴展一個應用程序，就添加另一個副本並在其上分發請求。在入口處（在入口控制器和 API 網關中）可以找到第 7 層（HTTP）路由功能，並且可以使用儘可能多（或更多）的應用路由來擴展應用程序。

然而，在某些情況下，這還不夠。如果你希望（或需要）更多以應用程序為中心的擴展或插入其他服務的能力，那麼你就可以獲得更健壯的產品，可提供可編程性或以應用程序為中心的可伸縮性，或者兩者兼而有之。

這意味著插入代理。你正在使用的容器編排環境在很大程度上決定了代理的部署模型，無論它是反向代理還是前向代理。更有趣的是，還有第三個模型挎斗模式 ，這是由新興的服務網格實現支持的可擴展性的基礎。

反向代理

反向代理最接近於傳統模型，在這種模型中，虛擬伺服器接受所有傳入請求，並將其分發到資源池（伺服器中心、集群）中。

每個「應用程序」有一個代理。任何想要連接到應用程序的客戶端都連接到代理，代理然後選擇並轉發請求到適當的實例。如果綠色應用想要與藍色應用通信，它會向藍色代理髮送請求，藍色代理會確定藍色應用的兩個實例中的哪一個應該響應該請求。

在這個模型中，代理只關心它正在管理的應用程序。藍色代理不關心與橙色代理關聯的實例，反之亦然。

前向代理

這種模式更接近傳統的出站防火牆的模式。

在這個模型中，每個容器 節點 都有一個關聯的代理。如果客戶端想要連接到特定的應用程序或服務，它將連接到正在運行的客戶端所在的容器節點的本地代理。代理然後選擇一個適當的應用實例，並轉發客戶端的請求。

橙色和藍色的應用連接到與其節點相關的同一個代理。代理然後確定所請求的應用實例的哪個實例應該響應。

在這個模型中，每個代理必須知道每個應用，以確保它可以將請求轉發給適當的實例。

挎斗代理

這種模型也被稱為服務網格路由。在這個模型中，每個容器都有自己的代理。

如果客戶想要連接到一個應用，它將連接到挎斗代理，它會選擇一個合適的應用程序實例並轉發客戶端的請求。此行為與前向代理模型相同。

挎斗代理和前向代理之間的區別在於，挎斗代理不需要修改容器編排環境。例如，為了插入一個前向代理到 k8s，你需要代理和一個 kube-proxy 的替代。挎斗代理不需要這種修改，因為應用會自動連接到 「挎斗」 代理而不是通過代理路由。

總結

每種模式都有其優點和缺點。三者共同依賴環境數據（遠程監控和配置變化），以及融入生態系統的需求。有些模型是根據你選擇的環境預先確定的，因此需要仔細考慮將來的需求（服務插入、安全性、網路複雜性）在建立模型之前需要進行評估。

在容器及其在企業中的發展方面，我們還處於早期階段。隨著它們繼續延伸到生產環境中，了解容器化環境發布的應用程序的需求以及它們在代理模型實現上的差異是非常重要的。

這篇文章是匆匆寫就的。現在就這麼多。

via: https://dzone.com/articles/proxy-models-in-container-environments

作者：Lori MacVittie 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive