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

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

核心元件

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

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

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

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

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

適用於容器的應用程式閘道 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 應用程式防火牆原則之間的一對一對應。
  • 你可以在任意數量的安全政策中，針對定義的容器應用閘道資源，只引用一個網頁應用程式防火牆政策。

Azure / 一般概念

私人 IP 位址

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

子網路委派

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

使用者指派的受控識別

• Azure 資源受控識別可以免除以程式碼管理認證的需求。
• 你需要為每個 Azure 負載平衡控制器設定一個由使用者指派的管理身份，才能對容器的應用閘道進行變更。
• 適用於 Containers Configuration Manager 的 AppGw 是內建的 RBAC 角色，可讓 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 將適用於容器的應用程式閘道接收並啟動的要求與存取記錄中定義的後端目標關聯起來。

要求逾時

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