夏令明，周 俊，趙 鋒

(網(wǎng)絡(luò)通信與安全紫金山實(shí)驗(yàn)室 未來網(wǎng)絡(luò)研究中心，江蘇 南京 211111)

0 引言

單Kubernetes[1]集群無法滿足邊緣、地域、資源管理等需求，因此在東數(shù)西算等典型多集群場景中[2]，將不得不解決集群的接入控制、集群資源抽象、權(quán)限管理、應(yīng)用管理、多集群調(diào)度、服務(wù)維持、多租戶以及多集群服務(wù)發(fā)現(xiàn)等問題[3-5]，這大大增加了多集群方案的復(fù)雜性和難度。目前社區(qū)和業(yè)界，集群拓?fù)渚愿缸觾蓪蛹軜?gòu)為主，父集群作為主控集群，其余集群為子集群，用于承載工作負(fù)載，其中主流的有Kubefed[6-7]聯(lián)邦方案、Karmada[8]、Clusternet[9]、Admiralty[10]四種。

Kubefed和 Karmada是一類，它們通過Template、Overide、Propgation 等定義負(fù)載的通用配置、專有配置和調(diào)度策略。Karmada 自Kubefederation發(fā)展而來，但是支持更豐富的插件化調(diào)度能力以及多集群服務(wù)(Multi cluster service)等特性，Karmada 也順利成為CNCF基金會孵化項(xiàng)目。但是這二者僅支持中心式的兩層架構(gòu)，擴(kuò)展性和承載力都存在理論瓶頸。

Clusternet 項(xiàng)目是一個(gè)踐行了OCM模型的多集群方案，也入選了CNCF沙箱項(xiàng)目，子集群通過受控的Token，在子集群啟動時(shí)，接入到父集群之中。父集群通過Aggregated API的方式對所有原生Kubernetes資源進(jìn)行轉(zhuǎn)義形成Manifest文件推送到子集群中，Clusternet 同樣只能支持兩層架構(gòu)，也存在上述擴(kuò)展性的問題。

Admiralty 是一種多層調(diào)度模型，它達(dá)到了在使用多集群時(shí)和單集群一樣的體驗(yàn)，特點(diǎn)是把負(fù)載依賴根據(jù)Pod 跟隨調(diào)度，支持軟件定義搭建多集群架構(gòu)，但對應(yīng)用沒有做任何抽象，所有的概念都是Kubernetes原生的。Admiralty在分布式云場景中難以實(shí)現(xiàn)應(yīng)用的有效管理與維護(hù)。

以上四種方案，前三種無法實(shí)現(xiàn)多層自組織架構(gòu)，這無法滿足擴(kuò)展性要求，而東數(shù)西算等真實(shí)的組織架構(gòu)一定是分層的。Admiralty 沒有對應(yīng)用做抽象，只能基于Kubernetes 的調(diào)度框架去改造。為解決這些問題，本文提出了一種彈性的可自組織的多集群管理方案Gaia。

1 Gaia分布式云方案的設(shè)計(jì)

1.1 分布式云系統(tǒng)設(shè)計(jì)需要解決四個(gè)核心問題

(1)集群組織層級靈活多變

集群組織關(guān)系，即集群之間的關(guān)聯(lián)關(guān)系，也即它們是如何被組織在一起的，常見的模型有中心式、分布式、樹狀等。

(2)應(yīng)用描述復(fù)雜

應(yīng)用如何被抽象至關(guān)重要，它決定了調(diào)度的最小單元以及如何看待應(yīng)用負(fù)載，例如Clusternet中的應(yīng)用是Subscription，Admiralty的應(yīng)用就是原生Pod。

(3)不依賴集群層級的調(diào)度器設(shè)計(jì)

調(diào)度器的設(shè)計(jì)依賴于集群組織模型，兩層架構(gòu)的模型調(diào)度器就要求每層不同，但如果是N層模型，調(diào)度器就應(yīng)該輸入輸出一致，這樣才能保證集群組織的靈活性。

(4)跨集群服務(wù)快速準(zhǔn)確發(fā)現(xiàn)

應(yīng)用被多集群部署后，需要快速準(zhǔn)確地實(shí)施服務(wù)訪問，目前多集群方案均以集成為主，比如Admiralty集成了GSLB；早期Kubefed自研的Multi-Cluster Ingress DNS，后續(xù)陸續(xù)移除，并改為集成社區(qū)其他多集群服務(wù)發(fā)現(xiàn)的方案比如Istio；Karmada和Clusternet社區(qū)均集成Multi Cluster Service。

本文針對上述的第(1)、(3)個(gè)問題，提出彈性自組織的集群管理方法和多集群場景下的冪等分層調(diào)度方案。

1.2 概念

(1)集群關(guān)系

從軟件定義的理念出發(fā)，定義一個(gè)文件來描述集群兩兩之間的從屬關(guān)系，如圖1所示。其中Target描述了父集群的訪問方式和加入集群所需要的Bootstap Token。這樣可以將集群組成所期望的任意結(jié)構(gòu)。需要說明的是，集群之間可以是雙向的，也可以是指向自己的。

