1. 程式人生 > 其它 >艾莫爾研究院基於Karmada的落地實踐

艾莫爾研究院基於Karmada的落地實踐

摘要:本文從企業的業務背景、應用需求以及選擇Karmada前後的對比和收益等方面,闡述了艾莫爾使用多叢集技術完成企業技術升級的過程。

本文分享自華為雲社群《艾莫爾研究院基於Karmada的落地實踐》,作者: 艾莫爾人工智慧研究院容器平臺負責人 徐元昌。

引言

本篇文章來自艾莫爾人工智慧研究院在多叢集管理應用中的落地實踐,從企業的業務背景、應用需求以及選擇Karmada前後的對比和收益等方面,闡述了艾莫爾使用多叢集技術完成企業技術升級的過程。

背景

艾莫爾⼈⼯智慧研究院,是矽柏集團下⼀家致⼒於使⽤雲原⽣技術幫助企業數字化轉型的科技公司。公司主要產品是斬浪雲-雲原⽣應⽤平臺,該平臺圍繞雲原生、資料智慧、應用安全、應用效能、智慧應用等五大方向, 面向企業級市場,提供雲原生、大資料、AI、資訊保安等技術產品,覆蓋從開發、應用到運營整個環節, 滿足不同企業在生命週期不同階段的核心需求,為各行業打造⼀站式雲原⽣解決⽅案, 助⼒企業雲原⽣數字化轉型。

基於Kubernetes,我們構建了雲廠商無關的雲原生平臺,使用者無需感知雲廠商之間的差異即可使用Kubernetes託管業務應用。

隨著客戶對多雲需求的不斷增加, 叢集規模和叢集數量快速增⻓,運維複雜性也急劇增加,我們迫切需要圍繞 Kubernetes 構建多叢集技術。

過程中,我們考慮過自研多叢集管理方案,也對開源社群相關專案做了細緻的調研和測試,最終我們選擇了 Karmada 項⽬。下⾯將結合我們內部⼀些場景和需求,介紹選擇Karmada的原因以及在落地過程中的⼀些實踐。

多叢集方案選型

公司內部目前大約有50+左右的叢集,每個叢集有數百至上千節點不等。叢集不是同構的,其中一些叢集包含異構計算資源,如 GPU;叢集也不是同質的,其中一些邊緣叢集使用 k3s 構建。

根據我們的業務情況,我們對多叢集方案選型主要基於以下幾點:

  • Cluster API 定義要足夠抽象且具備靈活性,方便我們描述叢集的狀態、資源、成員,同時可以通過新增一個很薄的膠水層就描述叢集內異構成員和非同質叢集。
  • 能夠相容 Kubernetes 原⽣ API 和 CRD,這樣我們現存的一些系統不改造或者通過很少的改造就可以遷入多叢集。
  • 支援多叢集資源排程策略,同時具備自定義擴充套件的能力。因為我們的叢集分散在全球多個國家,我們希望可以在統一的平臺上去管理資源的排程。
  • 控制面要滿足高可用、高效能。我們希望隨著規模的增長,多集群系統可以水平擴充套件。

為什麼選擇 Karmada

首先 Karmada 是相容 Kubernetes 原生 API 和 CRD的。其次,從架構上而言,Karmada 的架構和 Kubernetes 很類似,具備層層遞進、可擴充套件性,具體來說:

  • 獨立的 etcd cluster: Karmada 可以使用獨立的 etcd 叢集,這和其他多集群系統依賴 Kubernetes 不同。獨立的 etcd 叢集可以讓控制面支撐更多的資源儲存,而不需要考慮擠壓 Kubernetes 叢集的問題。未來,我們還可以進一步在控制面將規模較大的資源物件拆分出去,以滿足更大規模的多叢集管理。
  • 獨立的 scheduler:Karmada 使用獨立的 scheduler 提供多叢集排程,這一點也是其他專案所不具備的。
  • agent/non-agent 接入模式: 相比於控制面 All-In-One 的系統,使用場景更加豐富。

下圖是 Karmada 的架構圖 :

Karmada 落地實踐

多叢集管理

當叢集數量達到一定程度,同時多個叢集之間存在著版本、配置、計算資源、API resource 等差異時,它們同時交叉在一起會導致多叢集管理複雜度呈指數級上升。我們需要自動化的系統去降低管理的複雜度。

Karmada 定義了 Cluster CRD 物件,基於該物件,我們構建了自動化的多叢集管理系統功能,降低了多叢集管理的整體複雜度,提高了系統管理人員的效率。

選擇合適的叢集接管模式

Karmada 提供了兩種叢集同步模式來處理控制⾯叢集 (Karmada Control Plane) 和成員叢集 (Member Cluster) 之間的協作:

  1. Push 模式,Karmada 控制⾯直接管理成員叢集並執行資源同步。這種模式下, 不需要為成員叢集部署額外的元件,只需要將成員叢集註冊到Karmada控制面即可。
  2. Pull 模式,成員叢集主動向Karmada控制面拉取資源並同步⾃⾝狀態。這種模式下, 成員叢集只需要部署’karmada-agent’元件即可,該元件會自動完成叢集註冊。

在實踐過程中,我們對不同場景使⽤哪種叢集管理⽅式總結如下表:

自動化叢集管理

新增一個 K8s 叢集流程比較繁雜,涉及叢集建立、叢集驗證、註冊等流程,還會涉及到跨部門協作。我們在 Karmada 之上疊加了業務相關的管理策略,如下圖所示。其中混合雲是聚焦在 IaaS 層的雲上、雲下資源管理平臺。

整合 Karmada 到現有平臺

我們將前⾯描述的⼀些內容和內部的雲原⽣平臺做了整合, 以簡化系統運維和管理⼈員的操作複雜度。

多叢集資源管理和排程

有些專案使用CRD來包裹Kubernetes原生API,使用者普遍感覺很痛苦,其中一個原因在於存量系統無法平滑接入,改造成本較大。

更本質的原因是這些多叢集專案把資源管理和排程的複雜性暴露給了使用者或者系統維護人員,而 Karmada 的出現帶給了我們驚喜!下面我們將談談我們是如何基於 Karmada 來解決問題的。

相容 K8s 原生 API

Karmada 是⾸個完全相容 K8s 原⽣ API 的多叢集容器編排項⽬, 使用者無需改動即可將現有叢集資源通過 Karmada 分發到多個叢集上。在架構設計上,Karmada 隱藏了多叢集資源管理和排程的複雜性,下圖是 Karmada API 的工作流程:

在筆者理解看來,Karmada 這個 API workflow 很好踐行了 “機制同策略分離” 的設計:Karmada 定義了一套多叢集資源管理的機制,然後在該機制上定義了相關策略。其中 Propagation Policy 定義資源在多叢集中的傳播策略,Override Policy 定義資源在多叢集中的差異配置策略。策略面向系統管理人員,終端使用者只需要提交自己的 K8s 原生 API 宣告就可以了。

在我們實踐過程中,我們將該理念融入到了平臺,下圖展現了平臺使用者只需要提交原生的 K8s API 就可以使用多叢集的能力了。

更高階的排程策略

和其他多集群系統不同的是,Karmada 支援很多高階的排程策略:

  • 定向排程: 這種方式與Kubernetes 的 Node 定向排程類似, 我們可以將部署的資源排程到指定的叢集上。
  • 親和性排程:使⽤⽅式上和 Kubernetes 類似, ⽀持 label selector, match expression 等語法。
  • 汙點容忍排程:這種方式和 kubernetes 的 Node Toleration 類似, Karmada 的Cluster API 可以宣告汙點 (Taint), 在多個叢集排程資源時, 如果該資源可以容忍(Toleration) 叢集宣告的 (Taint), 則可以將該資源排程到該叢集。

值得⼀提的是, Karmada 內部實現了⼀個和 Kubernetes 類似的排程框架 (Scheduler Framework), 當內建排程策略不滿⾜時, 我們還可以編寫⾃⼰的排程策略進行擴充套件。

同時, Karmada 在 PropagationPolicy 還定義了⼀個 SchedulerName 欄位,⽤於定義使⽤哪個排程器進⾏排程。未來, 當排程需求和場景更復雜時, 我們可以根據該欄位替換預設 (default) 排程器來滿⾜需求。

總而言之,Karmada 具備靈活的排程策略,支援按需擴充套件甚至多排程器架構。這種具有⾼度可擴充套件性和可定製化的能⼒正是我們所需要的。在我們實踐過程中,我們使用兩種方式將這些能力暴露給使用者:

  1. template,使用者在填寫完原生的 K8s API 聲明後,選擇一個系統建立的 template 宣告這些排程策略。同時系統支援對 template CRUD,template 能力基於 Karmada。
  2. strategy,將能力視覺化,讓使用者自己填寫。

下圖展示了我們第二種方式:

多叢集資源差異化配置

多個叢集之間的 workload 配置往往是不同的,最簡單的比如容器映象版本不同。我們將 Karmada 的 Override Policy 進行了封裝,給予使用者這種能力。如下圖所示:

多叢集資源狀態聚合

資源分散在多個叢集上執行,聚合這些資源的狀態形成一個統一的檢視是很關鍵的。Karmada 對 Kubernetes 原生資源進行了聚合,我們使用該聚合狀態構建平臺,如下圖所示:

Karmada 和現有系統的融合

我們現有的系統整合 Karmada非常輕鬆,AriesSurface 是我們第一個嘗試從單叢集推到多叢集的專案。AriesSurface 是一個多叢集巡檢系統 ,用於探測部署鏈路和叢集資料一致性。這兩個指標對於我們的叢集非常重要。在我們實踐過程中, 往往會發⽣所有監控指標都沒有問題, 但部署偏偏還是失敗了的情況。經過分析我們發現,監控資料⽆法⽆死⾓覆蓋所有異常, 監控只能暴露出系統異常, 但不能保障⼀些鏈路百分百可⽤。為此, 我們設計了和研發了基於 Pipeline (DAG) 的叢集巡檢系統。

