共用方式為

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

  • 發行項

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

注意

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

概述

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

架構和網路考慮

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

安全性考慮

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

作業考慮

  • 更新和修補程式
  • 容器映像更新
  • 垂直基礎結構延展性
  • 水平基礎結構延展性
  • 應用程式延展性
  • 可觀察性
  • Well-Architected 卓越營運架構

可靠性考慮

  • 服務等級協定
  • 使用可用區來達成備援
  • 健康情況檢查和自我修復
  • 零停機時間應用程式部署
  • 資源限制
  • Well-Architected 可靠性框架

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

注意

某些區段會區分 AKS 標準與 AKS 自動。 如果區段無法區分這兩者，則會假設特徵同位。

架構考慮

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

這些考慮並非 Well-Architected Framework 支柱所特有。 不過，當您選擇 Azure 容器服務時，他們應該對企業需求進行額外的審查和評估。

注意

AKS 自動是一種比 AKS 標準更具指導性的解決方案。 無法停用某些現成可用的功能。 本指南不會指出這些功能。 如需這些條件約束的最新資訊，以及標準與自動功能比較，請參閱：AKS 自動和標準功能比較。

操作系統支援

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

容器應用程式 AKS AKS 自動 適用於容器的 Web 應用程式
Linux 支援 ✅ ✅ ✅ ✅
Windows 支援 ❌ ✅ ❌ ✅
混合作業系統支援 ❌ ✅ ❌ ❌*

*適用於容器的 Web 應用程式的混合 OS 支援需要適用於 Windows 和 Linux 的個別 Azure App Service 方案。

網路相關考量

在規劃初期瞭解網路設計是很重要的，因為安全性和合規性限制以及所施加的指導方針。 一般而言，本指南所涵蓋 Azure 服務之間的主要差異取決於喜好設定：

  • Container Apps 是 PaaS 供應專案，可提供許多 Azure 受控網路功能，例如服務探索、內部受控網域和虛擬網路控制。
  • AKS 是三個服務中最可設定的，並提供對網路流程的最大控制。 例如，它提供自定義輸入控制器，以及透過 Kubernetes 網路原則控制叢集內部流量。 工作負載小組可以利用各種 Azure 受控 網路附加元件，以及從更廣泛的 Kubernetes 生態系統安裝及操作任何附加元件。
  • 適用於容器的 Web 應用程式 是 App Service的功能。 因此，網路概念，特別是專用網整合，非常專屬於App Service。 對已經使用 App Service 的負責工作負載的團隊來說，此服務會很熟悉。 我們鼓勵那些沒有 App Service 經驗且希望更熟悉 Azure 虛擬網路整合的團隊考慮使用容器應用程式。

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

網路位址空間

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

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

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

瞭解流量

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

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

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

子網規劃

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

容器應用程式 AKS 適用於容器的 Web 應用程式
子網內共置工作負載的支援* ❌* ✅ 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 應用程式
進入IP數目 一 多 App Service 環境：一個
沒有 App Service 環境：很多

容器應用允許每個環境（公用或私人）一個IP。 AKS 允許任意數目的IP、公用或私人。 在 App Service 環境外的 Web App for Containers 允許 App Service 計劃內所有應用程式共用一個公用 IP，並可使用 Azure 私人端點的多個不同私人 IP。

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

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

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

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

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

私有網路整合

針對需要嚴格第 4 層專用網路進入和退出的工作負載，您應該考慮容器應用程式、AKS 和單一租戶的 App Service 環境 SKU，其中工作負載會部署到自我管理的虛擬網路，並提供傳統細微的專用網路控制。

容器應用程式 AKS 適用於容器的 Web 應用程式
專用進入虛擬網路 ✅ ✅ 透過 私人端點
從虛擬網路的私人出口 ✅ ✅ 透過 虛擬網路 整合
完全封鎖的公共端點 ✅ ✅ 僅 App Service 環境（應用服務環境）
使用適用於容器的 Web 應用程式進行私有網路連接

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

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

通訊協定涵蓋範圍

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

容器應用程式 (Container Apps) 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 應用程式
第 4 層負載平衡器 Azure 管理 共同責任 Azure 管理
第 7 層負載平衡器 Azure 管理 共用或自我管理 Azure 管理

服務探索

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

容器應用程式 AKS 適用於容器的 Web 應用程式
服務探索 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 應用程式
設定自定義網域 開箱即用 BYO 開箱即用
管理的 TLS 用於 Azure FQDN 開箱即用 N/A 開箱即用
自定義網域的管理型 TLS 預覽版 BYO 開箱即用或自帶

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

雙向 TLS

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

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

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

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

特定服務的網路概念

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

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

安全性考慮

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

安全性比較概觀

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

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

