Share via


Azure Kubernetes Service (AKS) 的主動-被動災害復原解決方案概觀

在 Azure Kubernetes Service (AKS) 中建立應用程式,並於資源建立過程中選擇 Azure 區域時,這是單一區域應用程式。 當區域在災害期間變成無法使用時,您的應用程式也會變成無法使用。 如果您在次要 Azure 區域中建立相同的部署,應用程式就不容易受到單一區域災害影響,這可保證業務持續性,且跨區域的任何資料複寫都可讓您復原最近的應用程式狀態。

本指南概述 AKS 的主動-被動災害復原解決方案。 在此解決方案中,我們會將兩個獨立且相同的 AKS 叢集部署到兩個配對的 Azure 區域,僅一個叢集會主動為流量提供服務。

注意

我們已在內部檢閱下列做法,並與 Microsoft 合作夥伴合作進行審查。

主動-被動解決方案概觀

在此災害復原方法中,我們會在兩個 Azure 區域中部署兩個獨立的 AKS 叢集。 不過,一次只有一個叢集會主動為流量提供服務。 次要叢集(未主動為流量提供服務)包含與主要叢集相同的設定和應用程式資料,但除非由 Azure Front Door 流量管理員指示,否則不接受任何流量。

案例和組態

裝載依賴資料庫等資源的應用程式時,最好實作此解決方案,以主動提供服務給一個區域中的流量。 在您需要裝載跨這兩個區域部署的無狀態應用程式,例如水平調整的情況下,建議您考慮 主動-主動解決方案,因為主動-被動解決方案會增加延遲。

元件

主動-被動災害復原解決方案會使用許多 Azure 服務。 此範例架構會用到下列元件:

多個叢集和區域:您可以部署多個 AKS 叢集,每個叢集都位於個別的 Azure 區域中。 在一般作業期間,網路流量會路由傳送至 Azure Front Door 設定中設定的主要 AKS 叢集。

設定的叢集優先順序:您會為每個叢集設定 1 到 5 之間的優先順序等級(1 是最高優先順序,5 是最低優先順序)。 您可以將多個叢集設定為相同的優先順序等級,並且為每個叢集指定權重。 如果主要叢集無法使用,流量會自動路由傳送至 Azure Front Door 中選取的下一個區域。 所有流量都必須通過 Azure Front Door,此系統才能運作。

Azure Front DoorAzure Front Door 可平衡負載,並且將流量路由傳送至主要區域中的 Azure 應用程式閘道 執行個體(叢集必須標示為優先順序 1)。 發生區域失敗時,服務會將流量重新導向至優先順序清單中的下一個叢集。

如需詳細資訊,請參閱 按照優先順序流量路由方法

中樞輪輻組:每個區域 AKS 執行個體都會部署中樞輪輻組。 Azure 防火牆管理員原則可管理每個區域的防火牆規則。

Key Vault:您會在每個區域中佈建 Azure Key Vault 來儲存秘密和金鑰。

Log Analytics:區域 Log Analytics 執行個體可儲存區域網路計量和診斷記錄。 共用執行個體則可儲存所有 AKS 執行個體的計量和診斷記錄。

Container Registry:工作負載的容器映像可儲存在受控容器登錄中。 透過這個解決方案,單一 Azure Container Registry 執行個體可用於叢集中的所有 Kubernetes 執行個體。 Azure Container Registry 的異地複寫可讓您將映像複寫至選取的 Azure 區域,並持續存取映像,即使某個區域發生中斷也一樣。

容錯移轉程序

如果一個區域中的某個服務或服務元件無法使用,則流量應該路由傳送到可使用該服務的區域。 多區域架構包含許多不同的失敗點。 在本節中,我們將討論潛在的失敗點。

應用程式 Pod (區域)

Kubernetes 部署物件可建立 Pod 的多個複本 (ReplicaSet)。 如果其中一個無法使用,則會在其餘複本之間路由傳送流量。 Kubernetes ReplicaSet 會嘗試啟動指定數目的複本正常執行。 如果一個執行個體停止運作,應該重新建立新的執行個體。 活躍度探查可檢查 Pod 中執行的應用程式或程序的狀態。 如果 Pod 沒有回應,活躍度探查會移除該 Pod,這會強制 ReplicaSet 建立新的執行個體。

如需詳細資訊,請參閱 Kubernetes ReplicaSet

應用程式 Pod (全域)

若整個區域變成無法使用,叢集中的 Pod 就再也無法為要求提供服務。 在這種情況下,Azure Front Door 執行個體會將所有流量路由傳送到其餘健康的區域。 這些區域中的 Kubernetes 叢集和 Pod 將繼續為要求提供服務。 若要對剩餘叢集增加的流量和要求進行補償,請記住下列指導:

  • 確保網路和計算資源的大小正確,可承受因區域容錯移轉而導致的流量突增。 例如,使用 Azure 容器網路介面 (CNI) 時,請確保您有一個子網路可支援具有尖峰流量負載的所有 Pod IP。
  • 使用水平 Pod 自動調整程式來增加 Pod 複本計數,以針對增加的區域需求進行補償。
  • 使用 AKS 叢集自動調整程式來增加 Kubernetes 執行個體節點計數,以針對增加的區域需求進行補償。

Kubernetes 節點集區 (區域)

計算資源有時候可能會發生局部故障,例如單一 Azure 伺服器機架中的電源變成無法使用。 若要保護 AKS 節點以免變成單點區域失敗,請使用 Azure 可用性區域。 可用性區域可確保每個可用性區域中的 AKS 節點實際獨立於另一個可用性區域中定義的節點。

Kubernetes 節點集區 (全域)

在完全的區域失敗中,Azure Front Door 會將流量路由傳送到其餘健康的區域。 同樣地,請務必針對剩餘叢集增加的流量和要求進行補償。

容錯移轉測試策略

雖然 AKS 中目前沒有機制可基於測試目的關閉整個部署區域,但 Azure Chaos Studio 提供了在叢集上建立混沌實驗的功能。

下一步

如果考慮使用不同的解決方案,請參閱下列文章: