人工智慧與 Kubernetes

在國外眾多知名網站 2021 年對 Kubernetes 的預測中，人工智慧技術與 Kubernetes 的更好結合通常都名列其中。Kubernetes 以其良好的擴充套件和分散式特性，以及強大的排程能力成為執行 DL/ML 工作負載的理想平臺。

上面是微眾銀行開源的機器學習平臺 Prophecis 的架構圖，我們可以看到綠色的部分是機器學習平臺通常都會有的功能包括訓練、開發、模型、資料和應用的管理等功能。而通常這些機器學習平臺都是執行在 Kubernetes 之上的，如紫色的部分所示：最底層是 Kubernetes，再往上是容器管理平臺 (微眾銀行的開發者曾在 KubeSphere 2020 Meetup 北京站上提到這裡採用的是 KubeSphere)，容器管理平臺在 Kubernetes 之上提供了儲存、網路、服務治理、CI/CD、以及可觀測性方面的能力。

Kubernetes 很強大，但通常在 Kubernetes 上執行 AI 的工作負載還需要更多非 K8s 原生能力的支援比如：

• 使用者管理: 涉及多租戶許可權管理等

• 多叢集管理

• 圖形化 GPU 工作負載排程

• GPU 監控

• 訓練、推理日誌管理

• Kubernetes 事件與審計

• 告警與通知

具體來說 Kubernetes 並沒有提供完善的使用者管理能力，而這是一個企業級機器學習平臺的剛需；同樣原生的 K8s 也並沒有提供多叢集管理的能力，而使用者有眾多 K8s 叢集需要統一管理；執行 AI 工作負載需要用到 GPU，昂貴的 GPU 需要有更好的監控及排程才能提高 GPU 利用率並節省成本；AI 的訓練需要很長時間才能完成，從幾個小時到幾天不等，透過容器平臺提供的日誌系統可以更容易地看到訓練進度；容器平臺事件管理可以幫助開發者更好地定位問題；容器平臺審計管理可以更容易地獲知誰對哪些資源做了什麼操作，讓使用者對整個容器平臺有深入的掌控。

總的來說，K8s 就像 Linux/Unix, 但使用者仍然需要 Ubuntu 或 Mac 。KubeSphere 是企業級分散式多租戶容器平臺，本質上是一個現代的分散式作業系統。KubeSphere 在 K8s 之上提供了豐富的平臺能力如使用者管理、多叢集管理、可觀測性、應用管理、微服務治理、CI/CD 等。

如何利用 K8s 和 KubeSphere 構建機器學習平臺

極棧平臺是一個面向企業或機構的機器學習服務平臺，提供從資料處理、模型訓練、模型測試到模型推理的 AI 全生命週期管理服務，致力於幫助企業或機構迅速構建 AI 演算法開發與應用能力。平臺提供低程式碼開發與自動化測試功能，支援任務智慧排程與資源智慧監控，幫助企業全面提升 AI 演算法開發效率，降低 AI 演算法應用與管理成本，快速實現智慧化升級。

極棧 AI 平臺迭代演變的挑戰

在使用 Kubernetes 之前，平臺使用 Docker 掛載指定 GPU 來分配算力，容器內建 Jupyter 線上 IDE 實現和開發者互動，開發者在分配的容器內完成訓練測試程式碼編寫、模型訓練，當時存在四個問題需要解決：

1. 算力利用率低：開發者在編碼時，GPU 僅僅用於程式碼除錯；同時開發者需手動開啟或者關閉環境，如果開發者訓練結束未關閉環境，將繼續佔用算力資源。以演算法大賽的場景為例，算力利用率平均在 50%，算力資源浪費嚴重。

2. 儲存運維成本高：平臺使用 Ceph 來儲存資料集、程式碼，比如容器掛載了 Ceph 的塊儲存來持久化儲存開發環境，方便再次使用時能在其他 node 還原。在大量開發者使用時，出現掛載卷釋放不了、容器無法停止等問題，影響開發者使用。

