本頁面說明如何跨多個區域執行 Kubernetes。
Kubernetes 的設計使單一叢集能夠跨多個故障區（Failure Zone）執行； 這些故障區通常隸屬於一個稱為**「地區」（Region）的邏輯分組。主要的雲端供應商將地區定義為一組故障區，亦稱為可用區（Availability Zone）**， 並提供一致的功能：在同一個地區內，各故障區提供相同的 API 與服務。
典型的雲端架構旨在將單一故障區故障對其他故障區服務的影響降至最低。
所有控制平面組件都支援以可互換資源池的方式執行， 並為各個組件建立多個副本
當您部署叢集控制平面時，需將控制平面組件的副本分散部署於多個故障區。 若高可用性是重要考量，應選擇至少三個故障區，並為各個控制平面組件（API 伺服器、排程器、etcd、叢集控制器管理器）建立多個副本，分散部署於這些故障區中。 若有使用雲端控制器管理器，也應將它複製到您所選擇的所有故障區中。
Kubernetes 會自動將工作負載資源 （例如 Deployment 或 StatefulSet） 的 Pod 分散部署於叢集中的不同節點。這種分散部署有助於降低故障造成的影響。
當節點啟動時，每個節點上的 kubelet 會自動在 Kubernetes API 中代表此特定節點的 Node 物件加上標籤。 這些標籤可以包含區域資訊。
如果您的叢集跨越多個故障區或地區，您可以結合使用節點標籤與 Pod 拓撲散佈限制， 來控制 Pod 在叢集中的各個故障域（地區、故障區，甚至特定節點）之間的分佈方式。 這些提示可讓排程器將 Pod 排程到更有利於可用性的位置， 從而降低相關故障影響整個工作負載的風險。
例如，您可以設定一項限制：確保在可行的情況下，一個 StatefulSet 的 3 個副本分別執行於不同的故障區 您可以透過宣告式的方式來定義此限制，不需要為每個工作負載明確指定使用哪些可用區。
Kubernetes 核心本身不會為您建立節點；您需要自行建立， 或使用像是 Cluster API 的工具來代為管理節點。
透過使用 Cluster API 等工具，您可以定義一組機器，將其分散在多個故障域中作為叢集的工作節點執行， 並定義規則，在發生整個區域的服務中斷時自動修復叢集。
您可以套用節點選擇器限制到您建立的 Pod， 以及 Deployment、StatefulSet 或 Job 等工作負載資源中的 Pod 模板。
當建立持久卷時，Kubernetes 會自動為連結至特定故障區的 PersistentVolume 加上區域標籤。
接著排程器會透過 NoVolumeZoneConflict 預選規則，
確保使用該 PersistentVolume 的 Pod 只會被排程到與該卷相同的故障區。
請注意到區域標籤的新增方式可能取決於您使用的雲端供應商與儲存佈建器。 請務必參考適用於您環境的特定文件，確保配置正確。
您可以為 PersistentVolumeClaims 指定一個StorageClass， 用來指定該類別中的儲存空間可以使用的故障域（區域）。 要了解配置能夠感知到故障域或區域的 StorageClass，請參閱允許的拓撲。
Kubernetes 本身並不包含故障區感知的網路功能。
您可以使用網路外掛來配置叢集網路，
而選用的網路解決方案可能包含與特定故障區相關的設定。例如，如果您的雲端供應商支援 type=LoadBalancer 的 Service，
負載平衡器可能只會將流量傳送至與處理此連線的負載平衡器位於相同區域的 Pod。請查看您的雲端供應商文件以瞭解詳情。
對於自訂或本地端部署，類似的考量同樣適用。 Service 與 Ingress 的行為，包含對不同故障區的處理方式， 會根據您叢集的實際部署方式而有所不同。
當您架設叢集時，還需要考慮：若某個地區內的所有故障區同時離線，您的架構是否能恢復服務，以及應如何恢復。 例如，是否仰賴某個故障區中至少有一個節點能夠執行 Pod？ 請確保任何叢集關鍵的修復工作，都不依賴叢集中至少有一個健康節點。例如：如果所有節點皆處於不健康狀態， 您可能需要執行一個帶有特殊 容許 的修復 Job， 使修復能順利完成，並讓至少一個節點恢復運作。
Kubernetes 並未提供此問題的解法；但在規劃時仍需納入考量。
若想了解排程器如何在叢集中依照設定的限制來排程 Pod， 請參閱排程與驅逐。