AKS 自動叢集隨附強化的預設組態，預設會啟用許多叢集、應用程式和網路安全性設定。 這些初始設定不僅可減少部署時間，還能為使用者提供預先驗證的標準化設定，從而為使用者提供第 2 天作業責任的堅實基礎。 此基礎有助於縮短技術新手小組長期叢集管理的學習曲線。

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

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 應用程式
網路原則 使用方案：❌
專用方案：❌		 ✅ ❌

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

網路安全組

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

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

內建入口IP限制

容器應用程式和適用於容器的 Web 應用程式為個別應用程式的輸入流量提供內建來源 IP 限制。 AKS 可以達到相同的功能，但需要 Kubernetes 原生功能，透過 Kubernetes Service api-resource，可以在其中設定 loadBalancerSourceRanges的值。

容器應用程式 AKS 適用於容器的 Web 應用程式
內建輸入IP限制 ✅ ❌* ✅
資源耗用量 - 取用叢集資源 -

注意

AKS 提供入口 IP 限制，但它是 Kubernetes 原生功能，而不像其他服務那樣是 Azure 原生功能。

應用層級安全性

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

Key Vault 集成

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

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

容器應用程式 AKS 適用於容器的 Web 應用程式
Key Vault 整合 ✅ ✅ ✅

如需詳細資訊，請參閱：

受控識別支援

應用程式可以使用受控識別來向Microsoft受 Entra ID 保護的服務進行驗證，而不需要使用密鑰或秘密。 容器應用程式和適用於容器的 Web 應用程式提供內建的 Azure 原生支援應用層級受控識別。 AKS 的應用程式層級受控識別支援是透過 Entra Workload ID來完成。 AKS 也需要基礎結構相關的受控識別，以允許 Kubelet 的叢集作業、控制平面和各種 AKS 附加元件。

容器應用程式 AKS 適用於容器的 Web 應用程式
基礎設施受控身分識別支援 N/A ✅ N/A
容器提取受控識別支援 ✅ ✅ ✅
應用程式受控識別支援 ✅ ✅ ✅

如需詳細資訊，請參閱：

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

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

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

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

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

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

安全性基準

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

注意

AKS 叢集會自動設定 特定安全性設定。 請確定這些符合您的工作負載需求。

Well-Architected 安全框架

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

如需更完整的 AKS 安全性指引，請參閱 Well-Architected 框架審查 - AKS。

作業考慮

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

更新和修補程式

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

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

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

容器應用程式 AKS AKS 自動 適用於容器的 Web 應用程式
控制平面更新 平臺 客戶 平臺 平臺
主機更新和修補程式 平臺 客戶 平臺 平臺
容器映像檔更新和補丁 客戶 客戶 客戶 客戶

容器映像更新

不論 Azure 容器解決方案是什麼，客戶始終要負責他們自己的容器映像檔。 如果容器基底映像檔有安全性修補程式，您有責任重建您的映像檔。 若要取得這些弱點的相關警示，請使用 適用於負載於 Container Registry 的容器的 Defender。

延展性

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

垂直基礎結構延展性

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

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

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

水平基礎結構延展性

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

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

容器應用程式 AKS 適用於容器的 Web 應用程式
基礎結構擴展和縮減 取用方案：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 應用程式
容器向外延展 HTTP、TCP 或以計量為基礎的 （CPU、記憶體、事件驅動）。 計量型 （CPU、記憶體或自訂）。 手動、以計量為基礎的或 自動（預覽）。
事件驅動延展性 是的。 雲端原生。 是的。 雲端原生。 需要其他設定。 是的。 Azure 資源特定。

AKS 預設自動啟用水平 Pod 自動調整器、Kubernetes 事件驅動自動調整（KEDA）和垂直 Pod 自動調整器。

可觀察性

工作負載檢測

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

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

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

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

記錄和計量

所有 Azure 容器服務都提供應用程式和平台記錄和計量功能。 應用程式記錄是您工作負載所產生的控制台記錄。 平台記錄會擷取在應用程式範圍之外平臺層級發生的事件，例如調整和部署。 計量是數值，可描述系統某個時間點的某些層面，可讓您監視和警示系統效能和健康情況。

Azure 監視器是 Azure 中與這些服務整合的主要記錄和計量服務。 Azure 監視器會使用 資源記錄 將不同來源的記錄分成類別，並收集計量，以提供資源效能的深入解析。 判斷每個 Azure 服務可使用哪些記錄和計量的其中一種方式，就是查看每個服務的資源記錄類別和可用計量。

