內部應用程式負載平衡器總覽

本文將介紹設定內部應用程式負載平衡器時需要瞭解的概念。

Google Cloud 內部應用程式負載平衡器是以 Proxy 為基礎的第 7 層負載平衡器，可讓您透過單一內部 IP 位址執行服務及調度服務資源。內部應用程式負載平衡器會將 HTTP 和 HTTPS 流量分配給各種 Google Cloud 平台 (例如 Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Run) 上託管的後端。詳情請參閱「用途」。

運作模式

您可以透過下列模式設定內部應用程式負載平衡器：

  • 跨區域內部應用程式負載平衡器。這項多區域負載平衡器是以開放原始碼 Envoy Proxy 為基礎的代管服務。跨區域模式可將流量平均分配到遍布全球的後端服務，包括流量管理功能，可確保將流量導向與轉送規則最接近的後端。這個負載平衡器也支援高可用性。將後端放在多個區域，有助於避免單一區域發生故障。如果某個區域的後端服務中斷，流量可以容錯移轉至其他區域。

  • 區域性內部應用程式負載平衡器。這項區域性負載平衡器是以開放原始碼 Envoy Proxy 為基礎的代管服務。區域模式要求後端必須位於單一 Google Cloud 區域。用戶端可以限制在該區域，也可以位於任何區域，具體取決於轉送規則是否停用或啟用全域存取權。這個負載平衡器可讓您依據 HTTP 或 HTTPS 參數，運用豐富的流量管理功能。設定負載平衡器後，系統會因應流量需求，自動分配 Envoy Proxy 數量。

    下表說明跨區域和區域模式之間的重要差異：

    負載平衡器模式 功能
    負載平衡器的虛擬 IP 位址 (VIP) 用戶端存取權 負載平衡後端 高可用性和容錯移轉
    跨區域內部應用程式負載平衡器 從特定 Google Cloud 區域的子網路分配。

    多個區域的 VIP 位址可以共用同一個全域後端服務。您可以使用 DNS 路由政策，將用戶端要求轉送至最接近的 VIP 位址，設定以 DNS 為基礎的全域負載平衡。

    		 全球皆可存取。虛擬私有雲中任何 Google Cloud 區域的用戶端，都能將流量傳送至負載平衡器。 全域後端。
    負載平衡器可將流量傳送至任何區域的後端。    		 自動容錯移轉至相同或不同區域中健康狀態良好的後端。
    區域性內部應用程式負載平衡器 從特定 Google Cloud 區域的子網路分配。 預設無法從全球各地存取。
    您可以選擇 啟用全域存取權。    		 區域性後端。
    負載平衡器只能將流量傳送至與負載平衡器 Proxy 位於相同區域的後端。    		 自動容錯移轉至同一區域內健康狀態良好的後端。

找出眾數

控制台

  1. 前往 Google Cloud 控制台的「Load balancing」(負載平衡) 頁面。

    前往「Load balancing」(負載平衡)

  2. 在「Load Balancers」(負載平衡器) 分頁中，您可以查看負載平衡器類型、通訊協定和區域。如果區域為空白，則負載平衡器處於跨區域模式。下表摘要說明如何識別負載平衡器的模式。

    負載平衡器模式 負載平衡器類型 存取權類型 區域
    跨區域內部應用程式負載平衡器 應用程式 內部
    區域性內部應用程式負載平衡器 應用程式 內部 指定區域

gcloud

  1. 如要判斷負載平衡器的模式，請執行下列指令：

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    在指令輸出內容中，檢查負載平衡配置、區域和網路層級。下表彙整了如何判斷負載平衡器的模式。

    負載平衡器模式 負載平衡架構 轉送規則
    跨區域內部應用程式負載平衡器 INTERNAL_MANAGED 全球
    區域性內部應用程式負載平衡器 INTERNAL_MANAGED 區域

架構與資源

下圖顯示內部應用程式負載平衡器所需的 Google Cloud 資源：

跨區域內部應用程式負載平衡器

這張圖表顯示在相同虛擬私有雲網路中，進階級跨區域內部應用程式負載平衡器部署作業的元件。每項全域轉送規則都會使用用戶端連線時採用的區域性 IP 位址。

跨區域內部應用程式負載平衡器元件。
跨區域內部應用程式負載平衡器元件 (按一下即可放大)。

區域性內部應用程式負載平衡器

這張圖表顯示進階級區域性內部應用程式負載平衡器部署作業的元件。

區域性內部應用程式負載平衡器元件。
區域性內部應用程式負載平衡器元件 (按一下即可放大)。

部署內部應用程式負載平衡器時，需要下列資源：

Proxy 專用子網路

在上圖中，僅限 Proxy 子網路提供一組 IP 位址，Google 會使用這些位址代您執行 Envoy Proxy。在您使用內部應用程式負載平衡器的虛擬私有雲網路中，每個區域都必須建立 Proxy 專用子網路。

下表說明跨區域和區域模式中，僅限 Proxy 子網路的差異。跨區域和區域性負載平衡器無法共用相同子網路。

負載平衡器模式 Proxy 專用子網路 --purpose 旗標的值
跨區域內部應用程式負載平衡器

GLOBAL_MANAGED_PROXY

在設定負載平衡器的每個區域中，跨區域 Envoy 型負載平衡器都必須有僅限 Proxy 的子網路。位於相同區域和網路的跨區域負載平衡器 Proxy 會共用同一個 Proxy 專用子網路。
區域性內部應用程式負載平衡器

REGIONAL_MANAGED_PROXY

在一個區域和虛擬私有雲網路中，所有區域性 Envoy 型負載平衡器都會共用同一個僅限 Proxy 子網路。

其他：

  • Proxy 專用子網路僅用於 Envoy Proxy，不適用於後端。
  • 區域和虛擬私有雲網路中所有內部應用程式負載平衡器的後端 VM 或端點，都會從 Proxy 專用子網路接收連線。
  • 對於區域內部應用程式負載平衡器和跨區域內部應用程式負載平衡器，Proxy 專用子網路可設定為 IPV4_IPV6 (雙堆疊) 堆疊類型。
  • 內部應用程式負載平衡器的虛擬 IP 位址「不」位於僅限 Proxy 子網路中。負載平衡器的 IP 位址是由內部代管轉送規則定義，詳情請參閱下文。

轉送規則和 IP 位址

轉送規則會依據 IP 位址、通訊埠和通訊協定，將流量轉送至由目標 Proxy 和後端服務組成的負載平衡設定。

IP 位址規格。每條轉送規則都會參照單一區域 IP 位址，您可以在應用程式的 DNS 記錄中使用該位址。您可以預留靜態 IP 位址供使用，也可以讓 Cloud Load Balancing 指派位址。建議您預留靜態 IP 位址，否則每次刪除轉送規則並建立新規則時，都必須使用新指派的臨時 IP 位址更新 DNS 記錄。

用戶端會使用 IP 位址和通訊埠連線至負載平衡器的 Envoy Proxy，轉送規則的 IP 位址則是負載平衡器的 IP 位址 (有時稱為虛擬 IP 位址或 VIP)。連線至負載平衡器的用戶端必須使用 HTTP 1.1 以上版本。如需支援的完整通訊協定清單，請參閱「負載平衡器功能比較」。

與轉送規則相關聯的內部 IP 位址，可來自與後端位於相同網路和區域的子網路。

通訊埠規格。應用程式負載平衡器的每項轉送規則都可以參照 1 到 65535 之間的單一連接埠。如要支援多個連接埠，請設定多個轉送規則。您可以設定多個轉送規則，使用相同的內部 IP 位址 (VIP)，並參照相同的目標 HTTP 或 HTTPS Proxy，只要每個轉送規則的 IP 位址、通訊埠和通訊協定整體組合不重複即可。這樣一來，您就能使用單一負載平衡器和共用網址對應，做為多個應用程式的 Proxy。

內部應用程式負載平衡器使用的轉送規則、IP 位址和負載平衡架構類型，取決於負載平衡器的模式。

跨區域內部應用程式負載平衡器
轉送規則

globalForwardingRules.insert 方法
區域 IP 位址

addresses.insert 方法
負載平衡架構

INTERNAL_MANAGED
IP 位址 (選填)

SHARED_LOADBALANCER_VIP
從用戶端轉送至負載平衡器的前端