3. 資料集安全無法保障：商用演算法資料集往往涉密，需要實現資料所有權和使用權分離，比如許多大型政企開發演算法往往外包給專業的 AI 公司。怎麼讓外部 AI 公司的演算法工程師在既能完成演算法開發，又能不接觸到資料集，是政企演算法平臺客戶的迫切需求。

4. 演算法測試人力成本高：對於演算法開發者提交的演算法，要對精度和效能等指標進行評測，達到演算法需求方要求的精度和效能指標後方可上線。還是以演算法大賽的場景舉例，一般的 AI 平臺會提供訓練資料集、測試資料集給到使用者，使用者完成演算法開發後，用演算法跑測試集，將結果寫入到 CSV 檔案裡面和演算法一起提交。對於獲獎的開發者，我們要還原開發者測試環境，重新用開發者的演算法來跑測試集，並和開發者提交的 CSV 結果對比，確定 CSV 檔案沒有被修改，保證比賽公平，這些都需要大量的測試人員參與，作為定位全棧 AI 開發的極棧平臺來說，要在平臺上開發萬千演算法，急需降低測試的人工成本。

為解決這些問題，2018 年中決定引入 Kubernetes 對平臺進行重構，但當時團隊沒有精通 Kubernetes 的人員，Kubernetes 的學習成本也不低，重構進展受到一定影響；後來我們發現了由青雲科技開源的容器管理平臺 KubeSphere，它把很多 Kubernetes 底層細節都遮蔽了，使用者只需要像用公有云一樣，用視覺化的方式使用，可以降低使用 Kubernetes 的成本。同時社群的維護團隊也非常認真負責，最開始把 KubeSphere 部署到我們測試環境，叢集執行一段時間會崩潰，開源社群的同學手把手幫助我們解決了問題，後來又陸續引入了 QingStor NeonSAN 來替代 Ceph，極大地提升了平臺穩定性。

KubeSphere v3.0.0 支援了多叢集管理、自定義監控，提供了完善的事件、審計查詢及告警能力；KubeSphere v3.1.x 新增對 KubeEdge 邊緣節點管理的功能、新增多維度計量計費的能力、重構了告警系統，提供了相容 Prometheus 格式的告警設定、新增了包括企業微信/釘釘/郵件/Slack/Webhook 等眾多通知渠道、同時對應用商店和 DevOps 也進行了重構；還在開發當中的 KubeSphere v3.2 將對執行 AI 工作負載提供更好的支援包括 GPU 工作負載排程、GPU 監控等；未來 KubeSphere v4.0.0 將升級為可插拔架構，前後端將都會獲得可插拔的能力，基於此可以構建可插拔到 KubeSphere 的機器學習平臺。

雲原生 AI 平臺實踐

提高算力資源利用

1. GPU 虛擬化

首先針對開發者編碼算力利用率低的情況，我們將編碼和訓練算力叢集分開，同時使用 GPU 虛擬化技術來更好利用 GPU 算力，這方面市場上已經有成熟的解決方案。在技術調研之後，選擇了騰訊雲開源的 GPUManager 作為虛擬化解決方案。

GPUManager 基於 GPU 驅動封裝實現，使用者需要對驅動的某些關鍵介面（如視訊記憶體分配、cuda thread 建立等）進行封裝劫持，在劫持過程中限制使用者程式對計算資源的使用，整體方案較為輕量化、效能損耗小，自身只有 5% 的效能損耗，支援同一張卡上容器間 GPU 和視訊記憶體使用隔離，保證了編碼這種算力利用率不高的場景開發者可以共享 GPU，同時在同一塊除錯時資源不會被搶佔。

2. 訓練叢集算力排程

在 Kubernetes 裡面使用 Job 來建立訓練任務，只需要指定需要使用的 GPU 資源，結合訊息佇列，訓練叢集算力資源利用率可以達到滿載。

	resources:
		requests:
			nvidia.com/gpu: 2
			cpu: 8
			memory: 16Gi
		limits:
			nvidia.com/gpu: 2
			cpu: 8
			memory: 16Gi

3. 資源監控

