北京最好白癜风医院排名 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
