概念

集群联邦 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 收集信息。