資源監控對叢集編碼、訓練最佳化有關鍵指導作用，KubeSphere 不僅能對 CPU 等傳統資源監控，透過自定義監控皮膚，簡單幾個步驟配置，便可順利完成可觀察性監控，同時極棧平臺也在 Kubernetes 基礎上，按照專案等維度，可以限制每個專案 GPU 總的使用量和每個使用者 GPU 資源分配。

現在，比如演算法大賽的場景，我們監控到的 GPU 平均使用率在編碼叢集達到了 70%，訓練叢集達到了 95%。

儲存：QingStor NeonSAN RDMA

我們採用 NVMe SSD+25GbE（RDMA）的 NeonSAN 來替換開源的 Ceph，NeonSAN 的表現很驚豔：比如隨機讀寫的 IOPS，讀達到了 180K，是 Ceph 的 6 倍，寫也可以達到 75.7K，是Ceph 的 5.3 倍，之後 AI 平臺最高 1000 個 Pod 併發訓練，沒有再出現儲存掛載卷釋放不了引起的卡頓問題。

資料集安全

我們做了資料安全沙箱來解決資料集安全的問題，資料安全沙箱實現了在不洩漏資料的同時，又能讓演算法開發者基於客戶資料訓練模型和評估演算法質量。

資料安全沙箱要解決兩個問題：

1. 安全隔離問題 ：對外叢集不能連通外網，把資料傳出去；在平臺內部，可以透過程式把資料傳輸到開發者能夠訪問的環境。比如在開發者可以控制的編碼環境裡面起個 http 服務接收訓練叢集傳輸過來的訓練資料。KubeSphere 提供了基於租戶的視覺化網路安全策略管理，極大地降低了容器平臺在網路層面的運維工作壓力。透過網路策略，可以在同一叢集內實現網路隔離，這意味著可以在 Pod 之間設定防火牆，如果多個策略選擇了一個 Pod, 則該 Pod 受限於這些策略的入站（Ingress）/出站（Egress）規則的並集，它們不會衝突，所以這裡只要設定一個限制訪問外網的策略和禁止訪問編碼 Pod 的策略即可。

2. 訓練體驗問題：隔離之後，開發者要能夠實時知道訓練和測試狀態，訓練和測試不能是一個黑箱，否則會極大影響模型訓練和演算法測試效率，如下圖。

• 開發者發起訓練或者測試，任務在算力叢集裡面跑了起來，EFK 收集和儲存容器日誌，針對不同資料集，可以設定不同等級的黑白名單過濾策略，防止圖片資料轉碼成日誌洩露出來，比如高安全性資料集直接設定白名單日誌展示。

• 我們開發了 EV_toolkit 視覺化工具包，來檢視訓練的指標如精度、損失函式（比如交叉熵）等，原理是訓練指標透過 toolkit 的 API 介面寫入到指定位置，再展示到介面上。

• 訓練監控：支援無人值守訓練，錯誤訊息通知，訓練進展定製化提醒，訓練結束通知。

自動測試

要完成演算法的自動測試需要解決 3 個問題：

1. 各個演算法框架開發出來的模型格式不統一，怎麼規範化統一呼叫。

2. 所有演算法輸入要統一、標準化。

3. 客戶對演算法要求越來越高，演算法輸出的資料結構也越來越複雜，演算法輸出怎麼跟資料標註的正確結果比對。

先來看看我們自研的推理框架 EVSdk，它解決了前兩個問題，一是制定了演算法統一封裝標準，不同於其他 AI 平臺針對單模型進行評估，極棧自動測試系統針對封裝好的演算法進行評估，因為隨著演算法越來越複雜，一個演算法有多個模型的情況也越來越常見，只是對單模型進行評估並不能評估交付給客戶的成品質量，另外對模型評估還要考慮各種開發框架模型格式相容問題；二是 EVSdk 抽象出了演算法輸入介面，比如針對影片分析，第一個引數是建立的檢測器例項，第二個引數是輸入的源幀，第三個引數是可配置的 json，比如 roi、置信度等，透過 EVSdk 制定規範實現了演算法輸入的標準化。除了解決自動測試的兩個問題，EVSdk 還提供工具包,比如演算法授權，另外有了統一的推理框架，外面一層的演算法工程化工作也可以標準化，由平臺統一提供，以安裝包形式安裝進去，不用開發者來做了，比如處理影片流、演算法對外提供 GRPC 服務等。

