
Kubefed(Federation v2)即 Kubernetes 联邦,是目前社区正在难产的多集群解决方案,目前的版本是 0.1.0,如果考虑到 Federation v1 的话,Kubefed 也算是有个出师未捷身先死的大兄弟了。
Federation v1 在Kubernetes v1.6 时进入了 Beta 阶段,但之后就没有更进一步的发展,一直到 Kubernetes v1.11 左右正式被弃用。至于被废弃的原因是因为开发团队认为集群联邦的实践比想象中还要困难,有许多问题是 v1 架构没被考虑进去的,比如:
从 Federation v1 架构上看,Federation 主要由 API Server、Controller Manager 和外部存储 etcd 构成。

Federation API Server 基本复用了 Kube Api Server,对外提供统一的资源管理入口,但只允许使用 Adapter 拓展支持的 Kubernetes 资源。
Controller Manager 协调不同集群之间的状态,通过与成员集群的 Api Server 通讯,来统筹管理所有的 Kubernetes 成员集群。
Federation v1 整体的架构和 Kubernetes 自身的架构还是很像的,并将成员集群作为一种资源进行管理。但是因为 v1 一开始并没有设计到灵活的添加新 Kubernetes 资源以及 CRD,以至于每当创建一种新资源都要新增 Adapter。
本来资源设计的就非常不灵活,加之 RBAC 的支持问题,使得无法做到多集群资源的权限管理,因而流产,并为 v2 积累了宝贵的教训。
Federation v2 利用 CRD 实现了整体功能,通过定义多种自定义资源(CR),从而省掉了 v1 的 API Server,但也因此引入了 Host Cluster 的概念。
kubefedctl join 使得成员集群加入到主集群(Host Cluster)虽然 Federation v2 在设计上做了非常大的变更并省掉了 API Server ,但总体架构变动并不大,当将 Federation Control Plan 部署完成之后可以看到由两个组件构成:
$ kubectl -n kube-federation-system get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
kubefed-admission-webhook 1/1 1 1 3s
kubefed-controller-manager 2/2 2 2 3sadmission-webhook 提供了准入控制,controller-manager 处理自定义资源以及协调不同集群间的状态。


在逻辑上,Federation v2 分为两个大部分:configuration 和 propagation。
configuration 的设计明显吸取了 v1 的教训,将很多会变化的内容配置化,configuration 主要包含两个配置:
对于 Type configuration,联邦 v2 是下足了功夫,包含三个关键部分:
以上基本上完成了资源的定义并为 propagation 提供了资源描述。除此之外,Federation v2 还支持定义部署策略和调度规则,实现更精细的管理。