適用於容器的應用程式閘道元件

本文提供適用於容器的應用程式閘道元件的詳細說明和需求。 它說明了 Application Gateway for Containers 如何接收來的請求並將其路由到後端目標。 如需適用於容器的應用程式閘道的一般概觀，請參閱什麼是適用於容器的應用程式閘道。

核心元件

  • 適用於容器的應用程式閘道資源是一種部署控制平面的 Azure 父資源。
  • 控制平面會根據客戶意圖協調代理設定。
  • 容器應用閘道有兩個子資源：關聯與前端。
    • 子資源只屬於其父容器應用閘道，不能與其他容器應用閘道資源共享。

適用於容器的應用程式閘道前端

  • 適用於容器的應用程式閘道前端是適用於容器的應用程式閘道父代資源的 Azure 子資源。
  • 容器應用閘道前端定義了用戶端流量在特定容器應用閘道所使用的入口點。
    • 你不能將一個前端與多個容器應用程式閘道關聯。
    • 你可以利用每個前端提供的獨特 FQDN 來建立 CNAME 紀錄。
    • 目前不支援私有 IP 位址。
  • 單一容器應用閘道可以支援多個前端。

適用於容器的應用程式閘道關聯

  • 適用於容器的應用程式閘道關聯資源是適用於容器的應用程式閘道父代資源的 Azure 子資源。
  • 適用於容器的應用程式閘道關聯定義虛擬網路的連接點。 關聯是將關聯資源與委託的 Azure 子網路進行 1：1 對應。
  • 容器應用閘道設計允許多個關聯。
    • 目前協會數量限制為1個。
  • 在建立關聯期間，基礎資料平面會佈建並連線到定義虛擬網路子網路中的某個子網路。
  • 每個關聯都應假設在佈建時，子網路中至少有 256 個位址可用。
    • 每次部署需要至少有 /24 的子網路遮罩 (假設該子網先前尚未佈建任何資源)。
      • 如果你計劃部署多個共享同一子網的容器資源應用閘道，計算所需位址為 n×256，其中 n 等於容器資源的應用閘道數量。 假設每個元素包含一個關聯。
    • 所有適用於容器的應用程式閘道關聯資源均應與適用於容器的應用程式閘道父代資源位於相同區域。

關聯子網上的網路安全群組

對於於 2026 年 4 月 23 日或之後建立的關聯，容器應用閘道關聯子網路完全支援網路安全群組（NSG），包括 入站與出站 規則。

「全部拒絕」規則也被支援，但若沒有明確的允許例外，可能會以以下方式影響流量：

  • 拒絕所有入站 規則會阻擋 80 和 443 埠 的流量，除非新增允許規則，阻止前端存取。
  • 拒絕所有輸入 規則會封鎖 AzureLoadBalancer 服務標籤，而此服務標籤是系統預設為 NSG 建立的。 你必須確保允許使用 AzureLoadBalancer 標籤，以確保閘道的順暢運作。
  • 拒絕所有輸出規則會阻擋從適用於容器的應用程式閘道到您 AKS 叢集的流量，包括健全狀態探查。 務必允許您的 Pod IP 範圍進行輸出存取。

附註

除了關聯子網路上的 NSG 規則外，套用至 AKS 子網路的 NSG 上的拒絕所有輸出規則，可能也會封鎖來自適用於容器的應用程式閘道 ALB 控制器的流量。 為確保 ALB 控制器能妥善調和負載平衡意圖，請確保允許外出流量流至 這些端點。

對於 2026年4月23日之前建立的關聯，可以設定入站NSG規則;然而，無論規則如何， 80 和 443 埠 的流量始終被允許。

關聯子網路上的使用者定義路由

可透過路由表規則細緻控制容器應用閘道的關聯子網。 當使用容器應用閘道器與 AKS 叢集之間的虛擬網路設備時，這非常有用。

Warning

路由表配置錯誤可能導致容器應用閘道（Application Gateway for Containers）中路由不對稱。 確保網路入口是回傳到網路，而非透過虛擬設備。

以下列出幾種支援的情境，以確保在面向公用網際網路的前端所接收的流量會回送至網際網路。

案例 1：使用 UDR 停用對應用程式閘道子網路的邊界閘道協定 (BGP) 路由傳播

有時候，預設閘道路由 (0.0.0.0/0) 會透過與「適用於容器的應用程式閘道」虛擬網路相關聯的 ExpressRoute 或 VPN 閘道進行通告。 此行為會破壞客戶端回傳至網際網路的流量。 在這種情況下，您可使用 UDR 來停用 BGP 路由傳播。

