集群联邦（Federation）

联邦

联合可以轻松管理多个群集。 它通过提供2个主要构件来实现：

• 跨群集同步资源：联邦可以使多个群集中的资源保持同步。 例如，可以确保多个群集中部署相同的程序。
• 跨群集发现：联邦提供了自动配置DNS服务器和负载均衡器与所有群集后端的功能。例如，您可以确保可以使用全局VIP或DNS记录来访问多个群集的后端。

---

• 高可用：通过在群集之间传播负载并自动配置DNS服务器和负载平衡器，联邦会将群集故障的影响降至最低。
• 避免提供者锁定(lock-in)：通过更轻松地跨群集迁移应用程序，联邦会阻止群集提供者锁定(lock-in)。

---

• 低延迟：让多个区域中的集群通过向距离它们最近的集群提供服务来最大限度地减少延迟。
• 故障隔离：最好有多个小型集群而不是一个单独人大型集群来进行故障隔离（例如：云提供商的不同可用区域中有多个集群）。
• 可扩展性：单个kubernetes集群具有可扩展性限制（大多数用户不应该这样做，更多详情请参阅Kubernetes Scaling和Performance Goals）。
• 混合云：可以在不同的云提供商或本地数据中心上拥有多个群集。

注意

• 增加网络带宽和成本：联邦控制台监视所有群集以确保当前状态符合预期。如果集群在云提供商或不同云提供商的不同区域(regions)运行，这可能会导致显着的网络成本。
• 减少跨群集隔离：联邦控制台中的错误可能影响所有群集。通过将联邦控制台中的逻辑保持最简，可以缓解这一问题。 只要可能，它大部分都会委托给控制台的kubernetes集群中。 设计和实施也在安全方面做了很多考虑，并避免发生错误时多集群停机。
• 成熟度：联邦项目相对较新，不太成熟。 并非所有资源都可用，许多资源仍然是alpha状态。 Issue 88列举了团队忙于解决的系统已知问题。

跨集群服务发现

Kubernetes有一个标准的插件：kube-dns，这个插件可以在集群内部提供DNS服务，通过DNS解析service名字来访问kubernetes服务。
集群联邦federation/v1beta1 API扩展基于DNS服务发现的功能。利用DNS，让POD可以跨集群、透明的解析服务。

跨集群调度

为了追求高可用性和更高的性能，集群联邦能够把不同POD指定给不同的Kubernetes集群中。集群联邦调度器将决定如何在不同kubernetes集群中分配工作负载。

通过跨集群调度，我们可以：

• 跨kubernetes集群均匀的调度任务负载
• 将各个kubernetes集群的工作负载进行最大化，如果当前kubernetes集群超出了承受能力，那麽将额外的工作负载路由到另一个比较空闲的kubernetes集群中
• 根据应用地理区域需求，调度工作负载到不同的kubernetes集群中，对于不同的终端用户，提供更高的带宽和更低的延迟。

集群高可用，故障自动迁移

集群联邦可以跨集群冗馀部署，当某个集群所在区域出现故障时，并不影响整个服务。集群联邦还可以检测集群是否为不可用状态，如果发现某个集群为不可用状态时，可以将失败的任务重新分配给集群联邦中其他可用状态的集群上。

支持的类型资源

• Cluster
• ConfigMap
• DaemonSets
• Deployment
• Events
• Ingress
• Namespaces
• ReplicaSets
• Secrets
• Services

架构

federation-v1

主要包含四个组件：

• federation-apiserver：类似kube-apiserver，兼容k8s API，只是对联邦处理的特定资源做了过滤（部分资源联邦不支持，故使用apiserver来过滤）。
• federation-controller-manager：提供多个集群间资源调度及状态通同步，工作原理类似kube-controller-manager。
• kubefed：Federation CLI工具，用来将子集群加入到联邦中。
• etcd：存储federation层面的资源对象，供federation control plane同步状态。

联邦的相关配置放在了对象的annotations中

federation-v2

Federation v2版本在v1的基础上，进一步简练、增强，主要功能仍然是跨地区跨服务商管理多个Kubernetes集群。其通过当下大热的CRD模型定义了独立的API，同时仍通过ControllerManager模型来同步、调度资源，通过kubefed2来将子集群加入联邦。CRD与ControllerManager组成的Control Plane模型（去除了v1中独立APIServer、Etcd），使其可以部署在任意的k8s集群中，同时还可将该集群也join到联邦控制面作为子集群，整体定义模型如下：

目前主要定义了Cluster configuration、Type configuration、Schedule、MultiClusterDNS这四种类型的CRD资源。

• Cluster configuration

主要定义了子集群注册时的配置信息，其中主要引用了Cluster-Registry[3]这个子项目来定义cluster的配置信息。用户只需执行kubefed2 join将安装好的集群加入联邦，federation-controller-manager会自动读取新加入集群的context信息，生成cluster configuration信息，并持久化到etcd中，供后续消费。

• Type configuration

主要定义了federation可以处理哪些资源对象(在v1版本中靠独立APIServer来过滤)，例如使federation处理deployment，就创建一个deployment type configuration。Type configuration中又包含了三种类型的CRD资源：

• Template：定义了federation要处理的资源对象，含有该对象的全部信息，例如depoyment的template中就直接引用了k8s的deployment。
• Placement：定义要将资源对象运行在哪些子集群中，如不定义该对象，则资源不会运行在任一集群。在v1版本中资源是会默认下发到每一个集群中。
• Override：对于同一资源对象，在不同服务商的集群配置中可能有会有差异。例如deployment对象，其中volume可能不同云厂商实现有所不同，所以需要差异化配置volume字段，Overide就提供了差异化修改template中字段的能力（当前仅支持部分字段，后续会支持全部字段差异化修改）。

Type configuration的整体工作流程为：假设用户创建deployment的Type configuration资源对象，federation-controller在watch到该对象后会再创建一个controller，该controller主要关注Deployment Template/Placement/Override对象的增删查改，然后做相应的增删查改动作到子集群中。

• Schedule
  主要定义应用在集群中的调度分布，该类型主要涉及Deployment与Replicaset俩种（该配置在v1中写在对象的annotations中）。用户可以定义对象在每个集群中分布的最多、最少实例数，并且还能在集群中做到应用实例数的均衡分布。值得注意的是，如果调度结果跟用户自定义的override冲突时，该调度算法享有优先权。例如用户override中定义为5个实例，实际调度结果只有3个，那么自定义的override中5个实例将被改为3个。
• MultiClusterDNS
  该资源主要在做多集群间的服务发现，其下主要包含ServiceDNSRecord、IngressDNSRecord、DNSEndpoint这几个资源对象。整个工作流程为：

1、用户首先创建Service资源，需要创建Service Template、Placement、Override（可选）三个对象，使Service分布到各子集群。

2、创建ServiceDNSRecord/IngressDNSRecord资源，federation-controller会根据该资源的配置，收集各子集群对应的service信息，最后生成由域名与IP组合而成的DNSEndpoint资源并持久化到etcd中。

3、将federation-controller创建的DNSEndpoint资源中的域名与IP自动配置到DNS服务商的服务器上，可通过external-dns项目[4]自动配置。

这样，就可以实现不同集群中应用的服务发现，其实质是将各集群服务的IP与对应域名配置到公网的DNS服务器上，以通过公网域名实现跨集群服务发现。