Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

應用程式負載平衡器的 GKE Ingress

Autopilot Standard

本頁面提供 Google Kubernetes Engine (GKE) 應用程式負載平衡器 Ingress 的一般總覽，並說明 Ingress 控制器如何佈建應用程式負載平衡器，將應用程式公開給來自虛擬私有雲網路內外 HTTP(S) 流量。

本頁是瞭解 GKE Ingress 功能的主要入口點。如要更詳細地瞭解基礎網路架構、流量轉送模式和安全性實作方式，請參閱「關於 GKE Ingress 轉送和安全性」。

本頁面假設您已瞭解下列事項：

本頁面適用於網路專家，他們負責為機構設計及建構網路，並安裝、設定及支援網路設備。如要進一步瞭解Google Cloud 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

總覽

GKE 提供內建的代管 Ingress 控制器，稱為 GKE Ingress。在 GKE 中建立 Ingress 資源時，控制器會自動設定 HTTPS 負載平衡器，允許 HTTP 或 HTTPS 流量傳送至您的 Service。Ingress 控制器會根據 Ingress 資訊清單和相關聯的 Service 物件中指定的規則，設定負載平衡器並將流量導向叢集中執行的應用程式。

Ingress 物件會與一或多個服務物件建立關聯，而這些服務物件又會與一組 Pod 建立關聯。如要進一步瞭解 Ingress 如何透過服務公開應用程式，請參閱「服務網路總覽」。

如要使用 Ingress，必須啟用 HTTP 負載平衡外掛程式。 GKE 叢集預設會啟用這個外掛程式，請勿停用。

Kubernetes 服務與 Google Cloud 後端服務的差異

Kubernetes Service 物件和 Google Cloud backend service 物件的用途類似，但有所不同。雖然兩者密切相關，但並非總是對應關係。

GKE Ingress 控制器會在這兩個概念之間扮演轉譯器的角色。建立 Ingress 資源時，控制器會佈建Google Cloud 負載平衡器。接著，控制器會為 Ingress 資訊清單中參照的每個不重複 (service.name、service.port) 組合，建立專屬的Google Cloud 後端服務。

舉例來說，Ingress 資訊清單可能具有相同的 Kubernetes 服務名稱，但會針對兩個不同的 host 或 path 規則指向不同的 service.port。在本例中，GKE Ingress 控制器會建立兩個不同的後端服務。因此，一個 Kubernetes Service 物件可以與多個 Google Cloud 後端服務相關聯。

外部和內部流量的輸入

GKE Ingress 資源分為兩種類型：

外部應用程式負載平衡器的 Ingress 會部署傳統版應用程式負載平衡器。這項連結網際網路的負載平衡器部署於 Google 邊緣網路，是可擴充的代管負載平衡資源集區。瞭解如何設定及使用外部應用程式負載平衡器的 Ingress。
內部應用程式負載平衡器的 Ingress 會部署內部應用程式負載平衡器。這些內部應用程式負載平衡器是由 GKE 叢集外部但虛擬私有雲網路內的 Envoy Proxy 系統提供支援。瞭解如何設定及使用 Ingress 搭配內部應用程式負載平衡器。

外部應用程式負載平衡器的必要網路環境

外部應用程式負載平衡器是代管的全球分散式系統，使用部署在 Google 邊緣網路的 Google Front End (GFE) Proxy。這些 Proxy 並非位於您的虛擬私有雲網路中。用戶端向負載平衡器的外部 IP 位址傳送要求時，系統會使用 Google 的任意傳播網路，將要求轉送至最近的 GFE。GFE 會終止使用者流量 (包括 TLS，如果已設定)，然後將流量轉送至 GKE 叢集中的後端 Pod。

為確保這項流程正常運作，GKE Ingress 控制器會自動建立防火牆規則，允許來自 GFE 和Google Cloud健康狀態檢查系統的流量連至 Pod。這些規則允許來自 Google 已知 IP 位址範圍 (130.211.0.0/22 和 35.191.0.0/16) 的流量。

外部應用程式負載平衡器的運作方式如下：

用戶端將要求傳送至負載平衡器轉送規則的 IP 位址和通訊埠。
要求會傳送至 Google 全球網路上的 Google Front End (GFE) Proxy。這個 Proxy 會終止用戶端的網路連線。
GFE Proxy 會根據負載平衡器的網址對應和後端服務，將要求轉送至 GKE 叢集中適當的後端 Pod 端點。

與內部應用程式負載平衡器不同，您不需要在虛擬私有雲網路中，為外部應用程式負載平衡器設定僅限 Proxy 的子網路。

內部應用程式負載平衡器的必要網路環境

內部應用程式負載平衡器會為網路提供 Proxy 集區。Proxy 會根據網址對應、BackendService 的工作階段相依性，以及每個後端 NEG 的平衡模式等因素，評估每個 HTTP(S) 要求應前往的位置。

區域的內部應用程式負載平衡器會使用虛擬私有雲網路中該區域的僅限 Proxy 子網路，為 Google Cloud建立的每個 Proxy 指派內部 IP 位址。

