作者 | vivo 互聯網服務器團隊-Zhang Rong

Karmada作為開源的云原生多云容器編排項目，吸引了眾多企業共同參與項目開發，并運行于生產環境中。同時多云也逐步成為數據中心建設的基礎架構，多區域容災與多活、大規模多集群管理、跨云彈性與遷移等場景推動云原生多云相關技術的快速發展。

一、 背景

隨著vivo業務不斷遷移到k8s上，集群規模和集群的數量快速增長，運維難度也急劇增加。為了構建多集群技術，我們也自研了多集群管理，但無法解決我們遇到的更多的問題。后來開始對社區相關項目做了細致的調研和測試，我們最終選擇了Karmada。

主要原因如下：

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

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

社區部署工具較多，需要用戶自己選擇。當前用戶部署方式如下：

• Karmadactl
• Karmada charts
• 二進制部署
• hack目錄下腳本

對于上面的幾種工具，在Karmada的社區開展了問卷調研?，并生成了統計報告。

主要總結如下：

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

針對以上問題，本文將分享Karmada-Operator的vivo實踐，包括Operator的方案選擇、API、架構設計和CI構建等。?

二、Karmada-Operator的落地實踐

2.1 Operator SDK介紹

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

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

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

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

如上圖所示，operator sdk可以基于helm、ansilbe和go構建operator，我們需根據當前的情況選擇我們合適的operator框架。

2.2 方案選擇

• 方案一：golang 開發Operator

• 方案二：ansible開發Operator

• 方案三：golang和ansible混合開發Operator

根據Karmada的實際生產部署調研情況和vivo自身的實踐，可以總結如下：

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

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

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

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

方案三，基于go+ansible的混合的Operator，讀者可以閱讀vivo開發的Kubernetes-Operator，就是基于這種方案。方案三具備方案二的所有能力，因為底層都是通過ansible去執行。

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

1. Operator SDK ansible已具備了和Operator SDK go相等的能力，并提供K8s、K8s_status模塊、相似的webhook功能去對k8s的資源管理，以及reconciliation的能力。
2. 符合目前Karmada實際生產部署的需求。
3. 簡單易學，只要知道ansbile的jinja模版、和K8s相同的yaml文件。你只需要編寫ansible task，開箱即用，reconciliation由Operator SDK 解決。
4. 對于常用ansible的人比較友好，不需要寫golang代碼。
5. 擴展能力強，用戶可自定義插件。管理端也支持local、ssh、zeromq三種方式連接。local模式可以直接對接K8s接口，ssh模式可以登錄執行腳本。可以很好的混合使用，解決我們當前的需求。
6. Karmada運維操作相對K8s要簡單，不需要復雜的crd定義，ansible需要解析少量vars去執行playbook就行。golang+ansible模式比較適合復雜CRD定義和業務邏輯復雜的系統。

2.3 API設計

如上圖所示，我們只需要執行Operator-SDK create api命令，就可以創建 KarmadaDeployment的CRD，然后就可以定義KarmadaDeployment的API。在watches.yaml里實現Reconcile的業務邏輯。

這里主要定義KarmadaDeployment、EtcdBackup和EtcdRestore個資源，分別用于Karmada的部署，和etcd的數據備份和恢復。ansible Operator會根據spec里定義解析成ansible的vars。status將通過 ansible runner 輸出為用戶自定義的狀態。也可以通過ansible的k8s_status更新KarmadaDeployment的狀態。當前主要考慮的是在K8s運行Karmada，后面會添加二進制部署模式，當前的CR沒有涉及。

2.4 架構設計

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

執行流程如下。

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

2.5 Karmada控制平面管理

如上圖所示，主要是karmada控制平面生命周期管理，對比當前社區的部署工具我們如下優化：

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

2.6 etcd集群管理

etcd集群是Karmada的元數據集群,生產中需要保證etcd集群高可用和故障恢復等。如上圖展示了etcd集群必要的生產要素，如自動擴縮容、升級、備份和etcd集群的故障恢復。自研了基于ansible的plugins和library, 實現etcd集群管理能力如下：

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

這里定義了etcdBackup和etcdRestore的CR，沒有合并到KarmadaDeployment里。主要考慮到etcd集群本身操作的安全性和簡化KarmadaDeployment的ansible任務。其中etcdRestore功能，可以根據etcd集群備份數據，實現導入到新的etcd集群，從而恢復Karmada集群所有的業務狀態。當前主要場景如下：

1. Karmada集群所在的機房裁撤，需要備份etcd數據，遷移到新的Karmada集群。
2. 期望通過Karmada-Operator管理Karmada集群，只需備份etcd數據，實現etcdRestore功能即可。
3. Karmada集群故障，可以通過etcd備份數據，結合etcdRestroe實現故障恢復。

2.7 member集群管理

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

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

三、Karmada-Operator的CI介紹

為了更好的提高開發人員的體驗，計劃提供Karmada-Operator的CI構建能力。這里在K8s集群里部署github的self-hosted Runner和kubevirt。

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

計劃添加的CI矩陣測試如下：

語法測試：

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

集群部署測試：

• Karmadactl、charts、yaml和二進制部署和所有配置項安裝測試
• join/ unjoin member 集群
• 升級Karmada
• etcd集群的備份和恢復

功能測試：

• Karmada e2e測試
• 創建bookinfo案例

性能測試：

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

四、總結

通過社區的調研和vivo的實踐，最終確定了Karmada-Operator方案設計。Karmada-Operator具有高度可擴展性、可靠性、更直觀地編寫操作邏輯和開箱即用等特點，我們相信通過這種高度可擴展的聲明式、自我修復云原生系統管理Karmada，為我們全面切換到Karmada去管理業務提供了強有力可靠保障。

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

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