GCP為Kubernetes引擎提供支援原生容器的負載平衡器

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，因此使用者可以使用節點等級的網路政策創建防火牆規則。