在引⼊多叢集之前,各個叢集的巡檢狀態是分散的, ⽆法做到全域性視⾓觀測;擁抱 Karmada

之後, 我們將其改造成多叢集巡檢系統, 下圖是我們整合 Karmada 後的⼀個架構:

  1. 巡檢系統會通過 Karmada 的 Propagation 將 CRD 下發到成員叢集。
  2. 成員叢集的 Surface 控制監聽到 CRD 建立,會根據定義渲染出一個 Pipeline 並計算出一個 DAG,控制器執行該 DAG 並生成巡檢結果。
  3. 控制面執行一個 detector 收集巡檢狀態並將結果做相應的聚合和計算。

巡檢系統可以幫助我們知道每個成員叢集相關鏈路的狀態, 從⽽為多叢集交叉部署和排程提供有效的資料⽀撐。下圖是我們線上系統的⼀個⼤盤圖:

我們還繪製了巡檢鏈路在不同時間點的時序狀態, 有助於我們回溯歷史時間點的異常資訊:

Karmada 和社群生態的融合

Karmada 良好的設計使得它可以很容易和社群中其他專案進行整合,下圖是我們整合 velero 做多叢集備份和恢復的架構。

我們在控制面擴充套件了 velero 的 Backup 和 Restore 的多叢集 CRD,通過 Karmada 的 PropagationPolicy 將對應的 CRD 分發到指定的成員叢集。Backup 和 Restore 對應的 Controller 會做 Reconcile, 並對成員叢集的 velero 的 CRD 進行狀態聚合。

基於 Karmada 的多叢集異構資源探索

下圖展示了我們是如何基於 Karmada 做 GPU 多叢集資源管理的:

得益於 Karmada 優越的架構設計,我們很快構建了多叢集 GPU 資源管理的原型系統。

在最底層的算力上,我們使用時分模型對 GPU 算力做了虛擬化,同一個節點上的多個 Pod 可以共享一張或多張卡。每個節點的 GPU agent 實現了 GPU device plugin,並將虛擬的 GPU核心與視訊記憶體註冊為 extended resource。GPU Scheduler 是一個 K8s scheduler plugin,對 extended resource 進行資源排程。

GPU 在多叢集管理的一個基本想法是統一GPU 資源檢視和GPU 資源排程。首先使用者提交 GPU 相關的工作負載和 PropagationPolicy。GPU Scheduler 是在 Karmada 中擴充套件的一個 scheduler plugin,它根據工作負載資源和 PropagationPolicy 進行一次簡單的排程。目前的實現會收集每個成員叢集的 GPU 資源資訊,但沒有在多叢集做統一排程,實際上表現為一個兩層排程。

總結

自從 2021年初接觸 Karmada 以來,我們基於 Karmada 構建了內部的多集群系統,獲得了諸多益處:

  1. 由於Karmada相容 Kubernetes-Native API, 這樣我們現有的資源定義不需要改造即可接入多叢集。
  2. 建立多叢集控制面標準, 通過 Karmada Cluster API, Cluster Controller 以及 push/push 的模式, 我們在內部建立了多叢集層面的控制標準, 任何上層系統的多叢集管理能力都能以統一的方式輸出。
  3. 面向場景的多叢集資源排程和編排能力, Karmada 內建的一系列 controller, scheduler plugins 以及和 Kubernetes 等價的 scheduler 擴充套件能力,可以讓我們針對不同的場景做不同的權衡和設計。
  4. 現存系統快速多叢集化, Karmada 靈活的架構設計讓我們內部原本面向單叢集的系統,可以很快過渡到多集群系統。

同時,在使用 Karmada 過程中,我們見證了Karmada 專案的成長。從 Karmada v0.5 到 v1.0, 我們幾乎參與每次 weekly meeting,見證了 Karmada 很多令人興奮的 feature 從 proposal 到最後的 merge, 團隊先後2人成為了Karmada 社群 member。我認為這是開源專案和商業公司一種非常良性的迴圈。我們使用 Karmada 完成了我們系統的構建,同時將遇到的問題和新的idea回饋給社群,團隊在此期間對開源的認識也更加深刻,我們很榮幸能夠參與到 Karmada 專案,也希望更多的開發者加入到 Karmada 一起共建繁榮社群。

附:Karmada社群技術交流地址

專案地址

https://github.com/karmada-io/karmada

Slack地址:

https://slack.cncf.io/

華為夥伴暨開發者大會2022火熱來襲,重磅內容不容錯過!

【精彩活動】

勇往直前·做全能開發者→12場技術直播前瞻,8大技術寶典高能輸出,還有程式碼密室、知識競賽等多輪神祕任務等你來挑戰。即刻闖關,開啟終極大獎!點選踏上全能開發者晉級之路吧!

【技術專題】

未來已來,2022技術探祕→華為各領域的前沿技術、重磅開源專案、創新的應用實踐,站在智慧世界的入口,探索未來如何照進現實,乾貨滿滿點選瞭解

 

點選關注,第一時間瞭解華為雲新鮮技術~