作者：孙健波（天元）
11 月 3 日，2022 杭州 · 云栖大会上，阿里云智能云原生利用平台总经理丁宇发表：KubeVela 面向四大外围方向能力降级，打造交付治理一体化的云原生利用平台。
本次降级是 KubeVela 从利用交付到利用治理一直质变造成的一次量变，同时也创始了业界基于可扩大模型构建交付和治理一体化利用平台的先河 。
降级次要面向四大外围方向：
- 资源状态可视化 。从利用首次部署到后续的继续交付，KubeVela 将整个利用资源的交付流程和拓扑构造通明可视化，并主动生成蕴含 100 多个外围指标的可观测性大盘，帮忙开发者自助式定位问题。更为重要的是，资源可视化能力能够轻松接入用户的自定义资源，满足用户的自定义可观测配置需要，实现在多集群层面的对立可观测。
- 平台能力插件化 。KubeVela 不仅建成了灵便可扩大、自助式装置的平台能力插件核心，还构建了 50 多款开箱即用的插件。这些插件蕴含了云资源、GitOps、可观测性、FinOps、IoT 等多种场景，帮忙业务开发者灵便构建面向不同场景的解决方案，并通过社区的实践经验大幅简化使用者的心智累赘。
- 交付流程自动化 。KubeVela 申明式工作流体系不仅具备操作系统资源的能力，还退出了条件判断、参数传递、分支并发等大量高级个性，每一个流程均能够通过配置语言编程扩大。包含多集群灰度公布、CI/CD 对接、平安合规接入在内的 10 多个场景化工作流帮忙开发者轻松实现自助式利用编排。
- 环境治理统一化 。你再也不须要为了装置 KubeVela 提前准备一个 Kubernetes 集群了，KubeVela 提供了在开发者本地或者虚拟机上自助式一键离线化装置整套管制立体的工具，联合多集群交付和治理能力，帮忙开发者实现开发、测试、生产的全流程多环境对立治理。
我的项目背景
随着云原生时代的到来，开发者为了构建合乎云原生的利用架构，不得不面对大量云和基础设施的简单 API，不仅应用难度大、学习门槛高，还会因为间接操作底层基础设施产生很大的稳定性危险。Kubernetes 很好的帮忙基础设施提供了对立的 API 集成界面，然而其定位是“为平台构建者提供的平台”，所以对于下层利用开发者而言就缺失了这样一层“以利用为核心”的应用界面。 凋谢利用模型（OAM）应运而生，它由阿里和微软在 2019 年联结公布，会集了两家企业在云原生利用开发中的大量实践经验，为构建云原生时代的利用平台提供了理论依据。
OAM 模型一经公布，便受到了包含 Oracle、腾讯、字节、第四范式在内的大量企业欢送和驳回。然而对于更多的企业而言，OAM 只是一个实践模型，不足能够间接应用的实际平台，难以落地。于是，阿里云的工程师联结社区驳回 OAM 的企业，基于大家的独特实际，一起构建了开箱即用的 OAM 实现引擎，KubeVela 便诞生了。
规范可扩大的利用交付引擎
KubeVela 于 2020 年 11 月正式公布，并始终保持以灵便可扩大、关注点拆散为设计准则，指标是将云原生技术组件和企业级利用连贯在一起，帮忙企业内的开发者疾速取得易于上手、安全可靠的软件交付和治理体验。 开源仅不到一年的工夫，便具备了多集群对立编排、基础设施无关、利用交付工作流等外围个性，受到社区用户宽泛的青睐，并于 2021 年 6 月正式退出 CNCF 基金会。
现在，KubeVela 已被招商银行、字节跳动、现实汽车、Shein 在内的 300 多家海内外企业采纳，整个 OAM 和 KubeVela 社区蕴含了数十个生态我的项目，累计取得了 8000 多个 star，收到了来自寰球数十个国家 300 多名开发者的大量奉献。
图 1 KubeVela 的对立利用交付
KubeVela 很好地帮忙企业构建了对立的利用交付能力，通过 KubeVela 的对立架构，企业能够在一份配置文件中同时交付微服务容器、云数据库、前端动态页面，以及他们外部自定义的扩大，实现多样化工作负载的编排和运维治理。业务利用的开发者在交付过程中也不再须要关怀 Kubernetes 资源的版本差别，又或者是不同云盘规格的差异。针对这一层对立的利用形容，KubeVela 提供了欠缺的版本治理、灰度公布、CI/CD 对接、多集群治理等性能，大大降低了企业外部应用云原生技术的门槛。
随着社区的一直倒退，越来越多的企业将 KubeVela 作为外部 PaaS 平台的外围引擎应用，基于 KubeVela 下层的对立模型和插件扩大机制，开发了一系列包含平安、可观测性、GitOps 等高级个性。 社区也涌现了一大批包含招商银行、Napptive、京东云在内的外围贡献者，为 KubeVela 生态奉献了大量新个性和插件，将 KubeVela 的边界逐步从利用交付延长到利用治理。
图 2 利用交付和治理一体化的利用平台
版本性能深刻解读
自 2021 年 4 月 KubeVela 正式公布 1.0 版本以来，OAM 模型也被 KubeVela 一直验证并逐步趋于稳定，KubeVela 历次版本迭代始终可能保障 API 向前兼容，对应 OAM 模型的 0.3.1 版本。依照 SemVer 对版本命名的国际惯例，本次公布的版本号为 1.6。尽管版本号只向前递增了 0.1，然而本次公布是从 1.2 版本公布一年多以来 KubeVela 面向利用治理能力的整体出现。接下来，咱们对外围性能逐个开展深刻的解读。
1.6 版本：
https://github.com/kubevela/k…
资源可视化成为一等公民
基于 OAM 模型的理念，可扩大与形象是 KubeVela 的两大外围特色。然而往往形象就代表黑盒化，用户一旦遇到问题难以排查，也无奈看到资源交付的停顿和状态，更是难以治理。而在本次公布中，咱们在可扩展性的根底上完满的解决了资源可视化的问题。对于 Kubernetes 的原生资源，KubeVela 会主动发现，并帮忙用户构建资源拓扑图。而对于用户本人扩大的自定义资源，则能够通过形容一份资源关联关系的配置，来自动化生成拓扑图。
这也意味着资源可视化在 KubeVela 体系中成为了一等公民，对于利用蕴含的任意工作负载，KubeVela 均能够残缺的描述拓扑关系、查看底层容器事件和日志、失去整体的交付衰弱状态。 如下图所示就是 KubeVela 的 UI 动画图。
图 3 VelaUX 资源可视化过程
VelaUX 文档：https://kubevela.net/docs/ref…
不仅如此，KubeVela 针对命令行用户也提供了一个相似“top”的交互界面，能够不便的查看交付的资源状态，充沛满足不同开发者的应用习惯！
图 4 vela top 命令行操作示意图
Vela top 命令行操作文档：
https://kubevela.net/docs/tutorials/vela-top
人造反对利用级可观测
“可观测性”是利用治理的重中之重，KubeVela 本次公布也对可观测性能力做了全面的晋升。具体蕴含三个局部：可观测基础设施搭建、面向利用的可观测、可观测即代码。
KubeVela 可观测能力文档：
https://kubevela.net/docs/pla…
可观测基础设施
对于不具备可观测性基础设施的用户而言，KubeVela 的插件体系能够帮你一键创立整个可观测软件栈。如下图所示，不仅蕴含了 Promethus、Grafana 这些常见的可观测服务，还蕴含 mysql-exporter 等面向业务场景的指标和日志采集。插件实现装置后就能够自动化看到平台内置的各项大盘，疾速构建利用平台的可观测。
图 5 开箱即用的可观测插件
对于曾经具备可观测服务的用户来说，KubeVela 也反对你将曾经部署好的 Promethus 和 Grafana 服务通过规范 API 的形式集成进来应用，当然也包含你自建或者云厂商提供的稳固、牢靠且不限容量的可观测服务 ，如阿里云的 ARMS 产品。
面向利用的可观测
KubeVela 的一大特点就是通过一个顶层利用形容（YAML）来驱动残缺的利用交付，可观测性能力天然也不例外。对于利用而言，其应用体验就是选用日志或者指标对应的运维特色，KubeVela 控制器便会主动为其生成对应的监控大盘。
图 6 面向利用的可观测
用户入口是面向利用的整体大盘，能够看到利用中的组件状态、版本信息、以及生成的资源，也蕴含了各类子资源对应的大盘链接，能够按需下钻看到更具体的信息。 你能够不便的站在利用的视角理解资源的全貌，无论是 Kubernetes 原生资源还是自定义资源。
可观测即代码（Observability as Code）
撑持利用可观测底层的能力则全副通过 IaC（Infrastructure as Code）的形式实现， 这也意味着 KubeVela 买通了从指标（含日志）采集、解析、富化、存储、数据源注册，始终到大盘可视化全链路的 IaC 化。
如下所示是一个通过 IaC 的形式创立 Grafana 大盘的示意图，该 IaC 模块提供了创立大盘“create-dashboard”这样的动作。相似的包含创立数据源、导入大盘等，这些惯例动作 KubeVela 社区曾经残缺内置，你无需学习其中的细节便能够间接应用。如果你想要做一些自定义，也齐全能够相似的通过 IaC 的形式编排你的流程，为你的平台自定义可观测能力。
图 7 可观测性即代码
多环境流水线对立治理
对于利用治理而言，开发、测试与生产不同环境治理也是难题之一。KubeVela 对立的利用模型不仅能够交付利用，也能够对环境做初始化，并且人造反对治理多集群，能够一键实现不同集群的基础设施组件装置。在 1.4 版本中咱们便公布了 VelaD 我的项目，能够不依赖 Kubernetes，在本地机器中一键拉起 KubeVela 的残缺环境。开发人员能够在本地（或虚拟机）疾速构建、验证利用，取得与生产统一的环境。而对不同环境的治理，也在本次公布中失去补齐。
本次公布退出了独立的流水线能力，相较于 KubeVela 自身具备的利用级工作流，独立的流水线具备以下个性：
- 它能够治理多个 KubeVela 利用，跨多个环境创立。
- 它不绑定利用，能够独立应用，如针对一组资源做扩缩容，针对一个利用做面向流程的灰度公布，批量执行一组运维操作。
- 它是一次性的，不对资源做治理，及时删除流水线也不会删除创立进去的资源。
- 它与利用流水线的执行引擎是同源的，这也齐全继承了 KubeVela 轻量级工作流的个性，相较于传统的基于容器的 CI 流水线，KubeVela 的流水线在执行各类资源操作时不依赖容器、无需额定的计算资源。
如下图所示，应用过程中咱们能够取得内置的流水线模板，填写环境上下文参数，而后疾速执行。而上面的例子就是通过流水线开启了多个 KuberVela 平台插件，插件背地就是 KubeVela 利用。
图 8 KubeVela 流水线 UI 示意图
集成并治理配置
配置管理也是利用治理的一大外围，KubeVela 的配置管理次要帮忙用户实现利用间配置的共享，并与第三方内部零碎做配置集成，实现配置的对立治理。例如连贯容器镜像仓库、Helm 仓库、第三方云服务（如上文提到的 ARMS 可观测套件）等内部零碎。
KubeVela 配置管理以 Kubernetes 的 Secret API 作为配置数据的载体，围绕的利用的应用按需进行多集群散发。利用可通过 Kubernetes 罕用的挂载 Secret 的形式读取配置，并对接权限体系。不仅如此，如果业务利用反对从 Nacos 等第三方配置管理平台读取配置，你也能够在定义配置模版时指定将配置内容输入到 Nacos 等服务，从而复用 Nacos 等注册核心的配置散发能力。
另外，你不仅能够从 UI/CLI 进行配置管理操作，也能够在利用工作流，流水线中进行配置读取和写入等操作。联合着流水线的数据传递能力和动作编排能力，实现利用间配置共享、配置自动化注入等更丰盛的场景。
图 9 配置管理示意图
KubeVela 的生态和将来
KubeVela 的此次降级在原先的利用交付根底上减少了大量利用治理的能力，是面向 “帮忙利用开发者取得易用、牢靠、平安的软件开发体验 ”指标后退的一大步。在 KubeVela 的实际下，咱们也在一直印证并欠缺 OAM 模型，在这里，咱们也想给大家分享一个好消息，信通院基于 OAM 公布的行业标准《云计算凋谢利用架构》也已正式出版，凋谢下载！
现在的 KubeVela 曾经不仅仅是一个基于 Kubernetes 的控制器，而是一个领有泛滥生态我的项目的平台。从底层基础设施对接，到下层面向用户的应用界面，再到可扩大的生态集成，KubeVela 正在疾速成长，兑现 OAM 公布之初的美妙愿景 ——“让利用的交付和治理更简略、平安、牢靠”！。
图 10 KubeVela 的工具生态
将来，KubeVela 社区将不断丰富开箱即用的零碎插件，丰盛面向场景的利用交付和治理解决方案，并将社区实际逐步积淀为 OAM 利用规范，建成一个开发、对立、标准化云原生利用生态。
扫码退出 KubeVela 社区交换群