共用方式為


Azure 容器應用程式的可靠性

Azure 容器應用 是一個完全託管、無伺服器的容器主機服務,用於部署微服務及容器化應用程式。

當您使用 Azure 時, 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作,並選取符合業務目標和正常運作時間目標所需的功能。

本文說明如何讓容器應用程式對各種潛在故障和問題具韌性,包括暫時性故障、可用性區域中斷、區域中斷以及服務維護。 同時說明如何利用備份從其他類型的問題中復原,並強調容器應用程式服務水準協議(SLA)的關鍵資訊。

生產部署建議

若想了解如何部署容器應用程式以支援解決方案的可靠性需求,以及可靠性如何影響架構的其他面向,請參閱 Azure Well-Architected 框架中的容器應用程式架構最佳實務

可靠性架構概觀

當你使用容器應用程式時,你部署了一個作為基礎部署單元的 環境 ,並定義了圍繞一群容器應用程式的安全邊界。 環境是您設定核心設定的地方,包括可用區域支援和網路組態。 這兩種環境類型分別是工作負載設定環境與僅供消耗的環境。 欲了解更多資訊,請參閱 容器應用程式中的運算與計費結構

你可以在同一環境中部署多個 應用程式 。 每個應用程式 都運行一個或多個容器。 環境也可以執行一個或多個工作,這些 工作代表非互動式任務。 欲了解更多資訊,請參閱「 容器應用程式中的容器 」及 「容器應用程式中的工作」。

每個應用程式都有一個或多個 副本,代表該應用程式的執行實例。 你可以控制應用程式的擴展方式,包括最小和最大副本數量,以及應用程式如何動態新增和移除副本。 平台排程器確保在實體主機間的最佳分配,同時滿足最低副本數量的要求。 如需詳細資訊,請參閱在容器應用程式中設定縮放規則

顯示具三個複本的應用程式在 Container Apps 環境中執行的圖表。

容器應用程式透過不同功能來支援應用程式的可靠性:

  • 自動健康監測: 內建的入口控制器會自動在健康副本間平衡流量。 若複本未通過健康檢查或其底層基礎設施長時間無法使用,服務會自動重啟失敗的容器或建立替代副本。 它還會將流量重新分配,避開不健康的副本,並管理叢集中的網路重試。 此自動復原程序不需要客戶介入,並會維護您指定的複本計數。 如需詳細資訊,請參閱健康狀態探查

  • 透過 DAPR 提升申請韌性: 容器應用程式與 Dapr 緊密整合,Dapr 是一個支援生產級微服務與容器化應用程式的框架。 DAPR 包含有助於提升韌性的功能,包括處理其他服務的故障。 欲了解更多資訊,請參閱 「容器應用程式中的微服務」。

  • 系統元件的基礎設施韌性: 這種彈性包括控制平面、入口控制器和容器執行時。 在有可用區域的區域,容器應用程式提供區域冗餘。 欲了解更多資訊,請參閱 對於可用性區域失效的韌性

對瞬態故障的彈性

暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中,而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤,通常透過重試受影響的請求來進行。

所有雲端裝載的應用程式在與任何雲端裝載的 API、資料庫和其他元件通訊時,都應該遵循 Azure 暫時性錯誤處理指引。 如需詳細資訊,請參閱 處理暫時性錯誤的建議

Container Apps 會透過其平台層級重試機制和健康情況監視,自動處理許多暫時性錯誤。 為確保您的應用程式對短暫故障具韌性,請採取以下步驟:

  • 配置健康探針 ,讓平台能偵測並回應特定應用的故障狀況。 根據應用程式啟動特性設定適當的失敗閾值和逾時值。 例如,為避免在臨時問題期間容器過早重啟,使用故障閾值為3,活度探針間隔為10秒。 如需詳細資訊,請參閱健康狀態探查

  • 使用服務發現復原力原則 (預覽版) 以主動預防、偵測服務要求失敗及從中恢復。 例如,當您使用復原原則時,如果存在導致應用程式無法回應的暫時性錯誤,則可以自動重試對應用程式的每個傳入要求。 如需詳細資訊,請參閱 服務探索復原能力 (預覽版)。

  • 在你的應用程式中實作重試邏輯,針對外部服務呼叫、資料庫連線和 API 請求。

    如果您的應用程式使用 Dapr 來整合雲端服務,請使用 Dapr 元件復原功能(預覽版) 來設定重新嘗試、超時和斷路器。

    對於其他相依性,您的應用程式必須處理暫時性錯誤。 呼叫外部服務時,請使用指數退避策略和斷路器模式,以防止在下游服務中斷期間發生連鎖故障。 容器應用程式內建的服務發現與負載平衡功能會自動將流量導離失敗的實例,但你的應用程式層級重試政策能確保在平台層級健康檢查觸發容器重新啟動前,能優雅地處理暫時性問題。

  • 設計工作能抵抗暫時性故障,包括作業執行過程中或其相依性中的故障。 將您的作業設計為在重新啟動時能夠繼續運作,或者透過設計使其具有冪等性,以便可以安全地重新執行。

對可用性區域故障的抵抗力

可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時,服務可以切換至其他剩餘的區域。

當你建立容器應用程式環境時,可以啟用 區域冗餘 ,將底層基礎設施分散到所選 Azure 區域的多個可用區域。 Container Apps 會自動在各區域之間排程您的應用程式複本。 這種分布是透明的,代表你不需要為每個副本指定區域的擺放。

區域備援可確保容器應用程式的複本分散在多個區域中,以增強應用程式對區域層級失敗的復原能力。

下圖展示了一個區域冗餘容器應用程式,包含三個副本。 每個副本皆於獨立的可用性區域中運行。

圖示顯示一個區域冗餘容器應用程式,包含三個副本。每個副本運行於獨立的可用區。

需求

  • 請查看區域支援。 區域備援適用於支援容器應用程式和可用性區域的所有區域。

    若要查看哪些區域支援可用性區域,請參閱 具有可用性區域支援的 Azure 區域

    欲了解哪些地區支援容器應用程式,請參閱 「按區域分類的產品可用性」。

  • 使用工作負載設定檔。 區域冗餘適用於所有容器應用程式方案,包括消耗型與專用型工作負載設定檔。

  • 在環境建立期間啟用區域備援。 這個設定在環境建立後無法更改。

  • 在虛擬網路中部署容器應用程式環境。 虛擬網路必須位於支援可用性區域的區域中。 請確定虛擬網路具有足夠大小的子網路。 僅供消費的環境需要具有/23 無類別域間路由(CIDR)範圍或更大範圍的子網,而工作負載配置的環境則需要具有/27 無類別域間路由(CIDR)範圍或更大範圍。

  • 將最小副本數量設為至少兩個,以確保分布在多個可用區域。 若符合以下任一條件,請考慮設定更高的最低複本數:

    • 您預期的尖峰負載需要兩個以上的複本。

    • 你必須能抵抗多個同時出現的區域停電。

    • 你要盡量減少在區域停電期間等待其他區域建立新副本的時間。

費用

啟用區域冗餘後,不會產生超出標準容器應用程式價格的額外費用。 無論是否啟用區域備援,您都會為計算資源、要求和虛擬核心秒數支付相同的費率。 欲了解更多資訊,請參閱 容器應用程式定價容器應用程式計費

設定可用性區域支援

  • 建立區域冗餘的容器應用程式環境。 關於涵蓋 Azure 入口網站、Azure CLI 和 Azure PowerShell 的部署說明,請參見 「建立區域冗餘容器應用程式」。

  • 移轉到區域冗餘部署。 您無法在現有的 Container Apps 環境中啟用區域備援。 若要升級非區域冗餘的現有環境,請在支援區域建立一個啟用區域冗餘的新環境。 然後重新部署你的容器應用程式。

  • 停用區域備援。 區域冗餘在環境建立時啟用後就無法再停用。 如果您需要非區域備援部署,則必須建立新環境,而不啟用區域備援選項,或部署至不支援可用性區域的區域。

  • 確認區域冗餘。 你可以使用 Azure 入口網站、Azure CLI 和 Azure PowerShell 來驗證環境的 區域冗餘狀態

容量規劃和管理

如果某個可用區域變得無法使用,容器應用程式平台會根據你的擴展規則決定何時替換該區域中遺失的副本。 正確配置你的比例規則很重要,這樣排程員才能做出適當的排程決策。

