因應 Azure Kubernetes Service (AKS) 中商務持續性和災害復原的最佳做法
當您在管理 Azure Kubernetes Service (AKS) 中的叢集時，應用程式的執行時間會變得很重要。 依據預設，AKS 會在 虛擬機器擴展集 (VMSS) 中使用多個節點來提供高可用性。 但這些節點無法避免系統發生區域失敗。 為了充分發揮您的執行時間，請事先規劃以維護商務持續性，並為災害復原做好準備。
本文著重於 AKS 內的商務持續性和災害復原方案。 您會了解如何：
- 規劃多個區域中的 AKS 叢集。
- 使用 Azure 流量管理員跨多個叢集路由傳送流量。
- 針對容器映像登錄使用異地複寫。
- 規劃跨多個叢集的應用程式狀態。
- 跨多個區域複寫儲存體。
規劃多區域部署
最佳做法
當您部署多個 AKS 叢集時，請選擇可使用 AKS 的區域。 使用配對的區域。
AKS 叢集會部署到單一區域。 若要避免系統發生區域失敗，請將應用程式部署到跨不同區域的多個 AKS 叢集內。 規劃部署 AKS 叢集的位置時，請考慮：
-
- 請選擇靠近使用者的區域。
- AKS 會持續延伸至新的區域。
-
- 請針對您的地理區域選擇兩個配對在一起的區域。
- AKS 平台更新 (計劃性維護) 會加以序列化，配對區域之間至少會有 24 小時的延遲。
- 配對區域的復原工作會視需要排定優先順序。
服務可用性
- 決定您的配對區域應為熱/熱、熱/暖，或熱/冷。
- 您是否想要同時執行這兩個區域，並 備 妥一個區域來開始提供流量？ 或
- 您是否要給予一個區域時間來準備提供流量？
AKS 區域可用性和配對區域需要聯合納入考慮。 請將 AKS 叢集部署到設計用來一起管理區域災害復原的配對區域。 例如，AKS 有在「美國東部」和「美國西部」提供。 這些區域會配對。 在建立 AKS BC/DR 策略時，請選擇這兩個區域。
在部署應用程式時，還必須將另一個步驟新增至 CI/CD 管線，以利於部署至這些 AKS 叢集。 更新部署管線能防止應用程式只會部署至您其中一個區域和 AKS 叢集。 在那樣情況下，導向至次要區域的客戶流量，將不會接收最新的程式碼更新。
使用 Azure 流量管理員來路由傳送流量
最佳做法
若要獲得最佳的效能和備援能力，請先透過流量管理員導引所有應用程式流量，再讓流量進入 AKS 叢集。
如果您在不同區域中有多個 AKS 叢集，請使用流量管理員來控制在每個叢集中所執行的應用程式。 Azure 流量管理員是 DNS 型的流量負載平衡器，可以將網路流量分散到各個區域。 使用流量管理員，根據叢集回應時間或優先順序來路由使用者。
如果您有單一 AKS 叢集，通常會連線至指定應用程式的服務 IP 或 DNS 名稱。 在多個叢集部署內，您應該連線至流量管理員的 DNS 名稱，而那也指向每個 AKS 叢集上的服務。 透過使用流量管理員端點定義這些服務。 每個端點皆是 服務負載平衡器 IP。 使用此設定，能讓您將網路流量從一個區域中的 Azure 流量管理員端點，導向至不同區域中的端點。
Azure 流量管理員會執行 DNS 查閱，並傳回最適當的端點。 使用優先順序路由，您可以啟用主要服務端點和多個備份端點，以防主要或其中一個備份端點無法使用。
如需如何設定端點和路由的資訊，請參閱 在流量管理員中設定優先順序流量路由方法。
使用 Azure Front Door 應用程式路由
使用分割 TCP 型任一通訊協定，Azure Front Door 將您的終端使用者立即連線到最接近的 Front Door POP (存在點)。 Azure Front Door 的其他功能如下：
- TLS 終止
- 自訂網域
- Web 應用程式防火牆
- URL 重寫
- 工作階段親和性
請檢閱應用程式流量的需求，以了解哪一種解決方案最合適。
具有全域虛擬網路對等互連的交互連線區域。
透過虛擬網路對等互連彼此連線兩個虛擬網路，以啟用叢集之間的通訊。 虛擬網路彼此互連，以提供高頻寬跨越整個 Microsoft 骨幹網路 (甚至跨越不同的地理區域)。
在執行 AKS 叢集的對等互連虛擬網路前，請在 AKS 叢集內使用 Standard Load Balancer。 此必要條件讓 Kubernetes 服務能觸達跨虛擬網路對等互連。
為容器映像啟用異地複寫
最佳做法
請容器映像儲存在 Azure Container Registry，並將登錄異地複寫至每個 AKS 區域。
若要在 AKS 中部署及執行應用程式，您必須有辦法儲存和提取容器映像。 Azure Container Registry (ACR) 可與 AKS 整合，以利於安全地儲存容器映像或 Helm 圖表。 ACR 可支援讓多重主機異地複寫自動將映像複寫至世界各地的 Azure 區域。
若要改善效能和可用性，請使用 Container Registry 異地複寫，在具有 AKS 叢集的每個區域中建立登錄。然後，每個 AKS 叢集都會從相同區域中的本機容器登錄提取容器映射。
使用 Container Registry 異地複寫從相同區域提取映射有下列優點：
- 更快速：您可從相同 Azure 區域內的高速、低延遲網路連線提取映像。
- 更可靠：如果區域無法使用，您的 AKS 叢集會從可用的容器登錄提取映像。
- 更便宜：資料中心間沒有網路輸出費用。
異地複寫為進階版SKU 容器登錄功能。 如需瞭解設定複寫的步驟，請參閱 Azure Container Registry 異地複寫。
從容器內移除服務狀態
最佳做法
避免將服務狀態儲存於容器內。 而是使用支援多重區域複寫的 Azure 平台即服務 (PaaS)。
服務狀態係指服務正常運作所需的記憶體或磁碟資料。 狀態包括服務會讀取及寫入的資料結構和成員變數。 依據如何服務的架構而定，該狀態可能還包括儲存在磁碟上的檔案或其他資源。 例如，狀態可能包含用來儲存資料和交易記錄的檔案資料庫。
狀態能進行外部化，或者也能並存於運作該狀態的程式碼中。 狀態外部化的做法通常為使用資料庫，或透過網路在不同機器上，或在相同機器上，執行流程以外的其他資料存放。
在容器和微服務內執行的程序為不保留狀態時，它們則會有最好的復原性。 由於應用程式幾乎一律包含某些狀態，因此請使用 PaaS 解決方案，例如：
- Azure Cosmos DB
- 適用於 PostgreSQL 的 Azure 資料庫
- 適用於 MySQL 的 Azure 資料庫
- Azure SQL Database
如果要組建可攜應用程式，請參閱下列指導方針：
建立儲存體移轉計劃
最佳做法
如果您使用 Azure 儲存體，請針對將儲存體從主要區域遷移至備份區域的方法進行準備和測試。
您的應用程式可能會為其資料使用 Azure 儲存體。 如果是這樣，則應用程式將分散到多個位於不同區域的 AKS 叢集。 您必須讓儲存體保持同步。 下列為兩個常見的複寫儲存體方式：
- 以基礎結構為基礎的非同步複寫
- 以應用程式為基礎的非同步複寫
以基礎結構為基礎的非同步複寫
即使將 Pod 刪除後，您的應用程式仍可能需要永續性儲存體。 在 Kubernetes 中，您可以使用永續性磁碟區來保存資料儲存體。 永續性磁碟區會裝載至節點 VM，接著再對 Pod 公開。 永續性磁碟區會跟隨 Pod，即使 Pod 移到相同叢集內的不同節點也是如此。
您使用的複寫策略取決於您的儲存體解決方案。 下列常見的儲存體解決方案，提供災害復原和複寫指導：
通常，您會提供常見的儲存點，讓應用程式寫入其資料。 然後，此資料會複寫到各個區域，再進行本機存取。
如果使用 Azure 受控磁碟，則可以在 Azure 和 Kasten 上使用 Velero 來處理複寫和災害復原。 這些選項會備份原生的解決方案，但 Kubernetes 並不支援。
以應用程式為基礎的非同步複寫
Kubernetes 目前不提供以原生方式實作以應用程式為基礎的非同步複寫。 由於容器和 Kubernetes 具有鬆散耦合本質，所有傳統的應用程式或語言方法應當有所作用。 通常，應用程式本身複寫儲存體要求，其接著會再寫入至每個叢集的基礎資料儲存體。
後續步驟
本文著重於 AKS 叢集內的商務持續性和災害復原考量。 如需 AKS 中叢集作業的相關詳細資訊，請參閱下列關於最佳作法的內文：