根據預設，指派給負載平衡器轉送規則的 IP 位址來自 GKE 指派的節點子網路範圍，而非 Proxy 專用子網路。您也可以在建立規則時，從任何子網路手動指定轉送規則的 IP 位址。

下圖概述內部應用程式負載平衡器的流量流程，如上段所述。

內部應用程式負載平衡器的運作方式如下：

用戶端連線至負載平衡器轉送規則的 IP 位址和通訊埠。
Proxy 會接收並終止用戶端的網路連線。
Proxy 會根據負載平衡器的網址對應和後端服務，與 NEG 中的適當端點 (Pod) 建立連線。

每個 Proxy 都會聽取對應的負載平衡器轉送規則所指定的 IP 位址和通訊埠。從 Proxy 傳送至端點的每個封包，其來源 IP 位址都是從 Proxy 專用子網路指派給該 Proxy 的內部 IP 位址。

GKE Ingress 控制器行為

GKE Ingress 控制器是否處理 Ingress，取決於 kubernetes.io/ingress.class 註解的值：

`kubernetes.io/ingress.class` 值	`ingressClassName` 值	GKE Ingress 控制器行為
未設定	未設定	處理 Ingress 資訊清單，並建立外部應用程式負載平衡器。
未設定	任何值	不採取任何行動。如果已部署第三方 Ingress 控制器，該控制器可能會處理 Ingress 資訊清單。
`gce`	任何值。系統會忽略這個欄位。	處理 Ingress 資訊清單，並建立外部應用程式負載平衡器。
`gce-internal`	任何值。系統會忽略這個欄位。	處理 Ingress 資訊清單，並建立內部應用程式負載平衡器。
設為 `gce` 或 `gce-internal` 以外的值	任何值	不採取任何行動。如果已部署第三方 Ingress 控制器，Ingress 資訊清單可能會由該控制器處理。

`kubernetes.io/ingress.class` 註解淘汰

雖然 kubernetes.io/ingress.class 註解已在 Kubernetes 中淘汰，但 GKE 仍會使用這個註解。您必須使用這個註解來識別 Ingress 類別。

套用設定時，您可能會看到淘汰警告。這則警告指出註解已淘汰，並指示您改用 ingressClassName 欄位。您可以放心忽略這則警告，因為 GKE Ingress 仍會繼續只依賴 kubernetes.io/ingress.class 註解。

對應至 Compute Engine 資源的 Ingress

GKE Ingress 控制器會根據部署在叢集中的 Ingress 資源，部署及管理 Compute Engine 負載平衡器資源。Compute Engine 資源的對應方式取決於 Ingress 資源的結構。

以下資訊清單說明 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

這個 Ingress 資訊清單會指示 GKE 建立下列 Compute Engine 資源：

