Share via

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

  • 發行項

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

HA 是指高度可靠且具有最短停機時間的系統或服務的設計與實作。 HA 是工具、技術和程序的組合，可確保系統或服務能夠執行其預期功能。 HA 是災害復原規劃的重要元件。 災害復原是從災害復原並將商務作業還原至正常狀態的程式。 災害復原是 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) 是可接受的停機時間上限，停機時間由您的規格所定義。 例如，如果災害中可接受的停機時間八小時，則 RTO 為八小時。

可用性區域

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

分區復原

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

負載平衡

全域負載平衡

全域負載平衡服務會將流量分散到跨區域後端、雲端或混合式內部部署服務。 這些服務將終端使用者流量路由傳送至最接近的可用後端。 這也會反應服務中可靠性或效能的變更，將可用性和效能發揮到極致。 下列 Azure 服務提供全域負載平衡：

區域負載平衡

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

可檢視性

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

範圍定義

當您管理 AKS 叢集時，應用程式運行時間變得很重要。 依據預設，AKS 會在 虛擬機器擴展集中使用多個節點來提供高可用性，這些節點不會保護您的系統受到區域失敗危害。 為了充分發揮您的執行時間，請事先規劃以維護商務持續性，並使用下列最佳做法做好災害復原的準備：

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

部署模型實作

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

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

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

使用此範例結構：

  • 您會在個別的 Azure 區域中部署兩個 AKS 叢集。
  • 正常作業期間，會將網路流量路由傳送到區域之間。 如果某個區域變成無法使用，流量會自動路由傳送至最接近發出要求之使用者的區域。
  • 每個區域 AKS 執行個體都會有部署中樞輪輻組。 Azure 防火牆管理員原則可管理每個區域的防火牆規則。
  • Azure Key Vault 會在每個區域中佈建來儲存秘密和金鑰。
  • Azure Front Door 可平衡負載，並將流量路由傳送到位於每個 AKS 叢集前面的區域 Azure 應用程式閘道執行個體。
  • 區域 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 Key Vault 會在每個區域中佈建來儲存秘密和金鑰。
  • 區域 Log Analytics 執行個體可儲存區域網路計量和診斷記錄。
  • 工作負載的容器映像可儲存在受控容器登錄中。 單一 Azure Container Registry 可用於叢集中的所有 Kubernetes 執行個體。 Azure Container Registry 的異地複寫可將映像複寫至選取的 Azure 區域，即使某個區域發生中斷，依然可持續存取映像。

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

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

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

  3. 建立 Web 應用程式的兩個執行個體，並在每個叢集上建立一個執行個體。

  4. 使用下列資源建立 Azure Front Door 設定檔：

    • 端點。
    • 原點群組在主要區域中的優先順序為一。
    • 第二個原點群組在次要區域中的優先順序為二。
    • 路由。

  5. 只限從 Azure Front Door 執行個體到 Web 應用程式的網路流量。

  6. 配置所有其他後端 Azure 服務，例如資料庫、儲存體帳戶和驗證提供者。

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

如需更多資訊，請參閱 AKS 建議的主動/被動災害復原解決方案概觀。

被動-冷容錯移轉的部署模型

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

使用此範例結構：

  • 您要建立兩個 AKS 叢集，最好在不同的區域或區域中，以取得更好的復原能力。
  • 當您需要容錯轉移時，請啟動部署以接管流量流程。
  • 如果主要被動叢集關閉，您必須手動啟動冷叢集以接管流量。
  • 此條件必須由每次手動輸入或您指定的特定事件來設定。
  • Azure Key Vault 會在每個區域中佈建來儲存秘密和金鑰。
  • 區域 Log Analytics 執行個體可針對每個叢集儲存區域網路計量和診斷記錄。

若要在 AKS 中建立被動-冷容錯移轉部署模型，請執行下列步驟：

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

如需更多資訊，請參閱 AKS 建議的被動-冷容錯移轉原解決方案概觀。

服務配額和限制

AKS 服務都會針對資源和功能設定預設限制和配額，包括特定 VM SKU 的使用限制。

資源 限制
每個訂用帳戶的叢集上限 5,000
注意：將叢集分散到不同的區域，以考慮 Azure API 節流限制
具有虛擬機器擴展集和 Standard Load Balancer SKU 的每個叢集節點數目上限 所有 節點集區 5,000 個
注意：如果您無法為每個叢集相應增加 5,000 個節點，請參閱 大型叢集的最佳做法。
每個節點集區的最大節點數 (虛擬機器擴展集節點集區) 1000
每個叢集的節點集區數目上限 100
每個節點的 Pod 數目上限：使用 Kubenet 網路外掛程式1 最大值：250
Azure CLI 預設值：110
Azure Resource Manager 範本預設值：110
Azure 入口網站部署預設值：30
每個節點的 Pod 數目上限：使用 Azure 容器網路介面 (Azure CNI)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 伺服器/etcd 實例。
免費層 有限的資源，具有 50 個變動和 100 個唯讀呼叫的傳遞要求限制。 每個叢集的建議節點限制為 10 個節點。 最適合用於實驗、學習和簡單的測試。 不建議用於生產/關鍵性工作負載。

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

Backup

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

如需詳細資訊，請參閱下列文章：