若要正確設定規模規則,遵循下列原則:

  • 設定應用程式可以容忍的抄本數目下限。 遺失的複本可能需要短時間才能被替換,因為平台必須偵測舊複本已不見。 接著,新複本必須啟動並傳回良好整備度探查,才能接收傳入的要求。 如果你無法容忍任何副本數量低於你指定的最低數量的期間,可以考慮 過度配置 ,以確保即使某區域無法使用,也能保持應用程式的效能。

  • 設定資源請求與限制 ,幫助容器應用程式排程器在各區域做出最佳擺放決策。 未指定的資源需求可能會導致高負載期間不均勻的分佈或放置失敗。

欲了解更多關於設定選項的資訊,請參閱 設定縮放規則

所有區域都狀況良好時的行為

本節說明當 Container Apps 資源設定為區域備援,且所有可用性區域都可運作時,預期會發生什麼事。

  • 區域間的流量路由: 透過區域冗餘容器應用程式,平台採用主動-主動模式,多個副本同時服務流量。 輸入控制器會將傳入的要求分發到所有良好的複本中,不論其所在區域,並預設使用循環負載平衡。 每個區域獨立處理請求,平台不會優先分配特定區域作為流量分配。 健康情況探查源自所有區域,以確保從多個角度對每個複本進行準確的健康情況評估。

  • 區域間的資料複製: 容器應用程式不會在區域間複製應用程式資料,因為它是為無狀態工作負載設計的。 你的應用程式儲存在短暫性儲存中的任何資料,包括容器範圍儲存和副本範圍儲存,在容器或副本關閉時都會被刪除。

    針對具狀態資料需求,請掛接針對區域備援儲存體設定的 Azure 檔案儲存體檔案共用,或使用其他 Azure 服務,例如 Azure Cosmos DB 或 Azure SQL Database,以提供本身的跨可用性區域複寫功能。

    平台只會複寫控制平面中繼資料,包括您的應用程式組態、擴展規則和跨區域的密碼,以實現高可用性。 建立複本時,容器映像會視需要從容器登錄提取到每個區域。

區域失敗期間的行為

本節說明當 Container Apps 資源設定為區域備援,且可用性區域中斷時,會發生什麼預期情況。

  • 偵測與回應: Azure 會自動偵測區域故障。 容器應用程式會立即停止將新的複本排程至失敗的區域,並開始將流量重新分配到其他區域中狀況良好的複本。 該平台會自動處理所有容錯移轉操作,而無需您的干預。

  • 通知: Microsoft 不會在區域關閉時自動通知您。 不過,您可以使用 Azure 服務健康情況 來了解服務的整體健康情況,包括任何區域失敗,而且您可以設定 服務健康情況警示 來通知您問題。

    您也可以透過 Azure 監視器中的容器應用程式計量來監視應用程式的健康情況。 在複本計數減少時設定警示,並要求故障率,以在區域相關問題發生時,立即收到通知。

  • 現行要求:對失敗區域內複本的發行小眾測試版要求可能會被丟掉,或出現逾時或連線錯誤。 任何在受影響區域執行的工作都會被中止並標記為失敗。

  • 預期資料遺失: 容器應用程式平台層級不會發生資料遺失,因為該服務是為無狀態工作負載設計的。 當複本終止時,儲存在可用區域內 暫時儲存體 中的任何資料都會遺失,而且暫時性儲存體只能用於暫存資料。

  • 預期的停機時間: 應用程式在區域失效期間幾乎不會有停機時間。 實際影響取決於應用程式的健康情況探查設定,以及狀況良好區域中的複本數目。 請確保客戶遵循 臨時故障處理指引 ,以減少任何影響。

    在受影響區域執行的作業會被中止並標記為失敗。 如果你需要工作對區域故障有彈性,請設定重試或設定平行性,讓工作能執行多個相同執行的副本。 如需詳細資訊,請參閱 進階任務組態

  • 流量重新路由:輸入控制器的健全狀態探查可快速偵測到無法連線的複本,並將其從負載平衡集區中移除。 根據你應用程式的健康探測設定,這個故障轉移通常在大約 30 秒內完成。 後續傳入流量會分配到剩餘狀況良好的複本上。 這種流量重定向對用戶端透明進行,用戶端仍使用相同的應用程式網址。

    如果啟用 會話親和性 ,且某區域中斷,先前路由到該區域副本的用戶端會被路由到新的副本,因為先前的副本已無法使用。 與先前複本相關聯的任何狀態都已遺失。

    故障區域不會新增工作。

  • 執行個體管理: 如果您的自動縮放規則是根據增加的負載觸發,則可能會有新的複本執行個體在良好區域中建立。