容器應用程式 AKS AKS 自動 適用於容器的 Web 應用程式
對記錄串流的支援 ✅ ✅ ✅ ✅
Azure 監視器 支援 ✅ ✅ ✅ ✅
Azure 監視器資源記錄 主控台 和 系統 Kubernetes API 伺服器、稽核、調度器、叢集自動調節器等 與 AKS 相同 ConsoleLogs、HTTPLogs、EnvironmentPlatformLogs 等等
計量集合和監視 透過 Azure 監視器的計量;透過 Dapr 計量 自定義計量 透過 Azure 監視器的計量;透過 Prometheus 自訂計量 （需要手動設定） 預先配置的 Managed Prometheus 負責收集度量資料，Managed Grafana 負責資料的視覺化，所有度量資料均通過 Azure 監視器處理。 透過 Azure 監視器的計量
預先設定的 Prometheus 和 Grafana ❌ 需要手動設定 ✅ Managed Prometheus 和 Managed Grafana 預設為已預先配置。 ❌

Container Apps 將其所有內部 Kubernetes 記錄抽象化成兩個類別：主控台記錄，其中包含工作負載容器記錄，以及包含所有平臺相關記錄的系統記錄。 針對計量，Container Apps 會與 Azure 監視器整合，以收集標準計量，並透過 Dapr 整合支援進階案例的自定義計量。

AKS 提供 Kubernetes 相關日誌，並能細緻控制記錄的內容。 AKS 會保留與 Kubernetes 用戶端工具的完整相容性，以進行記錄串流，例如 kubectl。 針對計量，AKS 會與 Azure 監視器整合以收集叢集和節點計量。 使用 Prometheus 進行自訂指標收集並與 Grafana 進行視覺化是可行的，但需要手動設定與配置。

AKS 自動配備了已預先設定的特定監視工具。 它會針對計量集合使用Managed Prometheus，並針對視覺效果使用Managed Grafana。 叢集和應用程式計量會自動收集，並可加以可視化。 AKS Automatic 也會與用於記錄和計量收集的 Azure 監視器整合。

適用於容器的 Web 應用程式 提供數種資源記錄類別，因為其平臺 （App Service） 並非專用於容器工作負載。 針對管理其內部 Docker 平臺的容器特定作業，它會提供 AppServicePlatformLogs 記錄類別。 另一個重要類別是 AppServiceEnvironmentPlatformLogs，其會記錄縮放和設定變更等事件。 計量是透過 Azure 監視器收集，可讓您監視應用程式效能和資源使用率。

Well-Architected 卓越營運架構

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

可靠性

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

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

服務等級協定

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

Azure 有許多特定服務的 SLA。 在自然、軟體及硬體環境中，不可能存在 100% 服務水平，因為失敗可能隨時發生，例如風暴和地震。 SLA 不是保證，而是以財務方式支援的服務可用性協定。

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

免費與付費方案

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

AKS 的其他因素

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

  • 控制平面。 Kubernetes API 伺服器有個別的 SLA。
  • 資料平面。 節點集區使用底層 VM SKU 的服務等級協議。
  • 可用性區域。 這兩個平面有不同的 SLA，這取決於 AKS 叢集是否已啟用可用性區域，以及 和 是否在可用性區域之間運行多個實例。

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

可用性區域的冗餘

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

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

特徵 容器應用程式 AKS 適用於容器的 Web 應用程式
可用性區域支援 滿 滿 滿

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

健康情況檢查和自我修復

健康情況檢查端點對於可靠的工作負載至關重要。 但建置這些端點只是解決方案的一半。 另一半是控制裝載平台的運作及其在故障時的應對方式。

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

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

另一個重要的考慮因素是應用程式中請求這些健康檢查的頻率（內部細節）。 如果您在這些請求之間有很長的間隔，您可能會繼續處理流量，直到實例被視為不健康為止。

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

容器應用程式 (Container Apps) AKS 適用於容器的 Web 應用程式
啟動探測 ✅ ✅ 部分支援
準備狀態探測 ✅ ✅ ❌
Liveness 探查 ✅ ✅ ✅
區間粒度 秒 秒 1 分鐘
通訊協定支援 HTTP（S）
TCP		 HTTP（S）
TCP
gRPC		 HTTP（S）

在容器網路應用程式中進行健康檢查是最簡單的實作方式，。 有一些重要的考慮：

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

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

自動修復

若要識別故障的容器實例，並停止將流量傳送至該實例，這是一個開始。 下一個步驟是實作自動修復。 自動修復 是透過重新啟動應用程式來嘗試從不健康狀態中復原的過程。 以下是三個容器服務比較的方式：

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

零停機時間應用程式部署

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

容器應用程式 AKS 適用於容器的 Web 應用程式
零停機策略 滾動更新 輪流更新，以及所有其他 Kubernetes 策略 部署位置

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

資源限制

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

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

Well-Architected 可靠性框架

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

結論

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

一般而言，當您比較 Azure 容器服務時，會出現一個主題：AKS 會呈現最底層的基礎結構，從而提供最大的控制和可設定性，而 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。

後續步驟