淺析 Kubernetes 多集群調度方案

作者：Edwardesire 2022-07-24 21:11:19

本文不會詳細介紹這些項目在部署和網絡管理的內容，重點分析兩個項目（Kubefed、Liqo）的跨集群資源調度。

Kubernetes 是一個容器編排平臺，用于調度、部署和管理容器化應用。并且經過幾年的發(fā)展，k8s 已經成為事實上的容器編排平臺標準。集群是 k8s 架構的構建塊（building block）。集群由多個工作節(jié)點（物理機或者虛擬機）組成，提供一個可供容器運行的資源池。一個集群擁有：

一個單獨的 API 入口
一個集群范圍的資源命名組織結構
一個調度域
一個服務路由域
……

每個集群都是獨立的系統(tǒng)，可以部署在公司的自建機房，也可以部署在云廠商的一個可用區(qū)。k8s 負責管理集群的可用資源：調度器將容器調度到適當的機器、kubelet 負責 pod/ 容器的生命周期管理。這些都是大家很熟悉的概念了。但是 k8s 的作用范圍是集群內，一個集群內的控制平面無法感知另一個集群的資源余量和服務狀態(tài)。當多集群的應用場景出現時，我們怎么處理多個集群的調度呢。

為什么要有多集群調度？

通常來說，一個集群的大小需要預估業(yè)務的資源總量。當資源不夠時，可以通過增加機器數量來進行集群擴容。但是集群規(guī)模也不是無限上升的。當節(jié)點 /pod 的數量越多，對控制平臺的組件的壓力就越大，進而影響集群整體穩(wěn)定性。

單集群的容量限制：單集群的最大節(jié)點數不是一個確定值，其受到集群的部署方法和業(yè)務使用集群資源的方式的影響。在官方文檔中的集群注意事項里提到單集群 5000 個節(jié)點上限，我們可以理解為推薦最大節(jié)點數。
多租戶：因為容器沒法做到完美的隔離，不同租戶可以通過不同宿主機或者不同集群分割開。對企業(yè)內部也是如此，業(yè)務線就是租戶。不同業(yè)務線對于資源的敏感程度也不同，企業(yè)也會將機器資源劃分為不同集群給不同業(yè)務線用。
云爆發(fā)：云爆發(fā)是一種部署模式，通過公有云資源來滿足應用高峰時段的資源需求。正常流量時期，業(yè)務應用部署在有限資源的集群里。當資源需求量增加，通過擴容到公有云來消減高峰壓力。
高可用：單集群能夠做到容器級別的容錯，當容器異常或者無響應時，應用的副本能夠較快地另一節(jié)點上重建。但是單集群無法應對網絡故障或者數據中心故障導致的服務的不可用。跨地域的多集群架構能夠達到跨機房、跨區(qū)域的容災。
地域親和性：盡管國內互聯網一直在提速，但是處于帶寬成本的考量，同一調用鏈的服務網絡距離越近越好。服務的主調和被調部署在同一個地域內能夠有效減少帶寬成本；并且分而治之的方式讓應用服務本區(qū)域的業(yè)務，也能有效緩解應用服務的壓力。

當然，使用多集群調度肯定會增加整體架構的復雜度，集群之間的狀態(tài)同步也會增加控制面的額外開銷。所以，多集群的主要攻克的難點就是跨集群的信息同步和跨集群網絡連通方式。跨集群網絡連通方式一般的處理方式就是確保不同機房的網絡相互可達，這也是最簡單的方式。

而我比較干興趣的是跨集群的信息同步。多集群的服務實例調度，需要保證在多集群的資源同步的實時，將 pod 調度不同的集群中不會 pod pending 的情況。控制平面的跨集群同步主要有兩類方式：

定義專屬的 API server：通過一套統(tǒng)一的中心化 API 來管理多集群以及機器資源。KubeFed 就是采用的這種方法，通過擴展 k8s API 對象來管理應用在跨集群的分布。
基于 Virtual Kubelet：Virtual Kubelet 本質上是允許我們冒充 Kubelet 的行為來管理 virtual node 的機制。這個 virtual node 的背后可以是任何物件，只要 virtual node 能夠做到上報 node 狀態(tài)、和 pod 的生命周期管理。Liqo 就是通過定制的 virtual kubelet 來實現多集群管理。

KubeFed^[1]和Liqo^[2]都是開源項目，兩者的主要區(qū)別如下：

