KubeFed架构设计

KubeFed（Kubernetes Cluster Federation，Kubernetes集群联邦）是Kubernetes项目下的多集群特殊兴趣小组（Special Interest Group，SIG）发布和管理的。集群联邦实现了单一集群统一管理多个Kubernetes集群的机制，这些集群可能是不同公有云厂商的云平台下创建的集群，也可能是数据中心内部自建的集群。集群联邦解决的最主要的使用场景就是将应用的部署扩展到多集群环境中，用户可以在被称为Hosting Cluster的主集群中统一配置并管理其他成员集群（包括主集群自身）。

集群联邦经历了两个版本的迭代，第1版由Kubernetes项目核心团队维护，跟随Kubernetes 1.5发布，在迭代至Kubernetes 1.8时转交给多集群特殊兴趣小组。第1版集群联邦的整体架构与Kubernetes类似，如下所示，在被管理的成员集群上层引入用于接收创建多集群工作负载请求的联邦API服务器（Federation API Server）和用于将对应的多集群工作负载下发给成员集群的联邦控制管理器（Federation Controller Manager）。

集群联邦第1版架构

在API层面，联邦资源的调度通过添加注解（annotation）实现，最大限度地兼容原有Kubernetes API。这样做的好处是可以复用现有的代码，用户已有的部署文件不需要做太大改动即可迁移。但这也制约了集群联邦的进一步发展，使之无法很好地对API进行演进。对于每一种联邦资源，需要有对应的控制器实现多集群调度，所以早期的集群联邦只支持有限的几种资源类型。

集群联邦方案的资源设计非常不灵活，基于角色的访问控制（RBAC）策略的支持也存在诸多问题，导致其无法做到多集群资源的权限管理。多集群特殊兴趣小组意识到这种设计与Kubernetes主要发行版中的配置管理方式不符，且在设计上存在很多缺陷，所以在Kubernetes 1.11之后开发了新的版本，也就是现在的KubeFed项目。

与第1版相比，第2版最大的变化就是移除了联邦API服务器，并且利用Kubernetes的自定义资源定义（CRD）机制实现了集群联邦的整体功能，架构如下所示。部署KubeFed后可以看到两个组件：kubefed-controller-manager和kubefed-admission-webhook。kubefed-controller-manager组件负责处理自定义资源以及协调被管理集群之间的状态，kubefed-admission-webhook组件则提供了准入机制。

KubeFed架构

可以看到一个主集群（Host Cluster）和多个成员集群（Member Cluster），主集群可以是成员集群并且运行具体的工作负载，也可以只作为管控集群。

在Kubernetes集群联邦第2版的处理逻辑中，通过ClusterConfiguration声明了哪些Kubernetes集群纳入联邦，通过TypeConfiguration声明了哪些Kubernetes API资源用于联邦管理。TypeConfiguration又包括Template、Placement和Overrides几种类型定义。Template用于定义跨集群资源通用的表示形式，Placement用于定义资源应用于哪些集群，Overrides用于定义对集群中哪些字段进行更新、覆盖。FederatedDeployment资源中关于Template、Placement和Overrides的定义如下所示。

apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template: # 定义Deployment的所有内容，可以理解为Deployment与Pod之间的关联
    metadata:
      labels:
        app: nginx
    spec:
      ...
  placement:
    clusters:
    - name: cluster2
    - name: cluster1
  overrides:
  - clusterName: cluster2
    clusterOverrides:
    - path: spec.replicas
      value: 5

KubeFed集群联邦管理相关能力的实践，使用的版本为KubeFed 0.5.0，要求Kubernetes版本不低于1.13、Helm版本不低于3.2。