Azure Kubernetes Service 的高可用性和災害復原概觀 (AKS)

在雲端中建立和管理應用程式時,一律會有中斷和災害中斷的風險。 若要確保商務持續性(BC),您必須規劃高可用性 (HA) 和災害復原 (DR)。

HA 是指高度可靠且體驗最短停機時間的系統或服務的設計與實作。 HA 是工具、技術和程序的組合,可確保系統或服務能夠執行其預期功能。 HA 是DR規劃的重要元件。 DR 是從災害復原並將商務作業還原至正常狀態的程式。 DR 是 BC 的子集,這是維護商務功能或在發生重大中斷時快速繼續其程式。

本文涵蓋部署至 AKS 之應用程式的一些建議做法,但絕不是可能解決方案的詳盡清單。

技術概觀

Kubernetes 叢集分成兩個元件:

  • 控制 平面,提供應用程式工作負載的核心 Kubernetes 服務和協調流程,以及
  • 執行 應用程式工作負載的節點

Kubernetes 控制平面和節點元件的圖表。

當您建立 AKS 叢集時,Azure 平台會自動建立並設定控制平面。 AKS 提供兩個叢集管理的定價層: 免費層標準層。 如需詳細資訊,請參閱 AKS 叢集管理的免費和標準定價層。

控制平面及其資源只位於您建立叢集的區域。 AKS 提供具有專用 API 伺服器、排程器等的單一租使用者控制平面。您可以定義節點的數目和大小,而 Azure 平台會設定控制平面與節點之間的安全通訊。 與控制平面的互動是透過 Kubernetes API 進行,例如 kubectl 或 Kubernetes 儀錶板。

若要執行您的應用程式和支援服務,您需要 Kubernetes 節點。 AKS 叢集至少有一個節點,即執行 Kubernetes 節點元件和容器運行時間的 Azure 虛擬機(VM)。 節點的 Azure VM 大小會定義 CPU、記憶體、大小和可用的記憶體類型(例如高效能 SSD 或一般 HDD)。 針對您的應用程式是否需要大量 CPU 和記憶體或高效能記憶體,規劃 VM 和記憶體大小。 在 AKS 中,叢集節點的 VM 映像是以 Ubuntu Linux、 Azure Linux 或 Windows Server 2022 為基礎。 當您建立 AKS 叢集或相應放大節點數目時,Azure 平台會自動建立並設定要求的 VM 數目。

如需 AKS 中叢集和工作負載元件的詳細資訊,請參閱 AKS 的 Kubernetes 核心概念。

重要考量

區域和全球資源

區域資源會布建為單一 Azure 區域的部署戳記的一部分。 這些資源不會與其他區域中的資源分享,而且可以獨立移除或復寫至其他區域。 如需詳細資訊,請參閱 區域資源

全域資源 會共享系統的存留期,而且可以在多區域部署的內容中全域使用。 如需詳細資訊,請參閱 全域資源

復原目標

完整的災害復原計劃必須針對應用程式實作的每個程式指定商務需求:

  • 復原點目標 (RPO) 是可接受資料遺失的持續時間上限。 RPO 是以時間單位來測量,例如分鐘、小時或天。
  • 復原時間目標 (RTO) 是可接受的停機時間上限,由 您的規格所定義的停機時間 。 例如,如果災害中可接受的停機時間是 8小時,則 RTO 為8小時。

可用性區域

您可以使用可用性區域,將數據分散到相同區域中的多個區域。 在區域內,可用性區域已足夠接近其他可用性區域的低延遲連線,但相距甚遠,以減少多個可用性區域會受到本機中斷或天氣影響的可能性。 如需詳細資訊,請參閱使用可用性區域和區域的 建議。

區域性復原能力

AKS 叢集可復原區域性失敗。 如果區域失敗,叢集會繼續在其餘區域中執行。 叢集的控制平面和節點會分散到區域,而 Azure 平臺會自動處理節點的分佈。 如需詳細資訊,請參閱 AKS 區域復原

負載平衡

全域負載平衡

全域負載平衡服務會將流量分散到區域後端、雲端或混合式內部部署服務。 這些服務將終端使用者流量路由傳送至最接近的可用後端。 它們也會回應服務可靠性或效能的變更,以將可用性和效能最大化。 下列 Azure 服務提供全域負載平衡:

區域負載平衡

區域負載平衡服務會將虛擬網路內的流量分散到區域內的 VM 或區域和區域備援服務端點。 下列 Azure 服務提供區域負載平衡:

可檢視性

您需要從應用程式和基礎結構收集數據,以允許有效的作業和最大化的可靠性。 Azure 提供工具來協助您監視和管理 AKS 工作負載。 如需詳細資訊,請參閱 可檢視性資源

範圍定義

當您管理 AKS 叢集時,應用程式運行時間變得很重要。 根據預設,AKS 會使用虛擬機擴展集中的多個節點來提供高可用性,但這些節點不會保護您的系統免於區域失敗。 若要將運行時間最大化,請事先規劃,以維護商務持續性,並使用下列最佳做法準備災害復原:

  • 規劃多個區域中的 AKS 叢集。
  • 使用 Azure 流量管理員,跨多個叢集路由傳送流量。
  • 針對您的容器映像登錄使用異地複寫。
  • 規劃跨多個叢集的應用程式狀態。
  • 跨多個區域復寫記憶體。

