共计 7204 个字符，预计需要花费 19 分钟才能阅读完成。
简介：得益于 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，更好地实现业务指标，技术栈变化无穷的时代早已过来。
图 1 CNCF Landscape
下一代利用交付和治理须要具备灵便的拆卸能力，依据团队的须要，在最小能力集的根底上，以较小的老本裁减新的性能，同时让各种技术无效的智能合作，开发者学习老本却不能显著进步。只基于一套教训固化封装的传统 PaaS 计划，曾经被验证了难以满足一个团队在产品演进过程中一直变动的场景需要。
3、新一代 DevOps 技术，面向简单多样化的基础设施交付和治理利用。
十多年来，DevOps 技术始终随同着开发者以进步生产效率为指标一直演进。现在来看，业务利用的制作流程也产生了很大的变动，从传统的编码、测试、打包、部署、运维观测，到现在云的基础设施一直加厚，各类 SaaS 服务间接以 API 的模式成为了利用的组成部分。利用从开发语言多样化，到部署环境多样化，再到组成成分的多样化，传统的 DevOps 工具链逐步力不从心，而映射到用户这一层的就是一直减少的复杂性。
同样的 DevOps 理念，咱们须要不一样的解决思路。现代化的利用交付和治理，咱们仍然有着同样的谋求即尽可能减少人力投入，更加智能化。新一代的 DevOps 技术须要具备更易用的集成能力，服务治理能力，和观测与运维一体的治理能力。与此同时，工具须要简略好用，简单留在平台外部。企业抉择时可能联合本身业务须要，新架构与遗留的零碎一起合作，组装适合本人团队的平台计划，防止新的平台成为业务开发者或企业的累赘。
KubeVela 的解法和门路
打造下一代利用交付平台，咱们这么做：
图 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 KubeVela 产品架构阐明
围绕着这条路，在 1.3 版本中，社区带来了下述更新：
外围引擎：Kubernetes 多集群管制立体能力加强
利用不必革新，切换到多集群
企业曾经实现利用云原生革新的根底上，切换到多集群部署是否还须要进行配置革新呢？答案是否定的。
KubeVela 人造建设在多集群根底之上，对于同一份利用形容，咱们只须要在交付策略中指定须要交付的集群名称，或通过标签筛选特定集群即可，如图 4 所示利用配置代表将一个具备一个 nginx 组件的利用公布到标签为 region=hangzhou 的所有集群。
图 4 OAM 利用形容 - 抉择部署集群
当然，图 4 所示的利用形容是齐全以 OAM 举荐标准来的，如果你的现状是利用曾经以 Kubernetes 原生资源的模式定义，不必放心，咱们反对内嵌或援用的形式继承 Kubernetes 原生资源的形容格调，如下图 5“援用 Kubernetes 资源做多集群部署”所示，形容了一个非凡利用，它的组件是依赖了一个管控集群中存在的 Secret 资源，将其公布到标签为 region=hangzhou 的所有集群。
图 5 援用 Kubernetes 资源做多集群部署
除了利用的多集群部署以外，援用 Kubernetes 对象的性能还能够用于诸如已有资源的多集群复制，集群数据备份等场景。
解决多集群差别
利用对立形容之后，不同的集群部署时可能存在差别，如不同的区域采纳不同的环境变量、不同的镜像仓库地址；又比方不同的集群部署不同的组件、或者一个组件在多个集群部署互为高可用等。针对这类需要，咱们提供了部署差别形容策略，如下图 6 所示，这是利用配置的策略局部，第一和第二条 topology 类型的策略以两种形式定义了两个指标策略。第三差异性策略，代表只部署指定的组件。第四条差异性策略，代表部署指定的两个组件和其中一个组件的差异性镜像配置。
图 6 多集群差异化配置
KubeVela 反对灵便的差异性配置策略，可通过组件属性、Trait 等模式来配置差别。如上图所示第三个策略表白了组件抉择能力，第四个策略表白了镜像版本差别。咱们能够看到，形容差别时没有指定指标，即差异性形容是能够复用的，它与指标策略在工作流步骤中进行灵便组合。
配置多集群交付流程
利用交付到不同的指标集群的过程是可控的，通过工作流形容部署过程。如图 7 所示，表白了部署到两个集群的步骤以及别离采纳的指标策略和差异化策略。联合上文可知，策略部署只须要进行原子定义，在工作流局部能够灵便组合以实现不同场景的管制需要。
图 7 自定义多集群交付流程
交付工作流有更多的应用场景，包含多集群灰度公布，企业审批，公布准确管制等等。
版本控制，平安可追溯
简单利用的形容随着麻利开发随时都在扭转，为了保障利用公布平安，咱们须要具备在公布时或公布后的任何工夫能够让咱们利用依据须要回到之前的某一个正确状态的能力。因而以后版本咱们引入了更精确的版本记录机制。
图 8 查问利用历史版本
咱们能够查问利用的历史版本状态，包含了其公布工夫和是否胜利等。咱们能够基于版本比对以后的变更，同样也能够在公布时遇到故障基于上一个胜利版本渲染实现的配置快照疾速回退。在新版本公布实现后如果遇到故障和其余需要须要从新公布历史版本，不必去变更配置源（门路可能会比拟长，你也可能不记得进行了哪些变更），间接基于历史版本从新公布即可。
版本控制机制的背地是利用配置管理的集中化思维，利用残缺形容对立渲染后进行对立查看，存储和下发。
查看 KubeVela 外围引擎用法的更多详情
多集群利用交付：
https://kubevela.net/zh/docs/…
散发援用内部 Kubernetes 对象：
https://kubevela.net/zh/docs/…
利用版本治理：
https://kubevela.net/zh/docs/…
平台：VelaUX 引入多租隔离、用户认证和鉴权
多租隔离匹配多团队企业须要
在 VelaUX 中，咱们引入了基于“我的项目”的概念来进行逻辑的多租隔离，包含利用交付指标，利用和环境，成员和权限等。当企业中存在多个团队或多个项目组同时应用 VelaUX 平台公布各自业务利用时该能力变得十分重要。图 9 所示为我的项目列表页面，我的项目管理员可依据团队需要在该页面创立不同的我的项目，从而调配对应的资源。
图 9 项目管理页面
凋谢的认证 & 鉴权
作为一个根底平台，用户认证和鉴权能力是必须具备的根底能力之一。从 1.3 版本开始，咱们反对了用户认证和 RBAC 鉴权。
对于用户认证咱们置信大多数企业都有建设对立的认证平台（Oauth 或 LDAP），因而 VelaUX 集成 Dex 优先买通了单点登陆能力，反对 LDAP，OIDC，Gitlab/Github 等用户认证形式，把 VelaUX 作为你的开发者门户中的子系统之一。当然如果你的团队暂无对立认证的需要，咱们同样提供了根底的本地用户认证能力。
图 10 本地用户治理页面
对于鉴权，咱们采纳 RBAC 模式，但同时咱们也看到了根底的 RBAC 模式无奈解决准确权限管制场景，比方受权某一个利用的操作权给某用户，这类场景技术上波及了数据受权。咱们继承了 IAM 的设计理念，将权限扩大为资源 + 动作 + 条件 + 行为的策略组成，鉴权零碎（前端 UI 鉴权 / 后端 API 鉴权）曾经实现了面向策略的细粒度鉴权。但在受权方面以后版本仅内置了局部罕用权限策略，后续版本提供自定义创立权限的能力。
同时咱们也看到局部大型企业建设了独立的 IAM 平台，VelaUX 的 RBAC 数据模型与市场上常见 IAM 平台基本一致，因而心愿将 VelaUX 对接到自建 IAM 的用户能够进行扩大反对。
运维配置集中管理，保障多集群利用散发平安
利用交付过程中必然会面对一些运维需要的配置管理，特地是多集群根底上，配置管理需要尤其突出，例如公有镜像仓库的认证配置，又或者 Helm 制品库的认证配置，又或者 SSL 证书等。咱们须要对立治理这些配置的有效性并将其平安的同步到须要的中央，最好还不须要业务开发者感知。
1.3 版本咱们在 VelaUX 中引入了集成配置管理的模块，它的底层同样采纳组件模版和利用资源散发的链路来治理和散发配置，目前采纳 Secret 进行配置存储和散发。配置的生命周期独立于业务利用，咱们在每一个我的项目中独立保护配置的散发过程。对于管理员用户来说，只须要依据配置模版填写配置信息即可。
图 11 集成配置管理页面
不同的配置类型由不同的 Addon 提供，用户能够依据须要定义更多了配置类型，对立进行治理。对于业务级配置管理目前也在社区的布局中。
查看 VelaUX 用法的更多详情
项目管理：
https://kubevela.net/zh/docs/…
用户治理：
https://kubevela.net/zh/docs/…
RBAC 受权：
https://kubevela.net/zh/docs/…
集成并应用单点登陆：
https://kubevela.net/zh/docs/…
配置管理：
https://kubevela.net/zh/docs/…
生态：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 渲染和部署能力。咱们须要将其部署到子集群中，过来这个处理过程是散发到所有子集群。但社区反馈，对于不同的插件，不肯定都须要装置到所有集群，咱们须要一种差异性解决机制，按需的把扩大装置到指定的集群。
图 12 Addon 配置管理页面
用户在启用 Addon 时能够指定须要部署的集群，零碎将依据用户配置将插件实现部署。
Addon 生态减少新成员
在迭代扩大框架能力的同时，社区已有的 Addon 也在继续减少和降级。云服务反对层面，反对的厂商减少到 7 个。生态技术方面新增了 AI 训练和服务化插件，Kruise Rollout 插件，Dex 插件等。同时 Helm Chart 插件和 OCM 集群治理插件也做了用户体验更新。
查看 Addon 用法的更多详情
Addon 应用：https://kubevela.net/zh/docs/…
近期布局（Roadmap)
随着 KubeVela 内核的逐渐稳固，可扩大内核的红利逐渐开释，使得社区在 1.2 / 1.3 的版本演进逐步放慢。将来咱们将以两个月为周期逐渐迭代新的版本。在接下来的 1.4 版本中，咱们将退出以下个性：
- 可观测性：围绕 log、metrics、traces 提供残缺的可观测性计划，提供开箱即用的 KubeVela 零碎可观测性，容许自定义可观测性配置，集成已有的可观测性组件或云资源。
- 离线装置：提供绝对残缺的离线装置工具和解决方案，不便更多的用户将 KubeVela 应用在离线环境中。
- 多集群权限治理：提供深刻到 Kubernetes 多集群的权限治理能力。
- 更多开箱即用的插件生态能力。
KubeVela 社区期待你的退出，一起打造简略易用且标准化的下一代云原生利用交付和治理平台！
相干链接
[1] 三个月前公布的 v1.2 版本
https://kubevela.io/zh/blog/2…
[2] 集群自身规模的限度
https://kubernetes.io/docs/se…
[3]“Prodspec 和 Annealing”
https://www.usenix.org/public…
[4] CRD Controller
https://kubernetes.io/docs/co…
原文链接
本文为阿里云原创内容，未经容许不得转载。
