近期雲原生圈中多雲(Multi-Cloud)和混合雲的概念受到了很多關注，通過IBM、Vmware這倆筆收購不難看出，雲服務商正在相繼開拓混合雲市場。在IBM收購Redhat的聲明中，倆家公司強調它們將聯合推動基於kubernetes的混合雲解決方案，並致力成爲多雲和混合雲市場的領導者。VMware對Heptio的收購中也表示，將加強PKS與Heptio產品的合作，通過Kubernetes實現跨多雲的基礎架構平臺。
Federation(集羣聯邦)正是kubernetes社區中的多雲管理項目，可以方便地跨地區跨服務商管理多個Kubernetes集羣。其最初在1.3版本中被引入，後從主庫遷移到獨立repo(v1版本)[1]，由於v1版本存在的若干問題，現已切換到v2版本[2]。v1、v2版本雖然架構有較大差異，但共同目標都是使管理多個集羣更爲簡單，主要實現了以下倆個模型：
- 跨集羣的資源同步與伸縮(Sync and Scale resources across clusters)：提供在多個集羣中保持資源同步與伸縮的功能，例如確保一個Deployment可以運行在多個集羣中，並根據負載情況在集羣間合理伸縮。
- 跨級羣的服務發現(Cross cluster discovery)：提供自動配置DNS服務的功能，實現應用跨集羣服務發現的能力，例如在某一集羣中可以訪問另一集羣的應用。
Federation v1
Federation v1的架構跟k8s集羣的架構非常類似，整體架構如下：
主要包含四個組件：
- federation-apiserver：類似kube-apiserver，兼容k8s API，只是對聯邦處理的特定資源做了過濾（部分資源聯邦不支持，故使用apiserver來過濾）。
- federation-controller-manager：提供多個集羣間資源調度及狀態通同步，工作原理類似kube-controller-manager。
- kubefed：Federation CLI工具，用來將子集羣加入到聯邦中。
- etcd：存儲federation層面的資源對象，供federation control plane同步狀態。
V1版本爲了兼容k8s的API，將聯邦的相關配置都放在了對象的annotations中。如下圖所示，如果annotations中不包含聯邦的相關配置，則會在每個子集羣中創建同樣的4個實例。如果含有聯邦的配置，則federation-controller-manager會根據調度策略進行調度。
將federation層的配置寫到annotations中，雖然與k8s API保持了兼容，但也帶來了一些問題。由於沒有federation層獨立的API，導致了API版本無法很好的演進。這，也正催生了現在的v2版本（v1版本現已停止更新）。
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對象的增刪查改，然後做相應的增刪查改動作到子集羣中。
目前支持了k8s的Confimap、Deployment、Job等資源，後續還會增加更多資源。當然也支持用戶通過CRD資源自主定義Type configuration、Template、Placement、Override對象。
Schedule
主要定義應用在集羣中的調度分佈，該類型主要涉及Deployment與Replicaset倆種（該配置在v1中寫在對象的annotations中）。用戶可以定義對象在每個集羣中分佈的最多、最少實例數，並且還能在集羣中做到應用實例數的均衡分佈。值得注意的是，如果調度結果跟用戶自定義的override衝突時，該調度算法享有優先權。例如用戶override中定義爲5個實例，實際調度結果只有3個，那麼自定義的override中5個實例將被改爲3個。
MultiClusterDNS
如字段名，該資源主要在做多集羣間的服務發現，其下主要包含ServiceDNSRecord、IngressDNSRecord、DNSEndpoint這幾個資源對象。整個工作流程爲：
- 用戶首先創建Service資源，需要創建Service Template、Placement、Override（可選）三個對象，使Service分佈到各子集羣。
- 創建ServiceDNSRecord/IngressDNSRecord資源，federation-controller會根據該資源的配置，收集各子集羣對應的service信息，最後生成由域名與IP組合而成的DNSEndpoint資源並持久化到etcd中。
- 將federation-controller創建的DNSEndpoint資源中的域名與IP自動配置到DNS服務商的服務器上，可通過external-dns項目[4]自動配置。
這樣，就可以實現不同集羣中應用的服務發現，其實質是將各集羣服務的IP與對應域名配置到公網的DNS服務器上，以通過公網域名實現跨集羣服務發現。
總結
Federation v2中的CRD配置雖然略顯複雜，但是能夠根據負載情況，調度並調節各集羣的資源分佈，同時能夠提供跨集羣的應用故障轉移，以及跨集羣的服務發現。實現了方便的跨地區、跨服務商配置並管理多個k8s集羣，以及多集羣資源的統一管理
本文大概介紹了Federation v1、v2的整體架構，有興趣的同學可以進一步深入閱讀附錄中的源碼。
附錄：
- https://github.com/kubernetes/federation
- https://github.com/kubernetes-sigs/federation-v2
- https://github.com/kubernetes/cluster-registry
- https://github.com/kubernetes-incubator/external-dns