共用方式為

選擇 Azure 容器服務

  • 發行項

Azure 提供一系列容器裝載服務，其設計目的是要容納各種工作負載、架構和商務需求。 此容器服務選擇指南可協助您瞭解哪一個 Azure 容器服務最適合您的工作負載案例和需求。

注意

在本指南中，工作負載 一詞是指支援商務目標或執行商務程式的應用程式資源集合。 工作負載會使用多個服務，例如 API 和數據存放區，共同運作以提供特定的端對端功能。

如何使用本指南

本指南包含兩篇文章：本簡介文章和另一篇討論 考慮事項的文章，這些考慮在所有工作負載類型中都是共通的。

注意

如果您尚未認可容器化，請參閱 選擇 Azure 計算服務，以取得可用來裝載工作負載之其他計算選項的相關信息。

本簡介文章說明本指南範圍內的 Azure 容器服務，以及服務模型在可設定性與意見化解決方案之間如何比較，例如客戶管理與Microsoft管理方法之間的取捨。 在您根據服務模型喜好設定識別候選服務之後，下一個步驟是查看關於網路、安全性、作業和可靠性的 共同考量一文，並以滿足您的工作負載需求來評估這些選項。

本指南會根據工作負載的技術需求、大小和複雜度，以及工作負載小組的專業知識，考慮您可能需要做出的取捨。

本指南範圍內的 Azure 容器服務

本指南著重於 Azure 目前提供的容器服務子集。 此子集提供 Web 應用程式和 API、網路功能、可觀察性、開發人員工具和作業的成熟功能集。 這些容器服務被比較：

Azure Container Apps 標誌

Azure Container Apps 是完全受控的平臺，可讓您執行容器化應用程式，而不必擔心協調流程或基礎結構。 如需詳細資訊，請參閱 Azure Container Apps 檔。

AKS 標誌

Azure Kubernetes Service （AKS） 是受控 Kubernetes 服務，可用於執行容器化應用程式。 透過 AKS，您可以利用受控 附加元件和擴充功能， 額外的功能，同時保留最廣泛的設定層級。 如需詳細資訊，請參閱 AKS 檔案。

App Service 標誌

適用於容器的 Web 應用程式 是 Azure App Service 的一項功能，這是一項完全受控的服務，用於裝載內建基礎結構維護、安全性修補、調整和診斷工具的 HTTP 型 Web 應用程式。 如需詳細資訊，請參閱 App Service 文件。

如需所有 Azure 容器服務的完整清單，請參閱 容器服務產品類別頁面。

服務模型考慮

服務模型提供最廣泛的深入解析，瞭解任何 Azure 容器服務所提供的彈性和控制層級，以換取其整體簡單性和易於使用性。

如需服務模型相關術語和概念的一般簡介，包括基礎結構即服務（IaaS）和平臺即服務（PaaS），請參閱雲端 中的共同責任。

比較 Azure 容器解決方案的服務模型

AKS

作為 IaaS 和 PaaS 的混合方案，AKS 重視控制而非簡單性，利用容器協調流程事實上的標準：Kubernetes。 雖然 AKS 可簡化基礎核心基礎結構的管理，但此以 VM 為基礎的平臺仍會向您的應用程式公開，而且需要適當的護欄和程式，例如修補，以確保安全性和商務持續性。 計算基礎結構是由直接裝載於訂用帳戶中的其他 Azure 資源所支援，例如 Azure 負載平衡器。

AKS 也提供 Kubernetes API 伺服器的存取權，這可讓您自定義容器協調流程，進而從雲端原生運算基礎 （NCF） 部署專案。 因此，對於對 Kubernetes 不熟悉的團隊而言，會面臨明顯的學習挑戰。 如果您不熟悉容器化解決方案，則必須考慮此學習曲線。 下列 PaaS 解決方案提供較低的進入屏障。 當您的需求指定移動時，您可以移至 Kubernetes。

AKS 自動

AKS 自動化 藉由自動化處理複雜的叢集管理工作來簡化 Kubernetes 的實施，降低對深入 Kubernetes 專業知識的需求。 它提供更精簡且類似 PaaS 的體驗，同時保留 Kubernetes 的彈性和擴充性。 Azure 預設會處理叢集設定、節點布建、調整、安全性修補，並套用一些最佳做法設定。 這可減少作業工作，但隨附一組受限的可用拓撲選項。

注意

本指南將在適用的場合下區分 AKS 標準版和 AKS 自動版。 否則，可以假設所述功能在 Standard 和 Automatic 版本之間具有相同的等值性。

Azure 容器應用 (Azure Container Apps)

Azure Container Apps 是 Kubernetes 之上的抽象層，可讓您的應用程式執行和調整，而不需要直接管理基礎結構。 Container Apps 同時提供無伺服器和專用的計算選項，讓您完全掌控應用程式可用的計算資源類型和數量。 Container Apps 雖然隱藏了容器協調流程 API 的複雜性，但仍可讓您直接存取第 7 層入口、流量分割、A/B 測試和應用程式生命週期管理等重要功能。

適用於容器的 Web 應用程式

適用於容器的 Web 應用程式也是 PaaS 供應專案，但它提供比 Container Apps 更簡單且較少的控制。 它會將容器協調流程抽象化，但仍提供適當的調整、應用程式生命週期管理、流量分割、網路整合和可檢視性。

託管模型考量

您可以使用 Azure 資源，例如 AKS 叢集來裝載多個工作負載。 這麼做可協助您簡化作業，進而降低整體成本。 如果您選擇此路徑，以下是一些重要的考慮：

  • AKS 通常用於裝載多個工作負載或不同的工作負載元件。 您可以使用 Kubernetes 原生功能來隔離這些工作負載和元件，例如命名空間、訪問控制和網路控制，以符合安全性需求。

    如果您需要 Kubernetes API 所提供的額外功能，而且您的工作負載小組有足夠的經驗操作 Kubernetes 叢集，您也可以在單一工作負載案例中使用 AKS。 具有較少 Kubernetes 經驗的團隊仍可藉由利用 Azure 受控 附加元件 和功能，例如 叢集自動升級，來成功運營自己的叢集，以減少運營工作。

  • Container Apps 應該用來裝載具有共用安全性界限的單一工作負載。 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 App 都是由 Microsoft 管理並擁有類似功能層級的 PaaS 服務，但適用於容器的 Web App 強調簡單，以迎合其目標用戶：習慣了介面的現有 Azure PaaS 客戶。

經驗法則

一般而言，提供更簡單性的服務往往適合偏好專注於功能開發而不是基礎結構管理的客戶。 提供更多控制權的服務往往適合需要更多可設定性且具備管理自己基礎結構所需的技能、資源和業務理由的客戶。

所有工作負載的共同考量

雖然工作負載小組可能偏好特定服務模型，但該模型可能不符合整個組織的需求。 例如，開發人員可能偏好較少的作業工作，但安全性小組可能會考慮符合合規性需求所需的這類額外負荷。 小組必須共同作業，才能進行適當的取捨。

需知，共用的考量因素很廣泛。 視工作負載類型，以及組織內的角色而定，可能只有子集與您相關。

下表提供考慮的高階概觀，包括服務功能比較。 檢閱每個類別中的考慮，並將其與您的工作負載需求進行比較。

類別 概述
網路規劃考量 Azure 容器服務中的網路功能會根據您對簡單和可配置性的偏好而有所不同。 AKS 可高度設定，可提供對網路流程的廣泛控制，但需要更多操作工作。 Container Apps 提供 Azure 管理的網路功能。 這是 AKS 與適用於容器的 Web 應用程式之間的中間點，專為熟悉 App Service 的客戶量身打造。

關鍵是，網路設計決策可能會有長期的後果，因為在不重新部署工作負載的情況下變更它們是具有挑戰性的。 數個因素，例如IP位址規劃、負載平衡責任、服務探索方法和專用網功能，在這些服務之間有所不同。 您應該仔細檢閱服務如何符合特定網路需求。
安全性考慮 容器應用程式、AKS 和適用於容器的 Web 應用程式都提供與 Azure Key Vault 和受控識別等主要 Azure 安全性供應專案的整合。 AKS 提供其他功能，例如運行時間威脅防護和網路原則。 雖然容器應用程式之類的 PaaS 服務似乎提供較少的安全性功能，但部分原因是 Azure 管理了更多基礎結構元件，而不會向客戶公開，這可降低風險。
作業考慮 AKS 提供最多的自定義功能，但需要更大的作業輸入。 相反地，Container Apps 和 Web App for Containers 等 PaaS 解決方案可讓 Azure 處理 OS 更新等工作。 延展性和硬體 SKU 彈性至關重要。 AKS 提供彈性的硬體選項，而 Container Apps 和 Web App for Containers 則提供較少的選項。 AKS 中的應用程式延展性是客戶的責任，這表示您可以套用任何與 Kubernetes 相容的解決方案。 AKS 自動、容器應用程式和適用於容器的 Web 應用程式著重於更簡單的方法。
可靠性考慮 相較於 AKS，適用於容器和容器應用程式的 Web 應用程式健康情況探查組態有限，但設定更簡單，因為其使用熟悉的 Azure Resource Manager API。 AKS 需要使用 Kubernetes API。 它也要求您承擔管理 Kubernetes 節點集區延展性和可用性的額外責任，才能正確排程應用程式實例。 這些需求會導致 AKS 的額外作業工作。

此外，容器應用程式和適用於容器的 Web 應用程式的 SLA 比 AKS 更容易計算，其中控制平面和節點集區各自有自己的 SLA，因此需要據以複合。 所有服務在提供多區備援的數據中心中，都具備該功能。

在檢閱上述考量之後，您仍然可能找不到完美的契合。 這完全正常。

評估取捨

選擇雲端服務不是簡單的練習。 鑒於雲端運算的複雜性，許多小組之間的共同作業，以及涉及人員、預算和時間的資源限制，每個解決方案都有取捨。

請注意，對於任何指定的工作負載，某些需求可能比其他需求更為重要。 例如，應用程式小組可能偏好 PaaS 解決方案，如 Container Apps，但卻選擇 AKS，因為其安全小組需要在共置的工作負載元件之間使用預設拒絕的網路控制，這是 AKS 使用 Kubernetes 網路原則的獨有功能。

最後，請注意，上述共用考慮包含最常見的需求，但並不全面。 工作負載小組有責任先根據慣用服務的功能集調查每個需求，再確認決策。

結論

本指南說明您在選擇 Azure 容器服務時所面臨的最常見考慮。 其設計目的是要引導工作負載小組做出明智的決策。 此程式從選擇雲端服務模型開始，其牽涉到判斷所需的控制層級。 控制會犧牲簡單性。 換句話說，這是在自行管理的基礎結構與 Microsoft 所管理的基礎結構之間找到正確平衡的過程。

許多工作負載小組只能根據慣用的服務模型來選擇 Azure 容器服務：PaaS 與 IaaS。 其他小組必須進一步調查，以判斷服務特定功能如何處理工作負載或組織需求。

所有工作負載小組應在使用本指南時，納入審慎評估，以避免做出難以逆轉的決策。 不過，請注意，在開發人員嘗試服務，並根據經驗而不是理論來決定之前，不會確認決策。

貢獻者

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主要作者：

其他參與者：

下一步

深入瞭解本文中所述服務的共享架構考慮。

共用架構考慮