KubeVela 1.3 发布:开箱即用的可视化应用交付平台,引入插件生态、权限认证、版本化等企业级新特性

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 得益于 KubeVela 社区上百位开发者的参与和 30 多位核心贡献者的 500 多次代码提交, KubeVela 1.3 版本正式发布。相较于三个月前发布的 v1.2 版本[1],新版本在 OAM 核心引擎(Vela Core),可视化应用交付平台 (VelaUX) 和社区插件生态这三方面都给出了大量新特性。

作者:KubeVela 社区


得益于 KubeVela 社区上百位开发者的参与和 30 多位核心贡献者的 500 多次代码提交, KubeVela 1.3 版本正式发布。相较于三个月前发布的 v1.2 版本[1],新版本在 OAM 核心引擎(Vela Core),可视化应用交付平台 (VelaUX) 和社区插件生态这三方面都给出了大量新特性。这些特性的诞生均源自于阿里巴巴、LINE、招商银行、爱奇艺等社区用户大量的深度实践,最终贡献到 KubeVela 项目中,形成大家可以开箱即用的功能。


现代化应用交付的痛点和挑战


那么,现代化的云原生应用交付和管理,我们到底遇到了什么痛点和挑战呢?


1、混合云、多集群成为业务常态,应用的组成不仅包含容器,还包含云资源和各类自建服务。

一方面,随着国内外云厂商不断发展,大多数企业构建基础设施的方式已经变成以云服务为主,自建为辅的模式。更多的传统企业可以直接享受云技术发展带来的业务便利,使用云的弹性、降低自建基础设施的成本。企业需要一个标准化的应用交付层,可以统一囊括容器、云服务和各类自建服务,以便可以轻易的达成云上云下的互通,降低繁琐的应用迁移带来的风险,上云无忧。


另一方面,为了基础设施稳定性和多环境隔离等安全风控因素,也受到 Kubernetes 集群本身规模的限制[2] ,越来越多的企业开始采纳多个 Kubernetes 集群来管理容器工作负载。如何在多集群层面管理、编排容器应用,解决好调度、依赖关系、版本、灰度等难题,同时提供给业务开发者一个低门槛的使用体验,是一个很大的挑战。


可以看到,现代化应用交付中涉及的混合云、多集群不光是多个 Kubernetes 集群,还包括云服务、SaaS、自建服务在内的多样化工作负载及运维能力。


2、超过 1000+ 的云原生生态技术和产品如何按需选择。


我们以加入 CNCF 生态的开源项目为例,其数量已经超过了 1000。对于不同规模阶段、不同行业,以及不同技术背景的团队来说,看似研发团队都在做相似的业务应用交付和管理,但是随着需求和使用场景的变化会衍生出技术栈的巨大差异,这里就涉及非常大的学习成本和集成、迁移使用门槛。而 CNCF 上千个生态项目又时刻诱惑着我们,集成新项目,加入新 feature,更好地完成业务目标,技术栈一成不变的时代早已过去。


image.gif1.png

图 1 CNCF Landscape


下一代应用交付和管理需要具备灵活的装配能力,根据团队的需要,在最小能力集的基础上,以较小的成本扩充新的功能,同时让各种技术有效的智能协作,开发者学习成本却不能显著提高。只基于一套经验固化封装的传统 PaaS 方案,已经被验证了难以满足一个团队在产品演进过程中不断变化的场景需求。


3、新一代 DevOps 技术,面向复杂多样化的基础设施交付和管理应用。

十多年来,DevOps 技术一直伴随着开发者以提高生产效率为目标不断演进。如今来看,业务应用的制作流程也发生了很大的变化,从传统的编码、测试、打包、部署、运维观测,到如今云的基础设施不断加厚,各类 SaaS 服务直接以 API 的形式成为了应用的组成部分。应用从开发语言多样化,到部署环境多样化,再到组成成分的多样化,传统的 DevOps 工具链逐渐力不从心,而映射到用户这一层的就是不断增加的复杂性。


同样的 DevOps 理念,我们需要不一样的解决思路。现代化的应用交付和管理,我们依然有着同样的追求即尽可能减少人力投入,更加智能化。新一代的 DevOps 技术需要具备更易用的集成能力,服务治理能力,和观测与运维一体的管理能力。与此同时,工具需要简单好用,复杂留在平台内部。企业选择时能够结合自身业务需要,新架构与遗留的系统一同协作,组装合适自己团队的平台方案,避免新的平台成为业务开发者或企业的负担。


KubeVela 的解法和路径


打造下一代应用交付平台,我们这么做:


image.gif2.png

图 2 分层的 OAM/KubeVela 生态体系


1、OAM 开放应用模型:标准先行,通过实践持续沉淀方法论


基于阿里和微软的内部实践经验,我们在 2019 年推出了 OAM 这一全新的应用模型和理念,其核心在于关注点分离,通过组件和运维特征这一层统一抽象,规范化云原生时代业务研发和运维人员之间的协作关系,提高交付和运维效率,同时也期望能够通过标准化的应用层避免不同基础设施差异带来的复杂性。随后我们便发布了 KubeVela 作为 OAM 模型的标准化实现,帮助企业能够快速落地 OAM,同时保证符合 OAM 规范的应用能够随处运行。简单来说,OAM 用声明式的方式描述了现代化应用完整的组成部分,而 KubeVela 则按照 OAM 声明的终态去运行,通过面向终态的控制循环,两者共同保证了应用交付的一致性和正确性。


最近我们看到谷歌发表的论文公布了其内部基础设施建设的成果 “Prodspec 和 Annealing”[3],其设计理念和实践方式与 “OAM 和 KubeVela” 惊人的相似,可见国内外不同的企业在云原生应用交付领域的实践殊途同归,这也侧面印证了标准化模型和 KubeVela 实践的正确性。未来,我们也将不断根据社区对 KubeVela 地实践和演进,推动 OAM 模型的发展,持续将最佳实践沉淀为方法论。


2、打造混合环境、多集群交付控制平面,充分满足不同规模、不同场景用户自建平台的需要

KubeVela 的内核以 CRD Controller [4]的形式存在,它可以轻易的被 Kubernetes 生态集成,OAM 模型也与 Kubernetes API 兼容。KubeVela 的微内核除了具备 OAM 模型的抽象和编排能力,还是一个天然面向多集群、混合云环境设计的应用交付控制平面。这也意味着 KubeVela 可以无缝的衔接云资源、容器等多样化的工作负载,在不同的云、不同集群下的编排和交付。


除了基本的编排能力,KubeVela 的特色之一是允许用户自定义交付工作流,工作流的步骤可以使用现成的功能如部署组件到集群、等待人工审批、发送通知等,也可以通过基于 CUE 配置语言的扩展能力集成任意 IaC 化的流程,如 K8s CRD、SaaS API、Terraform 模块、镜像脚本等。工作流执行过程中进入到稳定状态时(如等待人工审批),KubeVela 同样会自动化地做状态维持。KubeVela 的 IaC 扩展能力使得它可以以极低的成本集成 Kubernetes 的生态技术,它非常适合被平台构建者集成到自己的 PaaS 或交付系统中,可以通过 KubeVela 的扩展性将企业现有的能力集成进来,并作为标准化能力与其他生态能力一同呈现给用户。


3、开箱即用的可视化应用交付平台,直接满足中小团队的业务需求


除了先进的模型和扩展的内核,我们在社区也遇到了大量的用户呼声,它们希望能够拿到开箱即用的产品,以便更好、更快地采用 KubeVela。从 1.2 版本开始,社区便投入到了可视化应用交付平台(VelaUX)项目的研发中,它以 KubeVela 的内核能力为基础,贯穿标准化、可扩展的理念,通过插件生态(Addon)的方式,打造了面向 CI/CD 垂直场景的可视化应用交付平台。我们希望企业可以直接采用 VelaUX 满足业务需求,又能具备很强的自定义能力,满足未来业务发展的需要。


3.png

图 3 KubeVela 产品架构说明


围绕着这条路,在 1.3 版本中,社区带来了下述更新:


核心引擎:Kubernetes 多集群控制平面能力增强


应用不用改造,切换到多集群

企业已经完成应用云原生改造的基础上,切换到多集群部署是否还需要进行配置改造呢?答案是否定的。


KubeVela 天然建立在多集群基础之上,对于同一份应用描述,我们只需要在交付策略中指定需要交付的集群名称,或通过标签筛选特定集群即可,如图 4 所示应用配置代表将一个具有一个 nginx 组件的应用发布到标签为 region=hangzhou 的所有集群。


image.gif4.png

图 4 OAM 应用描述-选择部署集群


当然,图 4 所示的应用描述是完全以 OAM 推荐规范来的,如果你的现状是应用已经以 Kubernetes 原生资源的形式定义,不用担心,我们支持内嵌或引用的方式继承 Kubernetes 原生资源的描述风格,如下图 5 “引用 Kubernetes 资源做多集群部署”所示,描述了一个特殊应用,它的组件是依赖了一个管控集群中存在的 Secret 资源,将其发布到标签为 region=hangzhou 的所有集群。


image.gif5.png

图 5 引用 Kubernetes 资源做多集群部署


除了应用的多集群部署以外,引用 Kubernetes 对象的功能还可以用于诸如已有资源的多集群复制,集群数据备份等场景。


处理多集群差异

应用统一描述之后,不同的集群部署时可能存在差异,如不同的区域采用不同的环境变量、不同的镜像仓库地址;又比如不同的集群部署不同的组件、或者一个组件在多个集群部署互为高可用等。针对这类需求,我们提供了部署差异描述策略,如下图 6 所示,这是应用配置的策略部分,第一和第二条 topology 类型的策略以两种方式定义了两个目标策略。第三差异性策略,代表只部署指定的组件。第四条差异性策略,代表部署指定的两个组件和其中一个组件的差异性镜像配置。


image.gif6.png

图 6 多集群差异化配置


KubeVela 支持灵活的差异性配置策略,可通过组件属性、Trait 等形式来配置差异。如上图所示第三个策略表达了组件选择能力,第四个策略表达了镜像版本差异。我们可以看到,描述差异时没有指定目标,即差异性描述是可以复用的,它与目标策略在工作流步骤中进行灵活组合。


配置多集群交付流程


应用交付到不同的目标集群的过程是可控的,通过工作流描述部署过程。如图 7 所示,表达了部署到两个集群的步骤以及分别采用的目标策略和差异化策略。结合上文可知,策略部署只需要进行原子定义,在工作流部分可以灵活组合以实现不同场景的控制需求。


image.gif7.png

图 7 自定义多集群交付流程


交付工作流有更多的使用场景,包括多集群灰度发布,企业审批,发布精确控制等等。


版本控制,安全可追溯

复杂应用的描述随着敏捷开发随时都在改变,为了保障应用发布安全,我们需要具有在发布时或发布后的任何时间可以让我们应用根据需要回到之前的某一个正确状态的能力。因此当前版本我们引入了更准确的版本记录机制。


image.gif8.png

图 8 查询应用历史版本


我们可以查询应用的历史版本状态,包括了其发布时间和是否成功等。我们可以基于版本比对当前的变更,同样也可以在发布时遇到故障基于上一个成功版本渲染完成的配置快照快速回退。在新版本发布完成后如果遇到故障和其他需求需要重新发布历史版本,不用去变更配置源(路径可能会比较长,你也可能不记得进行了哪些变更),直接基于历史版本重新发布即可。


版本控制机制的背后是应用配置管理的集中化思想,应用完整描述统一渲染后进行统一检查,存储和下发。


查看 KubeVela 核心引擎用法的更多详情





平台:VelaUX 引入多租隔离、用户认证和鉴权


多租隔离匹配多团队企业需要

在 VelaUX 中,我们引入了基于“项目”的概念来进行逻辑的多租隔离,包括应用交付目标,应用和环境,成员和权限等。当企业中存在多个团队或多个项目组同时使用 VelaUX 平台发布各自业务应用时该能力变得非常重要。图 9 所示为项目列表页面,项目管理员可根据团队需求在该页面创建不同的项目,从而分配对应的资源。


image.gif9.png

图 9 项目管理页面


开放的认证&鉴权


作为一个基础平台,用户认证和鉴权能力是必须具备的基础能力之一。从 1.3 版本开始,我们支持了用户认证和 RBAC 鉴权。


对于用户认证我们相信大多数企业都有建设统一的认证平台(Oauth 或 LDAP),因此 VelaUX 集成 Dex 优先打通了单点登陆能力,支持 LDAP,OIDC,Gitlab/Github 等用户认证方式,把 VelaUX 作为你的开发者门户中的子系统之一。当然如果你的团队暂无统一认证的需求,我们同样提供了基础的本地用户认证能力。


10.png

图 10 本地用户管理页面


对于鉴权,我们采用  RBAC  模式,但同时我们也看到了基础的 RBAC  模式无法处理精确权限控制场景,比如授权某一个应用的操作权给某用户,这类场景技术上涉及了数据授权。我们继承了 IAM 的设计理念,将权限扩展为资源+动作+条件+行为的策略组成,鉴权系统(前端 UI 鉴权/后端 API 鉴权)已经实现了面向策略的细粒度鉴权。但在授权方面当前版本仅内置了部分常用权限策略,后续版本提供自定义创建权限的能力。


同时我们也看到部分大型企业建设了独立的 IAM 平台,VelaUX 的 RBAC 数据模型与市场上常见 IAM 平台基本一致,因此希望将 VelaUX 对接到自建 IAM 的用户可以进行扩展支持。


运维配置集中管理,保障多集群应用分发安全

应用交付过程中必然会面对一些运维需求的配置管理,特别是多集群基础上,配置管理需求尤其突出,例如私有镜像仓库的认证配置,又或者 Helm 制品库的认证配置,又或者 SSL 证书等。我们需要统一管理这些配置的有效性并将其安全的同步到需要的地方,最好还不需要业务开发者感知。


1.3 版本我们在 VelaUX 中引入了集成配置管理的模块,它的底层同样采用组件模版和应用资源分发的链路来管理和分发配置,目前采用 Secret 进行配置存储和分发。配置的生命周期独立于业务应用,我们在每一个项目中独立维护配置的分发过程。对于管理员用户来说,只需要根据配置模版填写配置信息即可。


image.gif11.png

图 11 集成配置管理页面


不同的配置类型由不同的 Addon 提供,用户可以根据需要定义更多了配置类型,统一进行管理。对于业务级配置管理目前也在社区的规划中。


查看 VelaUX 用法的更多详情







生态:Addon 引入版本控制


Addon 版本管理,升级更安全

Addon 功能在 1.2 版本中引入,提供一种扩展插件的规范、安装、运维的管理能力。社区可以通过制作不同的 Addon 来扩充 KubeVela 的生态能力。当我们的插件和框架都在持续迭代时,版本兼容性问题逐步凸显,我们急需一套版本管理机制。


  • 与 Vela 版本的协同机制:Addon 元数据中支持定义支持的 Vela 版本,当安装环境版本不匹配时拒绝安装。


  • Addon 版本化分发:我们在 Github 中进行社区官方 Addon 的开发和管理,每一个 Addon 除了集成的第三方产品版本以外,还包括了 Definition 等多种配置,因此 Addon 每一次发布后我们根据其定义的版本号进行打包,历史记录得以保留。同时我们复用了 Helm Chart 的制品分发 API 规范来分发 Addon。


多集群 Addon 可控安装

有一类 Addon 在安装时需要在子集群中安装,例如图 12 所示的 FluxCD 插件,它提供了 Helm Chart 渲染和部署能力。我们需要将其部署到子集群中,过去这个处理过程是分发到所有子集群。但社区反馈,对于不同的插件,不一定都需要安装到所有集群,我们需要一种差异性处理机制,按需的把扩展安装到指定的集群。


image.gif12.png

图 12  Addon 配置管理页面


用户在启用 Addon 时可以指定需要部署的集群,系统将根据用户配置将插件完成部署。


Addon 生态增加新成员


在迭代扩展框架能力的同时,社区已有的 Addon 也在持续增加和升级。云服务支持层面,支持的厂商增加到 7 个。生态技术方面新增了AI 训练和服务化插件,Kruise Rollout 插件,Dex 插件等。同时 Helm Chart 插件和 OCM 集群管理插件也做了用户体验更新。


查看 Addon 用法的更多详情



近期规划(Roadmap)


随着 KubeVela 内核的逐步稳定,可扩展内核的红利逐步释放,使得社区在 1.2 / 1.3 的版本演进逐渐加快。未来我们将以两个月为周期逐步迭代新的版本。在接下来的 1.4 版本中,我们将加入以下特性:


  • 可观测性:围绕 log、metrics、traces 提供完整的可观测性方案,提供开箱即用的 KubeVela 系统可观测性,允许自定义可观测性配置,集成已有的可观测性组件或云资源。
  • 离线安装:提供相对完整的离线安装工具和解决方案,方便更多的用户将 KubeVela 使用在离线环境中。
  • 多集群权限管理:提供深入到 Kubernetes 多集群的权限管理能力。
  • 更多开箱即用的插件生态能力。


KubeVela 社区期待你的加入,一起打造简单易用且标准化的下一代云原生应用交付和管理平台!


相关链接


[1] 三个月前发布的 v1.2 版本

https://kubevela.io/zh/blog/2022/01/27/blog-1.2


[2] 集群本身规模的限制

https://kubernetes.io/docs/setup/best-practices/cluster-large/


[3] “Prodspec 和 Annealing”

https://www.usenix.org/publications/loginonline/prodspec-and-annealing-intent-based-actuation-google-production


[4] CRD Controller

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/


您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节:

  • 项目代码库:github.com/oam-dev/kubevela 欢迎 Star/Watch/Fork!
  • 项目官方主页与文档:kubevela.io ,从 1.1 版本开始,已提供中文、英文文档,更多语言文档欢迎开发者进行翻译。
  • 项目钉钉群:23310022;Slack:CNCF #kubevela Channel
  • 加入微信群:请先添加以下 maintainer 微信号,表明进入KubeVela用户群:


13.png

点击此处,查看 KubeVela 项目官网。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
7天前
|
运维 监控 Android开发
应用研发平台EMAS产品常见问题之热更新和云发布不能共存如何解决
应用研发平台EMAS(Enterprise Mobile Application Service)是阿里云提供的一个全栈移动应用开发平台,集成了应用开发、测试、部署、监控和运营服务;本合集旨在总结EMAS产品在应用开发和运维过程中的常见问题及解决方案,助力开发者和企业高效解决技术难题,加速移动应用的上线和稳定运行。
|
6月前
|
弹性计算 JSON 数据可视化
Grafana 10 新特性解读,体验与协作全面提升
Grafana 10 新特性解读:体验与协作全面提升
31430 5
|
3月前
|
监控 数据可视化 前端开发
智慧工地云平台源码 支持二次开发、支持源码交付
智慧工地利用移动互联、物联网、云计算、大数据等新一代信息技术,彻底改变传统施工现场各参建方的交互方式、工作方式和管理模式,为建设集团、施工企业、监理单位、设计单位、政府监管部门等提供一揽子工地现场管理信息化解决方案。 通过人员管理、车辆管理、视频监控、施工质量、设备管理、环境监测、能耗监测七大维度提供面向工程管理人员的现场综合指挥管理平台,实现对劳务人员、大型机械、施工车辆等对象信息、行为、成果的智慧管理。 •支持多端展示(PC端、手机端、平板端); •数字孪生可视化大屏,一张图掌握项目整体情况; •使用轻量化模型,高效部署三维可视化管理,与一线生产过程相融合,集成数据后台,统一前端入口
53 1
|
7月前
|
Kubernetes 数据可视化 Cloud Native
【源码】低代码PaaS平台,用简单配置快速构建企业级应用程序
基于最先进的云原生技术搭建,整合了Kubernetes、微服务、Serverless、NoSQL 等最先进的技术架构,并提供了完善的自动化开发测试工具与运维管理工具。 基于moleculer 微服务架构开发,每个软件包、每个业务对象都是一个微服务,可以独立部署,独立运行。
|
11月前
|
存储 Kubernetes 供应链
|
11月前
|
存储 运维 Prometheus
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
作者: 晖树,天元KubeVela是一个开箱即用的现代化应用交付与管理平台,它通过统一的应用模型、可编程可扩展的架构,帮助企业构建统一的平台,向上为不同场景的业务团队按需提供差异化、且开箱即用的平台层能力,大大降低了云原生技术的使用门槛。除了核心的云资源交付、应用管理、多集群、工作流等技术,KubeVela 还提供了全栈的声明式可观测能力,帮助业务开发者灵活定制,轻松洞察各类复杂的云原生工作负载。
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
|
12月前
|
JSON 运维 Prometheus
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
11624 0
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
|
运维 资源调度 Kubernetes
「开源人说」第五期 | KubeVela:一场向应用交付标准的“冲锋”
「开源人说」第五期聚焦云原生领域开源至今仅两年多的项目——KubeVela,将镜头对准 KubeVela 项目背后的代码贡献者和落地实践者,讲述这个从第一天就诞生在社区的技术,如何走到对不同场景应用“海纳百川”,直至成为 CNCF 孵化项目,并逐渐向应用交付领域的事实标准演进的故事。 阅读下文,让我们跟随 KubeVela 创始团队,一起了解它的开源背后的故事。
199676 1
「开源人说」第五期 | KubeVela:一场向应用交付标准的“冲锋”
|
SQL JSON Kubernetes
KubeVela 项目和能力简介 | 学习笔记
快速学习 KubeVela 项目和能力简介
695 0
KubeVela 项目和能力简介 | 学习笔记
|
运维 Cloud Native API
KubeVela 插件指南:轻松扩展你的平台专属能力
本文作者为 KubeVela 社区贡献者 姜洪烨。 我在原文基础上做了适量修改。KubeVela 插件(addon)可以方便地扩展 KubeVela 的能力。正如我们所知,KubeVela 是一个微内核高度可扩展的平台,用户可以通过 模块定义(Definition)扩展 KubeVela 的系统能力,而 KubeVela 插件正是方便将这些自定义扩展及其依赖打包并分发的核心功能。不仅如此,Kube
KubeVela 插件指南:轻松扩展你的平台专属能力

相关产品

  • 云消息队列 MQ
  • 云消息队列 Kafka 版
  • 微服务引擎