自我裝載閘道概觀

適用於：開發人員 | 進階

自我裝載閘道是預設受控閘道的選擇性容器化版本，包含在每個 API 管理執行個體中。它適用於例如在託管 API 的相同環境中放置閘道的情境。使用自我裝載閘道可改善 API 流量，以及因應 API 安全性和合規性需求。

本文說明 Azure API 管理的自我裝載閘道功能如何啟用混合式和多雲端 API 管理。它還介紹了該功能的高級架構並描述了其功能。

如需受控閘道與自我裝載閘道之間差異的概觀，請參閱 API 管理中的 API 閘道。

混合式與多雲端 API 管理

自我裝載閘道功能可擴充混合式和多雲端環境的 API 管理支援，並可讓您從 Azure 上的單一 API 管理執行個體有效率且安全地管理裝載在內部部署和跨雲端的 API。

使用自我裝載閘道，您可以彈性地將容器化版本的 API 管理閘道元件部署至您裝載 API 的相同環境。所有自行託管的閘道皆由其所聯合的 API 管理實例進行管理，因此為您提供跨所有內部和外部 API 的可視性和統一管理體驗。

每個 API 管理實例都由下列重要元件所組成：

公開為 API 的管理平面，用來透過 Azure 入口網站、PowerShell 和其他支援的技術來設定服務
閘道（或資料平面），負責代理 API 要求、套用原則以及收集遙測
開發人員用來探索、學習和上線以使用 API 的開發人員入口網站

根據預設，所有這些元件都會部署在 Azure 上，導致所有 API 流量（在下圖中顯示為實心黑色箭頭）流經 Azure，而不論實作 API 的後端裝載在何處。此模型簡化了操作，代價是延遲增加、合規性問題，而且在某些情況下會收取額外的資料傳輸費用。

將自我託管閘道部署到託管後端 API 實作的相同環境中，可讓 API 流量直接流向後端 API，從而減少延遲、最佳化資料傳輸成本並實現合規性，同時保留組織中所有 API 的單一管理、可觀察性和探索點的優勢，無論其實作託管在何處。

包裝

可從 Microsoft Artifact Registry 將自我裝載閘道做為以 Linux 為基礎的 Docker 容器映像來使用。它可以部署到 Docker、Kubernetes 或任何其他在本地伺服器叢集、雲端基礎架構上執行的容器編排解決方案，或出於評估和開發目的，在個人電腦上執行。您也可以將自我裝載閘道部署至已啟用 Azure Arc 的 Kubernetes 叢集，做為叢集延伸模組。

容器映像

提供各種自管閘道器的容器映像：

標籤慣例	建議	範例	輪替標籤	建議用於生產環境
`{major}.{minor}.{patch}`	使用此標籤來一律執行相同版本的閘道。	`2.0.0`	❌	✔️
`v{major}`	使用此標籤，一律以每個新功能和修補檔來執行閘道的主要版本。	`v2`	✔️	❌
`v{major}-preview`	如果您一律想要執行最新的預覽容器映像，請使用此標籤。	`v2-preview`	✔️	❌
`latest`	如果您想要評估自我裝載閘道，請使用此標籤。	`latest`	✔️	❌
`beta` ¹	如果您想要評估自我裝載閘道預覽版，則請使用此標記。	`beta`	✔️	❌

您可以在此處找到可用標籤的完整清單。

¹預覽版未正式支援，僅供實驗之用。請參閱自我裝載閘道支援原則。

在正式部署選項中使用標籤

Azure 入口網站中的部署選項會使用 v2 標籤，可讓您使用最新版本的自我裝載閘道 v2 容器映像，搭配所有功能更新和修補程式。

附註

命令和 YAML 程式碼片段會提供作為參考。如果需要，您可以使用更具體的標籤。

當您安裝具有 Helm 圖表的閘道時，映像標記會最佳化。 Helm 圖表的應用程式版本會將網路閘道釘選到指定的版本，而且不依賴 latest。

如需詳細資訊，請參閱使用 Helm 在 Kubernetes 上安裝 API 管理自我裝載閘道。

使用輪替標籤的風險

輪替標籤是發行新版本容器映像時可能會更新的標籤。使用這種類型的標籤可讓容器使用者接收容器映像的更新，而不需要更新其部署。

當您使用這種類型的標籤時，您可能會在不知不覺的情況下平行執行不同的版本，例如，當您在更新標籤後 v2 執行擴展動作時。

範例：v2 標籤隨 2.0.0 容器映像一起釋放。當2.1.0被釋放時，v2標籤將連結到2.1.0影像。

重要事項

請考慮在生產中使用特定版本標籤，以避免無意中升級到較新版本。

與 Azure 的連線

自我裝載閘道需要在連接埠 443 上對 Azure 輸出 TCP/IP 連線。每個自我裝載閘道都必須與單一 API 管理實例相關聯，並透過其管理平面進行設定。自我裝載閘道會使用與 Azure 的連線，以便：

透過每分鐘傳送心跳訊息來報告狀態。
定期（每 10 秒）檢查並套用可用設定更新。
將計量傳送至 Azure 監視器（如果設定為這樣做）。
將事件傳送至 Application Insights（如果設定為這樣做）。

FQDN 相依性

若要正常運作，每個自我裝載閘道都需要在連接埠 443 上輸出連線至與其雲端式 API 管理執行個體相關聯的下列端點：

