KubeCube 多級租戶模型

語言: CN / TW / HK

KubeCube (https://kubecube.io) 是由網易數帆近期開源的一個輕量化的企業級容器平臺,為企業提供 kubernetes 資源視覺化管理以及統一的多叢集多租戶管理功能。KubeCube 社群將通過系列技術文章解讀 KubeCube 的設計特點和技術實現,幫助開發者和使用者更快地理解和上手 KubeCube。本文是第二篇,深度解讀 KubeCube 的多級租戶模型設計。

背景

在我們跟企業交流時,發現不同企業雖然規模不一樣,但選擇進行容器化的初衷還是為了降本增效、很多企業會選擇多個部門共用 K8s 叢集或者物理資源,在共享資源的同時,希望有足夠的隔離性。
 
多租戶是一種軟體架構技術,可以實現多個租戶之間資源複用和共享基礎設施,方便運營管理,有效節省開發應用成本;同時又可以實現個性化定製,每個租戶的資料是隔離的。
 
當前大部分雲供應商都提供了多租戶的解決方案來實現 K8s 資源共享和隔離,以滿足企業不同組織架構共享一個 K8s 基礎設施的需求。我們將容器服務在以往企業落地實施過程中的經驗進行了總結,去資料庫化採用更輕量更原生的 CRD + Operator 機制,在傳統多租戶模型基礎上加入了專案層級與軟體管理過程相對應,形成了新的多級租戶模型,適配企業組織架構和軟體資源管理的規範,使得企業可以更好的建立統一的多 K8s 叢集管理平臺。

租戶模型介紹

KubeCube 的多級租戶模型通過租戶和專案實現許可權隔離和資源分配。一個租戶表示一個組織(部門、團隊),做資源隔離。一個專案通常可以表示一個完整業務應用系統,與企業的軟體專案管理過程相對應,可以根據業務系統功能分解拆分多個名稱空間管理應用子系統。
 
租戶和專案都是跨叢集的概念,所有租戶共享多套 K8s 叢集基礎設施,通過許可權限定和配額管理保證必要的隔離,防止惡意操作帶來的風險。

多級租戶模型設計

KubeCube 多級租戶模型提供租戶、專案、空間 3 層模型以滿足不同規模企業的組織架構層級,從架構上看是一種 層級樹形結構 ,一個租戶包含多個專案,一個專案包含多個名稱空間,專案包含的名稱空間可以位於不同的 K8s 叢集。這裡的名稱空間指的是 K8s 的 Namespace ,用於實際承接業務應用的部署,是管理的最小單元。
 
 
租戶和專案在實現上是一個 CRD ,使用者只需要在管控 K8s 叢集上建立租戶和專案的 CR,KubeCube會將租戶和專案的 CR 實時同步到所有的計算 K8s 叢集。運維人員可以集中式的管理所有的計算 K8s 叢集,新增叢集時會自動同步租戶專案等基礎資訊,專案管理員只需要在任一 K8s 叢集(包括管控和計算叢集)建立名稱空間即可。
 
 
租戶、專案和名稱空間三者之間的關聯關係是通過層級名稱空間實現的 ,每一個租戶都關聯一個 Namespace ,每一個專案也都關聯一個 Namespace ,通過租戶和專案的Manifest裡 .spec.namespace 欄位指定關聯的 Namespace 名稱。租戶和專案關聯的名稱空間與實際承載應用的名稱空間不同,它是為了解決管理員僅可以在擁有許可權的租戶和專案下面建立名稱空間而引入的一個特殊名稱空間。
 
為了避免供應商鎖定和更好的相容原生 K8s 能力,KubeCube 的許可權模型是基於 K8s 原生的 RBAC 能力實現的,我們期望專案管理員僅可以在他擁有許可權的專案下面建立名稱空間。假設授權給一個專案管理員 ClusterRole 定義賦予建立 Namespace 的許可權,由於 Namespace 是叢集級別資源,那麼他將擁有超出專案範圍任意建立名稱空間的許可權,這與我們的期望不符合。
 
這裡我們引入 HNC (The Hierarchical Namespace Controller)的 SubNamespace 的概念,它是名稱空間級別的資源,負責自動生成和控制 Namespace 的生命週期。在 KubeCube 的設計中,租戶和專案管理員都沒有直接建立名稱空間的許可權,他們通過擁有建立 SubNamespace 的許可權來間接獲得建立名稱空間權利。 SubNamespace 是名稱空間級別的資源,通過 RBAC 限制 SubNamespace 操作許可權,租戶管理員只能在自己租戶關聯的 Namespace 下建立 SubNamespace ,專案管理員只能在自己專案關聯的 Namespace 下建立 SubNamespace ,再由 HNC 控制器元件根據 SubNamespace 自動建立 Namespace ,最終實現管理員僅可以在擁有許可權的租戶和專案下面建立名稱空間的許可權。
 
 
實際使用中,使用者建立租戶和專案的 CR 時,KubeCube 程式會自動監聽並建立相應的 SubeNamespace ,再由 HNC 控制器監聽並建立 Namespace ,繼而將租戶和專案與名稱空間關聯起來。
 
KubeCube 租戶模型採用多層級名稱空間的設計除了考慮許可權限定能夠相容原生 K8s 的 RBAC 外,還額外考慮到一個因素是可以放置租戶級的公共配置和專案級的公共配置,如針對整個專案的統一監控配置。在必要的時候,還可以指定 HNC 控制器將父級名稱空間的資源複製傳遞到子名稱空間,如使用者許可權繫結 RoleBinding 配置。

租戶專案許可權設計

KubeCube 多級租戶模型中預設了四種角色,它們的許可權由大到小分別是:
 
  • 平臺管理員:擁有最高許可權,負責管理 K8s 叢集,建立租戶,設定角色許可權和租戶配額。
  • 租戶管理員:擁有某個租戶的所有許可權,主要負責租戶下的專案管理。
  • 專案管理員:負責在 K8s 叢集上建立名稱空間,部署應用,配置監控。
  • 專案觀察員:僅擁有專案下名稱空間和資源的查詢許可權,可以檢視應用日誌和監控。
在實現上,四種角色是四個 ClusterRole 定義,使用 CluaterRoleBinding 可以給使用者授予平臺管理員許可權,使用 RoleBinding 可以給使用者授予受限的租戶管理員、專案管理員和專案觀察員許可權。在層級名稱空間結構中,授予一個使用者租戶管理員許可權相當於在租戶關聯的名稱空間及它所有下級名稱空間下建立 RoleBinding ,同理授予一個使用者專案管理員和專案觀察員許可權相當於在專案關聯的名稱空間及它所有下級名稱空間下建立 RoleBinding
 
 
HNC 控制器元件在建立 Namespace 的時候,可以指定把 SubNamespace 所在的父名稱空間的所有 RoleBinding 資訊往下複製傳遞。因此給使用者授予租戶管理員許可權時只需要在指定租戶關聯的名稱空間下建立 RoleBinding ,授權專案管理員和專案觀察員許可權時只需要在指定專案關聯的名稱空間下建立 RoleBinding ,許可權繫結關係會隨著名稱空間的建立逐級複製下發,最終在名稱空間下會擁有不同人不同角色的 RoleBinding 資訊。

資源配額管理設計

KubeCube 的配額管理主要是針對多租戶共享的 K8s 基礎設施叢集的資源分配,平臺管理員可以為每一個租戶劃分每一個 K8s 叢集的資源使用額度,包括 CPU、記憶體、磁碟和GPU的配額大小。租戶管理員可以繼續給專案劃分配額,專案管理員可以給每一個承載應用系統的名稱空間劃分配額。叢集資訊 Cluster (CRD)裡記錄著整個叢集的可用配額資訊,租戶和專案的配額資訊和已分配資訊儲存在 CubeResourceQuta (CRD)裡,名稱空間的配額資訊使用 K8s 原生 ResourceQuota
 
 
實際使用的時候,專案配額可以省略,如 KubeCube 預設整合的管理平臺,平臺管理員只需要給每一個租戶劃分每一個 K8s 叢集的可用額度,專案管理員在每一個 K8s 叢集上建立名稱空間的時候都不能分配超出所屬租戶的資源額度。

總結

KubeCube 多級租戶模型突破傳統的容器服務多租戶模式,採用租戶、專案和空間的三級結構,與企業組織架構和軟體管理適配,實現更細粒度的資源配額管理,滿足企業統一容器平臺的構建需求。以多層級名稱空間為基礎,租戶專案許可權隔離相容原生 RBAC,使得 KubeCube 多級租戶模型可以更好的相容原生 K8s 叢集,完全能夠在已有 K8s 叢集上進行原地升級安裝 KubeCube。
 
作者:KubeCube 社群
相關文章:
【影片】 KubeCube設計實踐,初學者玩好Kubernetes的正確姿勢 (需下載活動行APP)
KubeCube 專案主頁: https://www.kubecube.io
KubeCube 專案 GitHub: https://github.com/kubecube-io/kubecube
KubeCube 技術交流群: