打開鏈接點亮社區Star,照亮技術的前進之路。每一個點贊,都是社區技術大佬前進的動力
Github 地址: *https://github.com/orgs/secretflow/kuscia
架構
Kuscia(Kubernetes-based Secure Collaborative InfrA)是一款基於 K3s 的輕量級隱私計算任務編排框架,旨在屏蔽異構基礎設施和協議,並提供統一的隱私計算底座。在此基礎上,kuscia 提供了資源管理、應用調度、容器加載、服務發現、數據安全訪問、運維監控等諸多能力。
Kuscia 集羣由控制平面(俗稱調度面、Master)和節點組成。控制平面負責調度,節點負責計算。
一般來講,控制平面和節點之間,1:N 組成了中心化網絡,1:1 組成了點對點(P2P)網絡。中心化網絡中的節點稱為 Lite 節點,點對點網絡中的節點稱為 Autonomy 節點。
Kuscia 支持 Lite 節點與 Autonomy 節點、以及兩個中心化網絡互聯互通,並支持與第三方廠商的節點互聯互通,從而構建更大的隱私計算網絡。
Kuscia 組件
控制平面
控制平面監聽和響應集羣事件,實現資源管理和應用調度功能,核心組件包括 K3s、Kuscia Controllers、Kuscia Storage(暫未開源)、Envoy、互聯互通適配器。
K3s
K3s 是一個輕量級的 Kubernetes 發行版,用於處理 Kubernetes 的內置資源。
Kuscia Controllers
Kuscia 擴展了一組 K3s 控制器,用於處理 Kuscia 的自定義資源,這些控制器包括:
- Job Controller:作業控制器,負責解析作業 DAG 的描述信息,進行 DAG 的編排與多任務調度、採集任務狀態。
- Task Controller:任務控制器,負責解析任務的描述信息,實現多方任務的 Co-Scheduling 調度,對應作業 DAG 中的頂點。
- Kuscia Scheduler: Kuscia 調度器,負責多方 Pod 的 Co-Scheduling 調度,具備 All-or-Nothing 調度效果。
- Domain Controller:節點控制器,負責管理節點資源、為節點分配 Namespace。
- DomainRoute Controller:路由控制器,負責管理節點與節點、節點與 Master 的路由規則以及身份認證和鑑權策略。
- InterConn Controllers:互聯互通控制器,負責不同控制平面下的節點互通,從而協同完成多方任務調度,支持多種互聯互通協議。
- Data Controller: 數據控制器,負責數據授權管理,暫未開源。
- Serving Controller:服務控制器,負責常駐任務流的編排和調度,暫未開源。
Kuscia Storage
Kuscia Storage 是對 K3s 原生集羣存儲的補充。K3s 原生集羣存儲不適合存儲大 value,因此對於大 value 的資源屬性,如作業配置等,將存儲在 Kuscia Storage
中。該模塊暫未開源。
Envoy
Envoy 是一個開源的邊緣和服務代理。在控制平面中,Envoy 是節點與 Master、Master 與 Master 之間的流量代理,從 DomainRoute Controller 接收路由規則和身份認證、鑑權策略。
Envoy 將發送給互聯互通合作方 Master 的請求轉發到對端的 Envoy(若對端非 Kuscia 架構,則轉發給對端網關),同時對來自節點和互聯互通合作方 Master
的請求進行身份認證和鑑權,將合法請求轉發給 K3s 的 ApiServer 或 Kuscia Storage。
節點
節點的全稱為隱私計算節點,由一組工作機器(或虛擬機)組成,託管運行隱私計算應用的 Pod。
根據組網模式的不同,節點分為 Lite 和 Autonomy 兩種類型:
- 中心化網絡中的節點稱為 Lite 節點,Lite 節點不包含控制平面。
- 點對點網絡(P2P)中的節點稱為 Autonomy 節點,每個 Autonomy 節點包含獨立的控制平面。
Lite 節點主要由 Agent、NetworkMesh、DataMesh(功能暫不完備),提供容器管理、通信管理、數據管理等功能。
此外,節點支持服務組件可插拔,用户可根據實際場景使用所需要的服務組件。
Agent
Agent 主要負責節點實例註冊和容器管理。將節點實例註冊為 K3s 集羣的工作節點後,用於管理 K3s 集羣下發的任務 Pod,並對 Pod 生命週期和節點實例生命週期進行管理。
Agent 當前支持 RunC、 RunP 和 RunK 三種運行時:
- RunC:即容器運行時,以原生容器的方式拉起任務 Pod。
- RunP:即進程運行時,直接在 Agent 容器內以進程形式拉起任務 Pod。
- RunK:即 K8s 運行時,對接 K8s 集羣,將任務 Pod 轉發提交至 K8s 集羣中執行。
三種運行時有各自的適用場景,你可以在不同的場景中根據運行時的特性來選擇最合適的運行時:
- RunC: 在 ECS 部署環境中推薦使用,兼顧了安全性與便捷性。
- RunP: 在 K8s 部署環境中推薦使用,架構簡單且對權限無要求。
- RunK: 在高併發任務場景中推薦使用,安全性強且資源利用率高。
| RunC | RunP | RunK | |
|---|---|---|---|
| 資源隔離 | 支持 | 不支持 | 支持 |
| 部署權限 | Kuscia 容器特權啓動 | 無要求 | 申請機構 K8s 動態創建資源權限(例如 Pod、ConfigMap 等) |
| 任務安全風險擴散 | 任務運行在不同容器中,不易擴散 | 任務運行在同一容器中,易擴散 | 任務運行在不同容器(Pod)中,不易擴散 |
| 資源利用率 | 較低 | 較低 | 較高(任務需要的資源可以在機構 K8s 側動態擴縮) |
NetworkMesh
NetworkMesh 是算法容器之間進行網絡通信的基礎設施,包含 CoreDNS、DomainRoute、Envoy、Transport 四個組件。
CoreDNS
CoreDNS 是一個靈活可擴展的 DNS 服務器,在 Kuscia 中,主要用於解析應用 Service 的域名,從而實現域內的服務發現。
DomainRoute
節點側的 DomainRoute,一方面監聽 DomainRoute Controller 配置的節點與節點、節點與 master 之間的路由規則、身份認證和鑑權策略;另一方面監聽節點命名空間下的
Service 和 Endpoints,配置 Envoy 的 Upstream Cluster,從而實現跨域的服務發現。
Envoy
在節點側,Envoy 是節點與 Master、節點與節點之間流量代理,從 DomainRoute 接收路由規則、身份認證和鑑權策略以及 Upstream Cluster 配置。
Envoy 將發送給 Master 和合作節點的請求轉發給對端的 Envoy(若對端非 Kuscia 架構,則轉發給對端網關),同時對來自合作節點的請求進行身份認證和鑑權,
將合法請求轉發到目標應用的 Pod 上。
Transport
適配《北京金融科技產業聯盟互聯互通標準》的傳輸層通信組件,提供消息隊列的傳輸模式。
DataMesh
負責數據源和數據集(數據表、模型、任務報告等)的註冊和管理,元信息的查詢修改功能。注意該組件暫未實現權限管控功能,請勿在生產環境中使用該組件。
組網模式
Kuscia 支持兩種組網模式:中心化組網模式和點對點組網模式。
{#centralized}
中心化組網模式
中心化組網模式下,多個節點共享控制平面,控制平面負責管理多個節點的資源和任務調度。這種模式下節點佔用資源較少,稱為 Lite 節點。
中心化組網模式適合於大型機構內部的節點互聯,通過統一的控制平面,可顯著降低運維和資源成本,且便於快速新增節點。
{#peer-to-peer}
點對點組網模式
在點對點(P2P: Peer-to-Peer)組網模式下,節點擁有獨立的控制平面,節點實例和控制平面在同一個子網中,這種類型的節點被稱為 Autonomy 節點。
在該模式下,參與方通過 InterConn Controller,
從調度方同步 Pod 到本集羣,由本方 Scheduler 綁定到節點實例。
點對點組網模式適合小型機構或是安全性要求高的場景。
部署模式
Kuscia 提供三種部署模式:Docker 模式、K8s 模式、K8s 控制器模式,以適配不同機構的基礎設施。
- Docker 模式:適合基於物理機或虛擬機部署隱私計算任務的機構,可以直接在機器上以 Docker 容器方式部署控制平面和節點實例。
- K8s 模式:適合基於公有 K8s 集羣部署隱私計算任務的機構,可將控制平面和節點以 K8s 應用的方式部署到機構 K8s 集羣中。
- K8s 控制器模式:適合基於專有 K8s 集羣部署隱私計算任務的機構,可將 Kuscia Controllers、Kuscia Storage、Envoy 部署在 K8s 集羣的控制平面中。
作業編排與任務調度
在 Kuscia 編排框架中,作業(Job)編排和任務(Task)調度主要通過 Job Controller、Task Controller、InterConn Controller、Kuscia Scheduler 協同完成。
- Job Controller:負責 Job DAG 調度和 Job 生命週期管理。根據 Job DAG 中的 Task 依賴關係、調度參數等控制 Task 的調度順序以及並行度。
- Task Controller:負責 Task 多個參與方之間的 Co-Scheduling 調度和 Task 生命週期管理。
- Kuscia Scheduler:負責 Task 在一個參與方下的多個 Pod 之間的 Co-Scheduling 調度和 Pod 生命週期管理。
- InterConn Controller:用於點對點(P2P)組網模式下,調度方與參與方之間的 Task 資源同步。
在點對點(P2P)組網模式下,Job 的調度時序圖如下:
其中 Job 中的一個 Task 調度流程如下:
- Task Controller 在各參與方節點的 Namespace 下分別創建 TaskResource 對象和 PodGroup(包含一組 Label 相同的任務 Pod)。
- 任務參與方的 InterConn Controller 從調度方集羣中將本方的 TaskResource 和 PodGroup 同步到參與方集羣中。參與方集羣中的 TaskResource 和 PodGroup 的狀態也會通過
InterConn Controller 同步到調度方集羣中。 - Kuscia Scheduler 為各 PodGroup 中的 Pod 預留資源,當 PodGroup 中資源預留成功的 Pod 數量滿足 MinReservedPods
閥值時,將 PodGroup 對應的 TaskResource 狀態更新為 Reserved。在點對點(P2P)組網模式下,調度方的 Kuscia Scheduler 不會調度本集羣中非本方的 Pod。 - Task Controller 監聽到 TaskResource 預留成功的數量滿足 MinReservedMembers 閾值時,則將各參與方的 TaskResource 的狀態更新為 Schedulable。
- Kuscia Scheduler 監聽到 TaskResource 的狀態變為 Schedulable 後,綁定 PodGroup 中的任務 Pod 到已分配的節點上。