還要解決演算法輸出的問題，演算法輸出就是要找到輸出 JSON 或者 XML 的節點裡面的演算法預測資料，找到之後和標註的正確資料做對比。自動測試系統引入了兩個概念：

• 模版：定義了演算法輸出的資料結構，這個資料結構中包含若干個變數和如何從原始資料中獲取到具體值的路由路徑，根據模版解析原始資料之後，模版中的所有變數將被填充具體的值。

• 路由路徑：一種針對資料查詢的路由規則，使用這種規則可以把 xml / json 等不同的資料物件對映到相同的資料結構。對於不同來源或者不同結構的測試資料，就可以透過改變配置檔案，得到相同資料結構的資料，從而可以對同一型別的任務使用同一個解析器來計算演算法指標。

下圖示例裡面擷取了一個模板裡面最小單元，但足以說明自動測試原理。自動測試程式要在演算法輸出裡找到年齡這個值，來和圖片或影片標註的標籤裡面的年齡做對比。route_path 欄位告訴系統有個根節點的 key 是 people，age 這個欄位的 value 就是我們要找的路由路徑了，[0] 代表了這是一個陣列，這也很好理解，因為可以有多個人出現在一幀影片裡面，. 代表了下一級，[] 裡如果不是 0，比如 age 代表這是個物件，key 名叫做 age，@num 就是他的資料型別，至此程式就找到了 age 在演算法輸出的位置，找到後拿去和標註的正確資料作對比。當然有更復雜的評判標準，例如年齡誤差在 3 歲以內系統認為演算法分析結果是正確的。

極棧平臺現狀

PaaS 層用 KubeSphere 作為底座打造了三個平臺：資料平臺，開發平臺，推理平臺。採集到原始資料之後對資料大類進行打標，再用演算法對資料進行去重，以及把低質量資料去除掉等初篩工作，人工再進行篩選。因為 AI 訓練資料量非常大，我們還支援對資料生命週期進行設定，比如根據資料重要性進行儲存，然後到資料標註，標註是非常佔用時間的工作，需要做任務的分配和對標註人員做績效管理，透過再訓練的模型進行自動標註和人工調整標註。資料標註好之後流轉到開發平臺，開發平臺支援兩種開發模式，一是互動式開發，二是低程式碼的開發。最後演算法生產出來之後上架到推理平臺的演算法商店，推理平臺的客戶端可以部署到使用者側，使用者只需要輸入啟用碼就可以安裝演算法，然後分析本地實時影片流或圖片。

極棧平臺未來展望

1. 計算機視覺演算法和其他軟體不同在哪裡呢，比如說 KubeSphere，給我們用的產品和給另外公司用的是一致的。但是對於演算法來說，在 A 客戶那裡效果很好，到 B 客戶攝像頭距離遠一些、角度不同，或者是檢測物體多了個顏色，效果就不達標了，要重新採集資料來訓練模型。演算法可複製性不強，難以標準化、產品化。對於解決通用場景的問題，每提高一個百分點識別率需要的算力和資料成本要翻倍，所以目前業界總共花了百億成本才讓人臉識別達到產品化，針對萬千演算法，如何大規模可複用，這是我們要攻克的難題。

2. 既然適配通用場景非常難，回到現實場景中來，我們真的需要不斷去最佳化一個演算法適配所有使用者的場景嗎？對於每個使用者來說，他真正關心的是演算法在他自己場景下的演算法效果。而在實踐中，對於新場景，我們會將新場景資料集加入到訓練集裡面，對演算法進行再訓練來解決。如果系統能夠實現不讓演算法工程師介入再訓練過程，而是由客戶透過簡單的操作來完成,就解決了這個問題。