系統預設會啟用全域存取權，允許虛擬私有雲中任何區域的用戶端存取負載平衡器。後端可位於多個區域。
區域性內部應用程式負載平衡器
轉送規則

forwardingRules.insert 方法
區域 IP 位址

addresses.insert 方法
負載平衡架構

INTERNAL_MANAGED
IP 位址 (選填)

SHARED_LOADBALANCER_VIP
從用戶端轉送至負載平衡器的前端

您可以啟用全域存取權，允許虛擬私有雲中任何區域的用戶端存取負載平衡器。後端也必須與負載平衡器位於相同區域。

轉送規則和虛擬私有雲網路

本節說明內部應用程式負載平衡器使用的轉送規則，如何與虛擬私有雲網路建立關聯。

負載平衡器模式 虛擬私有雲網路關聯
跨區域內部應用程式負載平衡器

區域性內部應用程式負載平衡器

無論您使用 IPv4 位址或 IPv6 位址範圍，轉送規則一律會明確或隱含地與虛擬私有雲網路建立關聯。

區域內部 IPv4 位址和 IPv6 位址範圍一律位於虛擬私有雲網路內。建立轉送規則時，您必須指定要從哪個子網路取得內部 IP 位址。這個子網路必須與已建立 Proxy 專用子網路的區域和虛擬私有雲網路相同。因此，這代表網路有關聯。

網路和子網路需求。如要使用 IPv6 流量，網路和子網路必須符合下列設定規定：

  • 虛擬私有雲網路：您必須使用設有 --enable-ula-internal-ipv6 旗標的自訂模式虛擬私有雲網路。
  • 轉送規則子網路：這個子網路必須是雙重堆疊 (IPv4_IPv6) 或 IPV6_ONLY 子網路，且 ipv6-access-type 設為 INTERNAL。

IPv6 位址分配選項。轉送規則必須參照子網路 /64 內部 IPv6 位址範圍的 /96 IPv6 位址範圍。使用 --ip-version=IPV6 旗標設定轉送規則時， Google Cloud會自動從子網路範圍內分配隨機 /96 IPv6 前置字串。

限制。如要指定自訂臨時 IPv6 位址，請使用 Google Cloud CLI 或 API。 Google Cloud 控制台不支援為轉送規則指定自訂臨時 IPv6 位址。

目標 Proxy

目標 HTTP 或 HTTPS Proxy 會終止來自用戶端的 HTTP(S) 連線。HTTP(S) Proxy 會參考網址對應，決定如何將流量轉送至後端。目標 HTTPS Proxy 會使用 SSL 憑證向用戶端驗證自身身分。

負載平衡器會保留原始用戶端要求的主機標頭。

視應用程式需要處理的流量類型而定，您可以設定負載平衡器，使用目標 HTTP Proxy 或目標 HTTPS Proxy。

下表列出內部應用程式負載平衡器所需的目標 Proxy API：

負載平衡器模式 目標 Proxy
跨區域內部應用程式負載平衡器
區域性內部應用程式負載平衡器

X-Forwarded-For 標頭處理

負載平衡器會將兩個 IP 位址附加至 X-Forwarded-For 標頭：

  • 連線至負載平衡器的用戶端 IP 位址
  • 負載平衡器轉送規則的 IP 位址

如果傳入的要求沒有 X-Forwarded-For 標頭，這兩個 IP 位址就是整個標頭值。如果要求含有 X-Forwarded-For 標頭，系統會先保留其他資訊 (例如 Proxy 在傳送至負載平衡器途中記錄的 IP 位址)，再保留這兩個 IP 位址。

如果您將 Proxy 做為後端伺服器執行，這個 Proxy 通常會將更多資訊附加至 X-Forwarded-For 標頭，而您的軟體可能需要考量這一點。負載平衡器傳送的 Proxy 要求來自 Proxy 專用子網路中的 IP 位址，後端執行個體上的 Proxy 可能會記錄這個位址和後端執行個體本身的 IP 位址。

內部應用程式負載平衡器會對 X-Forwarded-For 標頭採取特定安全措施：

  • 標頭清理 (移除)。如果用戶端和負載平衡器之間有中繼 Proxy，負載平衡器會將傳入的 X-Forwarded-For 標頭視為不受信任，並移除標頭以防止 IP 詐欺。沒有設定選項可變更這項行為。
  • 附加行為。自訂標頭可用於建立新的 X-Forwarded-For 標頭，並插入用戶端 IP 和伺服器 IP。不過，在這種情況下，從負載平衡器的角度來看，用戶端 IP 是中繼 Proxy IP，而非原始用戶端 IP。

使用中介 Proxy 保留用戶端 IP

如果流量在到達內部應用程式負載平衡器之前，會先經過中介 Proxy，則只有在 X-Forwarded-For 標頭中存在的原始用戶端 IP 會遭到移除。

如要確保保留用戶端 IP，請採取下列建議做法：

  • 使用自訂標頭。設定中繼 Proxy，將已驗證的用戶端 IP 插入自訂標頭。例如：X-Original-Client-IP 或 X-Client-IP。
  • 直通設定。內部應用程式負載平衡器會將自訂標頭原封不動地傳遞至後端。
  • 後端更新。更新後端應用程式，從新的自訂標頭 (而非 X-Forwarded-For) 讀取用戶端 IP。

SSL 憑證

使用目標 HTTPS Proxy 的內部應用程式負載平衡器需要私密金鑰和 SSL 憑證，做為負載平衡器設定的一部分。

下表列出內部應用程式負載平衡器在各模式下所需的 SSL 憑證類型：

負載平衡器模式 SSL 憑證類型
跨區域內部應用程式負載平衡器

Certificate Manager 自行管理的憑證和 Google 代管的憑證。

Certificate Manager 支援下列類型的 Google 代管憑證：

不支援具備負載平衡器授權的 Google 代管憑證。

不支援 Compute Engine SSL 憑證。
區域性內部應用程式負載平衡器

Compute Engine 區域性 SSL 憑證

Certificate Manager 區域性自行管理憑證 和 Google 代管憑證。

Certificate Manager 支援下列類型的 Google 代管憑證：

系統不支援使用負載平衡器授權的 Google 代管憑證。

網址對應

目標 HTTP(S) Proxy 會使用網址對應，根據 HTTP 屬性 (例如要求路徑、Cookie 或標頭) 做出轉送決策。根據轉送決策，Proxy 會將用戶端要求轉送至特定後端服務。網址對應可指定要執行的其他動作，例如重寫標頭、將重新導向傳送給用戶端，以及設定逾時政策 (等等)。

下表列出各模式的內部應用程式負載平衡器所需的網址對應表類型：

負載平衡器模式 網址對應類型
跨區域內部應用程式負載平衡器 urlMaps
區域性內部應用程式負載平衡器 regionUrlMaps

後端服務

後端服務會向負載平衡器提供設定資訊，讓負載平衡器將要求導向後端，例如 Compute Engine 執行個體群組或網路端點群組 (NEG)。如要進一步瞭解後端服務，請參閱「後端服務總覽」。

後端服務範圍

下表列出內部應用程式負載平衡器使用的後端服務資源和範圍：

負載平衡器模式 後端服務資源
跨區域內部應用程式負載平衡器 backendServices
區域性內部應用程式負載平衡器 regionBackendServices

後端的通訊協定

應用程式負載平衡器的後端服務必須使用下列其中一種通訊協定，將要求傳送至後端：

  • HTTP：使用 HTTP/1.1，不使用 TLS
  • HTTPS (使用 HTTP/1.1 和 TLS)
  • HTTP/2：使用 HTTP/2 和 TLS (不支援未加密的 HTTP/2)。
  • H2C：透過 TCP 使用 HTTP/2。不需要 TLS。傳統版應用程式負載平衡器不支援 H2C。

負載平衡器只會使用您指定的後端服務通訊協定，與後端通訊。如果負載平衡器無法使用指定的後端服務通訊協定與後端通訊，就不會改用其他通訊協定。

後端服務通訊協定不一定要與用戶端用來與負載平衡器通訊的通訊協定相符。舉例來說，用戶端可以使用 HTTP/2 將要求傳送至負載平衡器，但負載平衡器可以使用 HTTP/1.1 (HTTP 或 HTTPS) 與後端通訊。

