KubeVela云原生时代的应用管理平台

　　在云原生时代，Kubernetes 项目已成为容器编排的行业标准，可是在应用管理这个领域却一直缺少一个行业标准 ；虽然也陆续出现过一些项目，但都没能成为标准，这其实也和各个企业的业务、技术架构有关，各个企业都在构建自己的应用管理平台，在自己的企业内部运行得非常完美，开源出来却难以适用于其它企业，所以在应用这个领域内很难形成一个类似于Kubernetes 这样的行业标准。本篇文章旨在给大家介绍一个最近在应用管理领域迅速发展并有望成为标准的项目--KubeVela。  01 背景
　　各个企业在拥抱云原生的过程中，大都不是一帆风顺的，在此列出一些常见问题：
　　Kubernetes 的学习成本大
　　目前，各个公司依靠 Kubernetes 强大的能力搭建了一个又一个统一的基础设施平台，对基础设施平台工程师而言，Kubernetes 为他们提供了便利，他们很容易就能把基础的资源，例如内存，CPU，网络，存储等给到开发人员。但是开发人员面对 Kubernetes 时，对其核心概念 Pod、Deployment、Statefulset、Service、Ingress、PVC、PV、CRD 等却是一头雾水，他们需要花很长的时间去理解熟悉这些概念，才能将自己开发的应用部署到服务器上去。在云原生时代，Kubernetes 提供了基础资源的抽象能力，面向的用户是基础设施团队而非业务开发团队，它的学习路线太过于陡峭，以至于影响了业务研发上线的进度。
　　基于 Kubernetes 的应用平台维护成本高
　　基于以上情况，很多公司都会基于 Kubernetes 来打造一个适合公司业务的应用平台。但是云原生社区的技术层出不穷，而且发展迅速，应用平台几个月不迭代就可能跟不上发展的脚步。当该平台需要新增功能的时候，可能需要开发人员造新的轮子，或者采用 CNCF 社区的成熟项目。如果选择造轮子的话，需要耗费大量的人力物力，而且新轮子的稳定性也需要时间去验证。如果借力社区成熟项目的话，就需要把新的项目集成到该平台中去，通过写一定的 ＂胶水＂ 代码来完成集成 ，初期不会有什么副作用，但是随着集成的项目越来越多，平台代码将变得越来越臃肿，以至于难以维护，更有甚者影响平台的稳定，牵一发而动全身。  02 KubeVela是什么？
　　KubeVela 的官方介绍是一个现代化的软件交付平台 ，它可以让你的应用交付在当今流行的混合、多云环境中变得更加简单、轻松、可靠。 可以理解为 KubeVela 是一个专为应用而生的管理平台，基于 Kubernetes 和 OAM 技术构建，涵盖了应用定义，应用管理，应用发布等功能，它简单易用而且可以高度拓展，能让开发和交付人员方便快捷地交付现代微服务应用。
　　KubeVela 项目发展迅速，其发展里程如下：
　　通过这几个版本的迭代更新，可以说 KubeVela 把简单易用，模块化，高度可拓展等特性都已实现了，企业可以基于 KubeVela 来灵活地构建自己的应用平台。
　　基于上文提到的问题，KubeVela 项目提供了自己的解决方案，它有如下的特点：
　　1. 提出了开放应用模型（OAM）来作为应用交付的顶层抽象 ，该模型支持交付任意类型的工作负载（包括容器、数据库甚至是虚拟机）到不同的云平台和 Kubernetes 集群中。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。应用只需要一次编排，就可以多处运行，免去了适配不同平台的痛苦。
　　2. 通过模块化设计，提供插件 addon 机制，拥有丰富的插件生态 ，官方提供的大量插件就能满足你开箱即用的需求，如遇到不满足的需求，还可以编写个性化插件，且并不需要改动平台的核心代码，就能轻松集成。
　　3. KubeVela 的整个交付模型完全是由用户声明式驱动的，兼顾用户体验和健壮性。 实现层通过 CUE 语言（一种源自 Google Borg 系统的数据配置语言）保证可扩展性，运行在 Kubernetes 之上，持续进行循环控制。这使得用户可以自由的根据需求场景来设计和选用交付工作流中的每一个步骤，满足业务快速增长的需求，同时持续保证生产环境面向终态的稳定性。
　　4. KubeVela 原生支持丰富的多集群/混合环境持续交付策略，也支持跨环境交付。 其既可作为统一的持续交付控制平面增强现有 CI/CD 流水线，也可以满足现代 GitOps 应用交付的趋势与要求，以基础设施即代码（IaC）的方式来驱动持续交付过程。 03 核心概念介绍
　　为了能够应对多变的交付环境，KubeVela 背后由一套完整的应用交付模型来进行运作，这个模型就是Open Application Model[1] ，简称 OAM ，其提供了各种组件，各种运维特性，各种发布策略，各种部署的 workflow，由这些东西拼在一起构成了一个统一的应用交付模型，进而实现能在目前复杂的环境中进行快速标准地交付和应用维护管理的需求。OAM 包括如下的概念：
　　应用（Application）
　　应用是定义了一个微服务业务单元所包括的制品（二进制、Docker 镜像、Helm Chart...）或云服务的交付和管理需求，它由组件（Component）、运维特征（Trait）、工作流（Workflow）、应用策略（Policy）四部分组成。  组件（Component）
　　组件是一个制品或云服务交付和管理形式的抽象，一个应用中可以包括多个组件，最佳的实践方案是一个应用中包括一个主组件（核心业务）和附属组件（强依赖或独享的中间件，运维组件等）。 运维特征（Trait）
　　运维特征是可以随时绑定给待部署组件的模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。 工作流（Workflow）
　　工作流由多个步骤组成，允许用户自定义应用在某个环境的交付过程。典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。 应用策略（Policy）
　　应用策略负责定义指定应用交付过程中的策略，比如质量保证策略、安全组策略、防火墙规则、SLO 目标、放置策略等。
　　插件（addon）
　　插件是 KubeVela 高度可拓展能力的体现，插件会将 KubeVela 中各种自定义的组件，运维特征，工作流，应用策略等能力打包到一起，在 kubevela 中可直接插拔使用。这样做的目的是能保证 KubeVela核心的精炼，又能根据自己的需求来添加新的功能。每一个插件一般会包括模块定义X-Definition ，代表它扩展的能力集合，以及第三方解决方案的安装包，如Kubernetes CRD 及其控制器等。
　　04 架构介绍
　　KubeVela 的整体架构如下所示：
　　KubeVela 作为一个应用发布平台的控制平面，可以部署在私有集群或者云平台上。它主要有如下几个组件： 核心控制器
　　为整个系统提供核心控制逻辑，完成诸如编排应用、生成 Kubernetes资源、运行工作流、修订版本快照、垃圾回收等等核心逻辑。 模块化能力控制器
　　负责对组件、运维特征、工作流、应用策略的 X-Definitions 对象进行注册和管理，提供自定义模块的能力。 插件控制器
　　负责注册和管理 KubeVela 运行所需要的第三方插件，比如 VelaUX、 Flux、Terraform 组件等等。 UI 控制台和 CLI
　　UI 控制台提供了一套可视化界面，服务于希望开箱即用的开发者用户，CLI 提供了一些快捷命令，适用于集成 KubeVela 和终端管理的用户。 05 案例分析
　　接下来就以一个实际的案例，来展示如何将 KubeVela应用到企业云原生应用平台中去。
　　背景：
　　目前的云原生应用平台是基于 Kubernetes 的 Deployment 作为应用的载体来实施部署的，对接了企业内原有的 CI/CD 系统，平台使用的用户越来越多，需求量激增。
　　需求：
　　1. 开发人员希望聚焦在应用层级，不关心底层的集群资源；
　　2. 应用类型增多，从原先只有 web 服务，到新增脚本任务，定时批处理任务，有状态服务等；
　　3. 应用运维人员希望可以定义弹性扩缩、升级发布、故障恢复等自动化运维策略
　　4. CI/CD 流程新增特殊功能节点。
　　...
　　可以看到，随着企业业务的快速发展，初期的云原生应用平台已经无法满足开发者的需求了，云平台需要进行迭代升级；但是平台开发者陷入了一个困境：平台的迭代速度已经跟不上需求产生的速度了 ，而且平台在开发的过程中积累了很多技术债，重构优化代码代价过大 ，只能放任，于是导致平台迭代的速度越来越慢。
　　那么有没有一个解决方案可以解决上述问题？答案就是接入 KubeVela 作为平台的核心驱动层，利用 KubeVela 对应用的抽象能力构建平台，使用高度可拓展的插件系统来拓展平台的能力，满足需求的快速变化。
　　方案：
　　应用列表
　　应用详情
　　架构
　　之前的应用平台是直接对接了 Kubernetes 集群，对 Kubernetes 的资源做了一些封装，暴露出来的还是原始的 Kubernetes 资源。
　　现在的方案是在云应用平台与集群之间加入了一层 KubeVela，通过 KubeVela 来实现应用的抽象。应用开发者在使用云应用平台的时候，更加容易的关注应用本身的参数，例如镜像，端口，副本数等；应用的运维人员也可以专注其运维方面的配置，比如域名配置，滚动发布，挂载存储之类等。
　　使用 KubeVela 作为中间层，有以下一些优点：
　　1. 把底层资源抽象成应用，减少开发者和运维人员的心智负担。
　　2. 利用 KubeVela 内置的能力给平台赋能，比如多集群部署，差异化配置等；借助完善的插件体系，在插件市场里可以找到适合的插件来实现需求，避免重复造轮子。
　　3. 也可以通过自定义插件来快速实现应用侧和运维侧的需求，再也不需要通过编写平台代码的方式，或者通过 CRD 的方式来响应需求的变化。
　　应用平台上层可以对接企业内已有的用户、租户体系，权限中心，审批中心等，使平台更容易管理。
　　应用的管理则是通过动态表单的方式渲染出 UI，来让用户完成对应用的定义，运维特性的定义，流程的定义等，然后平台把这些定义好的参数组装成一个个 Application 交给 KubeVela Core，KubeVela 负责将这些 Application 渲染成 Kubernetes 资源，下发到目标集群中去。其中采用动态表单是为了减少平台的代码改动，也可以理解为 UI 层面一定的抽象，前端通过插件内部定义好的动态表单 Schema 来展示不同内容。 06 总结
　　以上只是简单地介绍了一下 KubeVela 的基本概念，当然 KubeVela 的能力远不止这些，具体使用可以参考官方文档 KubeVela 简介 | KubeVela[2]。KubeVela 提供了一套可以实践的应用管理解决方案，大家可以尝试着与 CNCF 社区其它的项目进行碰撞，来构建适合自己企业的云应用平台。目前 KubeVela 社区是比较活跃的，两三个月就能发布一个新版本，具体的功能规划请参考 Roadmap | KubeVela [3]，如果对 KubeVela 感兴趣的话，可以尝试使用一下并积极加入 社区的讨论。