區域復原

當可用性區域從失敗中復原時,Container Apps 會自動將區域重新整合至作用中服務,而不需要您的介入。 平台的健康檢測器會檢測恢復區域中的基礎設施何時可用,容器應用程式會根據你的縮放設定開始將新副本排程至該區域。 健康區域內現有的複本在重新整合過程中仍持續服務交通,有助於防止服務中斷。

Container Apps 會在正常的調整作業中,逐步重新平衡所有可用區域的複本分布。 因縮放事件或替換狀況不良複本而建立複本時,會自動進行重新平衡。 平台不會強制立即重新散發現有狀況良好的複本,以防止不必要的容器重新啟動,並在復原期間維持應用程式穩定性。

測試區域失敗

容器應用程式平台會管理區域備援登錄的流量路由、容錯移轉和容錯容器應用程式。 此功能完全受控,因此您不需要起始或驗證可用性區域失敗程序。

為了驗證您的應用程式對區域等級故障的韌性,請使用受控測試方法模擬應用程式層面的中斷。 透過縮小應用程式規模,停止或移除特定區域的副本,並監控剩餘副本如何應對增加的負載。 在韌性測試期間監控關鍵指標,包括複本數量、請求成功率、回應時間及自動擴展行為。 確保你的最小副本數量在副本移除時仍維持服務可用性,並驗證你的擴展規則能承受剩餘副本增加的負載。 在您預期的時間範圍內,透過故意讓健全端點失效來測試健全狀態探查設定,以確認平台是否將狀況不良的執行個體從輪替中移除。

對區域範圍故障的復原能力

Container Apps 是單一區域服務。 如果區域無法使用,您的環境和應用程式也無法使用。

自訂多區域解決方案,以實現復原能力

若要降低單一區域故障影響應用程式的風險,您可以跨多個區域部署環境。 下列步驟有助於加強復原能力:

  • 將你的應用程式部署到每個區域的環境。 每個環境都需要自己的虛擬網路配置,且子網需求則獨立適用於每個區域部署。 你的容器映像檔必須在所有區域都能取得,這可以透過啟用地理複製的 Azure 容器登錄檔來達成。

  • 使用 Azure Front Door 或 Azure 流量管理員等服務來設定負載平衡和容錯移轉原則。

  • 跨區域複寫您的數據,以便復原最後一個應用程式狀態。

備份與還原

容器應用程式不會為您的應用程式或資料提供內建備份功能。 作為無狀態容器裝載平臺,Container Apps 預期應用程式會透過外部服務來管理自己的資料持續性和復原策略。 您的應用程式容器及其本機檔案系統是暫時的,當複本重新啟動或移動時,儲存在本機的任何資料都會遺失。

應用程式更新期間的彈性

使用修訂管理將更新部署至您的應用程式,而不會停機。 你可以用更新的容器映像檔建立新版本,並透過藍綠部署策略進行流量切換,或透過流量分割規則逐步調整流量。 在應用程式更新期間,平台會透過建立新容器來維持最低副本數量,然後再淘汰舊容器,有助於避免服務中斷。

欲了解更多資訊,請參閱 容器應用程式中的更新與部署變更

服務維護的韌性

Container Apps 會執行自動平台維護,以套用安全性更新、部署新功能,以及改善服務可靠性。 該平台利用跨故障域與可用性區域的滾動更新,以減少對執行中的應用程式的干擾。 在維護期間,你的容器能持續不中斷地運作,因為更新會分階段套用到底層基礎設施。

您可以指定自己的維護時段,也就是您想要對應用程式執行維護的時段。 請記得,關鍵更新可能會在維護期間之外發生。 欲了解更多資訊,請參閱 容器應用程式計畫維護

服務等級協定

Azure 服務的服務等級協定 (SLA) 描述服務的預期可用性,以及解決方案必須符合才能達到該可用性預期的條件。 如需詳細資訊,請參閱 在線服務的 SLA

容器應用程式的可用性 SLA 是根據你在應用程式上設定的擴展規則而定。