部署模型實作

部署模型 優點 缺點
主動-主動 • 故障轉移期間不會遺失數據或不一致
• 高復原能力
• 更有效能的資源使用率
• 複雜的實作和管理
• 成本較高
• 需要負載平衡器和流量路由的形式
主動-被動 • 更簡單的實作和管理
• 成本較低
• 不需要負載平衡器或流量管理員
• 在故障轉移期間可能會遺失數據或不一致
• 較長的復原時間和停機時間
• 資源使用量過低
被動-冷 • 成本最低
• 不需要同步處理、復寫、負載平衡器或流量管理員
• 適用於低優先順序、非關鍵性工作負載
• 故障轉移期間數據遺失或不一致的風險很高
• 最長的復原時間和停機時間
• 需要手動介入才能啟動叢集和觸發備份

主動-主動高可用性部署模型

在主動-主動高可用性 (HA) 部署模型中,您有兩個獨立 AKS 叢集部署在兩個不同的 Azure 區域中(通常是配對的區域,例如加拿大中部和加拿大東部或美國東部 2 和美國中部),可主動服務流量。

使用此範例架構:

  • 您會在個別的 Azure 區域中部署兩個 AKS 叢集。
  • 在正常作業期間,這兩個區域之間的網路流量會路由傳送。 如果某個區域變成無法使用,流量會自動路由傳送至最接近發出要求之用戶的區域。
  • 每個區域 AKS 實例都有已部署的中樞輪輻組。 Azure 防火牆 管理員原則會跨區域管理防火牆規則。
  • Azure 金鑰保存庫 會佈建在每個區域中,以儲存秘密和密鑰。
  • Azure Front Door 負載平衡並將流量路由傳送至區域 Azure 應用程式閘道 實例,該實例位於每個 AKS 叢集前面。
  • 區域Log Analytics實例會儲存區域網路計量和診斷記錄。
  • 工作負載的容器映像會儲存在受控容器登錄中。 單一 Azure Container Registry 用於叢集中的所有 Kubernetes 實例。 Azure Container Registry 的異地複寫可讓映像複寫至選取的 Azure 區域,並持續存取映像,即使區域發生中斷也一樣。

若要在 AKS 中建立主動-主動部署模型,請執行下列步驟:

  1. 在兩個不同的 Azure 區域中建立兩個相同的部署。

  2. 建立 Web 應用程式的兩個實例。

  3. 使用下列資源建立 Azure Front Door 配置檔:

    • 端點。
    • 兩個原始群組,各有一個優先順序
    • 路由。
  4. 僅從 Azure Front Door 實體限制 Web 應用程式的網路流量。 5. 設定所有其他後端 Azure 服務,例如資料庫、記憶體帳戶和驗證提供者。

  5. 使用持續部署將程式代碼部署至這兩個 Web 應用程式。

如需詳細資訊,請參閱 AKS 的建議主動-主動高可用性解決方案概觀。

主動-被動災害復原部署模型

在主動-被動災害復原 (DR) 部署模型中,您有兩個獨立 AKS 叢集部署在兩個不同的 Azure 區域中(通常是配對區域,例如加拿大中部和加拿大東部或美國東部 2 和美國中部),可主動服務流量。 在任何指定時間,只有一個叢集會主動提供流量。 另一個叢集包含與使用中叢集相同的組態和應用程式數據,但除非流量管理員指示,否則不接受流量。

使用此範例架構:

  • 您會在個別的 Azure 區域中部署兩個 AKS 叢集。
  • 在一般作業期間,網路流量會路由傳送至您在 Azure Front Door 設定中設定的主要 AKS 叢集。
    • 優先順序必須在 1-5 之間設定,1 設定為最高,5 設定為最低。
    • 您可以將多個叢集設定為相同的優先順序層級,並指定每個叢集的權數。
  • 如果主要叢集變得無法使用(發生災害),流量會自動路由傳送至 Azure Front Door 中選取的下一個區域。
    • 所有流量都必須通過 Azure Front Door 流量管理員,此系統才能運作。
  • Azure Front Door 會將流量路由傳送至主要區域中的 Azure 應用程式閘道(叢集必須標示為優先順序 1)。 如果此區域失敗,服務會將流量重新導向至優先順序清單中的下一個叢集。
    • 規則來自 Azure Front Door。
  • 每個區域 AKS 實例都會部署中樞輪輻組。 Azure 防火牆 管理員原則會跨區域管理防火牆規則。
  • Azure 金鑰保存庫 會佈建在每個區域中,以儲存秘密和密鑰。
  • 區域Log Analytics實例會儲存區域網路計量和診斷記錄。
  • 工作負載的容器映像會儲存在受控容器登錄中。 單一 Azure Container Registry 用於叢集中的所有 Kubernetes 實例。 Azure Container Registry 的異地複寫可讓映像複寫至選取的 Azure 區域,並持續存取映像,即使區域發生中斷也一樣。