場景	Kubefed	Liqo
Pod 調度	靜態(tài)調度、動態(tài)調度只支持 Deployment/ReplicaSet	動態(tài)調度，但是還是會出現 pending 情況
控制平面	一套中心化管理組件	每個集群對等管理
集群發(fā)現	主動注冊	動態(tài)發(fā)現和注冊新集群

本文不會詳細介紹這些項目在部署和網絡管理的內容，重點分析兩個項目（Kubefed、Liqo）的跨集群資源調度。

KubeFed

KubeFed 的目的是通過統(tǒng)一的 API 管理多個 k8s 集群，實現單一集群管理多個 k8s 集群的機制，并通過 CRD 的機制來擴展現有的 k8s 資源跨集群編排的能力。

KubeFed 將集群分為 host cluster，member cluster 兩個角色：

host cluster：KubeFed 的控制平面面，用戶需要安裝 KubeFed 的 operator 組件。
member cluster：注冊到 KubeFed API 上的集群，由 KubeFed 統(tǒng)一管理。通過命令行??kubefedctl join 的??方式手動注冊到 host cluster。

被聯邦管理的 k8s API 資源統(tǒng)稱為 Federated Resources，例如 FederatedDeployments。開啟跨集群調度也需要在 host cluster 上顯式地對應用資源開啟集群聯邦管理，開啟的方式是通過 ??kubefedctl federate?? 創(chuàng)建 FederatedTypeConfig。KubeFed 也支持聯邦化 namespace，讓 namespace 下面的資源都聯邦化。通過 federation control plane 來下發(fā)資源到 member cluster。

kubefed-overview

KubeFed 概覽

資源調度

那 KubeFed 怎么支持跨集群部署的呢？在開啟資源的聯邦化之后，Federated Resources 的 spec 分成 3 個基礎配置 :

template：原資源類型的 spec
placement：定義期望部署的集群
overrides：定義集群特定配置，基于原資源類型的 spec 進行修改，比如副本數的變化

用戶在部署服務時，可以在 spec 下定義部署的集群（placement）和集群指定參數（overrides）。比如服務需要在 cluster2 集群上增加副本數，修改 deployment 的 replicas，需要在 overrides 上填寫“/spec/replicas”的修改。可以想到為了通用，overrides 的配置有一定復雜性。

spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      ...
  placement:
    clusters:
    - name: cluster2
    - name: cluster1
  overrides:
  - clusterName: cluster2
    clusterOverrides:
    - path: "/spec/replicas"
      value: 5
    ...

Federated Resources 還支持通過另一個 CRD 來 ReplicaSchedulingPreference 配置資源類型級別的集群調度傾向。該方法通過指定資源類型在 member cluster 的最大 / 最小副本數實現了依據剩余可用資源的動態(tài)平衡。最終 controller 會將 preference 信息更新到 Federated Resources 的 overrides 上，從而重新分配實例。不過該功能還只支持 deployment/replicaset 資源。

可以看出在 KubeFed 的架構，還是區(qū)分了不同集群的配置和動態(tài)調度。

具體看看靜態(tài)調度和動態(tài)調度。

靜態(tài)調度

首先，FederatedTypeConfig 的 spec 里定義了 host cluster 中的 Federated Resources 和 member cluster 集群的所代表的資源：

