Kubernetes 聯邦

Kubernetes 聯邦是早期嘗試，目的是從聯邦控制平面管理跨叢集工作負載。Federation v1 已被棄用， 其以 CRD 為基礎、通常稱為 KubeFed 或 Federation v2 的後繼者，也不再是活躍的 Kubernetes 專案。 因此應將它視為歷史技術，而不是新平台的基礎。

聯邦試圖解決的問題 #

模型會註冊成員叢集，並將選定的資源傳播至這些叢集。模型旨在集中處理放置、複本分布、服務探索與設定， 同時保留獨立叢集。困難之處包括衝突處理、叢集故障、網路、身分識別、版本偏差，以及單一全域 API 可能 成為另一個可用性相依項。

原始實作使用獨立的聯邦 API 伺服器。後續工作將聯邦行為移入自訂資源與控制器，使其更容易擴充，但沒有消除 跨叢集狀態的營運複雜性。

使用目前的替代方案 #

根據問題選擇替代方案：

• GitOps 叢集群： Argo CD ApplicationSet 與 Flux 可將應用程式呈現並協調至多個已註冊叢集。
• 工作負載排程： Karmada 提供多叢集排程與傳播 API。
• 叢集群管理： Open Cluster Management 提供受管理叢集的註冊、原則與放置原語。
• 跨叢集網路： Cilium Cluster Mesh、Submariner 與服務網格的多叢集功能可處理連線；它們不會取代部署編排。

這些工具具有不同的控制平面與故障模式。不要假設選擇多叢集部署管理器也會提供全域服務探索、網路可達性或 共用身分識別。

為獨立叢集設計 #

將每個叢集視為可獨立操作的故障域。定義認證如何輪替、應用程式在控制平面中斷連線期間如何運作，以及工作負載 是在一個叢集還是多個叢集中啟用。除非資料存放區本身具備經測試的複寫與容錯移轉設計，否則偏好每個叢集各自的 持久資料。集中管理平面應改善一致性與可見性，而不應使本機復原變得不可能。