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

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

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 位於同一區域的後端。
  高可用性和容錯移轉	自動將容錯移轉至相同或不同區域中運作正常的後端。	自動將用戶端連線至相同區域內的健康後端。

識別模式

架構與資源

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

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

Proxy 專用子網路

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

下表說明地區和跨區模式中，僅代理程式子網路的差異：

負載平衡器模式	僅限 Proxy 子網路 --purpose 標記的值
跨區域內部應用程式負載平衡器	GLOBAL_MANAGED_PROXY 區域和跨區域負載平衡器無法共用相同的子網路 跨區域 Envoy 型負載平衡器必須在設定負載平衡器的每個區域中，具備僅限 Proxy 的子網路。同一個區域和網路中的跨區域負載平衡器 Proxy 會共用相同的 Proxy 專用子網路。
區域性內部應用程式負載平衡器	REGIONAL_MANAGED_PROXY 區域和跨區域負載平衡器無法共用相同的子網路 區域和虛擬私有雲網路中的所有區域 Envoy 型負載平衡器，都會共用同一個僅限 Proxy 的子網路

進一步說明：

• 僅限 Proxy 的子網路只用於 Envoy Proxy，而非後端。
• 地區和虛擬私有雲網路中，所有內部應用程式負載平衡器的後端 VM 或端點，都會接收來自 Proxy 專用子網路的連線。
• 內部應用程式負載平衡器的虛擬 IP 位址「不會」位於僅限 Proxy 的子網路中。負載平衡器的 IP 位址是由內部受管理的轉送規則定義，如下所述。

轉送規則和 IP 位址

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

IP 位址規格。每個轉送規則都會參照單一區域 IP 位址，供您用於應用程式的 DNS 記錄。您可以保留要使用的靜態 IP 位址，或由 Cloud Load Balancing 為您指派靜態 IP 位址。建議您保留靜態 IP 位址，否則每當您刪除轉送規則並建立新規則時，均必須使用新指派的臨時 IP 位址更新 DNS 記錄。

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

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

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

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

負載平衡器模式	轉送規則、IP 位址和 Proxy 專用子網路 --purpose	從用戶端轉送至負載平衡器前端
跨區域內部應用程式負載平衡器	通用轉送規則 區域性 IP 位址 負載平衡架構： INTERNAL_MANAGED 僅限 Proxy 的子網路 --purpose： GLOBAL_MANAGED_PROXY IP 位址 --purpose： SHARED_LOADBALANCER_VIP	根據預設，系統會啟用全域存取權，讓虛擬私有雲中任何區域的用戶端都能存取負載平衡器。後端可位於多個區域。
區域性內部應用程式負載平衡器	區域轉送規則 區域 IP 位址 負載平衡架構： INTERNAL_MANAGED 僅限 Proxy 的子網路 --purpose： REGIONAL_MANAGED_PROXY IP 位址 --purpose： SHARED_LOADBALANCER_VIP	您可以啟用全域存取權，讓虛擬私有雲中任何區域的用戶端都能存取負載平衡器。後端也必須與負載平衡器位於相同區域。

轉送規則和 VPC 網路

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

負載平衡器模式	虛擬私有雲網路關聯
跨區域內部應用程式負載平衡器 區域內部應用程式負載平衡器	區域性內部 IPv4 位址一律位於虛擬私有雲網路內。建立轉送規則時，您必須指定從哪個子網路取得內部 IP 位址。這個子網路必須位於已建立 Proxy 專用子網路的相同區域和虛擬私有雲網路。因此，這裡有隱含的網路關聯。

目標 Proxy

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

負載平衡器會保留原始用戶端要求的主機標頭。負載平衡器也會在 X-Forwarded-For 標頭中附加兩個 IP 位址：

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

如果傳入要求中沒有 X-Forwarded-For 標頭，這兩個 IP 位址就是整個標頭值。如果要求含有 X-Forwarded-For 標頭，系統會在兩個 IP 位址之前保留其他資訊，例如 Proxy 在前往負載平衡器的過程中記錄的 IP 位址。負載平衡器不會驗證此標頭中最後兩個 IP 位址之前的任何 IP 位址。

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

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

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

