简介：本次文章将首先介绍云原生利用交付和治理的挑战，而后介绍这背地的 KubeVela 和 OCM 技术原理，最初是整体的最佳实际，以及一个残缺的 Demo。
作者：冯泳，孙健波
大家好，很快乐能在 KubeCon 中国峰会给大家做分享，明天的主题是“以统一的体验构建和治理多集群利用”，配角是 KubeVela 和 OCM，这两个都是 CNCF 的开源我的项目。整个演讲大抵分为三局部，首先介绍云原生利用交付和治理的挑战，而后介绍这背地的 KubeVela 和 OCM 技术原理，最初是整体的最佳实际，以及一个残缺的 Demo。
背景
随着云原生生态的凋敝，Kubernetes 逐步成为了基础设施的规范集成界面，越来越多的基础设施能力变成了开箱即用的申明式 API，CRD Operator[1] 的遍及也让运维能力也逐步趋向于申明式和自动化。如图 1 所示，从底层基础设施到下层利用开发，现在的 CNCF 生态 [2] 中有上千个我的项目。
图 1. CNCF landscape 生态 – 摘自 2021.12
然而泛滥的抉择是礼物，也是研发工程师的懊恼。不同的利用架构波及到的不同开发语言、技术框架、打包形式、制品状态、云资源、以及运维形式各不相同。软件生命周期中，开发、测试、预发灰度、生产部署对应的环境和利用交付部署体验也存在很大的不统一。研发人员切换到云原生技术栈就波及大量简单的新常识须要学习，这就好比对着大量操作系统底层的 API 写程序，不足了编程框架和规范库，让利用开发事倍功半。
如何用好云原生凋敝的技术生态，又能让业务的研发人员取得统一的低门槛体验，同时安全可靠的交付利用，是业界面临的微小挑战。
业界的典型做法与挑战
为了解决利用交付的这最初一公里问题，业界的典型做法次要分为两大类。
第一类是在针对本身的业务场景基于 Kubernetes 构建外部的 PaaS 平台，暗藏 Kubernetes 平台接口，提供本身平台 API。这种模式通常在规模较大的公司，须要有对 Kubernetes 和业务都比拟精通的团队撑持。然而随着工夫的推移，业务场景变得复杂、需要逐步减少，外部自建的 PaaS 都会面临扩大能力有余、难以保护，最初不得不颠覆重做的窘境，这个问题在阿里晚期的利用云原生化革新的实际过程中尤为显著。另一方面，规模较大的公司通常会有不同的业务团队，因为顶层设计有余，不同团队各自构建的 PaaS 平台很容易成为相互独立的烟囱，大量类似的能力只能反复建设、无奈复用，更无奈对立治理。每个不同场景的不同平台又给更下层的业务团队带来了新的概念和学习累赘。
针对第一类场景存在的问题，业界逐步偏向于容器平台层原汁原味透出 K8s 原生 API，负责提供稳固的云原生生态能力，同时不影响灵活性和扩展性。利用交付通过相似 Jenkins/Gitlab 这样的 Pipeline，将利用制品打包（如 Helm Chart 等），而后间接部署到容器平台中，这就延长出第二类做法。基于传统 CI 生态工具间接对接容器平台的模式，如图 2 所示，这类做法的外围是通过脚本、配置等形式构建形象体系来简化应用门槛。这个形式目前是业内较为风行的解决方案，其益处分工较为明确，容器平台层作为 Infra/SRE 团队保护基础设施能力，利用交付则充分利用企业内现有的 CI 体系，不须要建设平台。
图 2. 业界典型的解决方案
这种形式肯定水平上解决了利用治理的问题，对于中小规模的企业即便对容器平台不足保护能力，也能够通过购买云服务的形式解决，同时也能为业务开发者提供一站式的统一体验。但次要问题就呈现在后面利用交付这一环，无论是哪种规模和场景的企业，都会很快遇到这些挑战：
不足自动化，须要大量手工保护工作。比方因为突发的网络起因、或者因为 Pipeline 零碎本身的某个问题，就会中断所有的公布并且须要人工染指，不足自愈能力。
不足对立的利用模型。无论是作为利用的残缺交付物，还是作为利用的外围入口（single source of truth），利用模型的对立都是极其重要的。不足对立的模型形容作为利用交付入口，就会导致不同的人能够从多处对系统进行变更，例如通过 CI Pipeline 零碎、或者间接更改 Kubernetes，工夫久了零碎的配置会呈现很大的不统一，从而引发故障。
存在平安危险。基于 CI pipeline 零碎构建的利用交付，CI/CD 体系的平安域通常不具备隔离性，即 CI/CD 通过一套零碎实现，基础设施所有集群的秘钥全都在同一套零碎中存储，一旦被黑客冲破容易引发十分大的系统安全危险。如代码覆盖率统计工具 Codecov 在往年 4 月份就遭逢了一起安全事故[3]，所有应用该产品的我的项目配置的 CI 秘钥全副泄露。另一方面，越来越多的开源软件被驳回到企业的生产零碎，这些软件的集成也加剧了安全隐患。
保护老本高。通过脚本和模板简化开发者心智是这种模式的外围，然而脚本和模板自身的保护如果不足开源规范和生态，很快就会缺乏活力，长此以往就变成了再也无人敢碰的神秘代码，极度依赖这套体系最后的构建者教训，难以连续和迭代。
所以如何构建稳固牢靠的利用交付和管理体系，成为了咱们亟需摸索的要害。
如何构建稳固牢靠的利用交付和管理体系？
如何保障利用交付的稳固、牢靠和平安，咱们别离来看解决问题的办法。首先，为了解决大规模利用交付的稳定性和可靠性问题，咱们从 Kubernetes 的设计中失去了启发。
Kubernetes 带来的启发
Kubernetes 有两个核心理念，一个是申明式 API，一个是面向终态的管制循环。
申明式是用户侧形象的最佳表达方式，它能够大大简化用户的心智，从形容过程到形容后果。申明式为什么能够简化心智，举一个吃饭的例子大家就容易了解了，传统基于过程式的形容就好比你本人在家里吃饭，你要购买食材、钻研菜谱，始终到做进去吃到，最初还要洗碗，整个过程是非常复杂的。而申明式的形容就是你去餐厅里吃饭，点菜的时候通知服务员你想吃的菜是什么，最终餐厅会把你要点的菜端上来给你。
图 3. Kubernetes 的管制循环
另一方面，面向终态的管制循环也是保障可靠性的最佳形式，这个设计准则要求咱们的零碎具备以下个性：
自动化，即可能始终面向最终的状态去运行，如果没达到状态，就持续运行。自动化的个性也保障了咱们的零碎不会因为一点点不稳固就中断，具备很强的自愈能力。
收敛性，即在零碎运行过程中后果能够向终态聚拢，每次执行都能一直迫近最终后果。
幂等性，示意咱们屡次执行同样的流程要保障后果是统一的，不会因为执行了屡次就出现意外的问题。
确定性，示意零碎只有运行是失常的，最终可能一直执行，直到达成一个确定的后果。
这四大个性也是大规模利用交付的外围因素。
利用交付安全性的准则
而后咱们来看看安全性的问题，其实外围很简略，就是像看待生产环境一样看待利用交付零碎的安全性。CNCF 基金会在 2021 年 4 月份也公布了利用交付最佳实际 [4] 和白皮书[5]，其中就提到了利用交付的一些安全性准则。
交付环境隔离，一方面指不同的交付目的地应该是隔离的，交付零碎不应该能够间接拜访所有的 Kubernetes 集群，同时不同的环境之间也应该是隔离的。另一方面，针对 CI/CD 不同利用生命周期的阶段，平安域也应该是隔离的，应用独立的秘钥信息。
集成物查看，这个准则指咱们在交付过程中，要对集成的开源工具，应用的依赖包，以及利用自身的镜像做必要的安全检查。
最小权限，这个准则大家都比拟容易了解，具体到实际中就是要做权限的拆分。比方应用 token 而非永恒秘钥，退出必要的审批流程，应用秘钥管理工具。尤其是云资源的应用，要对秘钥做必要的权限拆分，如应用子账号等机制，防止一个秘钥泄露又不能及时回收导致呈现单点故障。
审计和安全监控，这个准则要求咱们的利用交付和管理系统自身也要具备很好的可观测性能力，具备交付行为的审计和整体的安全监控。
面向终态的利用交付体系外围因素
所以总结下来，一个稳固、牢靠、平安的利用交付零碎，须要具备的外围因素如下图 4 所示。
图 4. 利用交付体系的外围因素
这个体系的入口是一个残缺的利用模型，涵盖不同的交付物、云资源、以及各类环境编排的配置，它是利用交付的对立入口，也是惟一的根据。
与此同时，这个利用模型采纳申明式的形式面向业务用户，为业务层提供针对应用场景的形象能力，可能升高用户的应用门槛，升高底层的 API 的复杂性，同时具备灵便扩大的能力。交付零碎通过拉取的形式与申明式 API 交互，用户只须要在模型层形容终态，最终交付零碎就会朝着这个终态一直收敛。
在交付零碎外部，要具备编排和部署两大外围性能。同时这两大外围性能的背地要始终维持一个面向终态继续运行的管制循环，这个管制循环是自动化和确定性的基石，同时也要具备对交付物、交付流程平安监测和审计的能力。
其中，编排解决的是不同交付物间接的依赖关系、部署程序、数据传递以及多集群多环境配置的问题，然而编排的复杂性不应该裸露给用户。交付零碎的编排执行引擎应该可能依据用户形容的申明式终态自动化的实现编排，而不是让用户手动编写编排的过程。部署则解决的是不同交付的部署，如云资源、Kubernetes 资源，以及多集群的交付问题，须要可能提供充沛的可扩展性，保障不同的交付物均能够部署，同时可能在多集群环境隔离的平安条件下实现部署。
下一代云原生利用交付与治理
KubeVela 就是齐全遵循这套理念构建的现代化的利用交付平台，它能够让你的利用交付与治理在当今风行的混合、多云环境中变得更加简略、轻松、牢靠。演进至今已有上百位贡献者参加代码奉献，吸纳了来自阿里、蚂蚁、腾讯、字节、第四范式、Gitlab 等一系列不同畛域公司的工程实际，充分利用云原生畛域百花齐放的技术生态红利实现利用的交付与治理。
图 5. KubeVela 架构
规范、凋谢的利用模型（OAM）
KubeVela 背地有一个残缺的利用模型，那就是 OAM（Open Application Model）。OAM 是阿里和微软在 2019 年联结公布的利用模型，现在曾经被阿里、微软、Oracle、Salesforce、腾讯等泛滥云厂商实际到云产品中，同时也被国家信通院立项作为《云计算凋谢利用架构》行业标准公布。image.gif
图 6. OAM 利用模型
如图 6 所示，OAM 模型将简单的利用交付和治理形象成利用、组件、运维能力，以及工作流这四个外围概念，使得用户能够通过一份配置文件，形容利用交付和治理的全部内容。OAM 具备充沛的可扩展性，满足利用交付到不同云、不同环境的诉求。同时 OAM 也不绑定 Kubernetes 生态，若开箱即用的 KubeVela 不满足需要，OAM 社区也欢送用户参加到模型层的建设中，依据模型独立实现。
基于 Kubernetes 的利用交付管制立体
KubeVela 是一个微内核的架构，其外围是一个基于 Kubernetes 的利用交付和管理控制立体，具备自愈、幂等、收敛以及确定这四大个性。最小化部署的 KubeVela 只须要 0.5 核以及 200M 内存即可反对上百个利用的交付。同时 KubeVela 本身也具备一系列开箱即用的插件，反对包含多集群交付、云资源管理、GitOps、Helm chart、可观测性等一系列性能，甚至包含 KubeVela 本身的 UI 控制台也是通过插件的形式集成的。
KubeVela 也不仅局限于 Kubernetes 生态，官网内置的云资源插件就能够集成任意的 terraform 模块，交付不同的云资源，甚至虚拟机。同时得益于 OAM 模型以及 KubeVela 从设计之初就严格遵循的可扩展性准则，用户能够轻易的减少和扩大生态的能力。
平安、牢靠的多集群治理技术（OCM）
KubeVela 背地的多集群技术也是保障利用稳固、平安、大规模交付的外围。咱们晓得，因为地区，规模，容灾等方面的思考，多集群早已成为企业外部基础设施的广泛状态。然而，Kubernetes 原生的治理能力目前依然停留在单集群级别。每一个集群能够稳固地自治运行，然而却不足横贯多个集群的兼顾治理能力。为了造成一个稳固、对立的利用交付和治理平台，须要具备如下能力：
运维管理人员可能获知多集群水位的变动，节点衰弱状态等信息
业务负责人可能决策如何调配应用服务在各个集群中的部署散布
利用运维人员可能获知服务状态，下发腾挪的策略
得益于 RedHat 和蚂蚁、阿里云独特发动并开源的 OCM（Open Cluster Management）多集群技术，KubeVela 能够轻松解决多集群、混合环境下资源、利用、配置、策略等对象的生命周期治理问题。OCM 使得用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，应用本人相熟的开源我的项目和产品轻松交付和治理利用。
图 7. OCM 的技术特点
与目前已有的多集群技术相比，OCM 的架构在以下方面具备技术当先劣势，满足用户对云原生利用交付平安、稳固、大规模能力的外围诉求：
模块化：OCM 治理平台由治理原语，根底组件和泛滥可扩大组件形成，这些组件能够像乐高积木一样自由组合构建满足用户需要的性能汇合。这一理念与 KubeVela 也人造符合，独特为用户提供了充沛的生态可扩展性。
大规模：OCM 的基础架构继承了 Kubernetes 凋谢，可扩大的特点。正如繁多 Kubernetes 集群能够反对数千个节点一样，OCM 在设计上能够反对数千个被治理集群。
平安：OCM 在设计上以零信赖和最小权限为根底，治理组件和被治理上的 agent 之间的注册通信采纳两次握手的形式。此外证书的更新，拜访权限的治理，权限 token 的散发也采纳和 Kubernetes 相似的设计，由相应的可扩大组件通过 Kubernetes 原生 API 形式实现。
可扩展性：OCM 提供了可扩大组件的编程框架和治理 API，和根底组件，治理原语一起，可能不便的将 Kubernetes 生态中的我的项目迁徙到 OCM 多集群治理平台。通过编程框架，OCM 社区曾经在多集群环境实现了泛滥 Kubernetes 的治理能力，也得益于此，KubeVela 与 OCM 能够轻松实现深度集成。
KubeVela 和 OCM 协同下的平安、统一的利用交付体验
KubeVela 和 OCM 天生具备互补性。KubeVela 负责应用层的交付和生命周期治理，OCM 则治理集群基础设施资源的生命周期。它们严密单干在一起提供了利用在多集群环境下交付和生命周期治理的端到端能力。
图 8. 跨环境、多集群交付的统一体验
如图 8 所示，应用 KubeVela 和 OCM，用户在不同环境的交付过程将齐全自动化，节俭大量人工操作。
同一个利用，业务研发人员只有形容一次组件，就能够在不同交付环境下绑定不同运维能力独立运行，比方开发环境能够应用端云联调，而预发生产环境能够绑定可观测性策略等等，无需反复诸如镜像、端口、环境变量等组件级别的参数，大大节俭了心智累赘。
另一方面，在管制立体，不同一个利用的跨环境部署能够在一次交付过程中自动化实现，能够自助抉择多种审批形式或是全自动执行。
更为重要的是，基于 KubeVela 和 OCM，能够构建齐全基于订阅模式的平安 GitOps 多集群利用交付。
图 9. GitOps 模式下的平安利用交付
如图 7 所示，CI 的流程还是沿用之前的模式，然而 CD 这一侧则形容一个独立的配置仓库，首先从 Git 仓库配置层面，两个仓库的权限是齐全隔离的。通过对立的利用模型，用户能够在配置仓库残缺的形容利用，同时 KubeVela 也能够监听残缺利用形容的变动，从而被动拉取利用配置。这个过程中，Git 仓库不持有交付零碎的任何秘钥。在交付零碎实现编排当前，管控数据则通过 OCM 实现下发，整个过程也是由运行时集群被动拉取的，交付零碎没有地方管控任何子集群的秘钥。管控数据下发到子集群当前，就能够由子集群的 GitOps agent 被动获取交付制品的变动，造成新的自治。
咱们能够看到，每一个环节都独立工作、自成体系，每一个环节都依据须要进行受权和审核，安全可靠。KubeVela 和 OCM 的协同能够对立编排和治理混合云、多集群、以及边缘利用，最终实现云边协同的平安交付。
开启你的端到端平台化之路
在咱们理解了以 KubeVela 和 OCM 为外围的利用交付和治理引擎设计原理当前，我能够看到，这一套模式带给咱们的最大益处是自动化、低门槛以及安全性。那么如何开展实际呢？从最新的 KubeVela v1.2 版本开始，咱们加强了端到端的残缺用户实际，你能够通过可视化的形式交付和治理利用。
首先，KubeVela 的架构是齐全基于微内核以及高可扩大的模式打造的，它能够帮忙用户以最小的老本，按需构建本人的云原生解决方案。如下图 8 所示是 KubeVela 的插件治理页面，包含 KubeVela 本身的 UI 性能以及 OCM 多集群性能，都是 KubeVela 的插件，在微内核的根底上，用户能够任意定制和切换本人的扩大性能。同时，它也帮忙用户敏捷地获取更多的云原生生态能力，帮忙企业更好的实现资源管理、DevOps、利用治理等场景。实现层面，KubeVela 的插件体系齐全基于开源社区的模式共建互助，所有提交到社区插件仓库 [6] 的内容，就会自动化的被 KubeVela 内核发现，咱们置信在不久的未来其即可有泛滥的抉择。
图 10. KubeVela 可视化插件页面
KubeVela 也默认反对了一系列组件类型，如图 9 所示，包含基于容器镜像的利用交付，该模式门槛低、无需理解 Kubernetes 常识，实用于大多数企业用户；当然也反对 Kubernetes 的 YAML 利用，围绕 OCM 技术将利用交付到多个集群；另外，用户通过装置官网保护的插件，能够获取到 Helm Chart 包、多种云厂商的云资源等组件类型，并取得对应的残缺利用交付和治理能力。你能够充分发挥设想，通过扩大，KubeVela 还能交付哪些类型的利用呢？
图 11. KubeVela 的组件
KubeVela 端到端的 UI 体系中，也默认增加了环境的概念，反对利用开发和交付生命周期中波及到的不同环境，例如开发、测试、生产环境等。同一个利用在不同的环境中部署齐全隔离，安全可靠，同时又无需用户反复配置，给用户带来了统一的体验。
图 12. 同一个环境中定义交付到多个集群
图 13. 通过可配置的工作流控制交付流程
目前，KubeVela 1.2 已公布预览版本 1.2.0-beta.3[7]，欢送社区用户下载体验。
将来 KubeVela 将更多的提供端到端的残缺用户体验，丰盛更多垂直场景下的能力，朝着开发者可能自助实现利用交付的方向演进，让混合环境下的利用交付就像咱们明天应用 App Store 一样简略。
相干链接
[1] CRD Operator：
https://kubernetes.io/docs/co…
[2] CNCF 生态：
https://landscape.cncf.io/
[3] 安全事故：
https://about.codecov.io/secu…
[4] 最佳实际：
https://www.cncf.io/announcem…
[5] 白皮书：
https://www.cncf.io/announcem…
[6] 社区插件仓库：
https://github.com/oam-dev/ca…
[7] 1.2.0-beta.3：
https://github.com/oam-dev/ku…
原文链接
本文为阿里云原创内容，未经容许不得转载。