Kubesphere 源码分析4 ks-console

1. 概述

ks-console主要是作为用户和kubereshpere交互的入口，主要为用户提供页面的交互方式，以及少量API接口。
如图所示，ks-console第一层级主要包含会话管理，其他API，页面。

1. 会话管理主要是登录授权后维持用户token等的权限cache
2. 其他API主要是直接提供了部分和dockerhub或者下载的部分API
3. 页面主要提供用户的交互入口

从页面功能来看，又分为管理页面和终端页面，终端页面是提供在页面上使用命令行直接与kubernetes的交互界面，管理页面则是集成化的对整个kubesphere的管理

管理业面又主要分为集群管理，权限管理和系统设置

• 集群管理 管理集群的整体资源
• 权限管理 管理用户或用户组的权限
• 系统设置 对系统邮箱，webhook等全局配置进行管理

console-mind.png

2. 结构分析

如图所示

1. 路由层是整个前段系统的入口，主要使用koa提供了最外层的服务框架，其中嵌入了配置管理config和部分交互数据压缩等的中间件工具utils。
2. 会话层主要是提供了用户的登录，以及登录后的session数据维持管理; 主要提供页面的访问入口。此外还有dockerhub等API接口。
3. 路由分发层则从业面上做了功能分发，提供管理页面（kubesphere pages）以及终端页面(terminal)两个访问入口。
4. 页面逻辑层中才是管理页面的真正实现，使用react框架，完成了页面的支持。
5. 管理页面或者终端页面都将最终在后台API层通过ks-apiserver 与后台交互。

terminal.png

• 路由层
  如下所示，可以看到在路有层中，根据访问路径对业务进行分发，包括基本工具API，登录管理API，终端页面，和最后的用户管理页面。

router
  .use(proxy('/devops_webhook/(.*)', devopsWebhookProxy))
  .use(proxy('/b2i_download/(.*)', b2iFileProxy))
  .get('/dockerhub/(.*)', parseBody, handleDockerhubProxy)
  .get('/blank_md', renderMarkdown)
 
  .all('/(k)?api(s)?/(.*)', checkToken, checkIfExist)
  .use(proxy('/(k)?api(s)?/(.*)', k8sResourceProxy))
 
  .get('/sample/:app', parseBody, handleSampleData)
 
  // session
  .post('/login', parseBody, handleLogin)
  .get('/login', renderLogin)
  .post('/login/confirm', parseBody, handleLoginConfirm)
  .get('/login/confirm', renderLoginConfirm)
  .post('/logout', handleLogout)
 
  // oauth
  .get('/oauth/redirect/:name', handleOAuthLogin)
 
  // terminal
  .get('/terminal*', renderTerminal)
  // page entry
  .all('*', renderView)

• 路由分发层
  注意前面最后路由分发的 renderTerminal 和 renderView其实现如下，该层是根据路由的路径不同，去查询对应打包文件中的页面入口，从而真正让用户进入终端页面和管理业面。

const renderIndex = async (ctx, params) => {
  const manifest = getManifest('main')
  const localeManifest = getLocaleManifest()
 
  await ctx.render('index', {
    manifest,
    isDev: global.MODE_DEV,
    title: clientConfig.title,
    hostname: ctx.hostname,
    globals: JSON.stringify({
      config: clientConfig,
      localeManifest,
      ...params,
    }), 
  })
}
 
const renderTerminal = async ctx => {
  try {
    const manifest = getManifest('terminalEntry')
    const [user, ksConfig] = await Promise.all([
      getCurrentUser(ctx),
      getKSConfig(),
    ])  
    const localeManifest = getLocaleManifest()
 
    await ctx.render('terminal', {
      manifest,
      isDev: global.MODE_DEV,
      title: clientConfig.title,
      hostname: ctx.hostname,
      globals: JSON.stringify({
        localeManifest,
        user,
        ksConfig,
      }), 
    })  
  } catch (err) {
    renderViewErr(ctx, err)
  }
}

• 页面逻辑层
  因为终端页面直接使用的第三方库，因此基本没有开发逻辑，而管理页面则是使用react实现后打包完成.
  其目录入下具体实现都按照react的规范设计, 在后面章节单独分析。

3. 页面结构

1. actions 调用底层最终的交互动作封装
2. assets 各种常量
3. configs 配置管理
4. pages 页面的封装
5. core 二次封装，整体入口
6. compents 套件封装
7. sccss 样式
8. storages 页面数据管理
9. utils 工具封装

code-tree.png

下面对管理页面整体结构分析

• 首先index是整个页面的入口。
• index中包含的route则是陆游的入口。
• 路由注册了两种页面，一种是导航页面view1, 一种是逻辑页面view2。
  逻辑页面会交互完成集群查询管理，节点管理等具体逻辑功能。而导航页面则只负责展示导航列并提供点击做页面跳转。
• 导航页面支持动态呈现，其通过global组件从config里面获取页面元素和布局，动态展现支持的资源提供跳转链接。
• 逻辑页面则是导航页面跳转的。
• 逻辑页面通过controller调用action中的模块和后台交互，管理获取后台的实际资源。
• 而store则是在前端存取的后台资源的cache。
• view展示数据时对应的后台资源则从store获取。

react.png