將 Azure Kubernetes Service (AKS) 和 MySQL 彈性伺服器工作負載移轉至可用性區域支援
本指南會說明如何移轉 Azure Kubernetes Service 和 MySQL 彈性伺服器工作負載，以完成所有相依服務的可用性區域支援。 如需所有工作負載相依性的完整清單，請參閱工作負載服務相依性。
您必須在建立 AKS 叢集或 MySQL 彈性伺服器時，啟用此工作負載的可用性區域支援。 如果您想要現有 AKS 叢集和 MySQL 彈性伺服器的可用性區域支援，就必須重新部署這些資源。
此移轉指引的主要重心放在考慮在 Azure 上執行下列架構時的基礎結構和可用性：
工作負載服務相依性
若要為可用性區域提供完整的工作負載支援，工作負載中的每個服務相依性都必須支援可用性區域。
可用性區域支援的服務有兩種方法：區域性或區域備援。 大部分服務會支援其中一種。 不過，在某些情況下，您可以為該服務選擇區域性資源或區域備援資源。 我們會指出哪些服務可支援下列建議中的區域性和區域備援資源。 我們也會指出哪些服務是全域服務，哪些服務是地區性服務。
AKS 和 MySQL 工作負載架構包含下列元件相依性：
Azure Kubernetes Service (AKS)
區域性：當您在建立期間預先選取用來部署節點集區的區域時，系統節點集區和使用者節點集區便是區域性集區。 建議您預先選取這三個區域，以獲得更好的復原能力。 您可以藉由提供
zones參數值，在現有 AKS 叢集中新增更多支援可用性區域的使用者節點集區。區域備援：Kubernetes 控制平面元件 (例如 etcd、API 伺服器、排程器和控制器管理員) 會自動複寫或分散到各區域。
注意
若要啟用 AKS 叢集控制平面元件的區域備援，您必須在建立 AKS 叢集時，使用區域來定義預設的系統節點集區。 在現有的非區域性 AKS 叢集中新增更多區域性節點集區並不會讓 AKS 叢集具備區域備援能力，因為該動作不會在事後將控制平面元件分散到各區域。
適用於 MySQL 的 Azure 資料庫彈性伺服器
區域性：區域性可用性模式表示，在與主要伺服器相同的區域內一律會有待命伺服器。 雖然此選項可減少容錯移轉時間和網路延遲，但因為單一區域中斷會同時影響主要伺服器和待命伺服器，所以其復原能力較差。
區域備援：區域備援可用性模式表示，在與主要伺服器位於相同地區中的另一個區域內一律會有待命伺服器。 主要伺服器和待命伺服器的區域備援會啟用兩個區域。 建議您使用此設定以獲得更好的復原能力。
Azure Standard Load Balancer 或 Azure 應用程式閘道
標準負載平衡器
若要了解與 Standard Load Balancer 資源相關的考量事項，請參閱 Load Balancer 和可用性區域。
區域備援：若要使用現有的 Load Balancer 來設定前端 IP，建議方式是選擇區域備援。 區域備援前端會對應至 AKS 叢集後端集區，後者會分散到多個區域。
區域性：如果您要將節點集區釘選到區域 1 和區域 2 等特定區域，便可以在現有的 Load Balancer 中預先為前端 IP 選取區域 1 和區域 2。 您可能會想要將節點集區釘選到特定區域的原因，可能是因為有 M 系列等特製化 VM SKU 系列可供使用。
Azure 應用程式閘道
只有應用程式閘道 v2 SKU (Standard 和 WAF) 才支援搭配 AKS 叢集使用應用程式閘道輸入控制器附加元件。 若要深入了解與 Azure 應用程式閘道相關的進一步考量事項，請參閱縮放應用程式閘道 v2 和 WAF v2。
區域性：若要使用可用性區域的好處，建議您在多個區域 (例如區域 1、區域 2 和區域 3) 中建立應用程式閘道資源。 選取這三個區域，以獲得最佳的地區內復原策略。 不過，若要對應至後端節點集區，您可以在建立應用程式閘道資源期間預先選取區域 1 和區域 2，以將節點集區釘選到特定區域。 您可能會想要將節點集區釘選到特定區域的原因，可能是因為有 M-series等特製化 VM SKU 系列可供使用。
區域備援儲存體 (ZRS)
建議您使用受控 ZRS 磁碟來設定 AKS 叢集，因為這些磁碟是區域備援資源。 磁碟區可以排程到所有區域上。
自 1.12 版起，Kubernetes 會注意到 Azure 可用性區域。 您可以在多區域 AKS 叢集中部署參考 Azure 受控磁碟的
PersistentVolumeClaim物件。 Kubernetes 會負責排程在正確可用性區域中宣告此 PVC 的任何 Pod。針對適用於 SQL 的 Azure 資料庫，建議您將資料和記錄檔裝載在區域備援儲存體 (ZRS) 中。 透過 ZRS 提供的儲存體層級複寫，會將這些檔案複寫至待命伺服器。
Azure 防火牆
區域性：若要使用可用性區域的好處，建議您在多個區域 (例如區域 1、區域 2 和區域 3) 中建立 Azure 防火牆資源。 建議您選取這三個區域，以獲得最佳的地區內復原策略。
Azure Bastion
地區性：Azure Bastion 會部署在 VNet 或對等互連 VNet 內，並與 Azure 地區相關聯。 如需詳細資訊，請參閱 Bastion 常見問題集。
Azure Container Registry (ACR)
區域備援：建議您在進階服務層級中建立區域備援登錄。 您也可以藉由為區域備援登錄複本設定 zoneRedundancy 屬性來建立區域備援登錄複本。 若要了解如何為 ACR 啟用區域備援，請參閱在 Azure Container Registry 中啟用區域備援以獲得復原能力和高可用性。
Azure Cache for Redis
區域備援：Azure Cache for Redis 支援進階和企業層中的區域備援設定。 區域備援快取可以將其節點放在相同地區的不同可用性區域中。
Microsoft Entra ID
全域：Microsoft Entra ID 是一種全域服務，具有多個層級的內部備援和自動復原能力。 Microsoft Entra ID 部署在全球超過 30 個資料中心內，可提供可用性區域 (如果有的話)。 隨著部署地區增加，此一數量也在快速成長。
Azure Key Vault
地區性：Azure Key Vault 會部署在地區中。 為了讓您的金鑰和祕密保有高持久性，金鑰保存庫的內容會複寫到地區內，以及複寫到相同地理位置內的次要地區。
區域備援：對於具有可用性區域且沒有地區配對的 Azure 地區，Key Vault 會使用區域備援儲存體 (ZRS) 在單一位置/地區內複寫金鑰保存庫的內容三次。
工作負載考量
Azure Kubernetes Service (AKS)
Pod 可以與其他 Pod 通訊 (不論是哪個節點或 Pod 登陸該節點時的所在可用性區域)。 如果 Pod 位於不同可用性區域中，您的應用程式可能會遇到較高的回應時間。 雖然 Pod 之間的額外往返延遲應該會落在大部分應用程式的可接受範圍內，但也有應用程式案例需要低延遲，尤其是 Pod 之間的聊天通訊模式。
建議您測試應用程式，確定其可在可用性區域之間順利執行。
基於這類低延遲的效能因素，Pod 可以共置於相同可用性區域內的相同資料中心。 若要在相同可用性區域內的相同資料中心共置 Pod，您可以使用唯一區域和鄰近放置群組來建立使用者節點集區。 您可以藉由建立新的代理程式節點集區並指定鄰近放置群組 (PPG)，將 PPG 新增至現有 AKS 叢集。 使用 Pod 拓撲散佈條件約束來控制如何將 Pod 分散至跨可用性區域、節點和地區的 AKS 叢集。
在需要低延遲通訊的 Pod 共置於相同的可用性區域後，Pod 之間就不會直接通訊。 相反地，Pod 會透過服務 (會定義 AKS 叢集中的 Pod 邏輯集合) 所建立的通道進行通訊。 Pod 可以設定為與 AKS 通訊，而與服務的通訊則會自動負載平衡至屬於該服務的所有 Pod。
為了利用可用性區域，節點集區包含屬於區域資源的基礎 VM。 若要支援具有不同計算或儲存體需求的應用程式，您可以在建立使用者節點集區時，使用特定 VM 大小建立使用者節點集區。
例如，因為應用程式中的微服務需要高輸送量、低延遲和記憶體最佳化的 VM 大小，以提供高 vCPU 計數和大量記憶體，您可能會決定針對使用者節點使用
M-series底下的Standard_M32ms。 視部署地區而定，當您在 Azure 入口網站中選取 VM 大小時，您可能會看到只有區域 1 和區域 2 支援此 VM 大小。 您可以接受此復原設定來換取高效能。建立節點集區之後，您無法變更其 VM 大小。 如需節點集區限制的詳細資訊，請參閱限制。
適用於 MySQL 的 Azure 資料庫彈性伺服器
在特定區域 (例如區域 1 和區域 2) 中部署節點集區的影響是，AKS 叢集的所有服務相依性也必須支援區域 1 和區域 2。 在此工作負載架構中，您的 AKS 叢集會與具有區域復原功能的「適用於 MySQL 的 Azure 資料庫彈性伺服器」具有服務相依性。 您會為主要伺服器選取區域 1，然後為要與 AKS 使用者節點集區共置的待命伺服器選取區域 2。
Azure Cache for Redis
Azure Cache for Redis 會透過您已選取的可用性區域，以循環方式在區域備援快取中分散節點。
您無法更新現有的進階快取以使用區域備援。 若要使用區域備援，您必須重新建立 Azure Cache for Redis。
若要達到最佳復原能力，建議您使用三個以上的複本建立 Azure Cache for Redis，以便將複本分散到三個可用性區域。
災害復原考量
可用性區域可用來提升復原能力，以便讓部署的主要地區內的工作負載實現高可用性。
災害復原是由商務持續性方案中所定義的復原作業和做法所組成。 商務持續性方案可解決工作負載在遇到中斷事件時的復原方式，以及在事件結束後完整復原的方式。 請考慮將您的部署延伸至替代地區。
針對應用程式層，請檢閱本文中關於 AKS 的商務持續性和災害復原考量。
請考慮在替代地區執行多個 AKS 叢集。 替代地區可以使用次要配對地區。 或者，如果主要地區沒有地區配對，您可以根據您對於可用服務、容量、地理鄰近性和資料主權的考量來選取替代地區。 請檢閱 Azure 地區決策指南。 另請檢閱部署戳記模式。
您可以選擇為 AKS 叢集設定主動-主動、主動-待命、主動-被動。
針對資料庫層，災害復原功能包括異地備援備份，能夠起始異地還原以及在不同地區部署讀取複本。
在中斷期間，您必須決定是否要起始復原作業。 只有在停機時間可能比工作負載的復原時間目標 (RTO) 還要久時，才需要起始復原作業。 否則，您可以藉由檢查 Azure 服務健康狀態儀表板上的服務狀態來等候服務自行復原。 在 Azure 入口網站的 [服務健康狀態] 刀鋒視窗中，您可以檢視與訂用帳戶相關聯的任何通知。
當您在適用於 MySQL 的 Azure 資料庫中使用異地還原功能起始復原作業時，系統會使用從另一個地區複寫而來的備份資料建立新的資料庫伺服器。
後續步驟
深入了解：