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 落地應用
KubeCube 項目主頁：https://www.kubecube.io
KubeCube 技術交流群：
留言列表