共用方式為

選擇 Azure 容器服務的一般架構考慮

  • 發行項

本文會引導您完成選擇 Azure 容器服務的程式。 它提供某些工作負載常見且重要功能層級考慮的概觀。 它可協助您做出決策，以確保您的工作負載符合可靠性、安全性、成本優化、營運卓越和效能效率的需求。

注意

本文是一系列的第二部分， 開頭為選擇 Azure 容器服務。 強烈建議您先閱讀該概觀文章，以取得這些架構考慮的內容。

概觀

本文中的考慮分為四個類別：

架構和網路考慮

  • 作業系統支援
  • 網路位址空間
  • 瞭解流量
  • 規劃子網路
  • 可用的輸入IP數目
  • 用戶定義的路由和 NAT 閘道支援
  • 專用網整合
  • 通訊協定涵蓋範圍
  • 負載平衡
  • 服務探索
  • 自定義網域和受控 TLS
  • 相互 TLS
  • 特定 Azure 服務的網路概念

安全性考量

  • 使用網路原則為叢集內流量提供安全性
  • 網路安全性群組
  • Azure Key Vault 整合
  • 受控識別支援
  • 使用適用於容器的 Defender 進行威脅防護和弱點評估
  • 安全性基準
  • Azure 架構完善的安全性架構

作業考慮

  • 更新和修補程式
  • 容器映像更新
  • 垂直基礎結構延展性
  • 水平基礎結構延展性
  • 應用程式延展性
  • 可檢視性
  • 架構完善的卓越營運架構

可靠性考慮

  • 服務等級協定
  • 透過可用性區域備援
  • 健康情況檢查和自我修復
  • 零停機時間應用程式部署
  • 資源限制
  • 可靠性架構完善的架構

請注意，本文著重於 Azure 容器服務的子集，其為 Web 應用程式和 API、網路、可觀察性、開發人員工具和作業提供成熟功能集：Azure Kubernetes Service （AKS）、Azure Container Apps 和適用於容器的 Web 應用程式。 如需所有 Azure 容器服務的完整清單，請參閱 容器服務產品類別頁面。

注意

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

架構考量

本節說明在不需要大量停機或重新部署的情況下，難以反轉或更正的架構決策。 對於網路和安全性等基本元件，特別需要記住此考慮。

這些考慮並不專屬於架構完善的架構要素。 不過，當您選擇 Azure 容器服務時，他們應該對企業需求進行額外的審查和評估。

作業系統支援

大部分的容器化應用程式都會在Linux容器中執行，所有Azure容器服務都支援這些容器。 對於需要 Windows 容器的工作負載元件，您的選項會更加有限。

容器應用程式 AKS 用於容器的 Web App
Linux 支援 ✅ ✅ ✅
Windows 支援 ❌ ✅ ✅
混合 OS 支援 ❌ ✅ ❌*

*適用於容器的 Web 應用程式的混合操作系統支援需要 Windows 和 Linux 的個別 Azure App 服務 方案。

網路考量

請務必瞭解規劃程式中的早期網路設計，因為安全性和合規性限制和強加的指導方針。 一般而言，本指南所涵蓋 Azure 服務之間的主要差異取決於喜好設定：

  • Container Apps 是 PaaS 供應專案，可提供許多 Azure 受控網路功能，例如服務探索和內部受控網域。 在考慮將網路選項最大化的替代方案之前，需要更多可設定性的工作負載小組可以使用工作負載/專用配置檔。
  • AKS 是三個服務中最可設定的，可透過網路流程提供最大的控制。 例如，它提供自定義輸入控制器，以及透過 Kubernetes 網路原則控制叢集內部流量。 工作負載小組可以利用各種 Azure 受控 網路附加元件，以及從更廣泛的 Kubernetes 生態系統安裝及操作任何附加元件。
  • 適用於容器的 Web 應用程式是 App Service 的功能。 因此，網路概念，特別是專用網整合，非常專屬於App Service。 此服務會熟悉已經使用App Service的工作負載小組。 鼓勵沒有 App Service 經驗且想要更熟悉 Azure 虛擬網路整合的 Teams 考慮容器應用程式。

請記住，網路是基本的基礎結構層。 通常很難在設計中進行變更，而不需要重新部署工作負載，這可能會導致停機時間。 因此，如果您的工作負載具有特定的網路需求，請先仔細檢閱本節，再縮小 Azure 容器服務選取範圍。

網路位址空間

當您將應用程式整合到虛擬網路時，您必須進行一些IP位址規劃，以確保容器實例有足夠的IP位址可用。 在此程式中，規劃更新的其他位址、藍/綠部署，以及部署額外實例的類似情況，這會取用額外的IP位址。

容器應用程式 AKS 用於容器的 Web App
專用子網 取用方案：選擇性
專用方案：必要		 必要 選擇性
IP 位址需求 取用方案：請參閱 僅限耗用量環境。
專用方案：請參閱 工作負載配置文件環境。		 請參閱 適用於 AKS 的 Azure 虛擬網路。 請參閱 App Service 子網需求。

請注意，AKS 需求取決於所選的網路外掛程式。 AKS 的某些網路外掛程式需要更廣泛的IP保留。 詳細數據不在本文的範圍內。 如需詳細資訊，請參閱 AKS 的網路概念。

瞭解流量

解決方案所需的流量類型可能會影響網路設計。

下列各節提供各種網路條件約束的相關信息。 這些條件約束會影響部署其他子網的需求，視您是否需要而定：

  • 多個共置工作負載。
  • 私人和/或公用輸入。
  • 叢集中（適用於容器應用程式和 AKS）或虛擬網路內（針對所有 Azure 容器服務）中東西部流量的訪問控制流程。

子網規劃

確保您擁有足以包含工作負載應用程式實例的子網，並不是決定部署這些應用程式之網路使用量的唯一因素。

容器應用程式 AKS 用於容器的 Web App
支援子網內共置的工作負載* ❌* ✅ N/A*

*這說明最佳做法，而不是技術限制。

針對 Container Apps，子網整合僅適用於單一 Container Apps 環境。 每個 Container Apps 環境都受限於單一輸入 IP、公用或私用。

每個 Container Apps 環境僅適用於相依應用程式共置的單一工作負載。 因此，如果您需要公用和私人輸入，您需要引進額外的 Azure 網路設備來進行輸入負載平衡。 範例包括 Azure 應用程式閘道和 Azure Front Door。 此外，如果您有多個需要隔離的工作負載，則需要額外的 Container Apps 環境，因此必須為每個環境配置額外的子網。

AKS 會以 Kubernetes 網路原則的形式，在叢集中提供細微的東西網路流量控制。 此流程控制可讓您將多個工作負載區隔在同一個叢集中具有不同網路安全性界限的工作負載。

針對適用於容器的 Web 應用程式，只要子網夠大，您就能將多少應用程式與單一子網整合，沒有任何限制。 相同虛擬網路中的 Web 應用程式之間沒有存取控制的最佳做法。 每個 Web 應用程式會分別管理來自虛擬網路或因特網的東西部或南北流量的訪問控制。

注意

您無法調整在其中部署資源的子網大小。 當您規劃網路以避免需要重新部署整個工作負載元件時，請特別小心，這可能會導致停機時間。

可用的輸入IP數目

下表將先前的子網規劃一節納入考慮，以定義可以針對裝載在 Azure 容器服務單一部署中任意數目的應用程式公開多少個 IP。

容器應用程式 AKS 用於容器的 Web App
輸入IP數目 一 多 App Service 環境：一個
無 App Service 環境：許多

容器應用程式允許每個環境、公用或私人的一個IP。 AKS 允許任意數目的IP、公用或私人。 適用於容器的 Web 應用程式，在 App Service 環境 之外，允許 App Service 方案內所有應用程式的一個公用 IP，以及使用 Azure 私人端點的多個不同私人 IP。

請務必注意，整合至 App Service 環境的 Web 應用程式只會透過與 App Service 環境 相關聯的單一輸入 IP 接收流量，無論是公用還是私人。

用戶定義的路由和 NAT 閘道支援

如果工作負載需要使用者定義的路由（UDR）和 NAT 閘道功能，才能進行細微的網路控制，Container Apps 需要使用 工作負載配置檔。 ACA 的僅限耗用量方案中無法使用 UDR 和 NAT 閘道相容性。

AKS 和 Web App for Containers 會透過標準虛擬網路功能或虛擬網路整合，分別實作這兩個網路功能。 為了詳細說明，App Service 環境 中的 AKS 節點集區和適用於容器的 Web 應用程式已經是直接虛擬網路資源。 不在 App Service 環境的容器 Web 應用程式透過虛擬網路整合支援 UDR 和 NAT 閘道。 透過虛擬網路整合，資源在技術上不會直接位於虛擬網路中，但其所有輸出存取都會流經虛擬網路，而網路的相關規則會如預期般影響流量。

容器應用程式 AKS 用於容器的 Web App
UDR 支援 僅限耗用量方案： ❌
工作負載設定檔計劃： ✅		 ✅ ✅
NAT 閘道支援 僅限耗用量方案： ❌
工作負載設定檔計劃： ✅		 ✅ ✅

專用網整合

對於需要嚴格第 4 層專用網輸入和輸出的工作負載，您應該考慮 Container Apps、AKS 和單一租使用者 App Service 環境 SKU，其中工作負載會部署至自我管理的虛擬網路，並提供自定義的細微專用網控制。

容器應用程式 AKS 用於容器的 Web App
私人輸入虛擬網路 ✅ ✅ 透過 私人端點
虛擬網路的私人輸出 ✅ ✅ 透過 虛擬網路 整合
完全隱藏的公用端點 ✅ ✅ 僅限 App Service 環境
使用適用於容器的 Web 應用程式進行專用網

Web App for Containers 提供其他網路功能，但本文所述的其他 Azure 服務不會以相同方式呈現。 若要實作嚴格的專用網需求，工作負載小組必須熟悉這些網路概念。 請仔細檢閱這些網路功能：

如果您想要 PaaS 解決方案，並偏好跨多個 Azure 解決方案共用的網路概念，您應該考慮 Container Apps。

通訊協定涵蓋範圍

裝載平臺的重要考慮是支援連入應用程式要求（輸入）的網路通訊協定。 適用於容器的 Web 應用程式是最嚴格的選項，僅支援 HTTP 和 HTTPS。 容器應用程式也允許連入 TCP 連線。 AKS 是最有彈性的，支援在自我選取的埠上使用不受限制的 TCP 和 UDP。

容器應用程式 AKS 適用於容器的 Web 應用程式
通訊協定和埠支援 HTTP （埠 80）*
HTTPS （埠 443）*
TCP （連接埠 1-65535,80 和 443 除外）		 TCP （任何連接埠）
UDP （任何連接埠）		 HTTP （連接埠 80）
HTTPS （連接埠 443）
WebSocket 支援 ✅ ✅ ✅
HTTP/2 支援 ✅ ✅ ✅

*在 Container Apps 環境中， HTTP/S 可以在任何埠 上公開以進行叢集內部通訊。 在該案例中，不會套用內建的 Container Apps HTTP 功能，例如 CORS 和會話親和性。

容器應用程式和適用於容器的 Web 應用程式都支援 TLS 1.2，使其內建 HTTPS 輸入。

負載平衡

使用容器應用程式和適用於容器的 Web 應用程式，Azure 會完全抽象化第 4 層和第 7 層負載平衡器。

相反地，AKS 會使用共用責任模型，其中 Azure 會管理工作負載小組透過與 Kubernetes API 互動所設定的基礎 Azure 基礎結構。 針對 AKS 中的第 7 層負載平衡，您可以選擇 Azure 受控選項，例如 AKS 受控應用程式路由附加元件或容器的 應用程式閘道，或部署和自行管理您選擇的輸入控制器。

容器應用程式 AKS 用於容器的 Web App
第 4 層負載平衡器 Azure 受控 共同責任 Azure 受控
第 7 層負載平衡器 Azure 受控 共用或自我管理 Azure 受控

服務探索

在雲端架構中，您可以隨時移除並重新建立運行時間以重新平衡資源，因此實例 IP 位址會定期變更。 這些架構會使用完整功能變數名稱 （FQDN） 進行可靠且一致的通訊。

容器應用程式 AKS 用於容器的 Web App
服務探索 Azure 管理的 FQDN Kubernetes 可設定 Azure 管理的 FQDN

Web Apps for Containers 提供公用輸入 （南北通訊） FQDN 現用。 不需要額外的 DNS 設定。 不過，沒有內建機制可促進或限制其他應用程式（東西方通訊）之間的流量。

Container Apps 也提供公用輸入 FQDN。 不過，容器應用程式會進一步允許公開應用程式 FQDN，並 只限制環境中的流量。 這項功能可讓您更輕鬆地管理東西向通訊，並啟用 Dapr 等元件。

Kubernetes 部署一開始無法在叢集外部或外部探索。 您必須建立 Kubernetes 服務，如 Kubernetes API 所定義，然後以可尋址的方式向網路公開應用程式。

重要

只有 Container Apps 和 AKS 透過其各自環境中的內部 DNS 配置來提供服務探索。 這項功能可以簡化開發/測試和生產環境的 DNS 設定。 例如，您可以使用只有環境或叢集內唯一的任意服務名稱來建立這些環境，讓它們可以在開發/測試和生產環境中相同。 使用適用於容器的 Web 應用程式時，服務名稱在不同環境中必須是唯一的，以避免與 Azure DNS 衝突。

自定義網域和受控 TLS

Container Apps 和 Web App for Containers 都提供現用的解決方案，以用於自定義網域和憑證管理。

容器應用程式 AKS 用於容器的 Web App
設定自訂網域 現為現用 BYO 現為現用
適用於 Azure FQDN 的受控 TLS 現為現用 N/A 現為現用
自定義網域的受控 TLS 預覽中 BYO 現用或 BYO

AKS 使用者負責管理其自定義網域的 DNS、叢集設定和 TLS 憑證。 雖然 AKS 不提供受控 TLS，但客戶可以利用 Kubernetes 生態系統中的軟體，例如熱門 的憑證管理員 來管理 TLS 憑證。

相互 TLS

限制連入流量的另一個替代方案是相互 TLS （mTLS）。 相互 TLS 是安全性通訊協定，可確保通訊中的用戶端和伺服器都經過驗證。 為了完成驗證，雙方會在傳輸任何數據之前交換和驗證憑證。

適用於容器的 Web 應用程式具有內建的 mTLS 支援連入用戶端連線。 不過，應用程式必須藉由 存取 X-ARR-ClientCert App Service 平台轉送的 HTTP 標頭 來驗證憑證。

Container Apps 也有 mTLS 的內建支援。 它會將客戶端憑證轉送至 HTTP 標頭 X-Forwarded-Client-Cert 中的應用程式。您也可以輕鬆地在單一環境中啟用 自動 mTLS，以在應用程式 之間進行內部通訊。