若要停用 BGP 路由傳播：

  1. 在 Azure 中建立路由表資源。
  2. 停用虛擬網路閘道路由傳播參數。
  3. 將路由表與適當的子網路產生關聯。

為此案例啟用 UDR 應該不會中斷任何現有的設定。

案例 2：使用 UDR 將 0.0.0.0/0 導向至網際網路

您可以建立 UDR，直接將 0.0.0.0/0 流量傳送至網際網路。

適用於容器的應用程式閘道 ALB 控制器

  • 適用於容器的應用程式閘道 ALB 控制器是一種 Kubernetes 部署，可藉由監看 Kubernetes 的自訂資源和資源設定來協調適用於容器的應用程式閘道設定和部署，例如但不限於輸入、閘道和 ApplicationLoadBalancer。 它使用 ARM 與容器應用閘道（Application Gateway for Containers）配置 API 來將配置傳播至 Azure 部署的容器應用閘道。
  • 使用 Helm 部署或安裝 ALB 控制器。
  • ALB 控制器包含兩個執行中的 Pod。
    • alb-controller pod 協調客戶意圖到容器應用程式閘道的負載平衡組態。
    • alb-controller-bootstrap pod 管理 CRD。

適用於容器的應用程式閘道安全性原則

  • 適用於容器的應用程式閘道安全性原則會定義 ALB 控制器要取用的安全性設定，例如 WAF。
  • 單一容器應用閘道資源可指向多個安全政策。
  • 目前，唯一提供的安全策略類型是 waf 針對 Web 應用程式防火牆功能。
  • 安全原則是 waf 安全原則資源與 Web 應用程式防火牆原則之間的一對一對應。
    • 你可以在任意數量的安全政策中，針對定義的容器應用閘道資源，只引用一個網頁應用程式防火牆政策。

適用於容器的應用程式閘道 AKS 受控增益集

適用於容器的應用程式閘道 AKS 增益集為 ALB Controller 提供由 AKS 管理的部署體驗，無需手動部署 helm 圖表。

使用管理型附加元件相較於基於 Helm 進行部署的一些優點包括：

  • 受控更新： 不需要手動更新舵手圖;更新由 AKS 管理。
  • 自動化身份管理： 該外掛會自動建立並配置管理身份（applicationloadbalancer-<cluster-name>），並賦予所需權限。
  • 簡化子網配置： 專用子網（aks-appgateway）會自動配置正確的委派。
  • 降低配置複雜度： 不需要手動設定聯邦憑證或角色分配。
  • AKS 自動支援： 使用 AKS 自動叢集時，必須部署附加元件。

Azure / 一般概念

私人 IP 位址

  • 私人 IP 位址未明確定義為 Azure Resource Manager 資源。 私有 IP 位址指的是特定虛擬網路子網中的特定主機位址。

子網路委派

  • Microsoft.ServiceNetworking/trafficControllers 是 Application Gateway for Containers 採用的命名空間，你可以將其委派給虛擬網路的子網。
  • 當您進行委派時，不會佈建適用於容器的應用程式閘道的資源，也不會與適用於容器的應用程式閘道的關聯資源建立專屬對應。
  • 任意數量的子網路可以有一個子網路委派 (與適用於容器的應用程式閘道相同或不同)。 一旦定義好，除非服務實作明確定義，否則你無法將其他資源配置到子網路中。

使用者指派的受控識別

  • Azure 資源受控識別可以免除以程式碼管理認證的需求。
  • 你需要為每個 Azure 負載平衡控制器設定一個由使用者指派的管理身份，才能對容器的應用閘道進行變更。
  • 適用於 Containers 設定管理員 的 AppGw 是內建的 RBAC 角色，可讓 ALB 控制器存取及設定適用於容器的應用程式閘道資源。

附註

AppGw for Containers 組態管理員角色擁有擁有者和貢獻者角色沒有的資料動作權限。 授權適當的權限至關重要，以避免 ALB 控制器對容器應用閘道服務進行變更。

適用於容器的應用程式閘道如何接受要求

每個容器應用閘道前端都會提供由 Azure 管理的已產生的完整限定網域名稱。 你可以使用 FQDN as-is，或用 CNAME 紀錄來遮蔽它。

在用戶端向容器的應用閘道發送請求前，用戶端會解析指向前端 FQDN 的 CNAME，或直接透過 DNS 伺服器解析由容器應用閘道提供的 FQDN。

DNS 解析器會將 DNS 記錄轉譯為 IP 位址。