負載平衡器模式	目標 Proxy
跨區域內部應用程式負載平衡器	全球 targetHttpProxies 全球 targetHttpsProxies
區域性內部應用程式負載平衡器	regionTargetHttpProxies regionTargetHttpsProxies

SSL 憑證

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

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

負載平衡器模式	SSL 憑證類型
區域性內部應用程式負載平衡器	Compute Engine 區域 SSL 憑證 憑證管理工具的區域性自行管理憑證和 Google 代管憑證。 Certificate Manager 支援下列類型的 Google 代管憑證： 區域性 Google 代管憑證，並具備個別專案 DNS 授權。詳情請參閱「部署區域性 Google 代管憑證」。 區域性 Google 代管憑證 (搭配私人憑證授權單位服務)。詳情請參閱「透過 CA 服務部署地區性 Google 代管憑證」。 不支援具備負載平衡器授權的 Google 代管憑證。
跨區域內部應用程式負載平衡器	憑證管理工具的自行管理憑證和 Google 代管憑證。 Certificate Manager 支援下列類型的 Google 代管憑證： 使用公開 DNS 進行 DNS 授權。詳情請參閱「部署全球 Google 代管憑證，並使用 DNS 授權」。 私人憑證授權單位服務。詳情請參閱「建立由 CA 服務執行個體核發的 Google 代管憑證」。 不支援具備負載平衡器授權的 Google 代管憑證。 不支援 Compute Engine SSL 憑證。

網址對應

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

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

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

後端服務

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

後端服務範圍

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

負載平衡器模式	後端服務資源
跨區域內部應用程式負載平衡器	backendServices (全域)
區域性內部應用程式負載平衡器	regionBackendServices (僅限部分地區)

後端的通訊協定

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

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

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

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

後端

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

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

後端和虛擬私有雲網路

後端可位於何處的限制取決於後端類型。

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

  後端網路定義

  • 對於區域性 NEG 和混合式 NEG，您必須在建立 NEG 時明確指定虛擬私人雲端網路。
  • 對於代管執行個體群組，VPC 網路是在執行個體範本中定義。
  • 對於非代管執行個體群組，執行個體群組的虛擬私有雲網路會設為與 nic0 介面的虛擬私有雲網路相符，適用於新增至執行個體群組的第一個 VM。

  後端網路需求

  後端網路必須符合下列任一網路需求：

  • 後端的 VPC 網路必須與轉送規則的 VPC 網路完全一致。

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

• 後端的 VPC 網路和轉送規則的 VPC 網路都必須是VPC 輻條，且連結至相同的 Network Connectivity Center 中樞。匯入和匯出篩選器必須允許轉送規則 VPC 網路中代理專用子網路，與後端執行個體或端點使用的子網路之間的通訊。

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

後端和網路介面

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

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

後端子集

後端子集是區域性內部應用程式負載平衡器支援的選用功能，可為每個 Proxy 執行個體指派部分後端，進而改善效能和擴充性。

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

健康狀態檢查

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

如要讓健康狀態檢查探測成功，您必須建立輸入許可防火牆規則，讓健康狀態檢查探測器可連線至後端執行個體。健康狀態檢查探針通常來自 Google 的集中式健康檢查機制。不過，對於混合型 NEG，健康狀態檢查會從僅限 Proxy 的子網路發出。詳情請參閱「分散式 Envoy 健康檢查」。

健康狀態檢查通訊協定

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

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

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

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

• 健康狀態檢查總覽
• 建立健康狀態檢查

防火牆規則

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

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

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

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

用戶端存取權

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

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

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

下表列出區域性內部應用程式負載平衡器的用戶端存取權：

全域存取權已停用	已啟用全域存取權
用戶端必須與負載平衡器位於相同的地區。且必須與負載平衡器位於相同的 VPC 網路，或位於透過 VPC 網路對等互連連線至負載平衡器的 VPC 網路。	用戶端可位於任何區域。但仍必須與負載平衡器位於相同的 VPC 網路，或是透過 VPC 網路對等互連功能連線至負載平衡器的 VPC 網路。
內部部署用戶端可以透過 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 後端。

• 您可以使用由 GKE 服務建立及管理的 GCE_VM_IP_PORT 區域 NEG，做為任何應用程式負載平衡器或 Proxy Network Load Balancer 的後端。詳情請參閱「透過獨立的區域 NEG 使用容器原生負載平衡功能」。