AKS 中的相互 TLS 可以透過 Istio 型服務網格實作為受控附加元件來實作，其中包括用於連入用戶端連線和服務間叢集內部通訊的 mTLS 功能。 工作負載小組也可以選擇從 Kubernetes 生態系統安裝和管理另一個服務網格供應專案。 這些選項可讓 Kubernetes 中的 mTLS 實作最具彈性。

服務特定的網路概念

上述各節將說明要考慮的一些最常見考慮。 如需詳細資訊，以及深入了解個別 Azure 容器服務專屬的網路功能，請參閱下列文章：

上述各節著重於網路設計。 繼續進行下一節，以深入瞭解網路安全性和保護網路流量。

安全性考量

無法解決安全性風險可能會導致未經授權的存取、數據外泄或敏感性資訊外洩。 容器會為您的應用程式提供封裝的環境。 不過，裝載系統和基礎網路重疊需要額外的護欄。 您選擇的 Azure 容器服務必須支援您個別保護每個應用程式的特定需求，並提供適當的安全性措施，以防止未經授權的存取，並降低攻擊的風險。

安全性比較概觀

大部分的 Azure 服務，包括容器應用程式、AKS 和適用於容器的 Web 應用程式，都與主要安全性供應專案整合，包括 金鑰保存庫 和受控識別。

在本指南中的服務中，AKS 透過呈現基礎元件，提供大部分的可設定性和擴充性，這些元件通常可透過組態選項加以保護。 例如，客戶可以停用 Kubernetes API 伺服器的本機帳戶，或透過組態選項開啟基礎節點的自動更新。

如需詳細的比較，請仔細檢閱下列考慮，以確保可以符合您的工作負載安全性需求。

Kubernetes 控制平面安全性

AKS 提供本文所考慮之三個選項的最大彈性，提供 Kubernetes API 的完整存取權，以便自定義容器協調流程。 不過，此 Kubernetes API 的存取也代表重要的受攻擊面，而且您需要保護它。

重要

請注意，本節與使用 Azure Resource Manager API 做為其控制平面的 Web App for Containers 無關。

身分識別型安全性

客戶須負責保護 API 的身分識別型存取。 現成可用的 Kubernetes 會提供自己的驗證和授權管理系統，這也需要使用訪問控制來保護。

若要利用單一平面的 Azure 身分識別和存取管理，最佳做法 是停用 Kubernetes 特定的本機帳戶 ，並改為 實作 AKS 管理的 Microsoft Entra 整合 與 適用於 Kubernetes 的 Azure RBAC。 如果您實作此最佳做法，系統管理員不需要在多個平台上執行身分識別和存取管理。

容器應用程式 AKS
Kubernetes API 訪問控制 不允許存取 完整存取

使用 Container Apps 的客戶無法存取 Kubernetes API。 Microsoft提供此 API 的安全性。

以網路為基礎的安全性

如果您想要限制對 Kubernetes 控制平面的網路存取，您必須使用 AKS，其提供兩個選項。 第一個選項是使用 私人 AKS 叢集，其使用 API 伺服器專用網與 AKS 叢集專用網之間的 Azure Private Link。 第二個選項是 API Server VNet 整合（預覽），其中 API 伺服器會整合到委派的子網中。 若要深入瞭解，請參閱檔。

實作 Kubernetes API 的網路限制存取會產生後果。 最值得注意的是，管理只能從專用網內執行。 這通常表示您必須部署 Azure DevOps 或 GitHub Actions 的自我裝載代理程式。 若要瞭解其他限制，請參閱產品特定檔。

容器應用程式 AKS
Kubernetes API 網路安全性 無法在 PaaS 中設定 可設定：公用IP或私人IP

這些考慮不適用於容器應用程式。 因為它是 PaaS，Microsoft會抽象化基礎結構。

數據平面網路安全性

下列網路功能可用來控制工作負載內的存取權。

使用網路原則為叢集內部流量提供安全性

某些安全性狀態需要環境中的網路流量隔離，例如當您使用多租用戶環境來裝載多個或多層式應用程式時。 在這些案例中，您應該選擇 AKS 並實 作網路原則，這是雲端原生技術，可讓您在 Kubernetes 叢集內細微設定第 4 層網路。

容器應用程式 AKS 用於容器的 Web App
網路原則 取用方案： ❌
專用方案： ❌		 ✅ ❌

在本文所述的三個 Azure 服務中，AKS 是唯一支援叢集內進一步工作負載隔離的服務。 容器應用程式或適用於容器的 Web 應用程式不支援網路原則。

網路安全性群組

在所有案例中，您可以使用網路安全組來規範更廣泛的虛擬網路內的網路通訊，這可讓您使用第 4 層流量規則來規範虛擬網路層級的輸入和輸出。

容器應用程式 AKS 用於容器的 Web App
網路安全性群組 取用方案： ✅
專用方案： ✅		 ✅ ✅ VNet 整合應用程式：僅限輸出

輸入的IP限制

通常網路流量限制是透過上述第 4 層規則套用。 不過，在沒有虛擬網路整合之應用程式的 PaaS 案例中，限制應用層上的流量很有用。