當用戶端起始要求時，指定的 DNS 名稱會當做主機標頭傳遞至定義前端上適用於容器的應用程式閘道。

一組路由規則會評估該主機名稱的要求應如何起始傳送至定義的後端目標。

適用於容器的應用程式閘道如何路由傳送要求

HTTP/2 要求

容器的應用程式閘道同時支援 HTTP/2 和 HTTP/1.1 通訊協定，以在用戶端與前端之間進行通訊。 HTTP/2 設定一律啟用且無法變更。 若用戶端偏好使用 HTTP/1.1 與容器應用閘道前端的通訊，則可依此進行協商。

容器的應用程式閘道與後端目標之間的通訊一律是透過 HTTP/1.1，但使用 HTTP/2 的 gRPC 除外。

修改要求

容器應用閘道在啟動後端目標請求前，會為所有請求插入三個額外的標頭：

  • x-forwarded-for
  • x-forwarded-proto
  • x-request-id

x-forwarded-for 是原始要求者的用戶端 IP 位址。 若請求透過代理伺服器，標頭值會附加接收地址，並以逗號分隔。 例如：1.2.3.4,5.6.7.8;其中 1.2.3.4 是容器應用閘道前代理的用戶端 IP 位址，5.6.7.8 是將流量轉發至容器應用閘道代理的位址。

x-forwarded-proto 回傳容器應用閘道從用戶端接收的協定。 值是 http 或 https。

x-request-id 是 Application Gateway for Containers 為每個客戶端請求產生的獨特 GUID，並且會在轉發至後端目標的請求中出現。 guid 是由 32 個英數字元組成，以破折號分隔 (例如：aaaa0000-bb11-2222-33cc-444444dddddd)。 您可以使用此 GUID 將適用於容器的應用程式閘道接收並啟動的要求與存取記錄中定義的後端目標關聯起來。

要求逾時

適用於容器的應用程式閘道在啟動及維護用戶端、適用於容器的應用程式閘道與後端之間的要求時，會強制執行以下逾時。

逾時 Duration 描述
要求逾時 60 秒 容器應用程式閘道等待後端目標回應的時間。
HTTP 閒置逾時 5 分鐘 設置 HTTP 連線關閉前的閒置逾時時間。
串流閒置逾時 5 分鐘 HTTP 連線承載的單一串流，在關閉之前的閒置逾時。
上游連線逾時 5 秒 是時候建立與後端目標的連線了。

附註

請求超時會嚴格要求在指定時間內完成，不論資料是否正在傳輸或請求處於閒置狀態。 舉例來說，如果你正在提供大量檔案下載，且預期傳輸時間會超過60秒，因為檔案大小或傳輸速度慢，可以考慮提高請求逾時值或將其設為0。

當請求逾時在多個地點設定時，容器應用閘道會依以下優先順序進行：

  1. 在 HTTPRouteRule 上定義的閘道 API HTTPRoute 逾時 (timeouts.request 和 timeouts.backendRequest) 會優先採用。
  2. RoutePolicy 逾時 (routeTimeout) 會在未設定閘道 API HTTPRoute 逾時時使用。
  3. 當 Gateway API HTTPRoute 逾時或 RoutePolicy 逾時皆未定義時，會使用預設的逾時值。

Connectivity

成功運作容器應用閘道所需的連接需求如下。

ALB 控制器傳出連線能力

端點 港口 Purpose
management.azure.com TCP 443 Azure ARM API
login.microsoftonline.com TCP 443 Entra AD 認證
*.oic.prod-aks.azure.com TCP 443 AKS OIDC 發行者 (Workload Identity)
*.alb.azure.com TCP 443 設定端點
mcr.microsoft.com TCP 443 用於 Helm 部署的容器映像
DNS 解析 UDP 53 在預設的 AKS 部署中，ALB Controller 會查詢叢集內的 coreDNS/kube-dns

ALB 控制器入站連線

附註

這些入站埠口是透過 ClusterIP Service 公開的，並不會直接發佈到網際網路。 他們會被開放以便於進行故障排除或診斷，如果需要，可透過網路政策進行封鎖。

港口 名稱 Purpose
TCP 8000 後端系統健康狀況 後端健康端點（/backendHealth）
TCP 8001 計量 Prometheus 指標端點 （/metrics）

前端連接

容器應用閘道的每個前端格式為 *.fzXX.alb.azure.com，其中 XX 為數字 0-99。 前端僅限在 443 和 80 埠進行監聽。

  • Last updated on