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

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

一、 背景

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

主要原因如下：

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

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

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

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

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

主要總結(jié)如下：

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

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

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

2.1 Operator SDK介紹

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

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

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

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

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

2.2 方案選擇

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

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

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

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

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

面對Karmada如此復(fù)雜的條件限制，我們再來分析下上面3個方案誰可能比較合適。

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

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

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

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

1. Operator SDK ansible已具備了和Operator SDK go相等的能力，并提供K8s、K8s_status模塊、相似的webhook功能去對k8s的資源管理，以及reconciliation的能力。
2. 符合目前Karmada實(shí)際生產(chǎn)部署的需求。
3. 簡單易學(xué)，只要知道ansbile的jinja模版、和K8s相同的yaml文件。你只需要編寫ansible task，開箱即用，reconciliation由Operator SDK 解決。
4. 對于常用ansible的人比較友好，不需要寫golang代碼。
5. 擴(kuò)展能力強(qiáng)，用戶可自定義插件。管理端也支持local、ssh、zeromq三種方式連接。local模式可以直接對接K8s接口，ssh模式可以登錄執(zhí)行腳本?？梢院芎玫幕旌鲜褂?，解決我們當(dāng)前的需求。
6. Karmada運(yùn)維操作相對K8s要簡單，不需要復(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個資源，分別用于Karmada的部署，和etcd的數(shù)據(jù)備份和恢復(fù)。ansible Operator會根據(jù)spec里定義解析成ansible的vars。status將通過 ansible runner 輸出為用戶自定義的狀態(tài)。也可以通過ansible的k8s_status更新KarmadaDeployment的狀態(tài)。當(dāng)前主要考慮的是在K8s運(yùn)行Karmada，后面會添加二進(jìn)制部署模式，當(dāng)前的CR沒有涉及。

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

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

執(zhí)行流程如下。

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

2.5 Karmada控制平面管理

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

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

2.6 etcd集群管理

etcd集群是Karmada的元數(shù)據(jù)集群,生產(chǎn)中需要保證etcd集群高可用和故障恢復(fù)等。如上圖展示了etcd集群必要的生產(chǎn)要素，如自動擴(kuò)縮容、升級、備份和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，沒有合并到KarmadaDeployment里。主要考慮到etcd集群本身操作的安全性和簡化KarmadaDeployment的ansible任務(wù)。其中etcdRestore功能，可以根據(jù)etcd集群備份數(shù)據(jù)，實(shí)現(xiàn)導(dǎo)入到新的etcd集群，從而恢復(fù)Karmada集群所有的業(yè)務(wù)狀態(tài)。當(dāng)前主要場景如下：

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

2.7 member集群管理

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

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

三、Karmada-Operator的CI介紹

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

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

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

語法測試：

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

集群部署測試：

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

功能測試：

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

性能測試：

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

四、總結(jié)

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

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

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