自我裝載閘道的支援原則

適用於：開發人員 | 進階

開發人員和進階層中的 Azure APIM 服務可讓您將 APIM 閘道部署為在內部部署基礎結構、其他雲端和支援容器的 Azure 基礎結構選項中執行的容器。本文將詳細說明適用於 APIM 自我裝載閘道的技術支援原則和限制。

受控閘道與自我裝載閘道之間的差異

部署 APIM 服務的執行個體時，您將一律取得受控 API 閘道作為服務的一部分。此閘道會在 Azure 所管理的基礎結構中執行，而軟體也會由 Azure 所管理及更新。

在支援的服務層級中，自我裝載閘道是選擇性的部署選項。

雖然受控和自我裝載的閘道會共用許多常見功能，但也有數個差異。

下表顯示 Microsoft 在管理和支援自我裝載閘道方面的責任、共同責任，以及客戶的責任。

Microsoft Azure	共同責任	客戶
▪️ 設定端點 (管理平面) - 自我裝載閘道取決於提供設定、API、主機名稱及原則資訊的設定端點。此設定端點是每個 APIM 服務管理平面的一部分。 ▪️ 閘道容器映像維護和更新 - 自我裝載閘道容器映像中的錯誤 (Bug) 修正程式、修補檔、效能改善及新功能。	▪ 保護自我裝載閘道與設定端點的通訊 - 自我裝載閘道與設定端點之間的通訊可受到兩種機制保護：存取權杖每 30 天就會自動到期，且需要針對執行中的容器更新；或使用不需要權杖重新整理的 Microsoft Entra ID 進行驗證。 ▪ 讓閘道保持最新狀態 - 客戶會定期監督將閘道更新為最新版本和最新功能。而 Microsoft 將提供更新的映像，其中包含新功能、錯誤 (Bug) 修正程式和修補檔。	▪ 閘道裝載 - 部署及操作閘道基礎結構：具有容器執行階段和/或 Kubernetes 叢集的虛擬機器。 ▪ 網路設定 - 維護管理平面連線和 API 存取的必要項目。 ▪ 閘道 SLA - 容量管理、調整和運作時間。 ▪ 提供診斷資料以尋求支援 - 收集診斷資料並與支援工程師共用。 ▪ 第三方 OSS (開放原始碼的軟體) 軟體元件 - 將自我裝載閘道與其他軟體 (例如 Prometheus、Grafana、服務網格、容器執行階段、Kubernetes 發行版本和 Proxy) 合併是客戶的責任。

我們有下列適用於自我裝載閘道容器映像的標記策略，遵循主要、次要、修補慣例：{major}.{minor}.{patch}。您可以找到完整的可用標籤清單。最佳做法是建議客戶執行容器映像的最新穩定版本。有鑑於容器映像持續發行，我們將為下列版本提供官方支援：

最新的主要版本和最新的三個次要版本

例如，如果最新版本是 2.2.0，我們將支援所有 2.2.x、2.1.x 和 2.0.x 次要版本。針對所有舊版，我們將要求您更新為支援的版本。
修正

如果我們在支援的版本中發現錯誤 (Bug)、CVE 或效能問題 (例如，在容器映像 2.0.0 中找到錯誤 (Bug))，修正程式將在最新次要版本 (例如 2.2.x) 中以修補檔的形式登陸。

關於如何在 Kubernetes 內使用自我裝載閘道的問題。例如，Microsoft 支援服務不會建議您如何建立自訂輸入控制器、服務網格、使用應用程式工作負載，或是套用第三方或開放原始碼的軟體套件或工具。
與自我裝載閘道合併的第三方開放原始碼專案，但特定的支援專案除外，例如：Open Telemetry 和 DAPR (分散式應用程式執行階段)。
第三方封閉來源軟體，包含安全性掃描工具和網路裝置或軟體。
針對網路自訂、CNIS、服務網格、網路原則、防火牆和複雜的網路線路進行疑難排解。 Microsoft 將只會檢查自我裝載閘道與設定端點之間的通訊是否正常運作。

如有疑問，請在 Microsoft Q&A 中尋求社群專家的解答。

如果您有支援方案，且需要技術協助，請建立支援要求：

您也可以從我們的社群取得協助。您可以在 GitHub (英文) 提出問題，或在 Stack Overflow (英文) 詢問問題，並以 "azure-api-management" 標記。

了解如何將 APIM 自我裝載閘道部署到已啟用 Azure Arc 的 Kubernetes 叢集、Azure Kubernetes Service，或是使用 YAML 或 Helm 圖表的 Kubernetes 叢集。
檢閱在生產環境中的 Kubernetes 上執行自我裝載閘道的指引。