概念
集群联邦 Federation 的目的是实现单一集群统一管理多个kubernetes集群的机制。这些集群可以是跨地域的，跨云厂商的或者是用户内部自建集群。一旦集群建立联邦后，就可以使用集群 Federation API 来管理多个集群的 kubernetes API 资源。
目标
- 简化管理多个联邦集群的Kubernetes API 资源
- 在多个集群之间分散工作负载(容器)，以提升应用(服务)的可靠性
- 在不同集群中，能更快速更容易地迁移应用(服务)
- 跨集群的服务发现，服务可以就近访问，以降低延迟
- 实践多云(Multi-cloud)或混合云(Hybird Cloud)的部署
集群联邦最初是 v1 版本，因为方案设计问题，导致可扩展性比较差，已经被废弃，目前社区提出了新的方案 Federation V2
Federation V1
从上图架构中得知Federation v1 的设计沿用类似Kubernetes 模型，其主要组件有以下:
- federation-apiserver :提供Federation API资源，只支持部分Kubernetes API resources。
- federation-controller-manager :协调不同集群之间的状态，如同步Federated资源与策略，并建立Kubernetes组件至对应集群上。
- etcd :储存Federation的状态。
该方案设计之初没有考虑到crd的特性，支持的 Federation API 资源类型都是写死的，无法有效的扩展，不能兼容新的api资源，不支持跨集群权限管理，如不支持RBAC。联邦层级的设定与策略依赖API 资源的Annotations 内容，这使得弹性不佳。
Federation V2
Federation V2 是Kubernetes SIG Multi-Cluster团队新提出的集群联邦架构( Architecture Doc与Brainstorming Doc )，新架构在Federation v1基础之上，简化扩展Federated API过程，并加强跨集群服务发现与编排的功能。
相较于V1，Federation V2移除了 federation-apiserver 组件，通过 crd 机制来完成 federated resource的扩充，kubefed-controller 组件通过监听crd的变化来完成联邦资源的同步和调度等功能。
联邦成员注册
集群联邦安装文档 DOC，集群成员注册后，会在管理集群创建一个 KubeFedCluster 资源来存储集群的基本信息，如API Endpoint、CA Bundle等，kubefed controller 通过这些信息来访问和管理联邦集群成员。
联邦化资源
Federation V2 可以联邦化任意资源，包括自定义的crd资源。对集群资源联邦化的实现主要是通过两种CRD来完成，分别是 FederatedTypeConfig 和 Federated<API Type> ，FederatedTypeConfig定义了 Federated<API Type> 和kubernetes api资源的关联关系。而 Federated<API Type> 用来定义怎么去联邦化对应的kubernetes api资源。
比如我们想将 configmap 通过联邦机制在多个集群中创建，则需要先在Federation Host集群中创建 FederatedConfigMap CRD资源，然后创建FederatedTypeConfig 资源将 FederatedConfigMap 和 Configmap 建立关联。
apiVersion: core.kubefed.k8s.io/v1beta1
kind: FederatedTypeConfig
metadata:
name: configmaps
namespace: kube-federation-system
spec:
federatedType:
group: types.kubefed.k8s.io
kind: FederatedConfigMap
pluralName: federatedconfigmaps
scope: Namespaced
version: v1beta1
propagation: Enabled
targetType:
kind: ConfigMap
pluralName: configmaps
scope: Namespaced
version: v1
如果要新增新的 federate type api，执行 kubefedctl enable <kubernetes resource api type> ，如下，如果想要联邦化新的资源crd资源 etcdclusters，则可以执行 kubefedctl enable etcdclusters ，执行后会自动生成新的crd联邦资源 federatedetcdclusters，以及类型为 federatedtypeconfigs 的cr资源 etcdclusters.<api_group>。
$ kubefedctl enable etcdclusters
$ kubectl api-resources | grep etcd
etcdclusters etcd etcd.database.coreos.com true EtcdCluster
federatedetcdclusters fetcd types.kubefed.k8s.io true FederatedEtcdCluster
$ kubectl -n kube-federation-system get federatedtypeconfigs | grep etcd
etcdclusters.etcd.database.coreos.com 3m16s
跨集群调度
KubeFed提供了一种自动化机制来将工作负载实例分散到不同的集群中，且能够基于总副本数与集群的定义策略来将Deployment或ReplicaSet资源进行编排。编排策略是通过创建ReplicaSchedulingPreference(RSP)，再由KubeFed RSP Controller监听与获取RSP内容来将工作负载实例建立到指定的集群上。
如下例子，假设有三个集群 cluser1，cluser2，cluser3
apiVersion: scheduling.kubefed.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-namespace
spec:
targetKind: FederatedDeployment
totalReplicas: 15
clusters:
"*":
weight: 2
maxReplicas: 12
cluster3:
minReplicas: 1
maxReplicas: 3
weight: 1
当rsp创建后，kubefed rsp controller 会监听到变化，并获取rsp内容，根据rsp定义的 name/namespace 找到对应的 federatedDeployment 资源，根据定义的策略计算出每个集群的副本数量，之后修改 federatedDeployment 资源的spec.overrides内，最好 kubefed sync cnotroller 会监听到 federatedDeployment 的变化，并将新的副本同步到联邦集群中。
跨集群服务发现
kubefed 提供了一系列api 资源和controller来实现跨集群Service/Ingress的DNS records自动发现和生成，并通过 ExternalDNS 将dns记录同步更新到服务提供商。
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: Domain
metadata:
name: test
namespace: kube-federation-system
domain: k8s.example.com
---
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: ServiceDNSRecord
metadata:
name: nginx
namespace: development
spec:
domainRef: test
recordTTL: 300
假设我们已经创建了一个名为nginx 的 FederatedDeployment ，并且创建了对应的 FederatedService 来提供 LoadBalancer。这时当创建以上 Domain与ServiceDNSRecord 资源后，KubeFed Service DNS Controller 会监听到 ServiceDNSRecord 的创建，并收集联邦集群成员的 Service 信息，更新到 ServiceDNSRecord 中；同时 DNS Endpoint Controller 会依据 ServiceDNSRecord 的内容生成并更新 DNSEndpoint 资源，最后ExternalDNS组件收集 DNSEndpoint 信息同步到DNS服务提供商。
若是Ingress 的话，会由IngressDNSRecord 资源取代，并由Ingress DNS Controller 收集信息。