轉送規則和 IP 位址。
Compute Engine 防火牆規則，允許負載平衡器健康狀態檢查和應用程式流量，來自 Google Front Ends 或 Envoy Proxy。
目標 HTTP Proxy 和目標 HTTPS Proxy (如果您設定了 TLS)。
網址對應，其中包含參照單一路徑比對器的單一主機規則。路徑比對工具有兩項路徑規則，分別適用於 /* 和 /discounted。每個路徑規則都會對應至不重複的後端服務。
NEG，其中包含每個 Service 的 Pod IP 位址清單做為端點。這些是因 my-discounted-products 和 my-products 服務而建立。

負載平衡方法

GKE 支援容器原生負載平衡和執行個體群組。

容器原生負載平衡

容器原生負載平衡是指直接將負載平衡至 GKE 中的 Pod 端點。容器原生負載平衡會使用 GCE_VM_IP_PORT 類型的網路端點群組 (NEG)，其中端點是 Pod 的 IP 位址。

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

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

符合下列所有條件時，GKE 會自動啟用容器原生負載平衡功能：

叢集為 VPC 原生。
叢集未使用 Shared VPC 虛擬私有雲網路。
叢集未使用 GKE 網路政策。
叢集已啟用 HttpLoadBalancing 外掛程式。GKE 叢集預設會啟用 HttpLoadBalancing 外掛程式，請勿停用。

GKE 啟用以容器為基礎的負載平衡時，系統會自動使用 cloud.google.com/neg: '{"ingress": true}' 註解 Service。這個註解會觸發建立 NEG，鏡像 Pod IP，讓 Compute Engine 負載平衡器直接與 Pod 通訊。

如果叢集的預設值不是 NEG，我們仍強烈建議使用容器原生負載平衡，但必須針對每項 Service 明確啟用。

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

優點

使用 NEG 時，容器原生負載平衡可提供效能更高且更穩定的網路：

提升網路效能：如果沒有容器原生負載平衡功能，流量會前往節點執行個體群組，然後依賴 iptables 規則 (由 kube-proxy 設定) 轉送到目標 Pod。有了容器原生負載平衡功能，流量會直接負載平衡至 Pod，不必透過 VM IP 和節點上的 kube-proxy 網路轉送。這個流程可省去額外的網路躍點，並改善延遲時間和處理量。

強化健康狀態檢查：實作 Pod 就緒閘道，從負載平衡器的角度判斷 Pod 健康狀態，而非僅依賴叢集內健康狀態探測。這項重要功能可讓負載平衡器掌握 Pod 生命週期事件 (啟動、遺失等)，並提升流量穩定性。如要進一步瞭解如何使用 Pod 就緒閘道判斷 Pod 健康狀態，請參閱「Pod 就緒」。

提高曝光度：透過容器原生負載平衡，您可以直接查看從應用程式負載平衡器到每個 Pod 的延遲時間。由於延遲不再以節點 IP 層級匯總，因此在 NEG 層級排解服務問題會更加容易。

支援 Cloud Service Mesh：必須使用 NEG 資料模型，才能使用 Google Cloud的服務網格全代管流量控制層 Cloud Service Mesh。

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

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

容器原生負載平衡器不支援區域性外部直通式網路負載平衡器。
請勿手動變更或更新 GKE 建立的應用程式負載平衡器設定。您所做的任何變更都會遭到 GKE 覆寫。

容器原生負載平衡器定價

您在本指南中建立的 Ingress 會佈建應用程式負載平衡器，因此您需要支付相關費用。如需負載平衡器定價資訊，請參閱 Cloud Load Balancing 定價頁面的「負載平衡和轉送規則」一節。

執行個體群組

使用執行個體群組時，Compute Engine 負載平衡器會將流量傳送至 VM IP 位址做為後端。在 VM 上執行容器時，容器會共用相同的主機介面，因此會有下列限制：

這會產生兩個負載平衡躍點：一個是從負載平衡器到 VM NodePort 的躍點，另一個是透過 kube-proxy 轉送至 Pod IP 位址 (可能位於不同的 VM) 的躍點。
額外的躍點會增加延遲時間，並使流量路徑更加複雜。
Compute Engine 負載平衡器無法直接查看 Pod，導致流量平衡不夠理想。
由於流量會經過兩次躍點，因此 VM 或 Pod 遺失等環境事件更可能導致流量間歇性遺失。

外部 Ingress 和使用路由的叢集

如果您使用使用路由的叢集搭配外部 Ingress，GKE Ingress 控制器就無法使用GCE_VM_IP_PORT網路端點群組 (NEG) 進行容器原生負載平衡。而是使用非代管執行個體群組後端，其中包含所有節點集區中的所有節點。如果LoadBalancer服務也使用這些未受管理的執行個體群組，可能會導致單一負載平衡執行個體群組限制相關問題。

在 VPC 原生叢集中建立的某些舊版外部 Ingress 物件，可能會在建立的每個外部應用程式負載平衡器後端服務上，使用執行個體群組後端。這與內部 Ingress 無關，因為內部 Ingress 資源一律使用 GCE_VM_IP_PORT NEG，且需要 VPC 原生叢集。

如要瞭解如何排解外部 Ingress 的 502 錯誤，請參閱「外部 Ingress 產生 HTTP 502 錯誤」。

GKE Ingress 控制器的限制

GKE Ingress 不支援由 Certificate Manager 管理的憑證。如要使用 Certificate Manager 管理的憑證，請使用 Gateway API。
在採用 NEG 的叢集中，Ingress 協調時間可能會受到 Ingress 數量的影響。舉例來說，如果叢集有 20 個 Ingress，每個 Ingress 包含 20 個不同的 NEG 後端，Ingress 變更的協調作業可能需要超過 30 分鐘。由於需要更多 NEG，這項異動對區域叢集的影響尤其明顯。
適用網址對應配額。
適用 Compute Engine 資源配額。
如果未搭配使用 NEG 與 GKE Ingress 控制器，GKE 叢集的節點數量上限為 1,000 個。使用 NEG 部署服務時，GKE 節點沒有數量限制。如果叢集節點超過 1,000 個，透過 Ingress 公開的任何非 NEG 服務都無法正常運作。
如要讓 GKE Ingress 控制器使用 readinessProbes 做為健康狀態檢查，Ingress 的 Pod 必須在建立 Ingress 時存在。如果副本縮放為 0，系統會套用預設健康狀態檢查。詳情請參閱這則 GitHub 問題留言。
Pod 的 readinessProbe 變更不會影響建立後的 Ingress。
外部應用程式負載平衡器會在全球分散的位置終止 TLS，盡可能縮短用戶端與負載平衡器之間的延遲時間。如要控管 TLS 終止的地理位置，請改用透過 LoadBalancer 類型的 GKE 服務公開的自訂 Ingress 控制器，並在位於適當區域的後端終止 TLS。
系統不支援將多個 Ingress 資源合併為單一 Google Cloud 負載平衡器。
您必須關閉應用程式的 mTLS，因為外部應用程式負載平衡器不支援這項功能。
Ingress 只能為前端公開 HTTP 通訊埠 80 和 443。