一、核心组件
- ks-console 前端服务组件
- ks-apiserver后端服务组件
- ks-controller-manager资源状态维护组件
Kubesphere的后端设计中沿用了K8s声明式API的风格，所有可操作的资源都尽可能的抽象成为<code>CustomResource</code>与命令式API的使用更加简洁，并且提供了更好的抽象性，告诉程序最终的期望状态（做什么），而不关心怎么做。
典型的，在声明式API中：
- 你得API包含相对而言为数不多的，尺寸较小的对象（资源）。
- 对象定义了应用或者基础设施的配置信息。
- 对象更新操作频率较低。
- 通常需要人来读取或者写入对象。
- 对象的主要操作是CRUD风格的（创建、读取、更新和删除）。
- 不需要跨对象的事务支持：API对象代表的是期望状态而非确切实际状态。
命令式API与声明式有所不同，以下的特征表明你得API不是声明式的：
- 客户端发出“做这个操作”的指令，之后在该操作结束时获得同步响应。
- 客户端发出“做这个操作”的指令，并获得一个操作ID，之后需要判断请求是否成功完成。
- 你会将你得API类比为RPC。
- 直接存储大量数据。
- 在对象上执行的常规操作并非CRUD风格。
- API不太容易用对象来建模。
借助kube-apiserver、为题材的进行数据同步和数据持久化，通过ks-controller-manager维护这些资源的状态。以达到最终状态的一致性。
例如Kubesphere中的流水线、用户凭证、用户实体、告警通知的配置，都可以抽象为资源实体，借助K8s成熟的架构与工具链，可以方便的与K8s进行结合，降低各组件之间的耦合，降低系统的复杂度。
二、ks-apiserver 的核心架构
ks-apiserver是kubesphere核心的后端组件，负责后端数据的交互，请求的代理分发、认证与鉴权。下图是ks-apiserver的核心架构：
ks-apiserver的开发使用了<code>go-restful</code>框架，可以在请求链路中增加多个Filter用于动态的拦截请求和响应，实现认证、鉴权、审计逻辑转发和反向代理功能，Kubesphere的API风格也尽可能的学习<code>K8s的模式</code>，方便使用<code>RBAC</code>进行权限控制。
借助CRD +controller的方式进行解耦，可以极大的简化与第三方工具、软件的集成方式。
k8s摄取也提供了丰富的工具链，借助<code>controller-runtime和kubebuiler</code>可以迅速的搭建起开发脚手架
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的目的：
- 更好的对资源进行抽象，抽象为Object更适合声明式API
- 更好的对API进行管理，版本、分组、分层、更方便API的拓展
- 更好的与权限控制进行整合，可以方便的从请求中获取元数据，apigroup，scope，version，verb
权限控制
Kubesphere权限控制的核心是<code>RBAC</code>基于角色的访问控制
关键的对象有：Role、User、Rolebinding
Role定义了一个角色可以访问的资源
<font color = #999AAA>角色是根据资源层进行划分的，clusterrole、workspacerole、namespaceRole 不同层级的角色定义了该角色在当前层级可以访问的资源</font>
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的扩展，可以通过动态注册的方式进行创建，自定义资源可以是不同层级下。用户可以使用kubectl来创建和访问其中的对象，就像操作内置资源一样。
通过CRD对资源进行抽象，在通过 controller 去 watch 资源变化维护资源状态， controller 的核心是 Reconcile， 与他的意思一样，controller 会监听资源的变化，通过被动、定时触发的方式对资源状态进行维护，直至打到声明的状态。
以 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: admin@kubesphere.io
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再由k8s informer 同步到各个副本中
ks-controller-manager 通过watch informer 中的数据变化，对资源状态进行维护，以创建用户为例, 通过<font color = #999AAA>POST /apis/iam.kubesphere.io/v1alpha2/users </font>创建用户之后, ks-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"]
定义一个可以创建piepeline资源的角色
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"]
