作者 | vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-Zhang Rong

Karmada作為開(kāi)源的云原生多云容器編排項(xiàng)目，吸引了眾多企業(yè)共同參與項(xiàng)目開(kāi)發(fā)，并運(yùn)行于生產(chǎn)環(huán)境中。同時(shí)多云也逐步成為數(shù)據(jù)中心建設(shè)的基礎(chǔ)架構(gòu)，多區(qū)域容災(zāi)與多活、大規(guī)模多集群管理、跨云彈性與遷移等場(chǎng)景推動(dòng)云原生多云相關(guān)技術(shù)的快速發(fā)展。

一、 背景

隨著vivo業(yè)務(wù)不斷遷移到k8s上，集群規(guī)模和集群的數(shù)量快速增長(zhǎng)，運(yùn)維難度也急劇增加。為了構(gòu)建多集群技術(shù)，我們也自研了多集群管理，但無(wú)法解決我們遇到的更多的問(wèn)題。后來(lái)開(kāi)始對(duì)社區(qū)相關(guān)項(xiàng)目做了細(xì)致的調(diào)研和測(cè)試，我們最終選擇了Karmada。

主要原因如下：

• 具備對(duì)多套K8s集群的統(tǒng)一管理能力，業(yè)務(wù)通過(guò)服務(wù)維度去管理資源，降低容器平臺(tái)的管理難度。
• 跨集群的彈性伸縮和調(diào)度能力，實(shí)現(xiàn)跨集群的資源合理利用，從而提升資源利用率并節(jié)約成本。
• Karmada完全使用了K8s原生的API，改造成本低。
• 容災(zāi)，Karmada控制平面與member集群解藕，集群異常時(shí)支持資源重新分配。
• 可擴(kuò)展性，如可以添加自研的調(diào)度插件和添加自研Openkruise解釋器插件等。

在我們探索怎么使用Karmada的同時(shí)，我們也遇到了Karmada自身運(yùn)維的問(wèn)題。

社區(qū)部署工具較多，需要用戶自己選擇。當(dāng)前用戶部署方式如下：

• Karmadactl
• Karmada charts
• 二進(jìn)制部署
• hack目錄下腳本

對(duì)于上面的幾種工具，在Karmada的社區(qū)開(kāi)展了問(wèn)卷調(diào)研?，并生成了統(tǒng)計(jì)報(bào)告。

主要總結(jié)如下：

• 社區(qū)部署工具較多，需要用戶自己選擇。
• 部署腳本也存在缺陷，需要用戶自己解決，github上關(guān)于這方面的提問(wèn)較多。
• 黑屏化操作，沒(méi)有提供k8s api操作，用戶難以產(chǎn)品化，我們主要期望對(duì)接我們的容器平臺(tái)，實(shí)現(xiàn)可視化安裝。
• 缺少CI測(cè)試和部署工具的發(fā)布計(jì)劃。
• etcd集群缺少生產(chǎn)環(huán)境的關(guān)鍵功能點(diǎn)，如etcd的高可用、定期備份和恢復(fù)。
• 需要安裝很多依賴插件，涉及到Karmada控制平面、Karmada的host集群和member集群。
• 缺少一鍵部署和配置繁瑣等痛點(diǎn)。

針對(duì)以上問(wèn)題，本文將分享Karmada-Operator的vivo實(shí)踐，包括Operator的方案選擇、API、架構(gòu)設(shè)計(jì)和CI構(gòu)建等。?

二、Karmada-Operator的落地實(shí)踐

2.1 Operator SDK介紹

Operator Framework 是一個(gè)開(kāi)源工具包，用于以有效、自動(dòng)化且可擴(kuò)展的方式管理 Kubernetes 原生應(yīng)用程序，即 Operator。Operator 利用 Kubernetes 的可擴(kuò)展性來(lái)展現(xiàn)云服務(wù)的自動(dòng)化優(yōu)勢(shì)，如置備、擴(kuò)展以及備份和恢復(fù)，同時(shí)能夠在 Kubernetes 可運(yùn)行的任何地方運(yùn)行。

Operator 有助于簡(jiǎn)化對(duì) Kubernetes 上的復(fù)雜、有狀態(tài)的應(yīng)用程序的管理。然而，現(xiàn)在編寫(xiě) Operator 并不容易，會(huì)面臨一些挑戰(zhàn)，如使用低級(jí)別 API、編寫(xiě)樣板文件以及缺乏模塊化功能（這會(huì)導(dǎo)致重復(fù)工作）。

Operator SDK 是一個(gè)框架，通過(guò)提供以下內(nèi)容來(lái)降低 Operator 的編寫(xiě)難度：