3. 我們下一步會開發行業低程式碼套件，演算法開發者在平臺內只需開發演算法和維護演算法在行業的領先性，使用者拿自己場景資料來標註，訓練模型，適配自己的場景，無需任何編碼工作，就可以完成演算法最佳化，最佳化效果不達標的場景，再由開發者介入。模型最佳化的工作如果無法避免，放到使用者側，演算法就相當於使用者餵養的寵物，這其實會重新定義使用者和演算法之間的關係，只有這樣走，演算法才能產品化，萬千場景才能開啟。

Serverless 在 AI 領域的應用

上面詳細闡述了 Kubernetes 在 AI 的應用實踐，其實 AI 也需要 Serverless 技術，具體來說 AI 的資料、訓練、推理等都可以同 Serverless 技術相結合而獲得更高的效率並降低成本：

• AI 離不開資料，以 Serverless 的方式處理資料成本更低。

• 可以透過定時或者事件觸發 Serverless 工作負載的方式進行 AI 訓練以及時釋放昂貴的 GPU。

• 訓練好的模型可以用 Serverless 的方式提供服務。

• AI 推理結果可以透過事件的方式觸發 Serverless 函式進行後續的處理。

Serverless 是雲原生領域不容錯失的賽道，以此為出發點，青雲科技開源了雲原生 FaaS 平臺 —— OpenFunction。

FaaS 平臺主要包含 Build、Serving 及 Events 幾個部分。其中 Build 負責將函式程式碼轉換成函式映象；Serving 部分負責基於生成的函式映象提供可伸縮的函式服務；Events 部分負責對接外部事件源並驅動函式執行。

Kubernetes 已經啟用 Docker 作為預設的 container runtime，從此不能在 K8s 叢集裡用 Docker in Docker 的方式 docker build 去 build 映象，需要有別的選擇。OpenFunction 現在預設支援 Cloud Native Buildpacks ，後面還將陸續支援 buildah、 buildkit、 kaniko 等。

Dapr 是微軟開源的分散式應用程式執行時，提供了執行分散式應用程式需要的一些通用基礎能力。OpenFunction 也把 Dapr 應用到了 OpenFunction 的 Serving 和 Events 裡。

函式服務最重要的是 0 與 N 副本之間的自動伸縮，對於同步函式，OpenFunction 支援 Knative Serving 作為同步函式執行時，後面還計劃支援 KEDA-HTTP ; 對於非同步函式來說，OpenFunction 結合 Dapr 與 KEDA 開發了名為 OpenFunction Async 的非同步函式執行時。

函式的事件管理我們調研了 Knative Eventing 之後覺得它雖然設計的比較好，但是有點過於複雜，不易學習和使用；Argo Events 架構雖然簡單了許多，但並不是專為 Serverless 而設計，並且要求所有事件都必須發往它的事件匯流排 EventBus。基於以上調研，我們自己開發了函式事件管理框架 OpenFunction Events。

OpenFunction Events 充分利用了 Dapr 的能力去對接眾多事件源、對接更多的 MQ 去作為 EventBus ，包含 EventSource、EventBus 和 Trigger 幾個元件：

• EventSource：用於對接眾多外部事件源如 Kafka、NATS、 PubSub、S3、GitHub 等。在獲取到事件之後，EventSource 可以直接呼叫同步函式進行處理，也可以將事件發往 EventBus 進行持久化，進而觸發同步或者非同步函式。

• EventBus：利用 Dapr 能夠以可插拔的方式對接眾多訊息佇列如 Kafka、NATS 等。

• Trigger：從 EventBus 中獲取事件，進行過濾選出關心的事件後，可以直接觸發同步函式，也可以將過濾出的事件發往 EventBus 觸發非同步函式。

Serverless 除了可以應用到上述 AI 領域之外，還可以應用到諸如 IoT 裝置資料處理、流式資料處理、Web / 移動終端後端 API backend (Backend for Frontend) 等領域。
OpenFunction 已經在 GitHub 開源，主要倉庫包括: OpenFunction[1]、functions-framework[2]、builder[3]、samples[4]

也歡迎大家到 KubeSphere 和 OpenFunction 社群的中文 Slack 頻道[5] 交流。

作者

極視角科技技術合夥人 黃河、青雲科技 KubeSphere 資深架構師 霍秉傑