KubeSphere 核心架构浅析

KubeSphere 是在 K8s 之上构建的面向云原生应用的容器混合云管理系统。支持多云与多集群管理，提供全栈的自动化运维能力，帮助企业用户简化 DevOps 工作流，提供运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。

KubeSphere 为用户提供构建企业级 K8s 环境所需的多项功能，例如多云与多集群管理、K8s 资源管理、DevOps、应用生命周期管理、微服务治理（服务网格）、日志查询与收集、服务与网络、多租户管理、监控告警、事件与审计查询、存储管理、访问权限控制、GPU 支持、网络策略、镜像仓库管理以及安全管理等。

得益于 K8s 优秀的架构与设计，KubeSphere 取长补短采用了更为轻量的架构模式，灵活的整合资源，进一步丰富了 K8s 生态。

KubeSphere 核心架构

KubeSphere 的核心架构如下图所示：

核心组件主要有三个：

• ks-console 前端服务组件

• ks-apiserver 后端服务组件

• ks-controller-manager 资源状态维护组件

KubeSphere 的后端设计中沿用了 K8s 声明式 API 的风格，所有可操作的资源都尽可能的抽象成为 CustomResource[1]。与命令式 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 中的流水线、用户凭证、用户实体、告警通知的配置，