GCP現在為運作於Google Kubernetes Engine(GKE)的應用程式,以及安裝在Compute Engine上的Kubernetes,提供原生容器負載平衡

使用者現在能使用網路端點組(Network Endpoint Groups,NEGs),以任意網路端點編寫負載平衡器作為IP埠對,並且對容器直接進行負載平衡。透過這個GCP上新的資料模型抽象層,企業可以獲得精確Pods的原生運作狀況,甚至是負載平衡到Pods之間。

最初負載平衡器是為支援虛擬機器的資源分配而設計,但是這樣的設計對於容器來說,並不能達到最佳效能,像是GKE這樣的容器協調器( Container Orchestrator),沒有一組為Pods定義的後端方法,所以負載平衡器會以執行個體分組作為後端。

像是GKE中的Ingress支援就以執行個體分組,使用HTTP/HTTPS負載平衡器對叢集中的節點進行負載平衡,這些節點遵循IPTable的規則,將請求路由到Pods中,但由於虛擬機器等級的負載平衡器,無法將Pods或是容器視為後端,導致負載不平衡,而且在節點之間還會發生次優路徑大量資料流量跳躍的情況發生。

GCP為了解決這些問題,現在具備原生容器負載平衡能力的新網路端點組抽象層與Kubernetes Ingress控制器整合,當企業使用多層部署要在網際網路公開一個或多個服務,現在可以創建一個Ingress物件,來負責提供HTTP/HTTPS負載平衡器,讓企業可以配置基於路徑或是主機的規則,以路由流量到後端服務。

與IPTables相比,原生容器負載平衡能為容器提供真正的最佳負載,由於之前的負載平衡系統並不了解後端容器,因此即使將流量平均分配到執行個體中,對容器來說也不見得是平均的,而原生容器負載平衡則能根據用戶定義的負載平衡演算法,將流量均勻分配到後端中。

另外,負載平衡系統具備掌握後端能力後,便能直接對容器進行執行狀態檢查,而不是將狀態檢查請求發送到節點上,再由節點轉發到隨機容器上,因此現在更能準確掌握後端系統運作的健康程度。而當後端的一個Pod被移除後,負載平衡器會原生的處理端點流量,並根據結束連結流量來設置後端服務。

由於負載平衡器可以直接對容器進行操作,負載平衡器到節點間將不會再有流量跳躍,因為負載平衡現在是一步而非兩個步驟。原生容器負載平衡還能幫助使用者排除Pod層級的故障,該服務保留來源IP,因此能輕易追蹤到流量來源,而且由於容器收到的封包來自負載平衡器而非來自其他節點的NAT,因此使用者可以使用節點等級的網路政策創建防火牆規則。


Advertisement

更多 iThome相關內容