作者：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/case-studies/multi-cluster
-
分发引证外部 Kubernetes 方针： https://kubevela.net/zh/docs/end-user/components/ref-objects
-
运用版别办理： https://kubevela.net/zh/docs/end-user/version-control
渠道：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/how-to/dashboard/user/project
-
用户办理： https://kubevela.net/zh/docs/how-to/dashboard/user/user
-
RBAC 授权： https://kubevela.net/zh/docs/how-to/dashboard/user/rbac
-
集成并运用单点登陆： https://kubevela.net/zh/docs/tutorials/sso
-
装备办理： https://kubevela.net/zh/docs/how-to/dashboard/config/dex-connectors
生态：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/how-to/cli/addon/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用户群：
点击此处，查看 KubeVela 项目官网。