共用虛擬私有雲架構

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

您可以透過多種方式在共用虛擬私人雲端網路中設定內部應用程式負載平衡器。無論部署類型為何，負載平衡器的所有元件都必須位於同一個機構。

子網路和 IP 位址	前端元件	後端元件
在共用虛擬私有雲主專案中建立必要的網路和子網路 (包括僅限 Proxy 的子網路)。 負載平衡器的內部 IP 位址可在主專案或服務專案中定義，但必須使用主專案中所需共用虛擬私人雲端網路的子網路。該位址本身來自參照子網路的主要 IP 範圍。	地區內部 IP 位址、轉送規則、目標 HTTP(S) Proxy 和相關網址對應必須在同一個專案中定義。這個專案可以是主機專案或服務專案。	您可以採取下列任一做法： 在相同的服務專案中，為前端元件建立後端服務和後端 (執行個體群組、無伺服器 NEG 或任何其他支援的後端類型)。 視需要在多個服務專案中建立後端服務和後端 (執行個體群組、無伺服器 NEG 或任何其他支援的後端類型)。單一網址對應可參照不同專案的後端服務。這類部署作業稱為跨專案服務參照。 每個後端服務都必須在其參照的後端所在專案中定義。定義與後端服務相關的健康狀態檢查時，所在的專案必須與後端服務所在專案相同。

雖然您可以在共用虛擬私有雲主專案中建立所有負載平衡元件和後端，但這類部署方式不會區分網路管理和服務開發職責。

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

下圖顯示標準的共用虛擬私人雲端部署作業，其中所有負載平衡器元件和後端都位於服務專案中。所有應用程式負載平衡器都支援這類部署方式。

負載平衡器會使用主機專案的 IP 位址和子網路。如果用戶端與負載平衡器位於相同的共用虛擬私有雲網路和區域，便可存取內部應用程式負載平衡器。用戶端可以位於主專案、已附加的服務專案或任何已連結的網路中。

共用虛擬私有雲環境中的無伺服器後端

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

跨專案服務參照

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

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

為每個功能團隊建立不同的專案，您也可以在機構內實現角色區隔。服務擁有者可以專注於在服務專案中建構服務，而網路團隊則可在其他專案中佈建及維護負載平衡器，兩者都能透過跨專案服務參照連結。

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

對於內部應用程式負載平衡器，跨專案服務參照功能僅支援共用虛擬私有雲環境。

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

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

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

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

以下是共用虛擬私有雲部署的範例，其中負載平衡器的前端和網址對應是在服務專案 A 中建立，而網址對應會參照服務專案 B 中的後端服務。

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

示例 2：主專案中的負載平衡器前端，以及服務專案中的後端

以下是共用虛擬私有雲部署的範例，其中負載平衡器的前端和網址對應項目是在主專案中建立，而後端服務則是在服務專案中建立。

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

逾時和重試

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

逾時類型和說明	預設值	支援自訂值
		跨區域	區域
後端服務逾時 要求和回應逾時。代表負載平衡器將要求的第一個位元組傳送至後端，以及後端將 HTTP 回應的最後一個位元組傳回至負載平衡器之間，允許的時間上限。如果後端未在這個時間限制內將整個 HTTP 回應傳回至負載平衡器，則系統會捨棄剩餘的回應資料。	後端服務上的無伺服器 NEG：60 分鐘 後端服務的所有其他後端類型：30 秒
用戶端 HTTP 保持運作逾時 用戶端與負載平衡器的 Envoy 代理程式之間 TCP 連線可閒置的時間長度上限。(同一個 TCP 連線可能會用於多個 HTTP 要求)。	610 秒
後端 HTTP 保持運作逾時 負載平衡器管理的 Envoy Proxy 與後端之間的 TCP 連線可閒置的時間上限。(同一個 TCP 連線可能會用於多個 HTTP 要求)。	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 連線。

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

用戶端 HTTP 保持運作逾時

用戶端 HTTP 保持運作逾時值代表 (下游) 用戶端與 Envoy 代理程式之間 TCP 連線可閒置的最長時間。預設的用戶端 HTTP 保持運作逾時時間值為 610 秒。您可以設定 5 到 1200 秒之間的逾時值。

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

負載平衡器的用戶端 HTTP keepalive 逾時時間必須大於下游用戶端或 Proxy 使用的 HTTP keepalive (TCP 閒置) 逾時時間。如果下游用戶端的 HTTP keepalive (TCP 閒置) 逾時時間大於負載平衡器的用戶端 HTTP keepalive 逾時時間，就可能發生競爭狀態。從下游用戶端的角度來看，已建立的 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

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

容錯移轉

如果後端出現問題，系統會自動將流量重新導向至健康的後端。

下表說明各模式的備援行為：

負載平衡器模式	容錯移轉行為	所有後端的運作狀態皆不良時的行為
跨區域內部應用程式負載平衡器	自動容錯移轉至相同區域或其他區域中的健康後端。 系統會根據設定的 流量分配，將流量分配至跨多個區域的健康後端。	傳回 HTTP 503
區域性內部應用程式負載平衡器	自動將用戶端連線至相同區域內的健康後端。 Envoy Proxy 會根據所設定的 流量分配，將流量傳送至區域中健康狀態良好的後端。	傳回 HTTP 503

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

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

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

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

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

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

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

   • 跨區域內部應用程式負載平衡器，其前端虛擬 IP 位址 (VIP) 位於虛擬私有雲網路中的 RegionA 和 RegionB 區域。您的客戶位於 RegionA 區域。
   • 您可以使用兩個區域的前端 VIP，讓負載平衡器可供存取，並使用 DNS 路由政策，將最佳 VIP 傳回給用戶端。如果您希望客戶使用地理位置上最近的 VIP，請使用地理位置轉送政策。
   • DNS 路由政策可偵測 VIP 在區域停機期間是否沒有回應，並將次佳的 VIP 傳回給客戶端，確保應用程式即使在區域停機期間也能正常運作。

   

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

   跨區域容錯部署範例會顯示下列內容：

   • 跨區域內部應用程式負載平衡器，其前端 VIP 位址位於 VPC 網路的 RegionA 區域。您的客戶也位於 RegionA 區域。
   • 參照 RegionA 和 RegionB Google Cloud 地區後端的全域後端服務。
   • 當 RegionA 區域的後端發生故障時，流量會轉移至 RegionB 區域。

   

WebSocket 支援

Google Cloud 當您使用 HTTP 或 HTTPS 做為後端的通訊協定時，以 HTTP(S) 為基礎的負載平衡器會支援 WebSocket 通訊協定。負載平衡器不需要任何設定，即可透過 Proxy 進行 WebSocket 連線。

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

WebSocket 通訊協定的運作方式如下：

1. 負載平衡器會辨識來自 HTTP 或 HTTPS 用戶端的 WebSocket Upgrade 要求。要求包含 Connection: Upgrade 和 Upgrade: websocket 標頭，後面接著其他相關的 WebSocket 要求標頭。
2. 後端傳送 WebSocket Upgrade 回應。後端執行個體會傳送 101 switching protocol 回應，其中包含 Connection: Upgrade 和 Upgrade: websocket 標頭，以及其他 WebSocket 相關的回應標頭。
3. 負載平衡器會在目前連線期間代理雙向流量。

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

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 值。如果宣告的值為零，負載平衡器就無法將要求轉送至伺服器，這可能會導致錯誤。

HTTP/2 限制

• 負載平衡器和執行個體之間的 HTTP/2 可能需要比 HTTP 或 HTTPS 多上許多的 TCP 連線。連線集區 (一種可減少 HTTP 或 HTTPS 連線數量的最佳化方式) 不適用於 HTTP/2。因此，後端連線頻率會提高，導致後端延遲時間變長。
• 負載平衡器和後端之間的 HTTP/2 不支援透過單一 HTTP/2 連線串流執行 WebSocket 通訊協定 (RFC 8441)。
• 負載平衡器和後端之間的 HTTP/2 不支援伺服器推送。
• Google Cloud API 或 Google Cloud 主控台不會顯示 gRPC 錯誤率和要求量。如果 gRPC 端點傳回錯誤，負載平衡器記錄和監控資料會回報 200 OK HTTP 狀態碼。

