Azure 提供一系列容器裝載服務，其設計目的是要容納各種工作負載、架構和商務需求。 此容器服務選擇指南可協助您的工作負載小組瞭解哪一個 Azure 容器服務最適合您的工作負載案例和需求。
注意
在本指南中， 工作負載 是指支援商務目標或商務程序實作的應用程式資源集合。 工作負載會使用多個服務，例如 API 和數據存放區，共同運作以提供特定的端對端功能。
概述
本指南包含本簡介文章和另一篇文章，說明在所有工作負載類型中所需考量。
注意
如果您未認可容器化， 請選擇不同的計算選項 來裝載您的工作負載。
本簡介文章概述本指南所涵蓋的 Azure 容器服務，並根據可設定性和預先定義的解決方案來比較其服務模型，例如客戶管理的與Microsoft管理的方法。 ** 在您根據自己的服務模型偏好識別候選服務之後，下一步是根據您的工作負載要求，檢視有關於網路、安全性、營運和可靠性方面的共通考量文章，進一步評估各個選項。
本指南可協助您根據工作負載的技術需求、大小和複雜度來評估取捨。 它也會考慮小組的專業知識，以確保明智的決策制定。
本指南範圍內的 Azure 容器服務
本指南著重於 Azure 提供的容器服務子集。 此子集提供 Web 應用程式和 API、網路功能、可觀察性、開發人員工具和作業的成熟功能集。 比較下列容器服務：
Azure Container Apps 是完全受控的平臺，可讓您執行容器化應用程式，而不必擔心協調流程或基礎結構。 如需詳細資訊，請參閱容器應用程式文件。
Azure Kubernetes Service （AKS） 是受控 Kubernetes 服務，可用於執行容器化應用程式。 透過 AKS，您可以利用受控的 附加元件和延伸模組 來獲得額外功能，同時保留最高水準的可配置性。 如需詳細資訊，請參閱 AKS 檔案。
適用於容器的 Web 應用程式 是 Azure App Service 的功能。 App Service 是完全受控的服務，可裝載 HTTP 型 Web 應用程式，其內建基礎結構維護、安全性修補、調整和診斷工具。 如需詳細資訊，請參閱 App Service 文件。
如需 Azure 容器服務的完整清單，請參閱 Azure 上的容器。
服務模型考慮
服務模型可協助您瞭解每個 Azure 容器服務所提供的彈性和控制程度。 複雜服務提供更多的控制，而更簡單的服務可讓管理更容易，但會限制自定義。
如需服務模型術語和概念的詳細資訊，包括基礎結構即服務 （IaaS） 和平臺即服務 （PaaS），請參閱 雲端中的共同責任。
比較 Azure 容器解決方案的服務模型
Azure Kubernetes Service （AKS）
AKS 是 IaaS 和 PaaS 的組合，其著重於控制，而不是簡單。 它會使用 Kubernetes，這是協調容器的標準系統。 AKS 可簡化基礎核心基礎結構的管理。 不過，此虛擬機 (VM) 型平臺會向您的應用程式暴露，且需要適當的管理措施和流程，例如修補，以確保安全性和業務連續性。 額外的 Azure 資源支援計算基礎結構，這些資源會直接裝載在您的訂用帳戶中，例如 Azure 負載平衡器、容器登錄或應用程式閘道。
AKS 可讓您存取 Kubernetes API 伺服器，這可讓您自定義容器協調流程，並從 Cloud Native Computing Foundation 部署輔助應用程式。 因此，對於初次接觸 Kubernetes 的工作負載團隊來說，面臨顯著的學習曲線。 如果您不熟悉容器化解決方案，則必須考慮此學習曲線。 下列 PaaS 解決方案提供較低的進入屏障。 當您的需求增加時，您可以轉換至 Kubernetes。
AKS 自動
AKS 自動 可透過自動化複雜的叢集管理工作，更輕鬆地採用 Kubernetes。 此自動化可減少進階 Kubernetes 專業知識的需求。 其提供更精簡且類似 PaaS 的體驗，同時維護 Kubernetes 的彈性和擴充性。 Azure 預設會管理叢集設定、節點布建、調整、安全性修補，以及套用最佳做法設定。 此自動化可減少作業工作，但會限制可用的拓撲選項。
注意
本指南會區分 AKS 標準與 AKS 自動，如果適用的話。 否則，您可以假設這兩個產品上所描述的功能相同。
容器應用程式
Container Apps 是 Kubernetes 之上的抽象層，可讓您的應用程式執行和調整，而不需要直接管理基礎結構。 容器應用程式同時提供無伺服器和專用的計算選項。 這些選項可讓您完全控制應用程式可用的計算資源類型和數量。 Container Apps 會抽象化容器協調流程 API，同時仍提供第 7 層輸入、流量分割、A/B 測試和應用程式生命週期管理等重要功能的內建存取。
用於容器的 Web App
適用於容器的 Web 應用程式是一種 PaaS 服務，與容器應用程式相比，它優先考量的是簡潔性而非控制性。 它會抽象化容器協調流程，同時仍支援調整、應用程式生命週期管理、流量分割、網路整合和可觀察性。
託管模型考量
您可以使用 Azure 資源，例如 AKS 叢集來裝載多個工作負載。 這種方法可協助您簡化作業，進而降低整體成本。 如果您選擇此選項，請考慮下列功能：
AKS 通常用於裝載多個工作負載或不同的工作負載元件。 您可以使用 Kubernetes 的原生功能來隔離這些工作負載和元件，例如命名空間、訪問控制和網路控制，以符合安全性需求。
如果您需要 Kubernetes API 所提供的額外功能，而且您的工作負載小組有足夠的作業 Kubernetes 叢集經驗，您也可以在單一工作負載案例中使用 AKS。 具有較少 Kubernetes 體驗的 Teams 仍然可以使用 Azure 管理的 附加元件 和叢 集自動升級 等功能，有效地管理自己的叢集，以減少作業工作。
Container Apps 應該用來裝載具有共用安全性界限的單一工作負載。 Container Apps 有一個稱為 Container Apps 環境的單一最上層邏輯界限，這也可作為增強的安全性界限。 沒有更細微訪問控制的機制。 例如，內部環境通訊不受限制，而且所有應用程式都會共用單一 Log Analytics 工作區。
如果工作負載有多個元件和安全性界限，請部署多個 Container Apps 環境，或改為考慮 AKS。
適用於容器的 Web 應用程式 是 App Service 的功能。 App Service 會將應用程式分組為稱為 App Service 方案的邏輯計算界限。 因為您可以在應用層級設定角色型訪問控制的範圍，因此您可能會想要在單一方案中裝載多個工作負載。 不過，最好為每個方案裝載單一工作負載，以避免吵雜的鄰近問題。 單一 App Service 方案中的所有應用程式都會共用相同的配置計算、記憶體和儲存體。
當您考慮硬體隔離時，請記住，App Service 方案通常會在其他 Azure 客戶共用的基礎結構上執行。 您可以選擇專用 VM 的專用層，或專用虛擬網路中專用 VM 的隔離層。
一般而言，所有 Azure 容器服務都可以裝載多個具有多個元件的應用程式。 不過，Container Apps 和 Web App for Containers 最適合單一工作負載元件，或共用類似生命週期的多個密切相關的工作負載元件，以及單一小組擁有並執行應用程式。
如果您需要在一部主機上裝載不同的應用程式元件或工作負載，請考慮使用 AKS。
控制與易於使用之間的取捨
AKS 提供最多的可設定性，但相較於其他服務，這種可設定性需要更多作工作。 容器應用程式和適用於容器的 Web 應用程式都是具有類似層級Microsoft管理功能的 PaaS 服務。 適用於容器的 Web 應用程式著重於簡單性來為其目標受眾提供服務，這些目標受眾是熟悉介面的目前 App Service 客戶。
最佳做法
提供更簡單的服務通常適合專注於功能開發而不是基礎結構管理的客戶。 提供更多控制權的服務通常適合需要可設定性且具備管理自己基礎結構的技能、資源和業務理由的客戶。
所有工作負載的共同考量
工作負載小組可能偏好特定的服務模型，但該模型可能不符合組織的整體需求。 例如，開發人員可能想要較少的作業工作，但安全性小組可能會考慮合規性所需的這項額外負荷。 團隊需要合作，才能進行正確的權衡取捨。
共同考慮事項涵蓋範圍廣泛的因素。 只有一小部分的考慮可能會根據工作負載類型套用至您。 您在組織中的角色也會影響相關考量的因素。
下表提供考慮的高階概觀，包括服務功能比較。 檢閱每個類別中的考慮，並將其與您的工作負載需求進行比較。
| 類別 | 概述 |
|---|---|
| 網路規劃考量 | Azure 容器服務中的網路配置取決於您對簡單性或可配置性的偏好。 AKS 提供對網路流程的廣泛控制，但需要更多作工作。 Container Apps 具有由 Azure 管理的網路功能，並定位於 AKS 與適用於容器的 Web 應用程式之間，針對已經使用 App Service 的客戶提供服務。 網路設計決策會產生長期後果，因為變更它們通常需要重新部署工作負載。 數個因素，例如IP位址規劃、負載平衡、服務探索和專用網，會因這些服務而異。 您應該仔細檢閱每個服務如何符合特定的網路需求。 |
| 安全性考慮 | 容器應用程式、AKS 和適用於容器的 Web 應用程式會與 Azure Key Vault 和受控識別等主要 Azure 安全性供應專案整合。 AKS 提供額外的功能，例如運行時間威脅防護和網路原則。 Container Apps 之類的 PaaS 服務似乎具有較少的安全性功能，但部分原因是 Azure 會管理更多基礎結構元件。 因為這些元件不會向客戶公開，因此風險較低。 |
| 作業考慮 | AKS 提供最多的客製化，但需要更多的操作投入。 容器應用程式和適用於容器的 Web 應用程式等 PaaS 解決方案可讓 Azure 處理 OS 更新之類的工作。 延展性和硬體 SKU 彈性很重要。 AKS 提供彈性的硬體選項，但容器應用程式和適用於容器的 Web 應用程式選擇較少。 在 AKS 中，應用程式延展性是您的責任，因此您可以套用任何與 Kubernetes 相容的解決方案。 AKS 自動、容器應用程式和適用於容器的 Web 應用程式著重於更簡單的方法。 |
| 可靠性考慮 | 相較於 AKS，Web 應用程式對於容器和容器應用程式的健康探測組態有限。 不過，因為其使用熟悉的 Azure Resource Manager API，所以設定起來更簡單。 AKS 需要 Kubernetes API，也要求您管理 Kubernetes 節點集區延展性和可用性，以正確排程應用程式實例。 這些要求會增加 AKS 的運作負擔。 容器應用程式和適用於容器的 Web 應用程式的服務等級協定 （SLA） 比 AKS SLA 更容易計算。 AKS 控制平面和節點集區各自有自己的服務等級協議 (SLA)，必須一併考量。 所有服務都會在支援該區域的數據中心提供區域備援。 |
即使您檢閱上述考慮之後，仍然可能找不到完美的適合，這是常見的。
評估取捨
雲端運算很複雜。 它牽涉到跨許多小組的共同作業，而且必須考慮人員、預算和時間的限制。 這些因素使得雲端服務選擇變得困難且充滿取捨。
對於任何工作負載，某些需求可能比其他工作負載更為重要。 例如，應用程式小組可能會偏好像 Container Apps 這樣的 PaaS 解決方案，但選擇 AKS，因為其安全性小組需要共置工作負載元件之間的拒絕預設網路控制。 AKS 專用的功能會使用 Kubernetes 網路原則。
上述共用考慮涵蓋最常見的需求，但並不全面。 您必須先根據慣用服務的功能集評估每個需求，才能做出決策。
結論
本指南涵蓋選擇 Azure 容器服務時最常見的考慮。 其設計目的是協助您的工作負載小組做出明智的決策。 此程式從選取雲端服務模型開始，其牽涉到判斷所需的控制層級。 更多的控制是以犧牲簡單為代價。 換句話說，目標是在自我管理基礎結構與Microsoft管理的基礎結構之間建立正確的平衡。
許多工作負載小組僅根據他們偏好 PaaS 或 IaaS 來選擇 Azure 容器服務。 其他小組必須進一步調查，以判斷服務特定功能如何處理工作負載或組織需求。
使用本指南仔細評估您的選項，並避免做出難以反轉的決策。 不過，除非開發人員嘗試服務，並根據實際作體驗來評估服務，而不是理論，否則沒有任何決定。
貢獻者
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- Andre Dewes |資深客戶工程師
- 馬科斯·馬丁內斯 |高級服務工程師
- Julie Ng |高級工程師
其他參與者：
- Martin Gjoshevski |資深客戶工程師
- Don High |首席客戶工程師
- Nelly Kiboi |服務工程師
- 徐紅劉 | 高級服務工程師
- 費薩爾·穆斯塔法 |資深客戶工程師
- 沃爾特·邁爾斯 |主要客戶工程經理
- 索納利卡·羅伊 |資深客戶工程師
- Paolo Salvatori |首席客戶工程師
- 維克多·桑塔納 |首席客戶工程師
- Carlos Mestre del Pino |雲端解決方案架構師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。