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

原文：https://www.ithome.com.tw/news/126449