圖1 集群關(guān)系圖

(2)常見拓?fù)浣Y(jié)構(gòu)

①主備模式

主備模式中，子集群的Target指向父集群，同時(shí)父集群的Target 也指向自己，如圖2所示。這種模式可以將應(yīng)用天然地配置到兩個(gè)集群中，是一種非常簡單的高可用模式，適合規(guī)模很小的環(huán)境，配置簡單。

圖2 主備模式

②去中心化模式

該模式中，所有的集群既是父集群又是子集群，如圖3所示。這種去中心化的結(jié)構(gòu)中，集群是Peer-to-Peer的關(guān)系，相較于主備模式該結(jié)構(gòu)具有更強(qiáng)的穩(wěn)定性和安全性。

圖3 去中心化模式

③中心式模式

這種方式有一個(gè)父集群做主控集群，托管N個(gè)子集群，如圖4所示。它適合中等規(guī)模的基礎(chǔ)設(shè)施環(huán)境，層級較少，管理簡單，但是拓展能力有限。

圖4 中心式模式

④樹狀模式

集群間根據(jù)Target 的指向，組成一個(gè)有層級的樹狀結(jié)構(gòu)，如圖5所示。該結(jié)構(gòu)適用于“云邊端”的復(fù)雜場景中，依靠冪等的分層調(diào)度器，可以輕松管理多云多廠商組成的大型且高復(fù)雜度的集群結(jié)構(gòu)。

(3)冪等的分層調(diào)度器

在管控分布式云基礎(chǔ)設(shè)施時(shí)，無論采用哪種拓?fù)淠Ｐ停珿aia控制器都不區(qū)分自己是什么位置。調(diào)度器的設(shè)計(jì)也必須堅(jiān)持輸入輸出一致，這樣帶來的好處是，集群間的結(jié)構(gòu)可以隨時(shí)變化，當(dāng)有新的集群加入時(shí)，自己變成了父節(jié)點(diǎn)，但是它同時(shí)又是其他集群的子集群，所以每一個(gè)集群的組件都是一樣的。

1.3 Gaia分布式云調(diào)度設(shè)計(jì)

Gaia的控制面由Scheduler 和 Controller兩部分組成，如圖6所示。它的每一層集群所關(guān)注的資源只有輸入和輸出兩部分，其中調(diào)度器的輸入和輸出類型一樣，都是一種叫做APP的CRD資源，經(jīng)過調(diào)度以后APP中會附加更詳細(xì)的調(diào)度結(jié)構(gòu)信息。需要說明的是，在葉子集群上的調(diào)度器不對APP做任何調(diào)度處理，因?yàn)樽畹讓拥恼{(diào)度邏輯交給Kubernetes。

圖6 Gaia控制面圖

(1)Scheduler：只會把資源調(diào)度在注冊到自己的子集群中，所有調(diào)度器輸入和輸出都是APP。

(2)Controller：控制器包括集群注冊控制器、注冊審批控制器、狀態(tài)上報(bào)控制器、MCS(Multi Cluster Service)控制器等。

(3)Binder：僅在葉子集群發(fā)揮作用，當(dāng)Binder發(fā)現(xiàn)APP調(diào)度成功且沒有子集群的時(shí)候，就把調(diào)度結(jié)果綁定到本集群。

2 方案功能實(shí)現(xiàn)

2.1 集群接入

葉子集群只用于承載工作負(fù)載，并不需要對外暴露公網(wǎng)地址，集群均為主動接入，資源同步采取Pull的模式。Gaia會被安裝在每一個(gè)集群中，等待Target資源指示如何接入Field集群，其接入過程如圖7所示。

圖7 集群接入

(1)子集群Gaia組件啟動后，循環(huán)等待Target對象部署，期間不影響集群功能；

(2)部署Target對象后，本集群發(fā)起集群注冊過程，注冊為目標(biāo)集群的子集群；

(3)在Parent Cluster創(chuàng)建命名空間(Namespace)、訪問規(guī)則(RBAC)、訪問賬戶(SA)、集群管理資源等，由Parent Cluster進(jìn)行集群注冊審批；

(4)子集群持續(xù)等待審批結(jié)果，審批通過后便可拿到相應(yīng)父集群的訪問權(quán)限，注冊為子集群。

一個(gè)典型的Target對象如表1所示，它包含父集群的地址、接入時(shí)的BootStrap Token以及本集群在父集群中的名字和一些其他信息。

表1 Target 對象

2.2 集群資源統(tǒng)計(jì)

集群接入后，子集群會根據(jù)上一步中Target配置的“reportFrequency”定時(shí)上報(bào)本集群的資源使用情況和結(jié)點(diǎn)的標(biāo)簽匯總，這些信息被稱作Scheduler Cache。

2.3 APP資源調(diào)度

以三層的樹狀模型為例，每一個(gè)子集群在父集群中存在一個(gè)執(zhí)行命名空間，在父集群接收到調(diào)度任務(wù)以后，會根據(jù)子集群上報(bào)的Scheduler Cache做基于水位的副本調(diào)度，每一級調(diào)度器都會經(jīng)歷一系列插件，如圖8所示，不同層的插件沒有依賴關(guān)系。

圖8 APP調(diào)度插件圖

完整的調(diào)度流程如圖9所示，在Binder判斷自己不存在子集群的時(shí)候，就會把本集群的調(diào)度結(jié)果推送到本集群，Binder的綁定過程比較簡單，不再詳述。

圖9 Gaia系統(tǒng)架構(gòu)圖

該調(diào)度器的優(yōu)點(diǎn)是：

(1)調(diào)度速度快，每一層都只負(fù)責(zé)自己當(dāng)前層的調(diào)度；

(2)資源可以無限拓展，管理海量集群；

(3)拓?fù)浣Y(jié)構(gòu)靈活改動，應(yīng)對多變的基礎(chǔ)設(shè)施；

