KubeSphere 核心架構淺析

作者簡介：萬宏明，KubeSphere 核心貢獻者，專注于云原生安全領域，

KubeSphere 是在 Kubernetes 之上構建的面向云原生應用的容器混合云管理系統，支持多云與多集群管理，提供全堆疊的自動化運維能力，幫助企業用戶簡化 DevOps 作業流，提供了運維友好的向導式操作界面，幫助企業快速構建一個強大和功能豐富的容器云平臺，

KubeSphere 為用戶提供構建企業級 Kubernetes 環境所需的多項功能，例如多云與多集群管理、Kubernetes 資源管理、DevOps、應用生命周期管理、微服務治理（服務網格）、日志查詢與收集、服務與網路、多租戶管理、監控告警、事件與審計查詢、存盤管理、訪問權限控制、GPU 支持、網路策略、鏡像倉庫管理以及安全管理等，

得益于 Kubernetes 優秀的架構與設計，KubeSphere 取長補短采用了更為輕量的架構模式，靈活的整合資源，進一步豐富了 K8s 生態，

KubeSphere 核心架構

KubeSphere 的核心架構如下圖所示：

核心組件主要有三個：

• ks-console 前端服務組件
• ks-apiserver 后端服務組件
• ks-controller-manager 資源狀態維護組件

KubeSphere 的后端設計中沿用了 K8s 宣告式 API 的風格，所有可操作的資源都盡可能的抽象成為 CustomResource，與命令式 API 相比，宣告性 API 的使用更加簡潔，并且提供了更好的抽象性, 告訴程式最終的期望狀態（做什么），而不關心怎么做，

典型地，在宣告式 API 中：

1. 你的 API 包含相對而言為數不多的、尺寸較小的物件（資源），
2. 物件定義了應用或者基礎設施的配置資訊，
3. 物件更新操作頻率較低，
4. 通常需要人來讀取或寫入物件，
5. 物件的主要操作是 CRUD 風格的（創建、讀取、更新和洗掉），
6. 不需要跨物件的事務支持：API 物件代表的是期望狀態而非確切實際狀態，

命令式 API（Imperative API）與宣告式有所不同， 以下跡象表明你的 API 可能不是宣告式的：

1. 客戶端發出“做這個操作”的指令，之后在該操作結束時獲得同步回應，
2. 客戶端發出“做這個操作”的指令，并獲得一個操作 ID，之后需要判斷請求是否成功完成，
3. 你會將你的 API 類比為 RPC，
4. 直接存盤大量資料，
5. 在物件上執行的常規操作并非 CRUD 風格，
6. API 不太容易用物件來建模，

借助 kube-apiserver、etcd 實作資料同步和資料持久化，通過 ks-controller-manager 維護這些資源的狀態，以達到最終狀態的一致性，如果你熟悉 K8s，可以很好的理解宣告式 API 帶來的好處，這也是 KubeSphere 最為核心的部分，

例如 KubeSphere 中的流水線、用戶憑證、用戶物體、告警通知的配置，都可以抽象為資源物體，借助 K8s 成熟的架構與工具鏈，可以方便的與 K8s 進行結合，降低各組件之間的耦合，降低系統的復雜度，

ks-apiserver 的核心架構

ks-apiserver 是 KubeSphere 核心的后端組件，負責前后端資料的互動、請求的代理分發、認證與鑒權，下圖是 ks-apiserver 的核心架構：

ks-apiserver 的開發使用了 go-restful 框架，可以在請求鏈路中增加多個 Filter 用于動態的攔截請求和回應，實作認證、鑒權、審計邏輯轉發和反向代理功能，KubeSphere 的 API 風格也盡可能的學習 K8s 的模式，方便使用 RBAC 進行權限控制，

借助 CRD + controller 的方式進行解耦，可以極大的簡化與第三方工具、軟體的集成方式，

K8s 社區也提供了豐富的工具鏈，借助 controller-runtime 和 kubebuiler 可以迅速的搭建起開發腳手架，

API 聚合與權限控制

可以通過拓展 ks-apiserver 實作 API 的聚合，進一步實作功能拓展、聚合查詢等功能，在 API 的開發程序中中需要遵循以下規范，以便與 KubeSphere 的租戶體系、資源體系進行整合，

• API 聚合
• 權限控制
• CRD + controller

API 規范

# 通過 api group 進行分組
/apis/{api-group}/{version}/{resources}
# 示例
/apis/apps/v1/deployments
/kapis/iam.kubesphere.io/v1alpha2/users
# api core
/api/v1/namespaces

# 通過 path 區分不同的動作
/api/{version}/watch/{resources}
/api/{version}/proxy/{resources}/{resource}

# 通過 path 區分不同的資源層級
/kapis/{api-group}/{version}/workspaces/{workspace}/{resources}/{resource}
/api/{version}/namespaces/{namespace}/{resource}

規范 API 的目的：

1. 更好的對資源進行抽象，抽象為 Object 更適合宣告式 API
2. 更好的對 API 進行管理，版本、分組、分層，更方便 API 的拓展
3. 更好的與權限控制進行整合，可以方便的從請求中獲取元資料，apigroup,scope,version,verb

權限控制

KubeSphere 權限控制的核心是 RBAC 基于角色的訪問控制，

關鍵的物件有： Role、User、RoleBinding，

Role 定義了一個角色可以訪問的資源，

角色是根據資源層級進行劃分的，cluster role、workspace role、namespace role 不同層級的角色定義了該角色在當前層級可以訪問的資源，

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  # 忽略 resourceNames 意味著允許系結任何 ClusterRole
  resourceNames: ["admin","edit","view"]
- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一個全域通配符
  verbs: ["get", "post"]

RoleBinding 可系結角色到某主體（Subject）上， 主體可以是組，用戶或者服務賬戶，

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: role-grantor-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

CRD + controller

自定義資源（Custom Resource） 是對 Kubernetes API 的擴展，可以通過動態注冊的方式拓展 K8s API，用戶可以使用 kubectl 來創建和訪問其中的物件，就像操作內置資源一樣，

通過 CRD 對資源進行抽象，再通過 controller 監聽資源變化維護資源狀態， controller 的核心是 Reconcile，與他的意思一樣，通過被動、定時觸發的方式對資源狀態進行維護，直至達到宣告的狀態，

以 User 資源為例，我們可以定義一下結構的 CRD 對 User 進行抽象:

apiVersion: iam.kubesphere.io/v1alpha2
kind: User
metadata:
  annotations:
    iam.kubesphere.io/last-password-change-time: "2021-05-12T05:50:07Z"
  name: admin
  resourceVersion: "478503717"
  selfLink: /apis/iam.kubesphere.io/v1alpha2/users/admin
  uid: 9e438fcc-f179-4254-b534-e913dfd7a727
spec:
  email: [email protected]
  lang: zh
  description: 'description'
  password: $2a$10$w312tzLTvXObnfEYiIrk9u5Nu/reJpwQeI66vrM1XJETWtpjd1/q2
status:
  lastLoginTime: "2021-06-08T06:37:36Z"
  state: Active

對應的 API 為：

# 創建
POST /apis/iam.kubesphere.io/v1alpha2/users

# 洗掉
DELETE /apis/iam.kubesphere.io/v1alpha2/users/{username}

# 修改
PUT /apis/iam.kubesphere.io/v1alpha2/users/{username}
PATCH /apis/iam.kubesphere.io/v1alpha2/users/{username}

# 查詢
GET /apis/iam.kubesphere.io/v1alpha2/users
GET /apis/iam.kubesphere.io/v1alpha2/users/{username}

ks-apiserver 負責將這些資料寫入 K8s 再由 informer 同步到各個副本中，

ks-controller-manager 通過監聽資料變化，對資源狀態進行維護，以創建用戶為例, 通過 POST /apis/iam.kubesphere.io/v1alpha2/users 創建用戶之后, user controller 會對用戶資源狀態進行同步，

func (c *userController) reconcile(key string) error {
	// Get the user with this name
	user, err := c.userLister.Get(key)

        if err != nil {
            // The user may no longer exist, in which case we stop
            // processing.
            if errors.IsNotFound(err) {
                utilruntime.HandleError(fmt.Errorf("user '%s' in work queue no longer exists", key))
                return nil
            }
            klog.Error(err)
            return err
        }

	if user, err = c.encryptPassword(user); err != nil {
		klog.Error(err)
		return err
	}

	if user, err = c.syncUserStatus(user); err != nil {
		klog.Error(err)
		return err
	}

	// synchronization through kubefed-controller when multi cluster is enabled
	if c.multiClusterEnabled {
		if err = c.multiClusterSync(user); err != nil {
			c.recorder.Event(user, corev1.EventTypeWarning, controller.FailedSynced, fmt.Sprintf(syncFailMessage, err))
			return err
		}
	}

	c.recorder.Event(user, corev1.EventTypeNormal, successSynced, messageResourceSynced)
	return nil
}

通過宣告式的 API 將復雜的邏輯放到 controller 進行處理，方便解耦，可以很方便的與其他系統、服務進行集成，例如：

/apis/devops.kubesphere.io/v1alpha2/namespaces/{namespace}/pipelines
/apis/devops.kubesphere.io/v1alpha2/namespaces/{namespace}/credentials
/apis/openpitrix.io/v1alpha2/namespaces/{namespace}/applications
/apis/notification.kubesphere.io/v1alpha2/configs

對應的權限控制策略：

定義一個可以增刪改查 user 資源的角色，

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: user-manager
rules:
- apiGroups: ["iam.kubesphere.io"]
  resources: ["users"]
  verbs: ["create","delete","patch","update","get","list"]

定義一個可以創建 pipeline 資源的角色，

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: devops-manager
rules:
- apiGroups: ["devops.kubesphere.io"]
  resources: ["pipelines"]
  verbs: ["create","delete","patch","update","get","list"]

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：Microsoft Project XCloud 分析

下一篇：開發人員體驗：API 成功的關鍵