容器應用程式和適用於容器的 Web 應用程式為個別應用程式的輸入流量提供內建的來源 IP 限制。

容器應用程式 AKS 用於容器的 Web App
應用層的輸入IP限制 現為現用 自我管理或透過受控附加元件 現為現用
資源耗用量 - 取用叢集資源 -

針對 AKS 工作負載，實作取決於所選的輸入控制器。 自我管理和 Azure 受控 應用程式路由附加元件 都會取用叢集資源。

應用程式層級安全性

您不僅需要保護網路和基礎結構層級的工作負載，而且需要在工作負載和應用層級保護工作負載。 Azure 容器解決方案會與 Azure 安全性供應專案整合，以協助標準化應用程式的安全性實作和控件。

金鑰保存庫整合

最佳做法是在金鑰管理解決方案中儲存及管理秘密、金鑰和憑證，例如 金鑰保存庫，為這些元件提供增強的安全性。 所有應用程式都應該與 金鑰保存庫整合，而不是在程式代碼或 Azure 計算服務中儲存和設定秘密。

金鑰保存庫整合可讓應用程式開發人員專注於其應用程式程序代碼。 本文中所述的所有三個 Azure 容器服務都可以自動同步處理來自 金鑰保存庫 服務的秘密，並將其提供給應用程式，通常是環境變數或掛接的檔案。

容器應用程式 AKS 用於容器的 Web App
金鑰保存庫整合 ✅ ✅ ✅

如需詳細資訊，請參閱

受控識別支援

具有受指派受控識別的應用程式可以存取 Azure 資源，而不需要密碼。 本指南中所述的所有容器服務都支援受控識別。

容器應用程式 AKS 用於容器的 Web App
受控識別支援 ✅ ✅ ✅

如需詳細資訊，請參閱

使用適用於容器的 Defender 進行威脅防護和弱點評估

針對弱點的威脅防護也很重要。 最佳做法是使用 適用於容器的Defender。 Azure 容器登錄支援弱點評估，因此任何 Azure 容器服務都可以使用它們，而不只是本文所述的評估。 不過，適用於容器的Defender運行時間保護僅適用於AKS。

當 AKS 公開原生 Kubernetes API 時，叢集安全性也可以透過 Kubernetes 生態系統中的 Kubernetes 特定安全性工具進行評估。

容器應用程式 AKS 用於容器的 Web App
運行時間威脅防護 ❌ ✅ ❌

如需更多資訊，請參閱適用於雲端的 Defender 中的容器支援矩陣。

請注意，容器映像弱點評估不是實時掃描。 Azure 容器登錄會定期掃描。

安全性基準

一般而言，大部分的 Azure 容器服務都會整合 Azure 安全性供應專案。 整體來說，請記住，安全性功能集只是實作雲端安全性的一小部分。 如需實作容器服務安全性的詳細資訊，請參閱下列服務特定的安全性基準：

安全性基準涵蓋其他 Azure 整合，包括硬體加密和記錄，但本文的範圍不足。

架構完善的安全性架構

本文著重於這裡所述容器服務功能的主要差異。

如需 AKS 的完整安全性指引，請參閱 架構完善的架構檢閱 - AKS。

操作考量

若要在生產環境中成功執行工作負載，小組必須實作卓越營運做法，包括集中式記錄、監視、延展性、定期更新和修補，以及映像管理。

更新和修補程式

請務必更新應用程式的基礎OS並定期修補。 不過，請記住，每次更新都有失敗的風險。 本節和下一節說明關於客戶與平台之間共同責任的三個容器服務的主要考慮。

作為受控 Kubernetes 服務，AKS 會提供節點 OS 和控制平面元件的更新映像。 但工作負載小組會負責將更新套用至其叢集。 您可以手動觸發更新，或利用 叢集自動升級通道 功能，以確保叢集是最新的。 請參閱 AKS 第 2 天作業指南，以瞭解 修補和升級 AKS 叢集。

容器應用程式和適用於容器的 Web 應用程式是 PaaS 解決方案。 Azure 負責管理更新和修補程式，讓客戶可以避免 AKS 升級管理的複雜性。

容器應用程式 AKS 用於容器的 Web App
控制平面更新 平台 客戶 平台
主機更新和修補程式 平台 客戶 平台
容器映像更新和修補程式 客戶 客戶 客戶

容器映像更新

無論 Azure 容器解決方案為何，客戶一律會負責自己的容器映像。 如果容器基底映射有安全性修補程式，您有責任重建映像。 若要取得這些弱點的相關警示，請使用 適用於容器 的Defender作為容器登錄中裝載的容器。

延展性

調整可用來調整資源容量以符合需求，新增更多容量以確保效能並移除未使用的容量以節省成本。 當您選擇容器解決方案時，必須考慮基礎結構條件約束和調整策略。

垂直基礎結構延展性

垂直調整 是指能夠增加或減少現有的基礎結構，也就是計算 CPU 和記憶體。 不同的工作負載需要不同的計算資源數量。 當您選擇 Azure 容器解決方案時，必須注意特定 Azure 服務可用的硬體 SKU 供應專案。 它們會有所不同，而且可能會施加額外的條件約束。

針對 AKS，請檢閱 Azure 檔中虛擬機的大小，以及 每個區域的 AKS 限制。

這些文章提供其他兩項服務的 SKU 供應專案詳細數據：

水平基礎結構延展性

水平調整 是指能夠透過新的基礎結構增加或減少容量，例如 VM 節點。 在調整增加或減少期間，Container Apps 取用層會抽象化基礎虛擬機。 針對其餘的 Azure 容器服務，您可以使用標準 Azure Resource Manager API 來管理水平調整策略。

請注意，相應放大和縮小包含實例的重新平衡，因此也會造成停機的風險。 風險小於垂直調整的對應風險。 不過，工作負載小組一律負責確保其應用程式可以處理失敗，以及實作其應用程式的正常啟動和關機，以避免停機。

容器應用程式 AKS 用於容器的 Web App
基礎結構相應放大和相應放大 取用方案：N/A
專用方案：可設定		 可設定 可設定
彈性硬體布建 取用方案：N/A
專用計劃：使用工作負載配置檔抽象化		 任何 VM SKU 抽象。 請參閱 App Service 方案。

重要

透過 Container Apps 專用方案（工作負載配置檔）和適用於容器的 Web 應用程式（App Service 方案）提供的硬體布建選項，不像 AKS 那麼有彈性。 您必須熟悉每個服務中可用的 SKU，以確保符合您的需求。

應用程式延展性

觸發基礎結構和應用程序調整的一般量值是資源耗用量：CPU 和記憶體。 某些容器解決方案可以使用應用程式特定內容來調整容器實例計數，例如 HTTP 要求。 例如，AKS 和 Container Apps 可以根據透過 KEDA 的訊息佇列和許多其他計量，透過其 縮放程式來調整容器實例。 當您選擇應用程式的延展性策略時，這些功能可提供彈性。 適用於容器的 Web 應用程式依賴 Azure 所提供的延展性選項。 （請參閱下表。適用於容器的 Web 應用程式不支援 KEDA 之類的自訂縮放程式設定。

容器應用程式 AKS 用於容器的 Web App
容器向外延展 HTTP、TCP 或以計量為基礎的 （CPU、記憶體、事件驅動） 。 以計量為基礎的 （CPU、記憶體或自訂） 。 手動、以計量為基礎的或 自動 （預覽） 。
事件驅動延展性 是。 雲端原生。 是。 雲端原生。 需要其他設定。 是。 Azure 資源特定。

可檢視性

工作負載檢測

收集複雜或多層式應用程式的計量可能會很困難。 若要取得計量，您可以透過兩種方式整合容器化工作負載與 Azure 監視器：

  • 自動檢測。 不需要變更程式碼。
  • 手動檢測。 整合及設定 SDK 和/或用戶端所需的最少程式碼變更。
容器應用程式 AKS 用於容器的 Web App
透過平台自動檢測 ❌ ❌ 部分支援*
透過代理程式自動檢測 ❌ 部分支援* N/A
手動檢測 透過 SDK 或 OpenTelemetry 透過 SDK 或 OpenTelemetry 透過 SDK 或 OpenTelemetry

*AKS 和 Web App for Containers 支援自動檢測 Linux 和 Windows 工作負載的特定設定，視應用程式語言而定。 如需詳細資訊，請參閱下列文章：

應用程式程式代碼內的檢測是應用程式開發人員的責任，因此與任何 Azure 容器解決方案無關。 您的工作負載可以使用下列解決方案：

記錄

所有 Azure 容器服務都提供應用程式和平台記錄功能。 應用程式記錄 是您工作負載所產生的控制台記錄。 平台記錄會 擷取在應用程式範圍之外平臺層級發生的事件，例如調整和部署。

容器服務的記錄功能與平台記錄有關的主要差異：記錄的內容，以及記錄在內部組織的方式。 Azure 監視器是 Azure 中與這些服務整合的主要記錄服務。 監視會使用 資源記錄 ，將來自不同來源的記錄分成類別。 判斷每個 Azure 服務可用的記錄的其中一種方式，就是查看每個服務可用的資源記錄類別。

容器應用程式 AKS 用於容器的 Web App
支援記錄串流 （即時串流） ✅ ✅ ✅
支援 Azure 監視器 ✅ ✅ ✅
Azure 監視器資源記錄 主控台 和 系統 Kubernetes API 伺服器、稽核、排程器、叢集自動調整程式等等 ConsoleLogs、HTTPLogs、EnvironmentPlatformLogs 等等

如需數據表中每個資源記錄的詳細描述，請選取數據表中的連結。

