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

本文提供適用於容器的應用程式閘道元件的詳細說明和需求。 提供適用於容器的應用程式閘道如何接受傳入要求並將其路由傳送至後端目標的相關資訊。 如需容器 應用程式閘道 的一般概觀，請參閱什麼是容器 應用程式閘道。

核心元件

• 容器資源的 應用程式閘道 是部署控制平面的 Azure 父資源。
• 控制平面負責根據客戶意願來協調 Proxy 設定。
• 容器 應用程式閘道 有兩個子資源;關聯和前端。
  • 子資源只專屬於容器的父系 應用程式閘道，而且不能由容器資源的另一個 應用程式閘道 參考。

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

• 容器前端資源的 應用程式閘道 是容器父資源 應用程式閘道 的 Azure 子資源。
• 容器前端的 應用程式閘道 會定義容器的指定 應用程式閘道 應該接收進入點用戶端流量。
  • 前端無法與容器的多個 應用程式閘道 相關聯。
  • 每個前端都會提供唯一的 FQDN，可由客戶的 CNAME 記錄參考。
  • 私人IP位址目前不受支援。
• 容器的單一 應用程式閘道 可以支援多個前端。

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

• 容器關聯資源的 應用程式閘道 是容器父資源 應用程式閘道 的 Azure 子資源。
• 適用於容器的應用程式閘道關聯定義虛擬網路的連接點。 關聯是將關聯資源以 1：1 方式對應至受委派的 Azure 子網路。
• 容器 應用程式閘道的設計目的是允許多個關聯。
  • 目前，目前關聯數目限制為1。
• 在建立關聯期間，基礎數據平面會布建並連線到定義虛擬網路子網內的子網。
• 每個關聯都應假設在佈建時，子網路中至少有 256 個位址可用。
  • 每個部署的最低 /24 子網掩碼（假設先前未在子網中布建任何資源）。
    • 如果已佈建 n 數量的適用於容器的應用程式閘道，並假設每個適用於容器的應用程式閘道都包含一個關聯，且想要共用相同的子網路，則可用的必要位址應該是 n*256。
  • 容器關聯資源的所有 應用程式閘道 都應該符合與容器父資源 應用程式閘道 相同的區域。

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

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

Azure / 一般概念

私人 IP 位址

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

子網路委派

• Microsoft.ServiceNetworking/trafficControllers 適用於容器的應用程式閘道所採用的命名空間，可以委派給虛擬網路的子網路。
• 發生委派時，不會佈建適用於容器的應用程式閘道資源，也不會與適用於容器的應用程式閘道關聯資源產生獨占對應。
• 任意數量的子網路可以有一個子網路委派 (與適用於容器的應用程式閘道相同或不同)。 定義後，除了已定義的服務以外，沒有任何其他資源可以佈建到這個子網路，除非服務實作已明確定義。

使用者指派的受控識別

• Azure 資源受控識別可以免除以程式碼管理認證的需求。
• 每個 Azure Load Balancer 控制器都需要使用者受控識別，才能變更容器 應用程式閘道。
• 適用於 Containers Configuration Manager 的 AppGw 是內建的 RBAC 角色，可讓 ALB 控制器存取及設定適用於容器的應用程式閘道資源。

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

每個適用於容器的應用程式閘道前端均提供由 Azure 管理且已產生的完整網域名稱。 FQDN 可以照原樣使用，或者客戶可以選擇使用 CNAME 記錄來遮罩 FQDN。

用戶端將要求傳送至適用於容器的應用程式閘道之前，用戶端會先解析指向前端 FQDN 的 CNAME；或用戶端可以使用 DNS 伺服器，直接解析適用於容器的應用程式閘道所提供的 FQDN。

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

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

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

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

HTTP/2 要求

應用程式閘道 for Containers 完全支援 HTTP/2 通訊協定，以便從用戶端到前端進行通訊。 從容器到後端目標的 應用程式閘道 通訊會使用 HTTP/1.1 通訊協定。 HTTP/2 設定一律已啟用，且無法變更。 如果用戶端偏好使用 HTTP/1.1 與容器 應用程式閘道 前端的通訊，他們可能會繼續據此進行交涉。

對要求的修改

容器的 應用程式閘道 會在從容器的 應用程式閘道 起始要求之前，將三個額外的標頭插入所有要求至後端目標：

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

x-forwarded-for 是原始要求者的用戶端 IP 位址。 如果要求是透過 Proxy 進行，標頭值會附加收到的位址，並以逗號分隔。 例如：1.2.3.4,5.6.7.8；其中 1.2.3.4 是適用於容器的應用程式閘道前端的 Proxy 用戶端 IP 位址，而 5.6.7.8 是轉送流量至適用於容器的應用程式閘道的 Proxy 位址。

x-forwarded-proto 會傳回適用於容器的應用程式閘道從用戶端所接收的通訊協定。 值是 http 或 https。

x-request-id 是適用於容器的應用程式閘道針對每一個用戶端要求所產生的唯一 GUID，會出現在送往後端目標的轉送要求中。 guid 是由 32 個英數位元組成，並以破折號分隔（例如：aaaa0000-bb11-2222-33cc-444444ddddd 此 GUID 可用來關聯適用於容器的應用程式閘道所收到的要求，並依照存取記錄中的定義，將該要求起始傳送到後端目標。

要求逾時

容器 應用程式閘道 會強制執行下列逾時，因為要求會在客戶端之間起始和維護、容器和後端 應用程式閘道。