隨著雲端服務的普及，服務可靠度已成為產品開發中的核心課題。
無論產品功能多麼豐富多樣，若無法提供穩定可靠的服務，都難以贏得消費者的信任與青睞。
近年來，搭隨著「容器化」及「微服務」的潮流，Kubernetes 迅速成為了業界的標準工具。
各大雲端業者紛紛推出了自家的 Kubernetes 託管服務，微軟也不例外。
本篇文章將探討一下 AKS (Azure Kubernetes Service) 如何透過可用性區域策略，實現高可靠度的服務部署。
可用性區域(Availability Zones)
在開始前，我們先來談談何謂可用性區域
可用性區域 (AZ, Availability Zone) 為某個區域 (Region) 中的一座實體資料中心 (DC, Datacenter)，它必須擁有獨立的電力設備及運算設施，你可以把它當作一座大機房來看待。
而雖說是雲端服務，但其實骨子裡其實還是遵循地端的基礎建設打造而成。
一般而言，Azure 在每個區域通常都會建立三個 AZ。而每個 AZ 之間，會透過高速網路線配置來盡可能減少網路延遲，通常AZ 對 AZ 的網路延遲會壓在 < 2ms 以內。
而區域不等於國家，有些條件足夠的國家（如美國、日本、印度等）是會同時有多個區域的，你可以在 Microsoft Datacenters 這個網站找到更多詳細的資訊。
試想：如何在單一 AZ 發生故障時，要如何能繼續確保整體服務的可用性及容錯性呢？其實就是在同個區域打造多座機房，來避免老生常談的單點故障問題，而這其實就是多可用性區域（Multi-AZs）的概念。
而當不幸發生單一可用性區域故障 (Single Zone Failure) 時，只要將流量導到位於另外兩個 AZ 中，就能使服務繼續運行。
【補充說明】
有時會受限於該區域的地理或電力條件等其他外力因素，導致該區域只有單一AZ 的狀況。例如早期位於日本西部的區域，就是只有 1 個 AZ 的狀況（已於 2023-03 正式啟用 3 個 AZ）。而 Azure 前陣子在台灣啟用的機房，目前是連 AZ 的標準都還不到，有興趣的讀者可以點這個連結去一探究竟。
AKS 上的可用性區域(AZ)
講完了可用性區域的概念後，我們來談談 AKS 是如何實作可用性區域的。
在 AKS 中，Node（節點）是用來承載服務的運算單元，代表的是一台 Azure VM。
既然是 VM，它就會被部署到特定的 AZ 去。
假設我可以在每個 AZ 都擺一台 VM，在單一 AZ 故障時，至少還有另外兩個 AZ 是能夠對外提供服務的。
在 AKS 中，我們可以在建立 Node Pool 時決定哪些 zone 要被啟用，而且這個功能是不需要額外收費的。
AKS 的 Cluster Autoscaler 會自動在 scale up 事件被觸發時，使得 Nodes 均衡地被分布在三個 AZ 之中。
Cluster Autoscaler 還有許多預設的參數，如果你想要了解細節或進一步調整，可以參考 AKS - Cluster Autoscaler Profile。
關於 AZ，這邊還有幾點事項是你必須留意的：
- AZ 的選項是在 Node Pool 的層級上設定
- AZ 只能在建立 AKS Cluster 或 Node Pool 階段時設定
- 在 Scale down 被觸發時，Autoscaler 並不會確保 Node 被均衡分布。
- 想要啟用 AZ，Cluster 必須得用 Azure Standard Load Balancers 才行（目前只能在 Cluster 建立階段調整，所以如果一開始沒有選對，就要整座打掉重練了…）
- Node Pool 至少要有 3 個 Node 以上，AZ 才有實質的效果
- 多 AZ 部署只在 single zone failure 的情況下有效，若發生 regional failure 則沒有任何幫助
- Node 的機器型號（SKU）在建立後就不能夠再進行調整
結語
在多 AZ 啟用的架構下，即便遭遇到單一可用性區域故障的情況，服務還是能夠藉由其他 AZ 繼續對外提供。
因此，無論是初次探索 AZ 的新手，還是熟悉 AKS 的老手，持續學習和探索這些設計的細節，都會是提升雲端架構可靠性的關鍵！
如果你手邊有 Azure 帳號，建議可以照著官方文件先手動 Run 過一遍，並觀察一下 node 的分布狀況，相信閱讀起來更加能夠身歷其境！