後端

下表列出內部應用程式負載平衡器在各模式中支援的後端功能。


負載平衡器模式 		後端服務支援的後端1 支援後端 bucket 支援 Cloud Armor 支援 Cloud CDN 支援 IAP 支援 Service Extensions
執行個體群組2 可用區 NEG3 網際網路 NEG 無伺服器 NEG 混合式 NEG Private Service Connect NEG
跨區域內部應用程式負載平衡器
Cloud Run
區域性內部應用程式負載平衡器
Cloud Run

1 後端服務上的後端必須是相同類型：所有執行個體群組或所有相同類型的 NEG。不過，區域 NEG 和混合式 NEG 可用於同一個後端服務，以支援混合式架構。GCE_VM_IP_PORT

2 同一後端服務支援可用區非代管、可用區代管和區域代管執行個體群組的組合。如果代管執行個體群組是兩個以上後端服務的後端，請將執行個體群組的自動調度資源政策設為使用 多個信號。

3 區域 NEG 必須使用 GCE_VM_IP_PORT 端點。

後端和虛擬私有雲網路

後端位置的限制取決於後端類型。

  • 如果是執行個體群組、可用區 NEG 和混合式連線 NEG，所有後端都必須與後端服務位於相同的專案和區域。不過，負載平衡器可以參照與後端服務位於相同專案，但使用不同虛擬私有雲網路的後端。 您可以使用虛擬私有雲網路對接、Cloud VPN 通道、Cloud Interconnect VLAN 連結或 Network Connectivity Center 架構，設定負載平衡器虛擬私有雲網路與後端虛擬私有雲網路之間的連線。

    後端網路定義

    • 如果是可用區 NEG 和混合型 NEG，您必須在建立 NEG 時明確指定虛擬私有雲網路。
    • 如果是代管執行個體群組，虛擬私有雲網路則是在執行個體範本中定義。
    • 對於非代管執行個體群組，系統會設定執行個體群組的虛擬私有雲網路，以符合新增至執行個體群組的第一個 VM 的 nic0 介面虛擬私有雲網路。

    後端網路需求

    後端網路必須符合下列其中一項網路規定：

    • 後端的虛擬私有雲網路必須與轉送規則的虛擬私有雲網路完全相符。

    • 後端的虛擬私有雲網路必須使用虛擬私有雲網路對接，連線至轉送規則的虛擬私有雲網路。您必須設定子網路路徑交換，才能在轉送規則的虛擬私有雲網路中，允許 Proxy 專用子網路與後端執行個體或端點使用的子網路之間進行通訊。

    後端 IPv6 子網路需求

    前端連線使用的 IP 版本與後端連線無關。由於僅限 Proxy 子網路為雙重堆疊 (IPV4_IPV6)，因此僅限 Proxy 子網路可以使用 IPv4 或 IPv6 與後端通訊。

    如果後端執行個體處理 IPv6 流量，後端子網路可設定為 IPV4_ONLY 或 IPV4_IPV6 (雙重堆疊) 堆疊類型。如果後端子網路的堆疊類型包含 IPv6，您必須將子網路的 ipv6-access-type 明確設為 INTERNAL。

  • 後端的虛擬私有雲網路和轉送規則的虛擬私有雲網路都必須是VPC 輪輻，且連接至同一個 NCC 中樞。匯入和匯出篩選器必須允許轉送規則虛擬私有雲網路中的僅限 Proxy 子網路，與後端執行個體或端點使用的子網路進行通訊。

  • 如果是其他後端類型，所有後端都必須位於同一個虛擬私有雲網路和區域。

後端和網路介面

如果使用執行個體群組後端，封包一律會傳送至 nic0。如要將封包傳送至非 nic0 介面 (vNIC 或動態網路介面)，請改用 NEG 後端。

如果您使用可用區 NEG 後端，封包會傳送至 NEG 中端點代表的任何網路介面。NEG 端點必須與 NEG 明確定義的虛擬私有雲網路位於同一個虛擬私有雲網路。

後端子集

後端子集是區域性內部應用程式負載平衡器支援的選用功能，可將後端子集指派給各個 Proxy 執行個體，提升效能和擴充性。

後端子集功能預設為停用。 如要瞭解如何啟用這項功能，請參閱「區域內部應用程式負載平衡器的後端子設定」。

健康狀態檢查

每個後端服務都會指定健康狀態檢查，定期監控後端是否已準備好接收負載平衡器的連線。這樣可降低要求傳送至無法處理要求的後端的風險。健康狀態檢查不會檢查應用程式本身是否正常運作。

為確保健康狀態檢查探測成功，您必須建立輸入允許防火牆規則，允許健康狀態檢查探測到達後端執行個體。健康狀態檢查探測通常源自 Google 的集中式健康狀態檢查機制。不過，如果是混合式 NEG，健康狀態檢查會來自僅限 Proxy 的子網路。詳情請參閱「分散式 Envoy 健康狀態檢查」。

健康狀態檢查通訊協定

雖然不一定可行，但最佳做法是使用通訊協定與後端服務通訊協定相符的健康狀態檢查。 舉例來說，HTTP/2 健康狀態檢查最能準確測試與後端的 HTTP/2 連線能力。相較之下，使用混合型 NEG 後端的內部應用程式負載平衡器不支援 gRPC 健康狀態檢查。如需支援的健康狀態檢查通訊協定清單，請參閱「健康狀態檢查」一節中的負載平衡功能。

下表列出內部應用程式負載平衡器支援的健康狀態檢查範圍：

負載平衡器模式 健康狀態檢查類型
跨區域內部應用程式負載平衡器 healthChecks
區域性內部應用程式負載平衡器 regionHealthChecks

如要進一步瞭解健康狀態檢查，請參閱下列資源：

防火牆規則

內部應用程式負載平衡器需要下列防火牆規則：

  • 允許來自 Google 中央健康狀態檢查範圍的流量。如要進一步瞭解特定健康狀態檢查探測 IP 位址範圍，以及為何必須允許來自這些範圍的流量，請參閱「探測 IP 範圍和防火牆規則」。
  • 允許輸入的規則，允許來自僅限 Proxy 的子網路的流量。

這些範圍的防火牆規則規定有特定例外狀況：

  • 混合式 NEG 不需要允許來自 Google 健康狀態檢查探測範圍的流量。不過，如果您在單一後端服務中同時使用混合式和可用區 NEG，則必須允許來自Google 健康狀態檢查探測範圍的流量，才能使用可用區 NEG。
  • 區域性網際網路 NEG 的健康狀態檢查為選用。使用區域性網際網路 NEG 的負載平衡器流量，會來自僅限 Proxy 的子網路，然後透過 Cloud NAT 轉譯為 NAT IP 位址 (手動或自動分配)。這類流量包括健康狀態檢查探測，以及從負載平衡器傳送至後端的使用者要求。詳情請參閱「區域 NEG：使用 Cloud NAT 閘道」。

使用 Cloud Next Generation Firewall (Cloud NGFW) 防火牆政策規則，控管用戶端對 Envoy Proxy 負載平衡器 (例如區域性內部應用程式負載平衡器和跨區域內部應用程式負載平衡器) 轉送規則的存取權。Cloud NGFW Essentials 和 Cloud NGFW Standard 都支援這些功能。針對跨區域內部應用程式負載平衡器，Cloud NGFW 也提供進階第 7 層威脅防護功能 (預先發布版)。詳情請參閱「使用全域網路防火牆政策保護 Envoy 型負載平衡器」和「使用區域性網路防火牆政策保護內部應用程式負載平衡器和內部 Proxy 網路負載平衡器」。

用戶端存取權

用戶端可以位於相同網路，或透過虛擬私有雲網路對接連線的虛擬私有雲網路。

對於跨區域內部應用程式負載平衡器，全域存取權預設為啟用。虛擬私有雲中任何區域的用戶端，都能存取負載平衡器。

根據預設，如果是區域性內部應用程式負載平衡器，用戶端必須與負載平衡器位於相同區域。您可以啟用全域存取權，允許虛擬私有雲中任何區域的用戶端存取負載平衡器。

下表摘要說明區域性內部應用程式負載平衡器的用戶端存取權：

已停用全域存取權 已啟用全域存取權
用戶端必須與負載平衡器位於相同區域。此外，這些執行個體必須與負載平衡器位於同一個虛擬私有雲網路，或是透過虛擬私有雲網路對等互連，連線至負載平衡器的虛擬私有雲網路。 用戶端可位於任何區域。不過，這些端點仍須與負載平衡器位於相同的虛擬私有雲網路，或透過虛擬私有雲網路對等互連，連線至負載平衡器的虛擬私有雲網路。
地端部署用戶端可以透過 Cloud VPN 通道或 VLAN 連結存取負載平衡器。這些通道或連結必須與負載平衡器位於相同區域。 地端部署用戶端可以透過 Cloud VPN 通道或 VLAN 連結存取負載平衡器。這些通道或附件可位於任何區域。

GKE 支援

GKE 會以下列方式使用內部應用程式負載平衡器：

  • 使用 GKE Gateway 控制器建立的內部閘道，可使用內部應用程式負載平衡器的任何模式。您可以選擇 GatewayClass 來控制負載平衡器的模式。GKE Gateway 控制器一律使用GCE_VM_IP_PORT區域 NEG 後端。

  • 使用 GKE Ingress 控制器建立的內部 Ingress 一律是區域內部應用程式負載平衡器。GKE Ingress 控制器一律使用GCE_VM_IP_PORT區域 NEG 後端。

Shared VPC 架構

內部應用程式負載平衡器支援使用 Shared VPC 的網路。Shared VPC 可讓機構將多項專案中的資源連線至共同的虛擬私有雲網路，以便透過該網路中的內部 IP，以更安全有效率的方式相互通訊。如果您不熟悉 Shared VPC，請參閱總覽說明文件。

在 Shared VPC 虛擬私有雲網路中，設定內部應用程式負載平衡器的方式有很多種。無論部署類型為何，負載平衡器的所有元件都必須位於同一個組織。

子網路和 IP 位址 前端元件 後端元件

在 Shared VPC 主專案中，建立必要的網路和子網路 (包括僅限 Proxy 的子網路)。

負載平衡器的內部 IP 位址可在主專案或服務專案中定義，但必須使用主專案中所需 Shared VPC 虛擬私有雲網路的子網路。位址本身來自參照子網路的主要 IP 範圍。

 區域性內部 IP 位址、轉送規則、目標 HTTP(S) Proxy 和相關聯的網址對應，都必須在同一個專案中定義。這個專案可以是主專案或服務專案。 你可以採取下列任一做法：
  • 在與前端元件相同的服務專案中，建立後端服務和後端 (執行個體群組、無伺服器 NEG 或任何其他支援的後端類型)。
  • 視需要建立後端服務和後端 (執行個體群組、無伺服器 NEG 或任何其他支援的後端類型)，數量不限。單一網址對應表可以參照不同專案中的後端服務。這類部署作業稱為跨專案服務參照。

每個後端服務都必須在與其參照後端相同的專案中定義。與後端服務相關聯的健康狀態檢查，也必須在後端服務所在的專案中定義。

雖然您可以在 Shared VPC 主專案中建立所有負載平衡元件和後端，但這類部署作業不會區分網路管理員和服務開發人員的責任。

服務專案中的所有負載平衡器元件和後端

下列架構圖顯示標準 Shared VPC 部署，其中所有負載平衡器元件和後端都位於服務專案中。所有應用程式負載平衡器都支援這種部署類型。

負載平衡器會使用主專案的 IP 位址和子網路。如果用戶端與負載平衡器位於相同的 Shared VPC 網路和區域，則可存取內部應用程式負載平衡器。用戶端可以位於主專案、附加的服務專案或任何連結的網路。

Shared VPC 網路中的內部應用程式負載平衡器。
Shared VPC 虛擬私有雲網路上的內部應用程式負載平衡器 (按一下可放大)。

Shared VPC 環境中的無伺服器後端

如果內部應用程式負載平衡器使用無伺服器 NEG 後端，則支援的 Cloud Run 服務必須與後端服務和無伺服器 NEG 位於同一個服務專案中。負載平衡器的前端元件 (轉送規則、目標 Proxy、網址對應) 可以在主專案、與後端元件相同的服務專案，或相同 Shared VPC 環境中的任何其他服務專案中建立。

跨專案參照服務

跨專案服務參照是一種部署模型，負載平衡器的前端和網址對應表位於一個專案，負載平衡器的後端服務和後端則位於另一個專案。

透過跨專案服務參照，機構可以設定一個中央負載平衡器，並將流量導向分散在多個不同專案中的數百項服務。您可以在單一網址對應中，集中管理所有流量轉送規則和政策。您也可以將負載平衡器與一組主機名稱和 SSL 憑證建立關聯。因此，您可以視需求調整部署應用程式所需的負載平衡器數量，並降低可管理性、營運成本和配額需求。

為每個職能團隊建立不同的專案，也能區隔組織內的角色。服務擁有者可以專注於在服務專案中建構服務，而網路團隊則可以在另一個專案中佈建及維護負載平衡器，兩者都可以使用跨專案服務參照進行連結。

服務擁有者可透過負載平衡器，自主控管服務曝光度，並決定哪些使用者可以存取服務。這項操作是透過名為「Compute 負載平衡器服務使用者角色」(roles/compute.loadBalancerServiceUser) 的特殊 IAM 角色完成。

如果是內部應用程式負載平衡器，則僅支援在 Shared VPC 環境中參照跨專案服務。

如要瞭解如何為內部應用程式負載平衡器設定 Shared VPC (無論是否使用跨專案服務參照)，請參閱「使用 Shared VPC 設定內部應用程式負載平衡器」。

跨專案服務參照的使用注意事項

  • 如果後端服務具有區域性網際網路 NEG 後端，則無法參照跨專案後端服務。支援所有其他後端類型。
  • Google Cloud 不會區分多個專案中名稱相同的資源 (例如後端服務)。因此，使用跨專案服務參照時，建議您在組織內的所有專案中，使用不重複的後端服務名稱。

範例 1：負載平衡器的前端和後端位於不同的服務專案

以下是 Shared VPC 部署作業範例，其中負載平衡器的前端和網址對應是在服務專案 A 中建立，而網址對應則參照服務專案 B 中的後端服務。

在本例中，服務專案 A 的網路管理員或負載平衡器管理員需要存取服務專案 B 的後端服務。服務專案 B 管理員將 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser) 授予服務專案 A 的負載平衡器管理員，後者想要參照服務專案 B 的後端服務。

服務專案中的負載平衡器前端和網址對應。
負載平衡器的前端和後端位於不同的服務專案 (按一下可放大)。

範例 2：負載平衡器前端位於主專案，後端位於服務專案

以下是 Shared VPC 部署作業的範例，其中負載平衡器的前端和網址對應是在主專案中建立，後端服務 (和後端) 則是在服務專案中建立。

在本例中，主專案中的網路管理員或負載平衡器管理員需要存取服務專案中的後端服務。服務專案管理員會將 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser) 授予主專案 A 中，想要參照服務專案中後端服務的負載平衡器管理員。

主專案中的負載平衡器前端和網址對應。
主專案中的負載平衡器前端和網址對應 (按一下可放大)。

逾時和重試

內部應用程式負載平衡器支援下列逾時類型：

逾時類型和說明 預設值 支援自訂值
跨區域 區域
後端服務逾時

要求和回應逾時。代表負載平衡器將要求的第一個位元組傳送至後端，到後端將 HTTP 回應的最後一個位元組傳回負載平衡器之間，允許的時間長度上限。如果後端未在這段時間內將完整的 HTTP 回應傳回負載平衡器，系統就會捨棄剩餘的回應資料。
  • 後端服務上的無伺服器 NEG：60 分鐘
  • 後端服務的所有其他後端類型：30 秒
用戶端 HTTP 保持運作逾時

用戶端與負載平衡器管理 Envoy Proxy 之間的 TCP 連線可閒置的最長時間。(同一個 TCP 連線可能用於多個 HTTP 要求)。

 610 秒
後端 HTTP 保持運作逾時

負載平衡器代管的 Envoy Proxy 與後端之間的 TCP 連線，最多可以閒置多久。(多個 HTTP 要求可能會使用同一個 TCP 連線)。

 10 分鐘 (600 秒)

後端服務逾時

可設定的後端服務逾時是指負載平衡器等待後端處理 HTTP 要求並傳回對應 HTTP 回應的時間上限。除了無伺服器 NEG 以外，後端服務逾時的預設值為 30 秒。

舉例來說，假設您要下載 500 MB 的檔案，後端服務逾時值為 90 秒，則負載平衡器會預期後端在 90 秒內傳送整個 500 MB 的檔案。如果後端服務逾時時間設定過短，後端可能無法傳送完整的 HTTP 回應。在這種情況下，如果負載平衡器至少已從後端收到 HTTP 回應標頭，就會傳回完整的回應標頭，以及在後端服務逾時前可取得的回應主體。

建議您將後端服務逾時時間設為後端處理 HTTP 回應所需的最長時間。如果後端執行的軟體需要更多時間處理 HTTP 要求並傳回完整回應，建議您提高後端服務逾時時間。

後端服務逾時接受介於 1 至 2,147,483,647 秒之間的值，但較大的值並非實用的設定選項。Google Cloud 也不保證基礎 TCP 連線在後端服務逾時的整個值期間都能保持開啟。用戶端系統必須實作重試邏輯，而非依賴長時間開啟的 TCP 連線。

如果是搭配內部應用程式負載平衡器使用的 WebSocket 連線，作用中的 WebSocket 連線不會遵循後端服務逾時設定。後端服務逾時後，閒置的 WebSocket 連線會關閉。

Google Cloud 定期重新啟動或變更服務 Envoy 軟體工作數量。後端服務逾時值越長，Envoy 工作重新啟動或替換時，終止 TCP 連線的可能性就越高。

如要設定後端服務逾時，請使用下列其中一種方法：

控制台

修改負載平衡器後端服務的「逾時」欄位。

gcloud

使用 gcloud compute backend-services update 指令修改後端服務資源的 --timeout 參數。

API

修改 regionBackendServices 資源的 timeoutSec 參數

用戶端 HTTP 保持運作逾時

「用戶端 HTTP 保持運作逾時」是指 TCP 連線在 (下游) 用戶端和 Envoy Proxy 之間可閒置的時間長度上限。用戶端 HTTP 保持運作逾時時間的預設值為 610 秒。您可以將逾時時間設為 5 到 1200 秒之間的值。

HTTP 保持運作逾時也稱為 TCP 閒置逾時。

負載平衡器的用戶端 HTTP 保持運作逾時時間，必須大於下游用戶端或 Proxy 使用的 HTTP 保持運作 (TCP 閒置) 逾時時間。如果下游用戶端的 HTTP 保持運作 (TCP 閒置) 逾時時間，大於負載平衡器的用戶端 HTTP 保持運作逾時時間，就可能發生競爭狀況。從下游用戶端的角度來看，已建立的 TCP 連線允許閒置的時間，比負載平衡器允許的時間更長。這表示負載平衡器判定 TCP 連線已關閉後，下游用戶端仍可傳送封包。發生這種情況時，負載平衡器會以 TCP 重設 (RST) 封包回應。

用戶端 HTTP 保持運作逾時到期時，GFE 或 Envoy Proxy 會傳送 TCP FIN 給用戶端，正常關閉連線。

後端 HTTP 保持運作逾時

內部應用程式負載平衡器是 Proxy，會使用 (下游) 用戶端與 Envoy Proxy 之間的第一個 TCP 連線，以及 Envoy Proxy 與後端之間的第二個 TCP 連線。

負載平衡器的次要 TCP 連線在每次要求後可能不會關閉，而是保持開啟狀態，以便處理多個 HTTP 要求和回應。後端 HTTP 保持運作逾時定義了負載平衡器與後端之間的 TCP 閒置逾時。後端 HTTP 保持運作逾時時間不適用於 WebSocket。

後端存活逾時固定為 10 分鐘 (600 秒)，無法變更。這可確保負載平衡器維持閒置連線至少 10 分鐘。這段期間過後，負載平衡器隨時可以將終止封包傳送至後端。

負載平衡器的後端連線存續逾時必須小於後端執行的軟體所用的連線存續逾時。這樣可避免競爭狀況，後端的作業系統可能會以 TCP 重設 (RST) 關閉 TCP 連線。由於負載平衡器的後端連線存續逾時無法設定，您必須設定後端軟體，讓 HTTP 連線存續 (TCP 閒置) 逾時值大於 600 秒。

後端 HTTP 保持運作逾時到期時，GFE 或 Envoy Proxy 會將 TCP FIN 傳送至後端 VM，以正常關閉連線。

下表列出常見網路伺服器軟體，修改保持運作逾時值時的必要變更。

網路伺服器軟體 參數 預設設定 建議設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

重試次數

如要設定重試，可以在網址對應中使用重試政策。預設重試次數 (numRetries) 為 1。perTryTimeout最長可設為 24 小時。

如果沒有重試政策，系統會重試一次沒有 HTTP 主體 (例如 GET 要求) 的失敗要求，導致 HTTP 502、503 或 504 回應。

系統不會重試 HTTP POST 要求。

重試的要求只會為最終回應產生一個記錄項目。

詳情請參閱「內部應用程式負載平衡器記錄與監控」。

存取連線網路

用戶端可以透過下列方式，從連線網路存取虛擬私有雲網路中的內部應用程式負載平衡器：

  • 虛擬私有雲網路對等互連
  • Cloud VPN 和 Cloud Interconnect

如需詳細範例，請參閱「內部應用程式負載平衡器和連線網路」。

工作階段相依性

在應用程式負載平衡器的後端服務上設定工作階段相依性，可盡可能將特定用戶端的要求傳送至同一個後端，前提是健康狀態良好的後端執行個體或端點數量保持不變，且先前選取的後端執行個體或端點未達容量上限。平衡模式的目標容量會決定後端何時達到容量上限。

下表列出不同應用程式負載平衡器支援的工作階段相依性選項類型。在下一個章節「工作階段相依性類型」中，我們將進一步詳細說明各個工作階段相依性類型。

表格：支援的工作階段相依性設定
產品 工作階段相依性選項
  • 無 (NONE)
  • 用戶端 IP (CLIENT_IP)
  • 產生的 Cookie (GENERATED_COOKIE)
  • 標頭欄位 (HEADER_FIELD)
  • HTTP Cookie (HTTP_COOKIE)
  • 有狀態的 Cookie 型相依性 (STRONG_COOKIE_AFFINITY)

另請注意：

  • 負載平衡地區政策的有效預設值 (localityLbPolicy) 會根據工作階段親和性設定而異。如果未設定工作階段相依性，也就是工作階段相依性仍為預設值 NONE，則 localityLbPolicy 的預設值為 ROUND_ROBIN。如果工作階段相依性設為 NONE 以外的值，則 localityLbPolicy 的預設值為 MAGLEV。
  • 如果使用內部應用程式負載平衡器，請勿在使用加權流量拆分時設定工作階段相依性。如果這麼做，系統會優先採用加權流量分配設定。

設定工作階段相依性時，請注意下列事項：

工作階段相依性類型

內部應用程式負載平衡器的工作階段相依性可分為下列其中一類：
  • 雜湊工作階段相依性 (NONE、CLIENT_IP)
  • 以 HTTP 標頭為準的工作階段相依性 (HEADER_FIELD)
  • 以 Cookie 為準的工作階段相依性 (GENERATED_COOKIE、HTTP_COOKIE、STRONG_COOKIE_AFFINITY)

雜湊型工作階段相依性

如果是雜湊型工作階段相依性，負載平衡器會使用一致雜湊演算法選取符合條件的後端。工作階段相依性設定會決定要使用 IP 標頭中的哪些欄位來計算雜湊。

以雜湊為準的工作階段相依性可分為下列類型：

無

工作階段相依性設定為 NONE「不」代表沒有工作階段相依性。這表示未明確設定任何工作階段相依性選項。

一律會執行雜湊作業來選取後端。如果工作階段相依性設定為 NONE，負載平衡器會使用 5 元組雜湊選取後端。5 元組雜湊包含來源 IP 位址、來源埠、通訊協定、目的地 IP 位址和目的地埠。

預設值為工作階段相依性 NONE。

用戶端 IP 相依性

用戶端 IP 工作階段相依性 (CLIENT_IP) 是根據封包的來源和目的地 IP 位址建立的 2 元組雜湊。用戶端 IP 相依性會將來自相同用戶端 IP 位址的所有要求轉送至同一個後端，前提是該後端有足夠的容量且健康狀態良好。

使用用戶端 IP 相依性時，請注意下列事項：

  • 只有在封包直接傳送至負載平衡器時，封包目的地 IP 位址才會與負載平衡器轉送規則的 IP 位址相同。
  • 如果封包在傳送至 Google Cloud 負載平衡器之前，先由中介 NAT 或 Proxy 系統處理，則封包來源 IP 位址可能與原始用戶端相關聯的 IP 位址不符。如果許多用戶端共用相同的有效來源 IP 位址，部分後端 VM 可能會收到比其他 VM 更多連線或要求。

HTTP 標頭型工作階段相依性

使用標頭欄位親和性 (HEADER_FIELD) 時，系統會根據後端服務 consistentHash.httpHeaderName 欄位中的 HTTP 標頭值，將要求轉送至後端。如要將要求分配給所有可用的後端，每個用戶端都必須使用不同的 HTTP 標頭值。

符合下列條件時，系統支援標頭欄位親和性：

  • 負載平衡位置政策為 RING_HASH 或 MAGLEV。
  • 後端服務的 consistentHash 會指定 HTTP 標頭的名稱 (httpHeaderName)。

以 Cookie 為準的工作階段相依性可分為下列類型：

使用產生的 Cookie 型親和性 (GENERATED_COOKIE) 時，負載平衡器會在回應初始 HTTP 要求時，於 Set-Cookie 標頭中加入 HTTP Cookie。

產生的 Cookie 名稱會因負載平衡器類型而異。

產品 Cookie 名稱
跨區域內部應用程式負載平衡器 GCILB
區域性內部應用程式負載平衡器 GCILB

產生的 Cookie 路徑屬性一律為正斜線 (/)，因此只要其他後端服務也使用已產生 Cookie 的相依性，這個 Cookie 就會套用至相同網址對應中的所有後端服務。

您可以使用 affinityCookieTtlSec 後端服務參數，將 Cookie 的存留時間 (TTL) 值設為 0 至 1,209,600 秒 (含) 之間。如未指定 affinityCookieTtlSec，則預設 TTL 值為 0。

當用戶端在 HTTP 要求的 Cookie 要求標頭中加入產生的工作階段相依性 Cookie 時，只要工作階段相依性 Cookie 仍有效，負載平衡器就會將這些要求導向相同的後端執行個體或端點。方法是將 Cookie 值對應至參照特定後端執行個體或端點的索引，並確保產生的 Cookie 工作階段相依性符合相關規定。

如要使用已產生 Cookie 的相依性，請設定下列平衡模式和 localityLbPolicy 設定：

  • 如為後端執行個體群組，請使用 RATE 平衡模式。
  • 如為後端服務的 localityLbPolicy，請使用 RING_HASH 或 MAGLEV。如未明確設定 localityLbPolicy，負載平衡器會使用 MAGLEV 做為隱含預設值。

詳情請參閱「失去工作階段相依性」。

使用 HTTP Cookie 相似度 (HTTP_COOKIE) 時，負載平衡器會在 Set-Cookie 標頭中加入 HTTP Cookie，以回應初始 HTTP 要求。您需要指定 Cookie 的名稱、路徑和存留時間 (TTL)。

所有應用程式負載平衡器都支援 HTTP Cookie 相似度。

您可以使用下列後端服務參數和有效值，以秒、秒的小數部分 (以奈秒為單位)，或秒加上秒的小數部分 (以奈秒為單位) 設定 Cookie 的存留時間值：

  • consistentHash.httpCookie.ttl.seconds 可設為介於 0 和 315576000000 之間的值 (含頭尾)。
  • consistentHash.httpCookie.ttl.nanos 的值可設為 0 至 999999999 之間 (含頭尾)。由於單位是奈秒，999999999表示 .999999999 秒。

如果未指定 consistentHash.httpCookie.ttl.seconds 和 consistentHash.httpCookie.ttl.nanos，系統會改用 affinityCookieTtlSec 後端服務參數的值。如未指定 affinityCookieTtlSec，則預設存留時間值為 0。

當用戶端在 HTTP 要求的 Cookie 要求標頭中加入 HTTP 工作階段相依性 Cookie 時，只要工作階段相依性 Cookie 仍有效，負載平衡器就會將這些要求導向同一個後端執行個體或端點。方法是將 Cookie 值對應至參照特定後端執行個體或端點的索引，並確保產生的 Cookie 工作階段相依性符合相關規定。

如要使用 HTTP Cookie 親和性，請設定下列平衡模式和 localityLbPolicy 設定：

  • 如為後端執行個體群組，請使用 RATE 平衡模式。
  • 後端服務的 localityLbPolicy 請使用 RING_HASH 或 MAGLEV。如果未明確設定 localityLbPolicy，負載平衡器會使用 MAGLEV 做為隱含預設值。

詳情請參閱「失去工作階段相依性」。

以有狀態 Cookie 為基礎的工作階段相依性

使用有狀態 Cookie 相似度 (STRONG_COOKIE_AFFINITY) 時，負載平衡器會在 Set-Cookie 標頭中加入 HTTP Cookie，以回應初始 HTTP 要求。您可以指定 Cookie 的名稱、路徑和存留時間 (TTL)。

除了傳統版應用程式負載平衡器之外，所有應用程式負載平衡器都支援有狀態 Cookie 相似度。

您可以設定 Cookie 的存留時間值，單位為秒、秒的小數部分 (以奈秒為單位)，或秒加上秒的小數部分 (以奈秒為單位)。strongSessionAffinityCookie.ttl 代表的時間長度不得超過兩週 (1,209,600 秒)。

Cookie 的值會將所選執行個體或端點編碼，藉此識別所選後端執行個體或端點。只要 Cookie 有效，如果用戶端在後續 HTTP 要求的 Cookie 要求標頭中加入工作階段相依性 Cookie，負載平衡器就會將這些要求導向所選的後端執行個體或端點。

與其他工作階段相依性方法不同：

  • 有狀態的 Cookie 關聯性對負載平衡模式或負載平衡地區政策 (localityLbPolicy) 沒有特定要求。

  • 自動調度資源功能在代管執行個體群組中新增執行個體時，不會影響有狀態 Cookie 相似度。

  • 自動調度資源從代管執行個體群組中移除執行個體時，不會影響有狀態的 Cookie 關聯性，除非移除所選執行個體。

  • 自動修復功能從代管執行個體群組中移除執行個體時，不會影響有狀態的 Cookie 型親和性，除非移除所選執行個體。

詳情請參閱「失去工作階段相依性」。

Cookie 型相依性的存留時間為零代表什麼意思

所有以 Cookie 為基礎的工作階段相依性 (例如已產生 Cookie 的相依性、HTTP Cookie 相依性，以及以有狀態 Cookie 為基礎的相依性) 都具有存留時間屬性。

如果存留時間為零秒，表示負載平衡器不會為 Cookie 指派 Expires 屬性。在這種情況下，用戶端會將 Cookie 視為工作階段 Cookie。工作階段的定義因用戶端而異：

  • 部分用戶端 (例如網路瀏覽器) 會在整個瀏覽工作階段中保留 Cookie。也就是說，在應用程式關閉前，Cookie 會在多個要求中持續存在。

  • 其他用戶端則會將工作階段視為單一 HTTP 要求，並在要求完成後立即捨棄 Cookie。

失去工作階段相依性

所有工作階段相依性選項都必須符合下列條件：

  • 所選後端執行個體或端點必須維持後端設定。發生下列任一事件時，工作階段相依性可能會中斷：
    • 從執行個體群組中移除所選執行個體。
    • 代管執行個體群組自動調度資源或自動修復功能，會從代管執行個體群組中移除所選執行個體。
    • 從 NEG 中移除所選端點。
    • 從後端服務中移除包含所選執行個體或端點的執行個體群組或 NEG。
  • 所選後端執行個體或端點必須保持正常運作。如果所選執行個體或端點未通過健康狀態檢查，工作階段相依性可能會中斷。
除了以有狀態 Cookie 為基礎的工作階段相依性，所有工作階段相依性選項都必須符合下列額外規定：

  • 包含所選執行個體或端點的執行個體群組或 NEG，不得達到目標容量定義的上限。(如果是區域性代管執行個體群組，包含所選執行個體的執行個體群組可用區元件不得已滿)。如果執行個體群組或 NEG 已滿，但其他執行個體群組或 NEG 尚未滿，工作階段相依性可能會中斷。使用 UTILIZATION 平衡模式時，完整性可能會以無法預測的方式變更，因此您應使用 RATE 或 CONNECTION 平衡模式，盡量避免工作階段相依性中斷。

  • 已設定的後端執行個體或端點總數必須保持不變。發生下列至少一項事件時，設定的後端執行個體或端點數量會變更，工作階段相依性可能會中斷：

    • 新增執行個體或端點：

      • 您可以在後端服務中，將執行個體新增至現有的執行個體群組。
      • 代管執行個體群組自動調度資源功能，會將執行個體新增至後端服務的代管執行個體群組。
      • 將端點新增至後端服務的現有 NEG。
      • 將非空白的執行個體群組或 NEG 新增至後端服務。

    • 移除任何執行個體或端點，不只是所選執行個體或端點：

      • 從執行個體群組後端移除任何執行個體。
      • 代管執行個體群組自動調度資源或自動修復功能，會從代管執行個體群組後端移除任何執行個體。
      • 從 NEG 後端移除任何端點。
      • 從後端服務中移除任何現有的非空白後端執行個體群組或 NEG。

  • 健康狀態良好的後端執行個體或端點總數必須維持不變。發生下列任一事件時，健康狀態良好的後端執行個體或端點數量會變更，工作階段相依性可能會中斷：

    • 任何執行個體或端點通過健康狀態檢查，從健康狀態不良轉為良好。
    • 任何執行個體或端點未通過健康狀態檢查，從健康狀態良好轉為不良或逾時。

容錯移轉

如果後端健康狀態不佳，系統會自動將流量重新導向至健康狀態良好的後端。

下表說明各模式的容錯移轉行為：

負載平衡器模式 容錯移轉行為 所有後端運作狀態皆不良時的行為
跨區域內部應用程式負載平衡器

自動容錯移轉至相同區域或其他區域中的健康後端。

系統會根據設定的 流量分配，將流量分配給多個區域的健康後端。

 傳回 HTTP 503
區域性內部應用程式負載平衡器

自動容錯移轉至同一區域內健康狀態良好的後端。

Envoy Proxy 會根據設定的 流量分配，將流量傳送至區域中的健康後端。

 傳回 HTTP 503

高可用性和跨區域容錯移轉

區域性內部應用程式負載平衡器

如要實現高可用性，請在最能支援應用程式流量的區域中，部署多個個別的區域性內部應用程式負載平衡器。接著，您可以使用 Cloud DNS 地理位置路由政策，偵測負載平衡器是否在區域性服務中斷期間回應。地理位置政策會根據用戶端要求的來源，將流量轉送至下一個最接近的可用區域。內部應用程式負載平衡器預設會啟用健康狀態檢查。

跨區域內部應用程式負載平衡器

您可以在多個區域設定跨區域內部應用程式負載平衡器，享有下列優點：

  1. 如果某個區域的跨區域內部應用程式負載平衡器故障，DNS 路由政策會將流量轉送至其他區域的跨區域內部應用程式負載平衡器。

    高可用性部署範例顯示下列內容：

    • 跨區域內部應用程式負載平衡器，在虛擬私有雲網路的 RegionA 和 RegionB 區域中具有前端虛擬 IP 位址 (VIP)。用戶端位於 RegionA 區域。
    • 您可以透過兩個區域的前端 VIP 存取負載平衡器，並使用 DNS 路由政策將最佳 VIP 回傳給用戶端。如要讓用戶端使用地理位置最接近的 VIP，請使用地理位置路由政策。
    • DNS 路由政策可以偵測 VIP 在區域中斷期間是否沒有回應，並將下一個最佳 VIP 回傳給用戶端，確保應用程式即使在區域中斷期間也能正常運作。
    跨區域內部應用程式負載平衡器，採用高可用性部署。
    高可用性部署的跨區域內部應用程式負載平衡器 (按一下可放大)。

  2. 如果特定區域中的後端發生故障，跨區域內部應用程式負載平衡器流量會順利容錯移轉至其他區域中的後端。

    跨區域容錯移轉部署作業範例顯示下列內容：

    • 跨區域內部應用程式負載平衡器，在虛擬私有雲網路的 RegionA 區域中具有前端 VIP 位址。用戶端也位於 RegionA 區域。
    • 參照RegionA和RegionB Google Cloud 區域中後端的全域後端服務。
    • RegionA 區域的後端發生故障時，流量會容錯移轉至 RegionB 區域。
    跨區域內部應用程式負載平衡器，並採用跨區域容錯移轉部署作業。
    跨區域內部應用程式負載平衡器，採用跨區域容錯移轉部署 (按一下可放大)。

WebSocket 支援

Google Cloud 如果使用 HTTP/1.1(HTTP 或 HTTPS) 或 HTTP/2 做為後端通訊協定，HTTP (S) 負載平衡器支援 WebSocket 通訊協定。負載平衡器不需要任何設定，即可對 WebSocket 連線進行 Proxy 處理。

WebSocket 通訊協定可在用戶端和負載平衡器之間提供全雙工通訊管道。詳情請參閱 RFC 6455。

如果是 HTTP/1.1 連線，WebSocket 通訊協定會使用 HTTP/1.1 Upgrade 機制，將 TCP 連線從 HTTP 轉換為 WebSocket 連線。透過 HTTP/1.1 執行的 WebSocket 通訊協定運作方式如下：

  1. 負載平衡器會辨識 HTTP 或 HTTPS 用戶端的 WebSocket Upgrade 要求。要求包含 Connection: Upgrade 和 Upgrade: websocket 標頭，後面接著其他相關的 WebSocket 要求標頭。
  2. 後端會傳送 WebSocket Upgrade 回應。這包括含有 Connection: Upgrade 和 Upgrade: websocket 標頭的 101 Switching Protocols 回應，以及其他 WebSocket 相關的回應標頭。
  3. 在目前連線期間，負載平衡器會透過 Proxy 傳送雙向流量。

如果後端執行個體傳回狀態碼 HTTP 426 或 HTTP 502，負載平衡器就會關閉連線。

如果是 HTTP/2 連線，WebSocket 通訊協定會使用擴充的 CONNECT 方法和虛擬標頭欄位 (例如 :protocol)，在單一 HTTP/2 串流上建立通道，以便傳輸 WebSocket 的資料 (RFC 8441)。透過 HTTP/2 執行的 WebSocket 通訊協定運作方式如下：

  1. 後端伺服器會傳送 HTTP/2 SETTINGS 框架，其中包含設為 1 的 SETTINGS_ENABLE_CONNECT_PROTOCOL 參數。這會向負載平衡器宣傳後端支援擴充的 CONNECT 方法。

  2. 負載平衡器收到這項設定後，就會辨識並轉送 WebSocket 升級要求。它會使用擴充的 CONNECT 方法，將升級要求傳送至後端。要求包含 :method: CONNECT 和 :protocol: websocket 虛擬標頭，以及其他相關的 WebSocket 要求標頭。

  3. 後端傳送 WebSocket 成功回應。後端伺服器會傳送 200 OK 回應 (而非 HTTP/1.1 中使用的 101 Switching Protocols 回應)，透過 HTTP/2 連線的單一串流建立 WebSocket 通道。

  4. 負載平衡器會透過建立的 HTTP/2 串流，對雙向流量進行 Proxy 處理。

如果後端執行個體傳回狀態碼 426 或 502，則不會進行 WebSocket 升級，且狀態碼會傳播至用戶端。

WebSocket 的工作階段相依性與任何其他要求相同。 詳情請參閱「工作階段相依性」。

支援 HTTP/2

HTTP/2 是 HTTP/1 通訊協定的重大修訂版本，HTTP/2 支援有 2 種模式：

  • HTTP/2 over TLS
  • 透過 TCP 的明文 HTTP/2

HTTP/2 over TLS

用戶端與外部應用程式負載平衡器之間的連線，以及負載平衡器與後端之間的連線，都支援透過 TLS 傳輸 HTTP/2。