• 高級(jí) API 和抽象，用于更直觀地編寫(xiě)操作邏輯
• 支架和代碼生成工具，用于快速引導(dǎo)新項(xiàng)目
• 擴(kuò)展項(xiàng)，覆蓋常見(jiàn)的 Operator 用例

如上圖所示，operator sdk可以基于helm、ansilbe和go構(gòu)建operator，我們需根據(jù)當(dāng)前的情況選擇我們合適的operator框架。

2.2 方案選擇

• 方案一：golang 開(kāi)發(fā)Operator

• 方案二：ansible開(kāi)發(fā)Operator

• 方案三：golang和ansible混合開(kāi)發(fā)Operator

根據(jù)Karmada的實(shí)際生產(chǎn)部署調(diào)研情況和vivo自身的實(shí)踐，可以總結(jié)如下：

1. 要支持在K8s集群和不依賴K8s集群二進(jìn)制部署。
2. 支持外部獨(dú)立的etcd集群部署或者對(duì)接已有的etcd集群。
3. Karmada集群具備遷移能力，如機(jī)房裁撤和機(jī)器故障等，就需要etcd集群管理有備份和恢復(fù)能力，如根據(jù)etcd備份數(shù)據(jù)快速在其它機(jī)房恢復(fù)集群。
4. 需要支持第三方的vip給Karmada-apiserver提供負(fù)載均衡，目前vivo都是基于外部vip，并提供了域名。沒(méi)有使用K8s的service給Karmada-apiserver提供負(fù)載均衡。
5. Karmada控制平面一鍵部署和member集群的自動(dòng)化注冊(cè)和注銷。也需要獲取member集群的kubeconfig，pull模式也需要在member集群部署Karmada-agent。
6. Karmada集群的addons插件安裝，如istio、anp、第三方的crd等安裝，需要在Karmada的控制平面、host主機(jī)集群，甚至需要在member集群上進(jìn)行配置。
7. 提供api能力，實(shí)現(xiàn)可視化部署。
8. 針對(duì)Karmada單個(gè)組件的單獨(dú)升級(jí)和全量升級(jí)。
9. 支持在offline和離線模式。

面對(duì)Karmada如此復(fù)雜的條件限制，我們?cè)賮?lái)分析下上面3個(gè)方案誰(shuí)可能比較合適。

方案一，基于go開(kāi)發(fā)的Operator，比較適合基于K8s集群的有狀態(tài)服務(wù)管理，如etcd，數(shù)據(jù)庫(kù)等，比較成熟的有etcd-Operator。Karmada涉及到不依賴K8s集群二進(jìn)制部署、外部etcd、member集群的注冊(cè)、注銷和插件安裝，不能很好的支持或者需要增加開(kāi)發(fā)量。

方案二，基于ansible開(kāi)發(fā)的Operator，既可以基于K8s集群的對(duì)狀態(tài)服務(wù)管理，也可以脫離K8s集群對(duì)如不依賴K8s集群二進(jìn)制部署、外部etcd、member集群的注冊(cè)、注銷和插件安裝。這里主要通過(guò)ansible 的ssh登錄能力和K8s模塊管理，通過(guò)調(diào)研我們也發(fā)現(xiàn)90%以上的用戶可以提供ssh登錄。

方案三，基于go+ansible的混合的Operator，讀者可以閱讀vivo開(kāi)發(fā)的Kubernetes-Operator，就是基于這種方案。方案三具備方案二的所有能力，因?yàn)榈讓佣际峭ㄟ^(guò)ansible去執(zhí)行。

首先我們排除了方案一，對(duì)于方案二和方案三，本人也糾結(jié)了很長(zhǎng)是時(shí)間，最終我們選擇了方案二。主要原因如下：

1. Operator SDK ansible已具備了和Operator SDK go相等的能力，并提供K8s、K8s_status模塊、相似的webhook功能去對(duì)k8s的資源管理，以及reconciliation的能力。
2. 符合目前Karmada實(shí)際生產(chǎn)部署的需求。
3. 簡(jiǎn)單易學(xué)，只要知道ansbile的jinja模版、和K8s相同的yaml文件。你只需要編寫(xiě)ansible task，開(kāi)箱即用，reconciliation由Operator SDK 解決。
4. 對(duì)于常用ansible的人比較友好，不需要寫(xiě)golang代碼。
5. 擴(kuò)展能力強(qiáng)，用戶可自定義插件。管理端也支持local、ssh、zeromq三種方式連接。local模式可以直接對(duì)接K8s接口，ssh模式可以登錄執(zhí)行腳本?？梢院芎玫幕旌鲜褂茫鉀Q我們當(dāng)前的需求。
6. Karmada運(yùn)維操作相對(duì)K8s要簡(jiǎn)單，不需要復(fù)雜的crd定義，ansible需要解析少量vars去執(zhí)行playbook就行。golang+ansible模式比較適合復(fù)雜CRD定義和業(yè)務(wù)邏輯復(fù)雜的系統(tǒng)。