端點	是必要的嗎?	注意
設定端點的主機名稱	`<api-management-service-name>.configuration.azure-api.net` ¹	也支援並且可以使用自訂主機名稱，而不是預設主機名稱。
API 管理執行個體的公用 IP 位址	✔️	主要位置的 IP 位址已足夠。
Azure 儲存體服務標籤的公用 IP 位址	選擇性²	IP 位址必須對應至 API 管理實例的主要位置。
Azure Blob 儲存體帳戶的主機名稱	選擇性²	與執行個體相關聯的帳戶（`<blob-storage-account-name>.blob.core.windows.net`）。
Azure 資料表儲存體帳戶的主機名稱	選擇性²	與執行個體相關聯的帳戶（`<table-storage-account-name>.table.core.windows.net`）。
Azure Resource Manager 的端點	選用³	必要的端點是 `management.azure.com`。
Microsoft Entra 整合的端點	選用⁴	必要端點為 `<region>.login.microsoft.com` 和 `login.microsoftonline.com`。
適用於 Azure Application Insights 整合的端點	選用⁵	所需的最低端點是 `rt.services.visualstudio.com:443`、 `dc.services.visualstudio.com:443`和 `{region}.livediagnostics.monitor.azure.com:443`。如需詳細資訊，請參閱 Azure 監視器檔。
適用於事件中樞整合的端點	選用⁵	如需詳細資訊，請參閱 Azure 事件中樞文件。
適用於外部快取整合的端點	選用⁵	此需求取決於所使用的外部快取。

¹如需內部虛擬網路中 API 管理執行個體的相關資訊，請參閱內部虛擬網路中的連線能力。
²只有在原則中使用 API 偵測器或配額時，v2 中才需要。
³只有在使用 Microsoft Entra 驗證來驗證 RBAC 權限時才需要。
⁴只有在您使用 Microsoft Entra 驗證或與 Microsoft Entra 相關的原則時才需要。
⁵、只有在使用該功能且需要公用 IP 位址、連接埠和主機名稱資訊時才需要。

重要事項

DNS 主機名稱必須可解析為 IP 位址，且對應的 IP 位址必須可連線。
相關聯的儲存體帳戶名稱會列在 Azure 入口網站中服務的 [網路連線狀態 ] 頁面上。
相關聯儲存體帳戶下的公用 IP 位址是動態的，且可能在不另行通知的情況下變更。

內部虛擬網路中的連線能力

私人連線。 如果自我裝載閘道部署在虛擬網路中，請從自我裝載閘道的位置啟用對 v2 設定端點的私人連線，例如，在對等互連網路中使用私人 DNS。
互聯網連接。如果自我裝載閘道需要透過網際網路連線到 v2 組態端點，請設定組態端點的自訂主機名稱，並使用 Azure 應用程式閘道公開端點。

驗證選項

閘道容器的組態設定提供下列選項，以驗證自我裝載閘道與雲端式 API 管理執行個體組態端點之間的連線。

選項	考量
Microsoft Entra 驗證	設定一或多個 Microsoft Entra 應用程式以存取閘道。為每個應用程序單獨管理訪問權限。根據組織的政策，為密碼設定較長的到期時間。使用標準 Microsoft Entra 程序來指派或撤銷使用者或群組對應用程式的權限，以及更換機密。
閘道存取權杖。（也稱為驗證金鑰。	權杖至少每 30 天過期一次，且必須在容器中進行續期。由可獨立輪替的閘道金鑰支援（例如，撤銷存取權）。重新產生閘道金鑰會使使用它建立的所有存取權杖失效。

小提示

如需自我代管閘道在閘道存取權杖即將到期或已過期時所產生的事件網格事件相關資訊，請參閱 Azure API 管理作為事件網格來源。使用這些事件來確保已部署的網關始終能夠向相關聯的 API 管理實例進行驗證身份。

連線失敗

當 Azure 的連線中斷時，自我裝載閘道無法接收設定更新、報告其狀態或上傳遙測。

自我裝載閘道是針對「靜態失敗」而設計的，而且可以暫時承受與 Azure 之間的連線中斷。您可以使用或不使用本機設定備份來部署自我裝載閘道。透過設定備份，自我裝載閘道會定期針對最新下載的設定，將設定的備份複本儲存在其容器或 Pod 附加的永續性磁碟區上。

當備份關閉且 Azure 的連線中斷時：

執行自我裝載閘道會透過使用組態的記憶體內複本來繼續運作。
已停止的自我托管閘道器將無法啟動。

當備份開啟且 Azure 的連線中斷時：

運行自主托管閘道會使用記憶體中的設定副本持續運行。
已停用的自我託管閘道可以使用組態的備份複本重新啟動。

還原連線時，每個受中斷影響的自我裝載閘道都會自動重新連線到其相關聯的 API 管理實例，並下載閘道離線時發生的所有設定更新。

安全性

限制

受控閘道中可用的下列功能在自我裝載閘道中不可用：

TLS 工作階段繼續。
用戶端憑證重新交涉。若要使用用戶端憑證驗證，API 取用者必須將其憑證展現為初始 TLS 交握的一部分。若要確保此行為，請在設定自我裝載閘道的自訂主機名稱 (網域名稱) 時啟用「交涉用戶端憑證」設定。

傳輸層安全性 (TLS)

支援的通訊協定

自我裝載閘道預設支援 TLS v1.2。

如果您使用自訂網域，則可以在控制平面中啟用 TLS v1.0 和/或 v1.1。

可用的加密套件

自我裝載閘道會針對用戶端和伺服器連線使用下列密碼套件：

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

管理加密套件

在 v2.1.1 及更新版本中，您可以透過配置來管理正在使用的密碼：

net.server.tls.ciphers.allowed-suites 可讓您定義以逗點分隔的密碼清單，以用於 API 用戶端與自我管理閘道之間的 TLS 連線。
net.client.tls.ciphers.allowed-suites 可讓您定義以逗號分隔的密碼清單，以用於自我管理閘道與後端之間的 TLS 連線。

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-10-30