選擇 Azure 容器服務
Azure 提供了一系列的容器裝載服務，旨在滿足各種工作負載、架構和商務需求。 此容器服務選擇指南可協助您瞭解哪一個 Azure 容器服務最適合您的工作負載案例和需求。
注意
在本指南中，工作負載一詞是指支援商務目標或商務程序執行的應用程式資源集合。 工作負載會使用多個服務，例如 API 和數據存放區，共同運作以提供特定的端對端功能。
如何使用本指南
本指南包含兩篇文章：本簡介文章和另一篇文章，說明 在所有工作負載類型之間共用的 考慮。
注意
如果您尚未認可容器化，請參閱 選擇 Azure 計算服務 ，以取得可用來裝載工作負載之其他計算選項的相關信息。
本簡介文章說明本指南範圍內的 Azure 容器服務，以及服務模型在可設定性與意見化解決方案之間如何比較，例如客戶管理的與 Microsoft 管理的方法。 在您根據服務模型喜好設定識別候選服務之後，下一個步驟是檢閱網路、安全性、作業和可靠性的共用考慮一文，根據工作負載需求評估選項。
本指南會根據工作負載的技術需求、大小和複雜度，以及工作負載小組的專業知識，考慮您可能需要做出的取捨。
本指南範圍內的 Azure 容器服務
本指南著重於 Azure 目前提供的容器服務子集。 此子集提供 Web 應用程式和 API、網路功能、可觀察性、開發人員工具和作業的成熟功能集。 這些容器服務會進行比較：
Azure Container Apps 是完全受控的 Kubernetes 應用程式平臺，可協助您從程式碼或容器部署 HTTP 和非 HTTP 應用程式，而不需要協調基礎結構。 如需詳細資訊，請參閱 Azure Container Apps 檔。
Azure Kubernetes Service （AKS） 是受控 Kubernetes 服務，可用於執行容器化應用程式。 透過 AKS，您可以利用受控 附加元件和擴充 功能來取得其他功能，同時保留最廣泛的設定層級。 如需詳細資訊，請參閱 AKS 檔。
適用於容器的 Web 應用程式是一項 Azure App 服務 功能，這是一項完全受控的服務，可裝載具有內建基礎結構維護、安全性修補、調整和診斷工具的 HTTP 型 Web 應用程式。 如需詳細資訊，請參閱 App Service 文件。
如需所有 Azure 容器服務的完整清單，請參閱 容器服務產品類別頁面。
服務模型考慮
服務模型提供最廣泛的深入解析，瞭解任何 Azure 容器服務所提供的彈性和控制層級，以換取其整體簡單性和易於使用性。
如需服務模型相關術語和概念的一般簡介，包括基礎結構即服務（IaaS）和平臺即服務（PaaS），請參閱 雲端中的共同責任。
比較 Azure 容器解決方案的服務模型
AKS
作為 IaaS 和 PaaS 的混合式，AKS 會優先控制簡單性。 雖然 AKS 可簡化基礎核心基礎結構的管理，但此以 VM 為基礎的平臺仍會向您的應用程式公開，而且需要適當的護欄和程式，例如修補，以確保安全性和商務持續性。 計算基礎結構是由直接裝載於訂用帳戶中的其他 Azure 資源所支援，例如 Azure 負載平衡器。
AKS 也提供 Kubernetes API 伺服器的存取權，這可讓您自定義容器協調流程，進而從雲端原生運算基礎 （NCF） 部署專案。 因此，對於 Kubernetes 不熟悉的工作負載小組而言，會有顯著的學習曲線。 如果您不熟悉容器化解決方案，此學習曲線可能是威懾力。 下列 PaaS 解決方案提供較低的進入屏障。 當您的需求指定移動時，您可以移至 Kubernetes。
Azure 容器應用程式
Container Apps 是 PaaS 供應專案，可簡化控制。 它同時提供無伺服器和專用的計算選項，因此不需要修補作業系統或建置與操作系統相關的應用程式防護。 Container Apps 也會完全擷取容器協調流程 API，並透過 Azure API 提供其重要功能的子集，您的小組可能已經熟悉。 此外，第 7 層輸入、流量分割、A/B 測試和應用程式生命週期管理全都現成可用。
用於容器的 Web App
適用於容器的 Web 應用程式也是 PaaS 供應專案，但它提供比 Container Apps 更簡單且較少的控制。 它會將容器協調流程抽象化，但仍提供適當的調整、應用程式生命週期管理、流量分割、網路整合和可檢視性。
裝載模型考慮
您可以使用 Azure 資源，例如 AKS 叢集來裝載多個工作負載。 這麼做可協助您簡化作業，進而降低整體成本。 如果您選擇此路徑，以下是一些重要的考慮：
AKS 通常用來裝載多個工作負載或不同的工作負載元件。 您可以使用 Kubernetes 原生功能來隔離這些工作負載和元件，例如命名空間、訪問控制和網路控制，以符合安全性需求。
如果您需要 Kubernetes API 所提供的額外功能，而且您的工作負載小組有足夠的經驗操作 Kubernetes 叢集，您也可以在單一工作負載案例中使用 AKS。 具有較少 Kubernetes 體驗的小組仍可藉由利用 Azure 受控 附加元件 和功能，例如 叢集自動升級，以降低作業額外負荷，以成功操作自己的叢集。
容器應用程式 應該用來裝載具有共用安全性界限的單一工作負載。 Container Apps 有一個稱為 Container Apps 環境的單一最上層邏輯界限，這也可作為增強式安全性界限。 沒有其他細微訪問控制的機制。 例如，環境內部通訊不受限制，而且所有應用程式都會共用單一 Log Analytics 工作區。
如果工作負載有多個元件和多個安全性界限，請部署多個 Container Apps 環境，或改為考慮 AKS。
適用於容器 的 Web 應用程式是 App Service 的功能。 App Service 會將應用程式分組為稱為 App Service 方案的計費界限。 因為您可以在應用層級設定角色型訪問控制 （RBAC）的範圍，所以在單一方案中裝載多個工作負載可能會很誘人。 不過，建議您為每個計劃裝載單一工作負載，以避免產生 Noisy Neighbor 問題。 單一 App Service 方案中的所有應用程式都會共用相同的配置計算、記憶體和記憶體。
當您考慮硬體隔離時，必須注意 App Service 方案通常會在與其他 Azure 客戶共用的基礎結構上執行。 您可以選擇專用 VM 的專用層，或專用虛擬網路中專用 VM 的隔離層。
一般而言，所有 Azure 容器服務都可以裝載多個具有多個元件的應用程式。 不過，Container Apps 和 Web App for Containers 更適合單一工作負載元件或多個高度相關的工作負載元件，這些元件共用類似的生命週期，其中單一小組擁有和執行應用程式。
如果您需要在一部主機上裝載不同的應用程式元件或工作負載，請考慮使用 AKS。
控制與易於使用之間的取捨
AKS 提供最多的可設定性，但相較於其他服務，這種設定性會因為作業額外負荷增加而付出代價。 雖然容器應用程式和適用於容器的 Web 應用程式都是具有類似 Microsoft 管理功能的 PaaS 服務，但適用於容器的 Web 應用程式強調簡單，以迎合其目標物件：找到熟悉介面的現有 Azure PaaS 客戶。
經驗法則
一般而言，提供更簡單性的服務往往適合偏好更專注於功能開發，且較不專注於基礎結構的客戶。 提供更多控制權的服務往往適合需要更多可設定性且具備管理自己基礎結構所需的技能、資源和業務理由的客戶。
所有工作負載的共享考慮
雖然工作負載小組可能偏好特定服務模型，但該模型可能不符合整個組織的需求。 例如，開發人員可能偏好較少的作業額外負荷，但安全性小組可能會考慮符合合規性需求所需的這類額外負荷。 小組必須共同作業，才能進行適當的取捨。
請注意，共用考慮很廣泛。 視工作負載類型，以及組織內的角色而定，可能只有子集與您相關。
下表提供考慮的高階概觀，包括服務功能比較。 檢閱每個類別中的考慮，並將其與您的工作負載需求進行比較。
| 類別 | 概觀 |
|---|---|
| 網路考量 | Azure 容器服務中的網路功能會根據您的喜好設定而有所不同，以求簡單與可設定性。 AKS 可高度設定，可提供對網路流程的廣泛控制，但需要更多操作工作。 Container Apps 提供 Azure 管理的網路功能。 這是 AKS 與適用於容器的 Web 應用程式之間的中間點，專為熟悉 App Service 的客戶量身打造。 關鍵是，網路設計決策可能會有長期的後果，因為不需要重新部署工作負載就能變更它們的挑戰。 數個因素，例如IP位址規劃、負載平衡責任、服務探索方法和專用網功能，在這些服務之間有所不同。 您應該仔細檢閱服務如何符合特定網路需求。 |
| 安全性考量 | 容器應用程式、AKS 和適用於容器的 Web 應用程式都提供與 Azure 金鑰保存庫 和受控識別等重要 Azure 安全性供應專案的整合。 AKS 提供其他功能，例如運行時間威脅防護和網路原則。 雖然容器應用程式之類的 PaaS 服務似乎提供較少的安全性功能，但部分原因是 Azure 管理了更多基礎結構元件，而不會向客戶公開，這可降低風險。 |
| 作業考慮 | 雖然 AKS 提供最多的自定義功能，但它需要更大的作業輸入。 相反地，Container Apps 和 Web App for Containers 等 PaaS 解決方案可讓 Azure 處理 OS 更新等工作。 延展性和硬體 SKU 彈性至關重要。 AKS 提供彈性的硬體選項，而 Container Apps 和 Web App for Containers 則提供設定。 AKS 中的應用程式延展性是客戶的唯一責任。 容器應用程式和適用於容器的 Web 應用程式提供更精簡的方法。 |
| 可靠性考慮 | 容器的 Web 應用程式和 Container Apps 健康情況探查組態比 AKS 更精簡，因為其使用熟悉的 Azure Resource Manager API。 AKS 需要使用 Kubernetes API。 它也要求您承擔管理 Kubernetes 節點集區延展性和可用性的額外責任，才能正確排程應用程式實例。 這些需求會導致 AKS 的額外額外負荷。 此外，容器應用程式和適用於容器的 Web 應用程式的 SLA 比 AKS 更直接，其中控制平面和節點集區各自有自己的 SLA，因此必須據以複合。 所有服務都會在提供該區域的數據中心提供區域備援。 |
檢閱上述考慮之後，您仍然可能找不到完美的適合專案。 這完全正常。
評估取捨
選擇雲端服務不是簡單的練習。 鑒於雲端運算的複雜性，許多小組之間的共同作業，以及涉及人員、預算和時間的資源限制，每個解決方案都有取捨。
請注意，對於任何指定的工作負載，某些需求可能比其他需求更為重要。 例如，應用程式小組可能偏好使用如 Container Apps 的 PaaS 解決方案，但選擇 AKS，因為其安全性小組需要共置工作負載元件之間的拒絕預設網路控制，這是使用 Kubernetes 網路原則的僅限 AKS 功能。
最後，請注意，上述共用考慮包含最常見的需求，但並不全面。 工作負載小組有責任先根據慣用服務的功能集調查每個需求，再確認決策。
推論
本指南說明您在選擇 Azure 容器服務時所面臨的最常見考慮。 其設計目的是要引導工作負載小組做出明智的決策。 此程式從選擇雲端服務模型開始，其牽涉到判斷所需的控制層級。 控制會犧牲簡單性。 換句話說，這是在自我管理基礎結構與 Microsoft 所管理基礎結構之間尋找正確平衡的程式。
許多工作負載小組只能根據慣用的服務模型來選擇 Azure 容器服務：PaaS 與 IaaS。 其他小組必須進一步調查，以判斷服務特定功能如何處理工作負載或組織需求。
除了納入盡職盡責之外，所有工作負載小組都應該使用本指南，以避免難以反向決策。 不過，請注意，在開發人員嘗試服務，並根據經驗而不是理論來決定之前，不會確認決策。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Andre Dewes |資深客戶工程師
- 馬科斯·馬丁內斯 |高級服務工程師
- Julie Ng |高級工程師
其他投稿人：
- 米克·阿爾伯特 |技術寫入器
- Martin Gjoshevski |資深客戶工程師
- Don High |首席客戶工程師
- Nelly Kiboi |服務工程師
- 劉 旭紅 |高級服務工程師
- Faisal Mustafa |資深客戶工程師
- 沃爾特·邁爾斯 |主要客戶工程經理
- 索納利卡·羅伊 |資深客戶工程師
- Paolo Salvatori |首席客戶工程師
- 維克多·桑塔納 |首席客戶工程師
後續步驟
深入瞭解本文中所述服務的共享架構考慮。