2.3 API設(shè)計(jì)

如上圖所示，我們只需要執(zhí)行Operator-SDK create api命令，就可以創(chuàng)建 KarmadaDeployment的CRD，然后就可以定義KarmadaDeployment的API。在watches.yaml里實(shí)現(xiàn)Reconcile的業(yè)務(wù)邏輯。

這里主要定義KarmadaDeployment、EtcdBackup和EtcdRestore個(gè)資源，分別用于Karmada的部署，和etcd的數(shù)據(jù)備份和恢復(fù)。ansible Operator會(huì)根據(jù)spec里定義解析成ansible的vars。status將通過(guò) ansible runner 輸出為用戶自定義的狀態(tài)。也可以通過(guò)ansible的k8s_status更新KarmadaDeployment的狀態(tài)。當(dāng)前主要考慮的是在K8s運(yùn)行Karmada，后面會(huì)添加二進(jìn)制部署模式，當(dāng)前的CR沒(méi)有涉及。

2.4 架構(gòu)設(shè)計(jì)

如圖所示Karmada Operator提供了容器化和二進(jìn)制集群部署設(shè)計(jì)，其中Karmada的容器化部署不需要執(zhí)行ssh登錄，只需通過(guò)K8s和k8s_status就可以完成karmada控制面的管控。Karmada的二進(jìn)制部署主要通過(guò)ssh登錄完成Karmada控制平面的管控。member集群的join和unjoin需要提前提供member集群的kubeconfig文件，也可以設(shè)置member的登錄權(quán)限操作，需要在CR里定義member集群的用戶和密鑰。

執(zhí)行流程如下。

1. 用戶通過(guò)KarmadaDeployment定義Karmada操作
2. Karmada Operator感知KarmadaDeployment的CR變化，開(kāi)始進(jìn)入控制器邏輯
3. 根據(jù)用戶的定義，選擇是容器化部署或者二進(jìn)制部署，開(kāi)始執(zhí)行安裝、擴(kuò)所容和備份等操作
4. 執(zhí)行join/unjoin操作，將member集群注冊(cè)到Karmada集群或者注銷member集群

2.5 Karmada控制平面管理

如上圖所示，主要是karmada控制平面生命周期管理，對(duì)比當(dāng)前社區(qū)的部署工具我們?nèi)缦聝?yōu)化：

1. 標(biāo)準(zhǔn)化證書(shū)管理，主要是用openssl生成證書(shū)。其中etcd和Karmada證書(shū)單獨(dú)分開(kāi)維護(hù)，和k8s集群證書(shū)命名相同，方便接入我們的監(jiān)控。
2. Karmada-apiserver支持外部負(fù)載均衡，不限于當(dāng)前的k8s service提供的負(fù)載均衡。
3. 更靈活的升級(jí)策略，支持單獨(dú)組件升級(jí)和全量升級(jí)。
4. 更豐富的全局變量定義，計(jì)劃支持組件配置變更等。

2.6 etcd集群管理

etcd集群是Karmada的元數(shù)據(jù)集群,生產(chǎn)中需要保證etcd集群高可用和故障恢復(fù)等。如上圖展示了etcd集群必要的生產(chǎn)要素，如自動(dòng)擴(kuò)縮容、升級(jí)、備份和etcd集群的故障恢復(fù)。自研了基于ansible的plugins和library, 實(shí)現(xiàn)etcd集群管理能力如下：

1. 添加member到存在的etcd集群。
2. etcd集群刪除member。
3. etcd集群的備份，比如支持cephfs的數(shù)據(jù)備份。
4. etcd集群故障恢復(fù)。
5. etcd集群健康狀態(tài)查詢。

這里定義了etcdBackup和etcdRestore的CR，沒(méi)有合并到KarmadaDeployment里。主要考慮到etcd集群本身操作的安全性和簡(jiǎn)化KarmadaDeployment的ansible任務(wù)。其中etcdRestore功能，可以根據(jù)etcd集群備份數(shù)據(jù)，實(shí)現(xiàn)導(dǎo)入到新的etcd集群，從而恢復(fù)Karmada集群所有的業(yè)務(wù)狀態(tài)。當(dāng)前主要場(chǎng)景如下：

