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

自動駕駛標準

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

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

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

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

總覽

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

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

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

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

Kubernetes Service 物件和Google Cloud 後端服務物件的用途相似，但有所不同。雖然兩者密切相關，但這種關係不一定是一對一。

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 叢集外部但 VPC 網路內的 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) 要求應到達的位置。

區域的內部應用程式負載平衡器會使用 VPC 網路中該區域的僅限 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 End 或 Envoy Proxy 的應用程式流量。
如果您設定了 TLS，則為目標 HTTP Proxy 和目標 HTTPS Proxy。
網址對應，其中單一主機規則參照單一路徑比對器。路徑比對器有兩項路徑規則，分別適用於 /* 和 /discounted。每個路徑規則都會對應至專屬的後端服務。
NEG，其中包含每個服務的 Pod IP 位址清單做為端點。這些是 my-discounted-products 和 my-products 服務的結果。

負載平衡方法

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

容器原生負載平衡

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

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

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

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

叢集是虛擬私有雲原生叢集。
叢集未使用共用虛擬私有雲網路。
叢集未使用 GKE 網路政策。
叢集已啟用 HttpLoadBalancing 外掛程式。根據預設，GKE 叢集已啟用 HttpLoadBalancing 外掛程式，不得停用該功能。

GKE 啟用容器原生負載平衡後，系統會自動使用 cloud.google.com/neg: '{"ingress": true}' 註解 Service。這個註解會觸發建立與 Pod IP 相對應的 NEG，讓 Compute Engine 負載平衡器直接與 Pod 通訊。

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

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

優點

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

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

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

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

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

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

透過 GKE 上的 Ingress 建立的容器原生負載平衡器有下列限制：

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

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

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

執行個體群組

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

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

外部 Ingress 和使用路由的叢集

如果您使用以路徑為基礎的叢集和外部輸入，GKE 輸入控制器就無法使用容器原生負載平衡，也就是無法使用 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 資源的配額。
如果您未使用 NEGs 搭配 GKE 輸入控制器，則 GKE 叢集的節點數上限為 1,000 個。使用 NEG 部署服務時，沒有 GKE 節點限制。如果叢集節點超過 1,000 個，透過 Ingress 公開的任何非 NEG 服務都無法正常運作。
要使 GKE Ingress 控制器使用 readinessProbes 作為健康狀況檢查，則 Ingress 的 Pod 必須在 Ingress 建立時存在。如果您的複本縮放為 0，則將套用預設的健康狀況檢查。詳情請參閱這則 GitHub 問題評論。
Pod 的 readinessProbe 變更，在 Ingress 建立後便不會對其造成影響。
外部應用程式負載平衡器終止 TLS 的位置分散在世界各地，這樣可縮短用戶端與負載平衡器之間的延遲。如果需要對 TLS 終止位置進行地理位置控制，則應使用透過 GKE 服務 (類型為 LoadBalancer) 公開的自訂輸入控制器，並在適合您需求之地區中的後端終止 TLS。
系統不支援將多個 Ingress 資源合併為單一 Google Cloud 負載平衡器。
您必須關閉應用程式的 mTLS，因為外部應用程式負載平衡器不支援這項功能。
Ingress 只能為前端公開 HTTP 通訊埠 80 和 443。