北京最好白癜风医院排名 http://m.39.net/disease/a_c2i9w61.html1.
概述什么是KubeSphereConsole?KubeSphereConsole是KubeSphere集群的WebUI管理平台,提供可视化的方式管理K8s集群资源。KubeSphereConsole对于用户意味着什么?它可以帮助用户快速浏览集群当前运营状态,比如CPU消耗、内存消耗以及各个节点的健康状态。提供了可视化的方式,帮助用户快速创建K8s的资源。实时状态更新及详细的数据展示可以让平台资源对用户更透明。内置应用商店,帮助开发者在开发过程中快速部署一些常用的App。KubeSphere提供的远不止这些。这是KubeSphere目前前端的功能图,除了K8s基本的资源管理功能外,还有DevOps、日志、监控、微服务、灰度发布等功能。在项目开发上,截至2.1.0,KubeSphereConsole总共经历了6大版本,12个主要功能点,个GitCommits,总共11个代码贡献者。目前KubeSphereConsole已经在GitHub上开源了。为什么要做开源这件事?一是响应社区的号召,二是开发者参与到KubeSphere里,我们鼓励和欢迎这样的事情。希望能够和社区一起把KubeSphere建立得更加强大。2.前端架构接下来跟大家介绍KubeSphereConsole的前端架构。可以从两部分来说,我们主要采用前端Server和WebUI的架构。前端Server是基于Node.js和Koa.js开发,主要负责API转发、登录逻辑控制、配置文件写入等。Web端是一个标准的SPA应用。为什么选择前端Server,而不是像大部分的Web用Nginx托管?前端Server在完成静态页面托管、API转发的功能及前提之下,还可以完成其他的功能。使用前端Server,页面从前端Server输出,可以动态注入信息,比如配置文件、运行时、配置编码,还有用户的登录信息,不用你们在页面里,它可以提前写好,UI加载过程更加流畅。还有一些登录,像验证码、登录错误提示,比如验证码,如果前端来做会更好,放在后端的话很难找到合适的地方。像前端页面提供API,比如有一些比较复杂的应用需要一些数据,这些数据在Server里,不只是单纯写在js里,而是采用API的形式,采用API形式的话可以让我们拥有更好的定制能力,在不同的环境下是不一样的。接下来我来说Web层的技术,分为以下四部分:技术栈、组件化UI、状态管理和测试。技术栈是常用的React+Mobx.js。组件化UI是数据驱动。为什么选择这样的技术栈?人生苦短,当然选择最简单来做就完事了。React+Mobx.js在我们项目中的特点是具有轻量,比较容易学习,可以让我们更加专注业务开发。在WebUI,我们采用组件化方式进行构建,遵循原则和设计方法。什么是原则设计方法呢?很多人了解过,在此跟大家简单介绍。比如基本的标签是UI的原子,把这些标签整合起来形成一个简单的组件,比如按钮等这些是分子,我们在分子的基础上增加业务逻辑,把这些东西再组合形成模板,添加数据形成页面。KubeSphereConsole在里面实现了一套技术组件和一些比较复杂的业务组件。比如我们的样式、按钮和容器表单,这些是在KubeSphere里进行组件化的实践。这是组的功能,加大我们开发周期。这是容器组业务组件,它具有高内聚低耦合的特征。它输入的话只需要labelSelector进行筛选。筛选完之后可以输出关联、数据以及Porter里的容器信息,以及相关的监控数据,监听websocket,实时刷新列表。这样的组件可以在很多地方部署副本集,很轻松、很容易的复用。什么是状态管理?将组件和页面之间的状态统一管理起来,为什么要这样的状态管理?应用的状态影响着分布与许多组件之间,在大型应用里,这样的影响分布会让你的业务逻辑显得很混乱的状态。专门管理可以让数据流向变得清晰可循,可以让数据业务逻辑更容易进行复用。在KubeSphereConsole里大概分为四层状态管理,在全局Store里进行全局UI管理,websocket实例,路由实例等。模块管理,它是在某一个模块进入时初始化,退出的时候进行销毁。我们在KubeSphereConsole前面将业务划分为DevOps、项目、企业空间等,每个模块进入时,状态管理是独自加载的。分层设计的话可以让页面数据流量显得更清晰,设计周期更加简单。接下来介绍KubeSphereConsole测试化。为什么要有测试?测试是功能交互技术的保障。在单元测试方面,我们采用Jest+Enzyme的框架保证技术组件和业务组件的功能正常。我们着重于边界情况的测试,以及针对相关的BugReports进行覆盖。然后是端到端测试,主要目的是为了保证UI功能交互和展示效果上的运行。我们在端到端的测试里,与真实客户端进行交互,在总体上可以保证整个业务板块功能的正常。3.展望接下来我们一起探讨KubeSphereConsole未来的展望。KubeSphereConsole将如何成长?我们考虑到以下三方面:可扩展性、可监测性和业务抽象。什么是可扩展性?简单的说就是插件化,为什么要做这件事。不管是前端还是后端,只要业务功能持续增加,你的代码容量或者应用会变得庞大无比。进行差异化的改造要让核心模块保留,保留核心业务。其他业务功能以插件的形式加载进来,可以保证主体功能足够轻量。不同用户可以为自己专门的业务场景定制自己的插件。在部署运行时,整个系统看起来没那么多冗余的功能阻碍。前端页面监测系统,为什么要做这样的功能?因为我们发现很多用户实际前端页面运行场景中经常发生一些错误,我们要帮忙解决时很难复现。监测系统可以帮助记录错误的发生,更容易让我们Debug。主要包括异常监控、资源请求监控以及页面加载性能的监控,将监控信息、报错信息上传到特定的服务器上,有一个地方专门掌控前端的异常反馈,更容易帮助我们Debug。接下来是业务抽象。我们了解到很多用户对K8s的基础概念,比如Pods或者workload控制器,Depolyment,StatfulSet等,不是很了解,也不知道怎么做选择。我们考虑到这一点,打算在KubeSphereConsole里针对基础的资源进行一层抽象,让一些用户不用了解底层具体用了什么资源,而是它需要什么样的资源。用户需要某个服务,做出一些配置上的选择,我们来决定底层是什么样的资源实现。这样可以让一些用户更容易使用KubeSphere。今年的CloudNative+OpenSourceVirtualSummitChina中国峰会将首次以线上形式召开,KubeSphere团队为大家准备精彩话题及丰富的周边礼品,扫码直达,千万不要错过哦。
转载请注明:http://www.aierlanlan.com/rzdk/6454.html