(4)調(diào)度插件靈活可配。

缺點(diǎn)是資源上報(bào)信息粒度大，且沒有預(yù)占，集群高負(fù)載情況下會存在調(diào)度失敗的情況。

3 試驗(yàn)驗(yàn)證

基于以上描述，對集群注冊、分層調(diào)度器進(jìn)行驗(yàn)證。本文借助Kind工具部署1個(gè)Global集群、2個(gè)Field集群，每個(gè)Field下部署60個(gè)Cluster集群，搭建一個(gè)多集群的樹狀集群網(wǎng)絡(luò)的復(fù)雜基礎(chǔ)設(shè)施計(jì)算平臺，如圖10所示。

圖10 樹狀集群網(wǎng)絡(luò)結(jié)構(gòu)

(1)集群準(zhǔn)備

創(chuàng)建Kubernetes集群，在每一個(gè)集群上部署Gaia組件，這些Gaia組件還沒有通過Target資源去指定集群間關(guān)系，此時(shí)每一個(gè)集群都處于等待狀態(tài)。

(2)制作并創(chuàng)建Target

不同的集群依據(jù)Target對象文件，將本集群注冊為其他集群的子集群，其具體參數(shù)如表1所示。更改表中的“clusterName”為本集群提供唯一的注冊集群名稱；使用父集群的“parenturl”和“bootstraptoken”用于確認(rèn)接入父集群的地址。

(3)集群狀態(tài)

除Global集群外，其他集群按圖10所示通過部署Target接入父集群，可以在各層查看管理的集群。集群注冊時(shí)延如圖11所示。在已有126個(gè)集群的規(guī)模下，集群的注冊延遲保持穩(wěn)定在1 s。

圖11 集群注冊時(shí)延

作為對比，Karmada 方案做兩層集群管理模型時(shí)，其P50即中位數(shù)集群接入時(shí)間為5 356 ms[11]，本方案的集群注冊時(shí)延遲穩(wěn)定為1 012 ms。

(4)執(zhí)行案例調(diào)度

在Global集群上部署應(yīng)用，其應(yīng)用調(diào)度時(shí)延如圖12所示，在126個(gè)集群的規(guī)模之下，應(yīng)用平均調(diào)度延遲不高于200 ms，這里不包含資源創(chuàng)建的時(shí)間消耗。

圖12 應(yīng)用調(diào)度時(shí)延

作為對比Karmada 的測試報(bào)告中提到，資源分發(fā)的用戶在聯(lián)邦控制面提交資源模板和下發(fā)策略后到資源在成員集群上被創(chuàng)建的P99時(shí)延，不考慮控制面與成員集群之間的網(wǎng)絡(luò)波動，P99≤2 s。

最后在Cluster級別集群上進(jìn)行應(yīng)用的綁定部署，提供相應(yīng)服務(wù)。

4 結(jié)束語

本文分析了目前分布式云/多集群領(lǐng)域的研究現(xiàn)狀，并剖析了熱門開源社區(qū)的相關(guān)項(xiàng)目的特點(diǎn)，進(jìn)一步歸納總結(jié)了分布式云系統(tǒng)設(shè)計(jì)面臨的4個(gè)核心問題。針對這些問題，提出了一種多層級、可軟件定義的多集群管理方案。它的每層調(diào)度邏輯都是冪等的。通過實(shí)際模擬126個(gè)超大規(guī)模的集群環(huán)境，驗(yàn)證了該方案的可行性，試驗(yàn)結(jié)果表明這種方案理論上可以無限擴(kuò)展集群連接，同時(shí)保持應(yīng)用調(diào)度和集群擴(kuò)展的延遲保持在合理可用范圍，是東數(shù)西算等分布式云場景下的一種理想架構(gòu)。

然而，多集群調(diào)度平臺不僅僅需要關(guān)注集群資源管理、負(fù)載調(diào)度的效率等問題，還要考慮應(yīng)用抽象、多集群服務(wù)發(fā)現(xiàn)、多集群負(fù)載均衡等問題，目前這部分有一些解決方案，比如sigs/mcs-api、GSLB、Submariner等項(xiàng)目，后續(xù)工作需要繼續(xù)研究創(chuàng)新，使Gaia多集群方案功能得到進(jìn)一步完善。