以下是容器服務的記錄功能簡短摘要：

  • Container Apps 會將其所有內部 Kubernetes 記錄抽象化成兩個類別。 其中一個稱為 主控台 記錄，包含工作負載容器記錄。 第二 個系統 類別包含所有平台相關記錄。
  • AKS 提供所有 Kubernetes 相關記錄，並細微地控制可記錄的專案。 它也會保留與 Kubernetes 用戶端工具的完整相容性，以便進行記錄串流，例如 kubectl。
  • 適用於容器 的 Web 應用程式提供許多資源記錄類別，因為其平臺 （App Service） 並非專用於容器工作負載。 針對管理其內部 Docker 平臺的容器特定作業，它會提供 AppServicePlatformLogs 記錄類別。 另一個重要類別是 AppServiceEnvironmentPlatformLogs，其會記錄縮放和設定變更等事件。

架構完善的卓越營運架構

本文著重於這裡所述容器服務功能的主要差異。 請參閱下列文章，以檢閱下列服務的完整營運卓越指引：

可靠性

可靠性 是指系統回應失敗並維持完整功能的能力。 在應用程式軟體層級，工作負載應該實作最佳做法，例如快取、重試、斷路器模式和健康情況檢查。 在基礎結構層級，Azure 負責處理數據中心的硬體故障和電源中斷等實體失敗。 失敗仍可能發生。 工作負載小組應選取適當的 Azure 服務層級，並套用必要的最小實例設定，以在可用性區域之間實作自動故障轉移。

若要選擇適當的服務層級，您必須瞭解服務等級協定 （SLA） 和可用性區域的運作方式。

服務等級協定

可靠性通常是由 業務導向的計量 來測量，例如 SLA 或復原時間目標（RTO） 等復原計量。

Azure 有許多特定服務的 SLA。 沒有 100% 服務等級之類的專案，因為失敗一律可能發生在軟體和硬體中，而且本質上是暴風雨和地震。 SLA 不是保證，而是以財務方式支援的服務可用性協定。

如需最新的 SLA 和詳細數據， 請從Microsoft授權網站下載 Microsoft Online Services 的最新 SLA 檔 。

免費與付費層

一般而言，免費層的 Azure 服務不會提供 SLA，因此對於非生產環境而言，這些服務具有成本效益的選擇。 不過，針對生產環境，最好選擇具有 SLA 的付費層。

AKS 的其他因素

AKS 針對不同的元件和元件有不同的 SLA：

  • 控制平面。 Kubernetes API 伺服器有個別的 SLA。
  • 數據平面。 節點集區會使用基礎 VM SKU SLA。
  • 可用性區域。 這兩個平面有不同的 SLA，視 AKS 叢集是否已啟用 可用性區域，以及 跨可用性區域執行多個實例而定。

請注意，當您使用多個 Azure 服務時， 複合 SLO 可能會與個別服務 SLA 不同，且低於個別服務 SLA。

可用性區域的備援

可用性區域 是位於單一區域內具有獨立電力、冷卻等不同數據中心。 產生的備援會增加失敗的承受度，而不需要您實作多個區域架構。

Azure 在 Azure 運作資料中心區域的每個國家/區域都有可用性區域。 若要允許多個容器實例跨可用性區域，請務必選取提供可用性區域支援的SKU、服務層級和區域。

功能 容器應用程式 AKS 用於容器的 Web App
可用性區域支援 完整 完整 完整

例如，如果硬體裝載的可用性區域中發生問題，設定為執行單一實例的應用程式或基礎結構就會變成無法使用。 若要完全使用可用性區域支援，您應該部署至少設定三個容器實例的工作負載，分散於區域。

健康情況檢查和自我修復

健康情況檢查端點對於可靠的工作負載至關重要。 但建置這些端點只是解決方案的一半。 另一半是控制裝載平台的運作方式，以及發生失敗的方式。

若要進一步區分健康情況探查的類型，請查看 Kubernetes 的內建探查類型：

  • 啟動。 檢查應用程式是否成功啟動。
  • 整備程度。 檢查應用程式是否準備好處理傳入要求。
  • 活潑。 檢查應用程式是否仍在執行中並回應。

另一個重要考慮是從應用程式要求這些健康情況檢查的頻率（內部數據粒度）。 如果您在這些要求之間有很長的間隔，您可能會繼續提供流量，直到實例被視為狀況不良為止。

大部分的應用程式都支援透過 HTTP（S） 通訊協定進行健康情況檢查。 不過，有些可能需要其他通訊協定，例如 TCP 或 gRPC 來執行這些檢查。 當您設計健康情況檢查系統時，請記住這點。

容器應用程式 AKS 適用於容器的 Web 應用程式
啟動探查 ✅ ✅ 部分支援
整備探查 ✅ ✅ ❌
活躍度探查 ✅ ✅ ✅
間隔粒度 秒 秒 1 分鐘
通訊協定支援 HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

健康情況檢查最 容易在適用於容器的 Web 應用程式中實作。 有一些重要的考慮：

  • 其啟動探查內建且無法變更。 它會將 HTTP 要求傳送至容器的起始埠。 應用程式的任何回應都會被視為成功的啟動。
  • 它不支援整備探查。 如果啟動探查成功，容器實例就會新增至狀況良好的實例集區。
  • 它會以一分鐘間隔傳送健康情況檢查。 您無法變更間隔。
  • 您可以將狀況不良實例從內部負載平衡機制中移除的最低閾值是兩分鐘。 狀況不良的實例在健康情況檢查失敗后至少會取得兩分鐘的流量。 此設定的預設值為10分鐘。

