容器原生負載平衡

本頁面說明 Google Kubernetes Engine (GKE) 中的容器原生負載平衡。

本頁面假設您已瞭解Cloud Load Balancing 和區域網路端點群組 (NEG)。有了容器原生負載平衡，這些負載平衡器就能直接將流量平均分配給 Pod。

容器原生負載平衡架構

容器原生負載平衡使用GCE_VM_IP_PORT網路端點群組 (NEG)。NEG 的端點是 Pod IP 位址。

容器原生負載平衡一律用於內部 GKE Ingress，外部 Ingress 則可選擇是否使用。Ingress 控制器會建立負載平衡器，包括虛擬 IP 位址、轉送規則、健康狀態檢查和防火牆規則。

如要瞭解如何搭配使用容器原生負載平衡與 Ingress，請參閱「透過 Ingress 使用容器原生負載平衡功能」。

如要享有更多彈性，您也可以建立獨立的 NEG。在這種情況下，您必須負責建立及管理負載平衡器的所有層面。

容器原生負載平衡的優點

容器原生負載平衡具備下列優勢：

Pod 是負載平衡的核心物件
kube-proxy 會設定節點的 iptables 規則，將流量分配到多個 Pod。要是沒有容器原生負載平衡，負載平衡器流量會前往節點執行個體群組，並且透過 iptables 規則轉送到多個 Pod，而這些 Pod 不一定位於同一節點內。要是擁有容器原生負載平衡，負載平衡器流量會直接分配到多個 Pod，而這些 Pod 應接收流量，並且消除額外的網路躍點。此外，容器原生負載平衡直接以 Pod 為目標，因此健康狀態檢查可獲得改善。

比較預設行為 (左) 和容器原生負載平衡器行為。
網路效能獲得改善
因為容器原生負載平衡器可直接與 Pod 交流，而且連線的網路躍點較少，所以延遲時間和總處理量都獲得改善。
瀏覽權限提升
使用容器原生負載平衡時，您有權限可瀏覽應用程式負載平衡器到 Pod 的延遲。您可以看到從應用程式負載平衡器到每個 Pod 的延遲時間，這些時間是透過節點 IP 型容器原生負載平衡匯總而來。如此一來，NEG 層級服務的疑難排解就會變得更加容易。
支援進階負載平衡功能
GKE 中的容器原生負載平衡支援外部應用程式負載平衡器的多項功能，例如與 Google Cloud 服務整合，包括 Google Cloud Armor、Cloud CDN 和 Identity-Aware Proxy。此外，還具備負載平衡演算法，可精確分配流量。
支援 Cloud Service Mesh
需有 NEG 資料模型，才能使用 Cloud Service Mesh，這是Google Cloud的全代管服務網格流量控制層。

Pod 完備性

對於相關的 Pod，相應的 Ingress 控制器會管理 cloud.google.com/load-balancer-neg-ready 類型的完備性門檻。Ingress 控制器會輪詢負載平衡器的健康狀態檢查狀態，包括 NEG 中所有端點的健康狀態。當負載平衡器健康狀態檢查的狀態，顯示出與特定 Pod 對應的端點處於健康狀態時，Ingress 控制器會將 Pod 的完備性門檻值設為 True。然後，在每個節點上執行的 kubelet 會將完備性門檻的值以及 Pod 的完備性探測 (如有定義) 一併納入考量，計算 Pod 的有效完備性。

透過 Ingress 使用容器原生負載平衡時，系統會自動啟用 Pod 完備性門檻。

完備性門檻會控制滾動式更新的速率。當您啟動滾動式更新時，隨著 GKE 建立新的 Pod，會將每個新 Pod 的端點新增至 NEG。從負載平衡器的角度來看，當端點處於健康狀態時，Ingress 控制器會將完備性門檻設為 True。新建立的 Pod 必須至少通過其完備性門檻，「接下來」GKE 才能刪除舊的 Pod。這樣可確保 Pod 的對應端點已通過負載平衡器的健康狀態檢查，並確保後端容量維持不變。

如果 Pod 的完備性門檻並未顯示 Pod 已準備就緒，可能是因為容器映像檔錯誤，或是負載平衡器健康狀態檢查設定錯誤，導致負載平衡器未將流量導向新 Pod。如果在推出更新後的 Deployment 時發生故障，在嘗試建立新的 Pod 後，因為該 Pod 的完備性門檻永遠不會為 True，所以會暫停推出。如要瞭解如何偵測並修正這種狀況，請參閱疑難排解一節。

在缺少容器原生負載平衡和完備性門檻的情況下，GKE 在將 Pod 標記為準備就緒之前，無法偵測到負載平衡器的端點是否處於健康狀態。在先前的 Kubernetes 版本中，您可以指定延遲期間 (Deployment 規格中的 minReadySeconds) 來控制 Pod 移除和替換的速率。

如果符合下列任一條件，GKE 會將 Pod 的 cloud.google.com/load-balancer-neg-ready 值設為 True：

  • Pod 的 IP 位址都不是由 GKE 控制層管理的 GCE_VM_IP_PORTNEG 中的端點。
  • 一或多個 Pod 的 IP 位址是 GKE 控制層管理的 GCE_VM_IP_PORT NEG 中的端點。NEG 會附加至後端服務。後端服務已通過負載平衡器健康狀態檢查。
  • 一或多個 Pod 的 IP 位址是 GKE 控制層管理的 GCE_VM_IP_PORT NEG 中的端點。NEG 已附加至後端服務。後端服務的負載平衡器健康狀態檢查逾時。
  • Pod 的一或多個 IP 位址是其中一或多個 NEG 的端點。GCE_VM_IP_PORT沒有任何 NEG 附加至後端服務。 沒有可用的負載平衡器健康狀態檢查資料。

工作階段相依性

容器原生負載平衡支援以 Pod 為基礎的工作階段相依性。

使用容器原生負載平衡的必要條件

透過 GKE 上的 Ingress 使用容器原生負載平衡器時，必須符合下列需求：

  • 叢集必須是虛擬私有雲原生叢集。
  • 叢集必須啟用 HttpLoadBalancing 外掛程式。 根據預設，GKE 叢集已啟用 HttpLoadBalancing 外掛程式，不得停用該功能。

容器原生負載平衡器的限制

透過 GKE 上的 Ingress 使用容器原生負載平衡器時，有下列限制：

  • 不支援外部直通式網路負載平衡器。
  • 您不得手動變更或更新 GKE 建立的應用程式負載平衡器設定。您所做的任何變更都將被 GKE 覆寫。

容器原生負載平衡器的定價

您在本指南中建立的 Ingress 所佈建的應用程式負載平衡器，系統會向您收取費用。如需負載平衡器定價資訊，請參閱 VPC 定價頁面的「負載平衡和轉送規則」。

後續步驟