若要在 AKS 中建立主動-被動部署模型,請執行下列步驟:

  1. 在兩個不同的 Azure 區域中建立兩個相同的部署。

  2. 設定次要應用程式的自動調整規則,以便在主要區域變成非使用中時,調整為與主要實例相同的實例計數。 非使用中時,不需要相應增加。 這有助於降低成本。

  3. 建立 Web 應用程式的兩個實例,並在每個叢集上建立一個實例。

  4. 使用下列資源建立 Azure Front Door 配置檔:

    • 端點。
    • 主要區域的優先順序 為一 的源群組。
    • 次要區域的優先順序 為2的第二 個原始群組。
    • 路由。
  5. 僅從 Azure Front Door 實體限制 Web 應用程式的網路流量。

  6. 設定所有其他後端 Azure 服務,例如資料庫、記憶體帳戶和驗證提供者。

  7. 使用持續部署將程式代碼部署至這兩個 Web 應用程式。

如需詳細資訊,請參閱 AKS 的建議主動-被動災害復原解決方案概觀。

被動-冷故障轉移部署模型

被動冷故障轉移部署模型設定的方式與 主動-被動災害復原部署模型相同,但叢集在發生災害時啟動叢集之前會保持非使用中狀態。 我們考慮這種方法 的範圍不足 ,因為它牽涉到與主動-被動類似的組態,但具有手動介入以啟動叢集並觸發備份的額外複雜度。

使用此範例架構:

  • 您會建立兩個 AKS 叢集,最好在不同的區域或區域中,以取得更好的復原能力。
  • 當您需要故障轉移時,請啟動部署以接管流量流程。
  • 在主要被動叢集關閉的情況下,您必須手動啟動冷叢集以接管流量。
  • 此條件必須由每次手動輸入或您指定的特定事件來設定。
  • Azure 金鑰保存庫 會佈建在每個區域中,以儲存秘密和密鑰。
  • 區域 Log Analytics 實例會儲存每個叢集的區域網路計量和診斷記錄。

若要在 AKS 中建立被動-冷故障轉移部署模型,請執行下列步驟:

  1. 在不同的區域/區域中建立兩個相同的部署。
  2. 設定次要應用程式的自動調整規則,以便在主要區域變成非使用中時,調整為與主要實例相同的實例計數。 雖然非使用中,但不需要相應增加,這有助於降低成本。
  3. 建立 Web 應用程式的兩個實例,並在每個叢集上建立一個實例。
  4. 設定所有其他後端 Azure 服務,例如資料庫、記憶體帳戶和驗證提供者。
  5. 設定應觸發冷叢集的條件。 如有需要,您可以使用負載平衡器。

如需詳細資訊,請參閱 AKS 的建議被動冷故障轉移解決方案概觀。

服務配額和限制

AKS 會設定資源與功能的預設限制和配額,包括特定 VM SKU 的使用限制。

資源 限制
每個訂用帳戶的叢集上限 5000
注意:將叢集分散到不同的區域,以考慮 Azure API 節流限制
具有虛擬機器擴展集和 Standard Load Balancer SKU 的每個叢集節點數目上限 在所有 節點集區中 5000 個
注意:如果您無法為每個叢集相應增加 5000 個節點,請參閱 大型叢集的最佳做法。
每個節點集區的最大節點數 (虛擬機器擴展集節點集區) 1000
每個叢集的節點集區數目上限 100
每個節點的 Pod 數目上限:使用 Kubenet 網路外掛程式1 最大值:250
Azure CLI 預設值:110
Azure Resource Manager 範本預設值:110
Azure 入口網站部署預設值:30
每個節點的 Pod 數目上限:使用 Azure 容器網路介面1 最大值:250
建議用於 Windows Server 容器的最大值:110
預設值:30
Open Service Mesh (OSM) AKS 附加元件 Kubernetes 叢集版本:AKS 支援的版本
每個叢集的 OSM 控制器數目:1
每個 OSM 控制器的 Pod 數目:1600
由 OSM 管理的 Kubernetes Service 帳戶數目:160
每個叢集的負載平衡 Kubernetes 服務數目上限 (搭配 Standard Load Balancer SKU) 300
具有虛擬機器可用性設定組和基本 Load Balancer SKU 的每個叢集節點數目上限 100

1 Windows Server 容器必須使用 Azure CNI 網路外掛程式。 Windows Server 容器不支援 Kubenet。

Kubernetes 控制平面層 限制
標準層 根據負載自動調整 Kube API 伺服器。 較大的控制平面元件限制和 API 伺服器等執行個體。
免費層 有限的資源,具有 50 個變動和 100 個唯讀呼叫的傳遞要求限制。 每個叢集的建議節點限制為 10 個節點。 最適合用於實驗、學習和簡單的測試。 不建議用於生產/關鍵性工作負載

如需詳細資訊,請參閱 AKS 服務配額和限制

Backup

Azure 備份 支援使用備份延伸模組備份連結至叢集的 AKS 叢集資源和永續性磁碟區。 備份保存庫會透過擴充功能與 AKS 叢集通訊,以執行備份和還原作業。

如需詳細資訊,請參閱下列文章: