容器環境中的代理模型 | Linux 中國

我們大多數人都熟悉代理如何工作，但在基於容器的環境中有什麼不同？讓我們來看看有什麼改變。

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

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

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

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

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

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

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

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

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

反向代理

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

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

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

前向代理

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

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

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

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

挎鬥代理

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

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

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

總結

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

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

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

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

作者：Lori MacVittie[5] 譯者：geekpi 校對：wxy

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