1. Karmada集群所在的機(jī)房裁撤，需要備份etcd數(shù)據(jù)，遷移到新的Karmada集群。
2. 期望通過(guò)Karmada-Operator管理Karmada集群，只需備份etcd數(shù)據(jù)，實(shí)現(xiàn)etcdRestore功能即可。
3. Karmada集群故障，可以通過(guò)etcd備份數(shù)據(jù)，結(jié)合etcdRestroe實(shí)現(xiàn)故障恢復(fù)。

2.7 member集群管理

member集群的生命周期管理主要有注冊(cè)和注銷，上圖是執(zhí)行的流程。為了處理member集群的注冊(cè)和注銷，這里會(huì)動(dòng)態(tài)的生成inventory。Ansible Inventory 是包含靜態(tài) Inventory 和動(dòng)態(tài) Inventory 兩部分的，靜態(tài) Inventory 指的是在文件中指定的主機(jī)和組，動(dòng)態(tài) Inventory 指通過(guò)外部腳本獲取主機(jī)列表，并按照 ansible 所要求的格式返回給 ansilbe 命令的。

這里Karmada-Operator基于k8s的CR實(shí)現(xiàn)了動(dòng)態(tài)inventory plugins，主要通過(guò)解析KarmadaDeployment的members定義去動(dòng)態(tài)的生成inventory。這里添加了add-member和del-member 2個(gè)角色， add-member里集群會(huì)被注冊(cè)到Karmada控制平面，del-member里的集群會(huì)被從Karmada控制平面注銷，這樣就可以并發(fā)的注冊(cè)和注銷多個(gè)member集群。同時(shí)也可以提供ssh登錄模式，方便后期擴(kuò)展。

三、Karmada-Operator的CI介紹

為了更好的提高開(kāi)發(fā)人員的體驗(yàn)，計(jì)劃提供Karmada-Operator的CI構(gòu)建能力。這里在K8s集群里部署github的self-hosted Runner和kubevirt。

1. 用戶在github上提交PR
2. 觸發(fā)github Actions，我們?cè)趕elf-hosted里定義的流程
3. 執(zhí)行語(yǔ)法和單元測(cè)試
4. 通過(guò)kubevirt創(chuàng)建vm
5. 在多個(gè)vm里部署1個(gè)host和2個(gè)member集群
6. 部署Karmada和添加member集群
7. 執(zhí)行Karmada e2e和bookfinfo案例測(cè)試

計(jì)劃添加的CI矩陣測(cè)試如下：

語(yǔ)法測(cè)試：

• ansible-lint
• shellcheck
• yamllint
• syntax-check
• pep8

集群部署測(cè)試：

• Karmadactl、charts、yaml和二進(jìn)制部署和所有配置項(xiàng)安裝測(cè)試
• join/ unjoin member 集群
• 升級(jí)Karmada
• etcd集群的備份和恢復(fù)

功能測(cè)試：

• Karmada e2e測(cè)試
• 創(chuàng)建bookinfo案例

性能測(cè)試：

我們主要通過(guò)kubemark組件模擬了多個(gè)2000節(jié)點(diǎn)的member集群進(jìn)行了性能測(cè)試，其中一個(gè)測(cè)試案例是集群故障轉(zhuǎn)移，結(jié)論是4w個(gè)無(wú)狀態(tài)pod能夠在15分鐘完成故障遷移，有機(jī)會(huì)可以分享我們的性能測(cè)試。

四、總結(jié)

通過(guò)社區(qū)的調(diào)研和vivo的實(shí)踐，最終確定了Karmada-Operator方案設(shè)計(jì)。Karmada-Operator具有高度可擴(kuò)展性、可靠性、更直觀地編寫(xiě)操作邏輯和開(kāi)箱即用等特點(diǎn)，我們相信通過(guò)這種高度可擴(kuò)展的聲明式、自我修復(fù)云原生系統(tǒng)管理Karmada，為我們?nèi)媲袚Q到Karmada去管理業(yè)務(wù)提供了強(qiáng)有力可靠保障。

基于ansible的operator也存在如下缺點(diǎn)。第一點(diǎn)沒(méi)有提供webhook的能力，需要自己添加或者在ansible的task添加相關(guān)的校驗(yàn)；第二點(diǎn)是自動(dòng)生成了通用的CRD模版，沒(méi)有詳細(xì)可定義的腳手架工具去自動(dòng)生成CRD。

當(dāng)前Karmada-operator還在初始階段，提供了方案和部分實(shí)踐，具體功能還需不斷的完善和改進(jìn)。具體可以查看vivo的Karmada-Operato?r倉(cāng)庫(kù),歡迎大家試用和提建議。當(dāng)前代碼提供的能力矩陣可以查看項(xiàng)目規(guī)劃。