負載平衡器會使用 ALPN TLS 擴充功能，在 TLS 握手期間自動與用戶端協商 HTTP/2。即使負載平衡器設定為使用 HTTPS，新式用戶端預設仍會使用 HTTP/2。這項設定是在用戶端控管，而非負載平衡器。

如果用戶端不支援 HTTP/2，且負載平衡器已設定為在負載平衡器與後端執行個體之間使用 HTTP/2，負載平衡器可能仍會協商 HTTPS 連線或接受不安全的 HTTP 要求。負載平衡器接著會轉換這些 HTTPS 或 HTTP 要求，透過 HTTP/2 將要求 Proxy 至後端執行個體。

如要透過 TLS 使用 HTTP/2，您必須在後端啟用 TLS，並將後端服務通訊協定設為HTTP2。詳情請參閱「從負載平衡器到後端的加密」。

HTTP/2 並行串流數量上限

HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS 設定說明端點接受由對等端發起的串流數量上限。HTTP/2 用戶端向Google Cloud 負載平衡器通告的值實際上沒有意義，因為負載平衡器不會向用戶端啟動串流。

如果負載平衡器使用 HTTP/2 與 VM 上執行的伺服器通訊，負載平衡器會遵循伺服器公告的 SETTINGS_MAX_CONCURRENT_STREAMS 值，最大值為 100。在要求方向 (Google Cloud 負載平衡器 → gRPC 伺服器) 中，負載平衡器會使用 gRPC 伺服器的初始 SETTINGS 框架，判斷每個連線可同時使用的串流數量。如果伺服器公告的值高於 100，負載平衡器會將並行串流數量上限設為 100。如果公告的值為零，負載平衡器就無法將要求轉送至伺服器，這可能會導致錯誤。

HTTP/2 動態標頭資料表大小

HTTP/2 具有多工處理和 HPACK 標頭壓縮等功能，可大幅提升 HTTP/1.1 的效能。HPACK 使用動態資料表來強化標頭壓縮，加快所有作業的速度。如要瞭解 HTTP/2 中動態標頭表格大小變更的影響、這項功能如何提升效能，以及各種 HTTP 用戶端程式庫中的特定錯誤如何導致 HPACK 標頭壓縮問題，請參閱社群文章。

HTTP/2 限制

  • 負載平衡器與執行個體之間的 HTTP/2 可能需要比 HTTP 或 HTTPS 多出許多 TCP 連線。連線集區可減少 HTTP 或 HTTPS 連線數量，但 HTTP/2 不支援這項最佳化功能。因此，後端連線頻率較高，後端延遲時間可能也會較長。
  • 負載平衡器和後端之間的 HTTP/2 不支援伺服器推送。
  • gRPC 錯誤率和要求量不會顯示在Google Cloud API 或 Google Cloud 控制台中。如果 gRPC 端點傳回錯誤，負載平衡器記錄和監控資料會回報 200 OK HTTP 狀態碼。

透過明文 TCP 傳送 HTTP/2

根據 RFC 7540，以字串「h2c」表示的明文 TCP 上的 HTTP/2，可讓您使用 HTTP/2，而不需 TLS 加密。支援下列連線：

  • 用戶端到負載平衡器：自動支援，不需特殊設定。

使用 GKE Gateway 控制器和 Cloud Service Mesh 建立的負載平衡器，也支援 H2C。

gRPC 支援

gRPC 是遠端程序呼叫的開放原始碼架構。它採用 HTTP/2 標準。gRPC 的用途如下：

  • 低延遲、高擴充性的分散式系統
  • 開發與雲端伺服器通訊的行動用戶端
  • 設計必須準確、有效率且與語言無關的新通訊協定
  • 可實現擴充、驗證和記錄功能的分層式設計

如要搭配 Google Cloud 應用程式使用 gRPC，您必須透過 HTTP/2 端對端 Proxy 處理要求。如要這麼做，請建立應用程式負載平衡器，並採用下列其中一種設定：

  • 用戶端與負載平衡器之間的 TLS HTTP/2，以及負載平衡器與後端之間的 H2C：建立 HTTPS 負載平衡器 (設定目標 HTTPS Proxy 和 SSL 憑證)。此外，您也可以將後端服務通訊協定設為 H2C，設定負載平衡器在負載平衡器和後端之間使用 HTTP/2 建立未加密連線。

  • 使用 HTTP/2 over TLS 的端對端加密流量：您建立 HTTPS 負載平衡器 (設定目標 HTTPS Proxy 和 SSL 憑證)。負載平衡器會使用 ALPN TLS 擴充功能，在 SSL 握手期間與用戶端協商 HTTP/2。

    此外，您必須確保後端可以處理 TLS 流量，並將後端服務通訊協定設為 HTTP2，將負載平衡器設為使用 HTTP/2，在負載平衡器和後端之間建立加密連線。

    負載平衡器可能仍會與部分用戶端協商 HTTPS，或在設定為在負載平衡器和後端執行個體之間使用 HTTP/2 的負載平衡器上接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTP 或 HTTPS 要求，透過 HTTP/2 將要求轉送至後端執行個體。

TLS 支援

根據預設，HTTPS 目標 Proxy 終止用戶端 SSL 要求時，只會接受 TLS 1.0、1.1、1.2 和 1.3。

如果內部應用程式負載平衡器使用 HTTPS 做為後端服務通訊協定，可以與後端協商 TLS 1.2 或 1.3。

支援雙向 TLS

相互傳輸層安全標準 (mTLS) 是業界標準通訊協定，可供用戶端與伺服器進行雙向驗證。mTLS 會驗證用戶端和伺服器是否持有信任的憑證授權單位 (CA) 核發的有效憑證，確保雙方均具備所宣稱的身分。與標準 TLS 僅驗證伺服器不同，mTLS 要求用戶端和伺服器都必須提供憑證，在建立通訊前確認雙方身分。

所有應用程式負載平衡器都支援 mTLS。使用 mTLS 時，負載平衡器會要求用戶端在與負載平衡器進行 TLS 握手期間，傳送憑證來驗證自身身分。您可以設定Certificate Manager信任存放區，讓負載平衡器用來驗證用戶端憑證的信任鏈結。

如要進一步瞭解 mTLS，請參閱「相互傳輸層安全性驗證」。

限制

  • 不保證來自某個區域中某個可用區的用戶端要求，會傳送至與用戶端位於相同可用區的後端。工作階段相依性不會減少區域之間的通訊。

  • 內部應用程式負載平衡器與下列功能不相容：

  • 如要搭配使用 Certificate Manager 憑證和內部應用程式負載平衡器，您必須使用 API 或 gcloud CLI。Google Cloud 控制台不支援 Certificate Manager 憑證。

  • 連線至內部應用程式負載平衡器的用戶端必須使用 HTTP 1.1 以上版本。不支援 HTTP 1.0。

  • 如果僅限 Proxy 的子網路用盡 IP 位址，Google Cloud 不會發出警告。

  • 內部應用程式負載平衡器使用的內部轉送規則必須只有一個連接埠。

  • 在共用虛擬私有雲環境中，如果使用內部應用程式負載平衡器搭配 Cloud Run，服務專案中的獨立虛擬私有雲網路可以將流量傳送至同一個共用虛擬私有雲環境中，部署在任何其他服務專案的 Cloud Run 服務。這是已知問題。

  • Google Cloud 不保證基礎 TCP 連線在後端服務逾時期間內，能一直保持開啟狀態。用戶端系統必須實作重試邏輯，而非依賴長時間開啟的 TCP 連線。

  • 建立轉送規則時，您無法直接使用 --address 旗標指定非 RFC 1918 IP 位址 (例如 100.64.0.0/10 或私下使用的公開範圍)。否則會觸發 API 驗證錯誤，指出該位址並非 RFC 1918 位址。

    如要使用非 RFC 1918 IP 位址，請在建立轉送規則時，執行下列任一操作：

    • 省略 --address 標記，即可允許 Google Cloud 從子網路動態分配有效的 IP 位址。
    • 請先使用 --purpose=SHARED_LOADBALANCER_VIP 在目標子網路中預留具名 IP 位址資源。建立轉送規則時，請使用 --address 旗標參照保留名稱。

後續步驟