KubeVela 1.3 发布：开箱即用的可视化应用交付平台，引入插件生态、权限认证、版本化等企业级新特性
作者：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，更好地完成业务目标，技术栈一成不变的时代早已过去。
下一代应用交付和管理需要具备灵活的装配能力，根据团队的需要，在最小能力集的基础上，以较小的成本扩充新的功能，同时让各种技术有效的智能协作，开发者学习成本却不能显著提高。只基于一套经验固化封装的传统 PaaS 方案，已经被验证了难以满足一个团队在产品演进过程中不断变化的场景需求。
3、新一代 DevOps 技术，面向复杂多样化的基础设施交付和管理应用。
十多年来，DevOps 技术一直伴随着开发者以提高生产效率为目标不断演进。如今来看，业务应用的制作流程也发生了很大的变化，从传统的编码、测试、打包、部署、运维观测，到如今云的基础设施不断加厚，各类 SaaS 服务直接以 API 的形式成为了应用的组成部分。应用从开发语言多样化，到部署环境多样化，再到组成成分的多样化，传统的 DevOps 工具链逐渐力不从心，而映射到用户这一层的就是不断增加的复杂性。
同样的 DevOps 理念，我们需要不一样的解决思路。现代化的应用交付和管理，我们依然有着同样的追求即尽可能减少人力投入，更加智能化。新一代的 DevOps 技术需要具备更易用的集成能力，服务治理能力，和观测与运维一体的管理能力。与此同时，工具需要简单好用，复杂留在平台内部。企业选择时能够结合自身业务需要，新架构与遗留的系统一同协作，组装合适自己团队的平台方案，避免新的平台成为业务开发者或企业的负担。
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 满足业务需求，又能具备很强的自定义能力，满足未来业务发展的需要。
围绕着这条路，在 1.3 版本中，社区带来了下述更新：
核心引擎：Kubernetes 多集群控制平面能力增强
应用不用改造，切换到多集群
企业已经完成应用云原生改造的基础上，切换到多集群部署是否还需要进行配置改造呢？答案是否定的。
KubeVela 天然建立在多集群基础之上，对于同一份应用描述，我们只需要在交付策略中指定需要交付的集群名称，或通过标签筛选特定集群即可，如图 4 所示应用配置代表将一个具有一个 nginx 组件的应用发布到标签为 region=hangzhou 的所有集群。
当然，图 4 所示的应用描述是完全以 OAM 推荐规范来的，如果你的现状是应用已经以 Kubernetes 原生资源的形式定义，不用担心，我们支持内嵌或引用的方式继承 Kubernetes 原生资源的描述风格，如下图 5 “引用 Kubernetes 资源做多集群部署”所示，描述了一个特殊应用，它的组件是依赖了一个管控集群中存在的 Secret 资源，将其发布到标签为 region=hangzhou 的所有集群。
除了应用的多集群部署以外，引用 Kubernetes 对象的功能还可以用于诸如已有资源的多集群复制，集群数据备份等场景。
处理多集群差异
应用统一描述之后，不同的集群部署时可能存在差异，如不同的区域采用不同的环境变量、不同的镜像仓库地址；又比如不同的集群部署不同的组件、或者一个组件在多个集群部署互为高可用等。针对这类需求，我们提供了部署差异描述策略，如下图 6 所示，这是应用配置的策略部分，第一和第二条 topology 类型的策略以两种方式定义了两个目标策略。第三差异性策略，代表只部署指定的组件。第四条差异性策略，代表部署指定的两个组件和其中一个组件的差异性镜像配置。
KubeVela 支持灵活的差异性配置策略，可通过组件属性、Trait 等形式来配置差异。如上图所示第三个策略表达了组件选择能力，第四个策略表达了镜像版本差异。我们可以看到，描述差异时没有指定目标，即差异性描述是可以复用的，它与目标策略在工作流步骤中进行灵活组合。
配置多集群交付流程
应用交付到不同的目标集群的过程是可控的，通过工作流描述部署过程。如图 7 所示，表达了部署到两个集群的步骤以及分别采用的目标策略和差异化策略。结合上文可知，策略部署只需要进行原子定义，在工作流部分可以灵活组合以实现不同场景的控制需求。
交付工作流有更多的使用场景，包括多集群灰度发布，企业审批，发布精确控制等等。
版本控制，安全可追溯
复杂应用的描述随着敏捷开发随时都在改变，为了保障应用发布安全，我们需要具有在发布时或发布后的任何时间可以让我们应用根据需要回到之前的某一个正确状态的能力。因此当前版本我们引入了更准确的版本记录机制。
我们可以查询应用的历史版本状态，包括了其发布时间和是否成功等。我们可以基于版本比对当前的变更，同样也可以在发布时遇到故障基于上一个成功版本渲染完成的配置快照快速回退。在新版本发布完成后如果遇到故障和其他需求需要重新发布历史版本，不用去变更配置源（路径可能会比较长，你也可能不记得进行了哪些变更），直接基于历史版本重新发布即可。
版本控制机制的背后是应用配置管理的集中化思想，应用完整描述统一渲染后进行统一检查，存储和下发。
查看 KubeVela 核心引擎用法的更多详情
- 多集群应用交付：
- 分发引用外部 Kubernetes 对象：
- 应用版本管理：
平台：VelaUX 引入多租隔离、用户认证和鉴权
多租隔离匹配多团队企业需要
在 VelaUX 中，我们引入了基于“项目”的概念来进行逻辑的多租隔离，包括应用交付目标，应用和环境，成员和权限等。当企业中存在多个团队或多个项目组同时使用 VelaUX 平台发布各自业务应用时该能力变得非常重要。图 9 所示为项目列表页面，项目管理员可根据团队需求在该页面创建不同的项目，从而分配对应的资源。
开放的认证&鉴权
作为一个基础平台，用户认证和鉴权能力是必须具备的基础能力之一。从 1.3 版本开始，我们支持了用户认证和 RBAC 鉴权。
对于用户认证我们相信大多数企业都有建设统一的认证平台（Oauth 或 LDAP），因此 VelaUX 集成 Dex 优先打通了单点登陆能力，支持 LDAP，OIDC，Gitlab/Github 等用户认证方式，把 VelaUX 作为你的开发者门户中的子系统之一。当然如果你的团队暂无统一认证的需求，我们同样提供了基础的本地用户认证能力。
对于鉴权，我们采用 RBAC 模式，但同时我们也看到了基础的 RBAC 模式无法处理精确权限控制场景，比如授权某一个应用的操作权给某用户，这类场景技术上涉及了数据授权。我们继承了 IAM 的设计理念，将权限扩展为资源+动作+条件+行为的策略组成，鉴权系统（前端 UI 鉴权/后端 API 鉴权）已经实现了面向策略的细粒度鉴权。但在授权方面当前版本仅内置了部分常用权限策略，后续版本提供自定义创建权限的能力。
同时我们也看到部分大型企业建设了独立的 IAM 平台，VelaUX 的 RBAC 数据模型与市场上常见 IAM 平台基本一致，因此希望将 VelaUX 对接到自建 IAM 的用户可以进行扩展支持。
运维配置集中管理，保障多集群应用分发安全
应用交付过程中必然会面对一些运维需求的配置管理，特别是多集群基础上，配置管理需求尤其突出，例如私有镜像仓库的认证配置，又或者 Helm 制品库的认证配置，又或者 SSL 证书等。我们需要统一管理这些配置的有效性并将其安全的同步到需要的地方，最好还不需要业务开发者感知。
1.3 版本我们在 VelaUX 中引入了集成配置管理的模块，它的底层同样采用组件模版和应用资源分发的链路来管理和分发配置，目前采用 Secret 进行配置存储和分发。配置的生命周期独立于业务应用，我们在每一个项目中独立维护配置的分发过程。对于管理员用户来说，只需要根据配置模版填写配置信息即可。
不同的配置类型由不同的 Addon 提供，用户可以根据需要定义更多了配置类型，统一进行管理。对于业务级配置管理目前也在社区的规划中。
查看 VelaUX 用法的更多详情
- 项目管理：
- 用户管理：
- RBAC 授权：
- 集成并使用单点登陆：
- 配置管理：
生态：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 渲染和部署能力。我们需要将其部署到子集群中，过去这个处理过程是分发到所有子集群。但社区反馈，对于不同的插件，不一定都需要安装到所有集群，我们需要一种差异性处理机制，按需的把扩展安装到指定的集群。
用户在启用 Addon 时可以指定需要部署的集群，系统将根据用户配置将插件完成部署。
Addon 生态增加新成员
在迭代扩展框架能力的同时，社区已有的 Addon 也在持续增加和升级。云服务支持层面，支持的厂商增加到 7 个。生态技术方面新增了AI 训练和服务化插件，Kruise Rollout 插件，Dex 插件等。同时 Helm Chart 插件和 OCM 集群管理插件也做了用户体验更新。
查看 Addon 用法的更多详情
- Addon 使用：
近期规划（Roadmap)
随着 KubeVela 内核的逐步稳定，可扩展内核的红利逐步释放，使得社区在 1.2 / 1.3 的版本演进逐渐加快。未来我们将以两个月为周期逐步迭代新的版本。在接下来的 1.4 版本中，我们将加入以下特性：
- 可观测性：围绕 log、metrics、traces 提供完整的可观测性方案，提供开箱即用的 KubeVela 系统可观测性，允许自定义可观测性配置，集成已有的可观测性组件或云资源。
- 离线安装：提供相对完整的离线安装工具和解决方案，方便更多的用户将 KubeVela 使用在离线环境中。
- 多集群权限管理：提供深入到 Kubernetes 多集群的权限管理能力。
- 更多开箱即用的插件生态能力。
KubeVela 社区期待你的加入，一起打造简单易用且标准化的下一代云原生应用交付和管理平台！
相关链接
[1] 三个月前发布的 v1.2 版本
[2] 集群本身规模的限制
[3] “Prodspec 和 Annealing”
[4] CRD Controller
本文为阿里云原创内容，未经允许不得转载。