透過 TCP 傳輸明文 HTTP/2 (H2C)

透過 TCP 傳輸的純文字 HTTP/2 (也稱為 H2C) 可讓您在沒有 TLS 的情況下使用 HTTP/2。下列兩種連線都支援 H2C：

• 用戶端與負載平衡器之間的連線。無須進行特殊設定。

• 負載平衡器與後端之間的連線。

  如要為負載平衡器與其後端之間的連線設定 H2C，請將後端服務通訊協定設為 H2C。

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

傳統版應用程式負載平衡器不支援 H2C。

gRPC 支援

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

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

如要將 gRPC 與應用程式搭配使用，端到端皆必須透過 HTTP/2 經由 Proxy 傳送要求。 Google Cloud 如要這麼做，請使用下列任一設定建立應用程式負載平衡器：

• 針對端對端未加密流量 (不含 TLS)：您需要建立 HTTP 負載平衡器 (使用目標 HTTP Proxy 設定)。此外，您可以將後端服務通訊協定設為 H2C，讓負載平衡器在負載平衡器與其後端之間使用 HTTP/2 進行未加密連線。

• 針對端對端加密流量 (使用 TLS)：您需要建立 HTTPS 負載平衡器 (使用目標 HTTPS Proxy 和 SSL 憑證進行設定)。負載平衡器會使用 ALPN TLS 擴充功能，在 SSL 握手過程中與用戶端進行 HTTP/2 交涉。

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

  負載平衡器可能仍會與某些用戶端進行 HTTPS 交涉，或在設定為在負載平衡器和後端執行個體之間使用 HTTP/2 的負載平衡器上接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTP 或 HTTPS 要求，以透過 HTTP/2 經由 Proxy 將要求傳送至後端執行個體。

TLS 支援

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

當內部應用程式負載平衡器使用 HTTPS 做為後端服務通訊協定時，就可以與後端進行 TLS 1.2 或 1.3 交涉。

支援相互傳輸層安全性

相互傳輸層安全性 (mTLS) 是用於用戶端和伺服器之間相互驗證的業界標準通訊協定。mTLS 可確保用戶端和伺服器都持有由信任的憑證授權單位 (CA) 核發的有效憑證，藉此驗證彼此身分。與只驗證伺服器的標準 TLS 不同，mTLS 要求用戶端和伺服器都出示憑證，在建立通訊之前確認雙方的身分。

所有應用程式負載平衡器都支援 mTLS。使用 mTLS 時，負載平衡器會要求用戶端在與負載平衡器進行 TLS 握手期間傳送憑證，以便驗證自身。您可以設定 憑證管理工具信任儲存庫，讓負載平衡器日後用於驗證用戶端憑證的信任鏈結。

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

限制

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

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

  • Cloud CDN
  • Compute Engine 的 Google 代管 SSL 憑證 (支援 Certificate Manager 的 Google 代管憑證)

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

• 內部應用程式負載平衡器僅支援透過 TLS 的 HTTP/2。

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

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

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

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

• Google Cloud 無法保證基礎 TCP 連線可在後端服務逾時值的整個期間保持開啟。用戶端系統必須實作重試邏輯，而非依賴 TCP 連線長時間保持開啟。

• 內部應用程式負載平衡器不支援 Cloud Trace。

後續步驟

• 如要在共用虛擬私有雲配置中設定負載平衡功能，請參閱「使用共用虛擬私有雲設定內部應用程式負載平衡器」。

• 如要為在 GKE Pod 中執行的服務設定負載平衡，請參閱「部署 GKE 閘道」、「使用獨立 NEG 進行容器原生負載平衡」和「將內部應用程式負載平衡器連結至獨立 NEG」一節。

• 如要管理僅限 Proxy 子網路資源，請參閱「以 Envoy 為基礎的負載平衡器適用的僅限 Proxy 子網路」。

• 如要在區域內部應用程式負載平衡器上設定後端子集，請參閱「後端子集」。

• 如要使用 Private Service Connect 設定區域內部應用程式負載平衡器，請參閱「透過後端存取區域性 Google API」一文。

• 如要將自訂邏輯插入負載平衡資料路徑，請設定 Cloud Load Balancing 擴充功能。