另一方面，容器應用程式和 AKS 更有彈性，並提供類似的選項。 就特定差異而言，AKS 提供下列選項來執行容器應用程式中無法使用的健康情況檢查：

自動修復

若要識別不正確的容器實例，並停止將流量傳送至該實例，這是一個啟動。 下一個步驟是實作自動修復。 自動修復 是嘗試從狀況不良狀態復原的應用程式重新啟動的程式。 以下是三個容器服務比較的方式：

  • 在適用於容器的 Web 應用程式中，在健康情況檢查失敗后，沒有選項可以立即重新啟動容器實例。 如果實例持續失敗一小時，則會由新的 實例取代。 有另一項功能稱為 「自動修復」，可監視和重新啟動實例。 它與健康情況檢查不直接相關。 它會使用各種應用程式計量，例如記憶體限制、HTTP 要求持續時間和狀態代碼。
  • 如果即時性探查達到定義的失敗閾值，容器應用程式和 AKS 會自動嘗試重新啟動容器實例。

零停機時間應用程式部署

部署和取代應用程式的能力，而不會造成使用者停機對於可靠的工作負載至關重要。 本文所述的三個容器服務都支援零停機部署，但以不同方式進行。

容器應用程式 AKS 用於容器的 Web App
零停機時間策略 滾動更新 滾動更新，加上所有其他 Kubernetes 策略 部署位置

請注意，應用程式架構也必須支援零停機部署。 如需指引，請參閱 Azure 架構完善的架構 。

資源限制

可靠共享環境的另一個重要元件是控制容器的資源使用量（例如 CPU 或記憶體）。 您必須避免單一應用程式佔用所有資源並讓其他應用程式處於不良狀態的案例。

容器應用程式 AKS 用於容器的 Web App
資源限制（CPU 或記憶體） 每個應用程式/容器 每個應用程式/容器
每個命名空間		 每個 App Service 方案
  • 適用於容器的 Web 應用程式：您可以在單一 App Service 方案中裝載多個應用程式（容器）。 例如，您可以配置具有兩個 CPU 核心和 4 GiB RAM 的方案，您可以在容器中執行多個 Web 應用程式。 不過，您無法將其中一個應用程式限製為特定數量的CPU或記憶體。 它們全都爭奪相同的 App Service 方案資源。 如果您想要隔離應用程式資源，您需要建立其他 App Service 方案。
  • 容器應用程式：您可以在環境中設定每個應用程式的CPU和記憶體限制。 不過，您受限於一組 允許的CPU和記憶體組合。 例如，您無法設定一個 vCPU 和 1 GiB 的記憶體，但您可以設定一個 vCPU 和 2 GiB 的記憶體。 Container Apps 環境類似於 Kubernetes 命名空間。
  • AKS：只要節點有硬體可支援它，您就可以選擇 vCPU 和記憶體的任何組合。 如果您想要以這種方式分割叢集， 您也可以限制命名空間層級 的資源。

可靠性架構完善的架構

本文著重於 Azure 中容器服務功能的主要差異。 如果您想要檢閱特定服務的完整可靠性指引，請參閱下列文章：

結論

架構完善的解決方案會為成功的工作負載設定基礎。 雖然架構可以隨著工作負載成長而調整，且小組在其雲端旅程中取得進展，但某些決策，特別是圍繞網路，在不需要重大停機時間或重新部署的情況下難以逆轉。

一般而言，當您比較 Azure 容器服務時，會出現一個主題：AKS 會呈現最底層的基礎結構，從而提供最大的可設定性和擴充性。 AKS 工作負載的作業額外負荷和複雜度高度變動。 某些小組可以使用Microsoft受控附加元件和擴充功能，以及自動升級功能，大幅降低作業額外負荷。 其他客戶可能偏好完全控制叢集，以利用 Kubernetes 和NCF 生態系統的完整擴充性。 例如，雖然Microsoft提供 Flux 做為受控 GitOps 擴充功能，但許多小組會選擇自行設定及操作 ArgoCD。

例如，不需要CNCF 應用程式的工作負載小組，擁有較少的作業體驗，或偏好專注於應用程式功能，可能會偏好 PaaS 供應專案。 建議您先考慮容器應用程式。

雖然 Container Apps 和 Web App for Containers 都是 PaaS 供應專案，可提供類似層級的Microsoft受控基礎結構，但主要差異在於 Container Apps 更接近 Kubernetes，並為服務探索、事件驅動自動調整、 Dapr 整合等提供額外的雲端原生功能。 不過，不需要這些功能且熟悉 App Service 網路和部署模型的小組可能會偏好使用適用於容器的 Web 應用程式。

一般化可協助您縮小要考慮的 Azure 容器服務清單。 但請記住，您也需要詳細檢查個別需求，並將其與服務特定的功能集進行比對，以驗證您選擇的選擇。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

下一步