federatedType 定義在 host cluster 在多集群中的狀態(tài)的 API 資源類型（由用戶創(chuàng)建）
targetType 定義在 member cluster 集群代表 Federated Resources 的 API 資源類型（由 controller 創(chuàng)建）
statusType 用來更新 federated resource 的狀態(tài) (由 controller 創(chuàng)建，默認為 federatedType）

spec 對應的 federatedType 是定義的聯邦資源（由用戶創(chuàng)建），而 targetType 實際上是真正的 k8s workload 資源， KubeFed 的 controller 可以通過 federatedType 的 placement 和 overrides 來控制各個集群里的對應的 targetType 的資源的分布。具體來說，負責下發(fā) targetType 的 SyncController 會調用 dispatcher 生成 JSONPatch 并向 member cluster 創(chuàng)建底層資源。

kubefed-static-scheduling

KubeFed 靜態(tài)調度

默認創(chuàng)建 Federated 資源時，可以在 spec 下定義部署的集群（placement）和集群指定參數（overrides），實現多集群的 pod 分配。但是這種調度是靜態(tài)的。如果 overrides 設置的副本數超過集群剩余可用資源，那么新 pod 在集群里因為資源不夠導致 pending。靜態(tài)方式在大規(guī)模場景下無非是低效的，擴集群調度在極端情況下需要人工觀測集群剩余資源來規(guī)劃集群分布。但是很多服務是不需要感知集群信息的，他最在意的是還是服務實例能夠正常啟動，希望服務在不同集群的打散是一種動態(tài)被平臺托管的。所以 KubeFed 引入了 ReplicaSchedulingPreference（RSP）的功能。

RSP 的實現依賴于一個新的 CRD——ReplicaSchedulingPreference 關鍵的幾個配置項為：

totalReplicas：期望的副本數
rebalance：是否允許已調度的副本被重新平衡
intersectWithClusterSelector：是否結合 Fed Resources 的 placement 下定義的集群結合
clusters：定義各集群期望的最大最小副本數，以及分配權重

例如，下面這個例子期望 cluster1 和 cluster2 以 2:3 的比例下發(fā)服務的副本。當集群資源充足時，cluster1 會分配 4 個 pod，cluster2 被分配 6 個實例。當集群 cluster2 資源不足時，rebalance 的設置允許將 cluster2 的副本挪到 cluster1。

spec:
  targetKind: FederatedDeployment
  totalReplicas: 10
  rebalance: true
  intersectWithClusterSelector: false
  clusters:
   cluster1:
     weight: 2
   cluster2:
     weight: 3

下圖描述了 KubeFed RSP 的工作流程，起作用的組件是 ReplicaScheduler。

kubefed-rsp-sched

KubeFed ReplicaSchedulingPreference workflow

ReplicaScheduler 首先會獲取 PreferredClusters，將健康的集群的信息收集。然后獲取當前服務副本的集群分布，會統(tǒng)計每個集群的 currentReplicasPerCluster、estimatedCapacity：

currentReplicasPerCluster：集群內 running 并且 ready 的 pod 數量
estimatedCapacity：期望的副本數 spec.replicas - unschedulable 的 pod 數量

pod-unschedulable

ReplicaScheduler.Planner 依據上述信息（RSP 的 spec、currentReplicasPerCluster 和 estimatedCapacity），在可用集群中分配副本。Planner 的第一步會依據 ReplicaSchedulingPreference 中集群權重將可用集群排序，并劃定每個集群的可分配上界和下界：

下界：從 RSP 的 minReplicas 和 totalReplicas（totalReplicas 累減）、estimatedCapacity，三值中選擇最小的值作為每個集群的分配下界。
上界：如果 rebalance 未開啟：首先在 currentReplicasPerCluster 的數量、estimatedCapacity 和 RSP 的 maxReplicas 選擇最小值，作為集群可用數量的增量，每個集群的上界是下界+增量。

最終依據集群權重，將副本分配到各集群中。

ReplicaScheduler.Plugin 獲得新的 overrides 信息將原 Federated resources 的 spec 更新。之后的流程就是原有靜態(tài)調度負責下發(fā)到集群。整個 ReplicaSchedulingPreference 能夠動態(tài)地在多個集群分配 pod，并且包含了處理 Pending Pod 的情況。

但是局限在于只支持 Deployment/ReplicaSet 資源。

Liqo

與 KubeFed 相比，Liqo 有著 pod 無縫調度、去中心化治理等優(yōu)勢。

去中心化管理：采用 P2P 的對等管理，減少中心化管理組件。
無縫調度：創(chuàng)建用戶服務資源時，和單集群操作一致。

Liqo 將集群劃分為 home cluster 和 foreign cluster。在每個集群都需要安裝 liqo 的組件來管理多集群，這兩類集群本質上沒有區(qū)別。只是對于 home cluster 來說，其他的 foreign cluster 都是通過 Virtual Kubelet^[3] 的方式映射成本集群節(jié)點。home cluster 將 foreign cluster 當作一個大的節(jié)點來使用。這樣就能做到用戶在 home cluster 上創(chuàng)建資源時，能夠調度到 foregin cluster 上。Virutal Kubelet 具體的內容可以看這篇文章《Virtual Kubelet^[4]》。Virutal Kubelet 依據目的實現如下功能，就能在 k8s 集群內注冊一個虛擬的節(jié)點。

?
自定義的 provider 必須提供以下功能：
提供 pod、容器、資源的生命周期管理的功能
符合 virtual kubelet 提供的 API
不直接訪問 k8s apiserver，定義獲取數據的回調機制，例如 configmap、secrets

在集群注冊方面，Liqo 支持動態(tài)發(fā)現集群（mDNS、LAN 兩種方式）。在安裝 Liqo 組件時，可配置集群通過何種方式發(fā)現和集群共享出去的資源百分比（默認 30%）。所以 Liqo 的多集群前提是集群之間已經網絡可達。

Ligo 調度

在調度方面，因為 remote cluster 通過 virtual kueblet 將該集群視為一個大節(jié)點，可以直接依賴本集群的 kube-scheduler 來調度。但是這里還是有個問題。當 remote cluster 的資源碎片比較多時，大節(jié)點上報資源時會聚合成一個大塊資源。導致大套餐的 pod 調度到 remote cluster 會出現 pending。

Ligo 的工作流程如下圖所示 . 當用戶創(chuàng)建一個 deployment 時，默認調度器負責判斷能否調度到 virtual node 上。之后這個服務的 pod 創(chuàng)建會被 virtual kubelet 接管。當 pod 被調度的 virtual node 上時，virtual kubelet 會在 remote cluster 會對應的 replicaSet。使用 replicaSet 原因是 remote cluster 上的 pod 被驅逐時，能夠在集群上重建，而不是在 home cluster 重新調度。

liqo-pods-management

在了解多集群調度的細節(jié)之前，需要先弄清楚 virtual kubelet 的工作機制。我們知道 Kubelet 有個 SyncHandler, virtual kubelet 也有 PodLifecycleHandler，處理 pod 被 k8s 創(chuàng)建、更新、刪除的情況。例如，Liqo 的 virtual kubelet 處理創(chuàng)建 pod 時，會先將 pod 的元數據里包含 home cluster 的信息轉換成 foreign cluster (比如 label 和 namespace)，然后將 pod 包在 ReplicaSet 里通過 foreign Client 創(chuàng)建 ReplicaSet 資源。

上面介紹了一個 pod 在不同集群之間的映射。接下來從 foreign cluster 的角度發(fā)現 home cluster 的共享資源的具體流程。下屬 Controller 和 CRD 都是由 Liqo 安裝。

liqo-discovery

第一階段：發(fā)現 foreign cluster 并上報可用資源

DiscoveryController 是第一個集群注冊的 controller，DiscoveryController 發(fā)現并創(chuàng)建 foreignCluster 資源：通過 WAN/LAN 發(fā)現遠端集群，將 remote cluster 的信息填入 foreignCluster.spec，之后的 Controller 通過 foreignCluster 來獲取 remote cluster 的信息。
ForeignClusterController 監(jiān)聽 foreignCluster CR，并維護 remote cluster 的 identity 信息。這些信息用來構建 virtual kubelet，和 crdReplicator 使用。ForeignClusterController 通過 Authentication Service 向遠端的集群 ForeignAuthURL 驗證 remote cluster 的身份信息，并將集群的證書存儲在本地 secret。
ForeignClusterController 在確認 foreign cluster 期望 outgoingPeering（即 home cluster 可以分享資源給 foreign cluster 使用），會創(chuàng)建 resourceRequest CR（不包含具體資源，只有集群元數據 authURL，用作后續(xù)資源請求的處理）。ResourceRequestController 監(jiān)聽 resourceRequest CR，首先確保 foreignCluster 的 foreignCluster/tenant 資源存在；如果不存在則創(chuàng)建 CR，確保 ForeignAuthURL 是 resourceRequest.Spec.AuthURL。
ResourceRequestController 負責監(jiān)控本地資源，將需要更新共享資源配額的 remote cluster id 壓入 Broadcaster 組件的隊列里。將集群 Broadcaster 組件接著調用 OfferUpdater.Push 做資源同步。OfferUpdater 負責組裝 resourceOffer 里。resourceOffer 的 spec 保存集群的可共享資源，供遠端的 virtual kubelet 查詢。
并且 ResourceRequestController 還會監(jiān)聽本地 node/pod 事件，維護集群資源緩存（將 home cluster 全局可用資源，和 remote cluster 占用資源分開）。當達到更新閾值（默認 80%），也會主動調用 OfferUpdate.Push 更新可用資源。當創(chuàng)建 pod 時，集群資源減去 pod 資源；當 pod 有 remoteClusterId 標簽（vk 添加）時，會累加共享的 remote 集群的資源。做到區(qū)分本集群和 remote pod，當集群資源-pod 變化資源，會觸發(fā)更新。
最終 ResourceRequestController 的 OfferUpdater 按序處理 5、6 步 pushed 的 queue 里集群 id，獲取 home cluster 集群資源并更新 home 集群的 ResourceOffer 資源上限（offer.Spec.ResourceQuota.Hard）。計算公式：（本集群可用資源量 + remote cluster 的 pod 資源）* ResourceSharingPercentage（依據配置共享給遠端所有集群的資源）。

第二階段：virtual kubelet 監(jiān)聽 home cluster 的資源變化

從 foreign cluster 的角度，也會發(fā)現 home cluster 并創(chuàng)建相應的 foreign cluster。virtual kubelet 在 foreign cluster 注冊時，初始化 virtual-kubelet provider。在初始化的時候通過 foreignClusterID 拿到 home cluster 的 kubeClient Config（上一階段集群注冊時生成的 secret）。
LiqoNodeProvider 監(jiān)聽 resourceOffer 資源（通過 foreignClusterID 獲得自己的可用資源量）。從 offer 里的 ResourceQuota 中獲的 node 的資源的 Capacity 和 Allocatable 值并調用 onNodeChangeCallback。在 virtual kubelet 機制中，NodeProvider 是被上層 NodeController 調用 NotifyNodeStatus 方法，來監(jiān)控 virtual node 的變化。
實際的狀態(tài)更新由 NodeController 定義的回調函數將節(jié)點信息壓入 channel，NodeController 的控制循環(huán)實時異步地將資源變化向本集群的 api server 更新。

可以看到 home cluster 和 foreign cluster 沒有本質上的區(qū)別，兩者可以相互使用對方允許共享的機器資源。當然，集群 A 也可以配置成不貢獻自己的資源出去，只使用別的集群分享出來的資源。

總結

本文介紹了 KubeFed/Liqo 兩個開源項目多集群的資源管理和 pod 調度。

KubeFed 的資源調度總體上比較靜態(tài)，需要創(chuàng)建 workload 之前確保各集群有充足資源。它的動態(tài)調度能力有限，因為只能對 Deployment/ReplicaSet 開啟。當 KubeFed 下發(fā) pod 到集群出現 pod pending 的情況時，動態(tài)調度的能力能夠將 pod 遷移到其他集群。

Liqo 是能做到動態(tài)的資源發(fā)現和 pod 調度，但是它的方法是將一個集群抽象成一個工作節(jié)點。這種方式必然忽略了資源碎片的現象，使得虛擬節(jié)點的資源余量存在失真。比如集群內的 2 個節(jié)點共剩余 40 核可用資源，并不一定代表集群還能調度一個 40 核資源的 pod。但是從 Liqo 的方式來看，這個集群是能夠調度 40 核 pod 的。并且目前來看，如果集群內出現 pod pending 的情況，也沒法自動遷移 pod 到其他集群。

不過 Liqo 的整個思想是比較新穎的，通過對等的 P2P 方式將多個集群聚合成一個大的可用資源池。對于現有集群也不會引入一套新的 API。或許 Liqo 可以引入 descheduler 將 pending pod 遷移到其他機器來解決資源余量的誤差問題。

參考資料

A Brief History of Multicluster Kubernetes：https://www.tfir.io/a-brief-history-of-multicluster-kubernetes/
Simplifying multi-clusters in Kubernetes：https://www.cncf.io/blog/2021/04/12/simplifying-multi-clusters-in-kubernetes/
kubefed 簡介 :https://jimmysong.io/kubernetes-handbook/practice/federation.html
Unleashing the multi-cluster potential with Liqo:https://youtu.be/Ru-VrLcRXDg
Virtual Kubelet:https://www.huweihuang.com/kubernetes-notes/virtual-kubelet/virtual-kubelet.html

引用鏈接

[1]KubeFed: https://github.com/kubernetes-sigs/kubefed

[2]Liqo: https://github.com/liqotech/liqo

[3]Virtual Kubelet: https://github.com/virtual-kubelet/virtual-kubelet

[4]Virtual Kubelet: https://www.huweihuang.com/kubernetes-notes/virtual-kubelet/virtual-kubelet.html

責任編輯：龐桂玉來源：奇妙的Linux世界

Kubernetes Linux