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 和服务网格的多集群功能处理连接问题； 它们不能取代部署编排。

这些工具具有不同的控制平面和故障模式。不要假设选择多集群部署管理器后， 它也会提供全局服务发现、网络可达性或共享身份。

按独立集群进行设计 #

将每个集群视为可独立运行的故障域。定义凭据如何轮换、应用在控制平面断开期间如何运行， 以及工作负载是在一个集群中活动还是在多个集群中活动。除非数据存储本身具有经过测试的复制和 故障转移设计，否则优先使用按集群划分的持久化数据。中央管理平面应提升一致性和可见性， 同时不能使本地恢复变得不可能。