站长之家,上海关键词推广,wordpress建站软件,wordpress调用tags简介#xff1a; 如果你对云原生领域不太关注#xff0c;可能对 KubeVela 还没有做过太深入的了解。别着急#xff0c;本文就借着 v1.0 发布之际#xff0c;为你详细的梳理一次 KubeVela 项目的发展脉络#xff0c;解读它的核心思想和愿景#xff0c;领悟这个正冉冉升起的…简介 如果你对云原生领域不太关注可能对 KubeVela 还没有做过太深入的了解。别着急本文就借着 v1.0 发布之际为你详细的梳理一次 KubeVela 项目的发展脉络解读它的核心思想和愿景领悟这个正冉冉升起的云原生应用管理平台之星背后的“道之所在”。 作者 | KubeVela 项目维护者 来源 | 阿里巴巴云原生公众号
作为 OAMOpen Application Model在 Kubernetes 上的实现KubeVela 项目从 oam-kubernetes-runtime 演进至今不过半年多时间但发展势头非常迅猛不仅连续登上 GitHub Go 语言趋势榜首和 HackerNews 首页更是迅速收获了包括 MasterCard、Springer Nature、第四范式、SILOT、Upbound 等来自世界各地、不同行业的终端用户甚至还出现了像 Oracle Cloud、Napptive 等基于它构建的商业化产品。就在 2021年3月底KubeVela 社区宣布包含所有稳定版 API 的 v1.0 版本发布正式开始向企业级生产可用迈进。
不过如果你对云原生领域不太关注可能对 KubeVela 还没有做过太深入的了解。别着急本文就借着 v1.0 发布之际为你详细的梳理一次 KubeVela 项目的发展脉络解读它的核心思想和愿景领悟这个正冉冉升起的云原生应用管理平台之星背后的“道之所在”。
首先什么是 KubeVela
一言以蔽之KubeVela 是一个“可编程式”的云原生应用管理与交付平台。
可是什么是“可编程”呢它跟 Kubernetes 又是什么关系它能帮助我们解决什么问题
PaaS 系统的“能力困境”
PaaS 系统比如 Cloud Foundry、Heroku 等自诞生以来就以其简单、高效的应用部署体验而被所有人津津乐道。然而大家也知道我们今天的“云原生”却是一个 Kubernetes 大行其道的世界曾经的 PaaS包括 Docker到底遇到了什么问题呢
其实任何一个尝试使用过 PaaS 的人都会对这种系统的一个本质缺陷感触颇深那就是 PaaS 系统的“能力困境”。 图 1 - PaaS系统的能力困境
如图 1 所示PaaS 系统在最开始使用的时候往往体验非常好也总能恰如其分地解决问题。但随着使用时间的推移一个非常讨厌的情况就会出现应用的诉求开始超过 PaaS 系统能够提供的能力。而更可怕的是一旦这个问题出现用户对 PaaS 系统的满意度就会断崖式下跌这是因为无论是重新开发平台增加功能还是修改应用去适配平台都是一项投入巨大但收益很低的事情。更何况所有人这时候都会开始对平台失去信心谁知道下一次系统或者应用大改是不是很快又要发生了
这个“命门”可以说是 PaaS 虽然具备云原生所需的一切要素、却最终未能成为主流的主要原因。
而相比之下Kubernetes 的特点就比较突出了。尽管 Kubernetes 被人诟病“复杂”但随着应用复杂度的提升Kubernetes 的优点就会慢慢体现出来尤其是当用户的诉求开始需要你去通过 CRD Controller 支持的时候你一定会庆幸幸亏当初选了 K8s。
这里的原因在于Kubernetes 的本质其实是一个强大和健壮的基础设施能力接入平台也就是所谓的 The Platform for Platform。它的这套 API 和工作方式天然不适合直接跟人去进行交互但却能够以非常一致的方式接入任何基础设施能力为平台工程师构建 PaaS 等上层系统提供“无限弹药”。这种“BUG 级”的基础设施能力供给方式让再精密的 PaaS 系统相比之下都像是一个碍手碍脚的“玩具”这一点对于很多正挣扎于构建内部应用平台的大型企业来说它们才是 PaaS 厂商真正想赢取的用户无异于是久旱逢甘霖。
云原生 PaaS 新瓶装旧酒
前面提到的一点其实很重要假如一个大型企业要决定采纳一个 PaaS 系统还是选择 Kubernetes平台团队往往才是能决定拍板的那一方。但另一方面平台团队的意见虽然重要并不意味着最终用户的想法就可以不管了。事实上在任何一个组织中直接创造价值的业务团队才持有最高的话语权只不过起作用的时间稍晚而已。
所以在绝大多数情况下任何一个平台团队拿到 Kubernetes 之后并不会直接去让业务去学习 Kubernetes而是会基于 Kubernetes 构建一个“云原生” PaaS用它去服务业务方。
咦于是乎大家兜兜绕绕又回到了故事的原点。唯一的变化是咱们今天这个 PaaS 是基于 K8s 实现的确实轻松了不少。
但实际情况呢
这个基于 Kubernetes 构建 PaaS 的故事看似美好其实整个过程却难免有些“心酸”。说的好听点是开发 PaaS其实 80% 的工作是在设计和开发 UI剩下的工作则是安装和运维 K8s 插件。而更令人遗憾的是我们这样构建出来的 PaaS其实跟以前的 PaaS 没有本质不同任何时候用户诉求改变我们都需要花大量时间重新设计、修改前端、排期上线。结果就是K8s 日新月异的生态和无限可扩展的特性都被“封印”在我们亲手构建的 PaaS 之下“不见天日”。终于有一天业务方也实在忍不住要问了你们平台团队上了 K8s到底有啥价值
上面这个“为了解决 PaaS 的固有限制结果又引入一个新的 PaaS 和限制”的困局是现今很多公司在落地云原生技术的过程中遇到的一个核心问题。我们似乎再一次把用户锁定在一层固定的抽象和能力集当中。所谓云原生化的好处仅仅体现在咱们自己开发这个平台变得简单了 —— 而对业务用户来说这似乎没什么太大的意义。
更为麻烦的是云原生和 K8s 的引入也让运维人员这个角色变得非常微妙。本来他们所掌握的业务运维最佳实践是整个公司中最重要的经验和资产。然而在企业云原生化之后这个工作的内容都必须交给 K8s 去接管。所以很多人都说K8s 要让“运维”失业了这个说法虽然有点夸张但确实反映出了这个趋势带来的焦虑。而且我们不禁也在从另一个角度思考云原生化的背景下应用运维的经验和最佳实践又该怎么落实就拿一个简单的工作负载举例子一个 K8s Deployment 对象哪些字段暴露给用户、哪些不能虽然体现在 PaaS 的 UI 上但肯定不能是靠前端开发说了算的吧。
KubeVela下一代可编程式应用平台
阿里巴巴是整个业界在云原生技术上的先行者之一。所以上述这个围绕着应用平台的云原生技术难题相对也比较早的暴露了出来。在 2019 年末阿里基础技术团队与研发效能团队合作针对这个问题进行了大量的探索与尝试最终提出了“可编程式”应用平台的思想并以 OAM 和 KubeVela 开源项目的方式同大家见面。这套体系目前已经迅速成为了阿里构建应用平台的主流方式。
简单地说所谓“可编程”指的是我们在构建上层平台的过程中不会直接在 Kubernetes 本身上叠加抽象哪怕只是一个 UI而是通过 CUE 模板语言这种代码化Code的方式来抽象和管理、并透出基础设施提供的能力。
举个例子比如阿里的某个 PaaS 要对用户提供一个能力叫做 Web Service这个能力是指任何需要从外部访问的服务都以 K8s Deployment Service 的方式来部署对用户暴露镜像、端口等配置项。
在传统方法中我们可能会实现一个 CRD 叫做 WebService然后在它的 Controller 里来封装 Deployment 和 Service。但这必然会带来前面 PaaS “能力困境”的问题
我们应该给用户暴露几种 Service 类型未来用户想要其他类型怎么办用户 A 和用户 B 需要暴露的字段不统一该怎么办比如我们允许用户 B 修改 Label但 用户 A 不可以那这个 PaaS 该怎么设计……
而在 KubeVela 中像上面这样面向用户的功能则可以通过一段简单的 CUE 模板来描述这里有完整的例子。而当你编写好这样一个 CUE 文件之后直接通过一句 kubectl apply用户就可以立即使用到这个能力
$ kubectl apply -f web-service.yaml
更重要的是只要执行上面这条命令KubeVela 就会自动根据 CUE 模板内容生成这个能力的帮助文档和前端表单结构所以用户立刻就会在 PaaS 里面看到这个 WebService 功能如何使用比如有哪些参数、字段类型并且直接使用它如下 图 2 所示 图 2 - KubeVela 自动生成表单示意图
在 KubeVela 中平台的所有能力比如金丝雀发布、IngressAutoscaler 等等都是通过这种方式定义、维护和透出给用户的。这种端到端打通用户体验层与 Kubernetes 能力层的设计使得平台团队可以以极低的成本快速实现 PaaS 以及任何上层平台比如 AI PaaS大数据 PaaS同时高效地响应用户的持续演进诉求。
1. 不只是 Kubernetes 原生是 Platform-as-Code
尤为重要的是在实现层KubeVela 并不是简单的在客户端去渲染 CUE 模板而是使用 Kubernetes Controller 去渲染和维护生成的 API 对象。这里的原因有三点
Kubernetes Controller 天然适合维护用户层抽象到底层资源之间的映射并且通过控制循环Reconcile机制永远确保两者的一致性而不会发生 IaCInfrastructure-as-Code 系统里常见的 Configuration Drift配置漂移问题即底层资源跟用户层的输入发生不一致。平台团队编写的 CUE 模板 kubectl apply 到集群之后就变成了一个 Kubernetes 中的一个自定义资源Custom Resource它代表了一个抽象化、模块化的平台能力。这个能力可以被全公司的平台团队复用也可以继续修改演进而且它是 Namespace 化的资源所以平台的不同租户可以分配同名但不一样的模板互不影响。这样彻底解决了不同租户对同一个能力的使用诉求不一样的问题。如果随着时间推移用户对平台功能的设计提出了新的要求那么平台维护团队只需要安装一个新的模板新的设计就会立刻生效平台本身不需要做任何修改也不用重启或者重新部署。而且新模板也会立刻被渲染成表单出现在用户 UI 上。
所以说KubeVela 的上述设计从根本上解决了传统 IaC 系统用户体验虽好但是生产环境上“靠不住”的老大难问题又在绝大多数情况下让整个平台响应用户需求的时间从原先的数周降低到几小时完全打通了云原生技术与最终用户体验之间的壁垒。而它完全基于 Kubernetes 原生方式实现确保了整个平台严格的健壮性并且无论任何 CI/CD 以及 GitOps 工具只要它支持 Kubernetes就一定支持 KubeVela没有任何集成成本。
这套体系被大家形象的称为Platform-as-Code平台即代码。
2. 别急KubeVela 当然支持 Helm
提到 KubeVela 以及 CUE 模板这些概念很多小伙伴就开始问了KubeVela 跟 Helm 又是什么关系啊
实际上Helm 和 CUE 一样都是一种封装和抽象 Kubernetes API 资源的工具而且 Helm 使用的是 Go 模板语言天然适配 KubeVela Platform-as-Code 的设计思路。
所以在 KubeVela v1.0 中任何 Helm 包都可以作为应用组件被部署起来并且更重要的是无论是 Helm 组件还是 CUE 组件KubeVela 里的所有能力对它们都适用。这就使得通过 KubeVela 交付 Helm 包可以给你带来一些非常重要但是现有工具很难提供的能力。
举个例子Helm 包其实很多是来自第三方的比如 Kafka Chart可能就是 Kafka 背后的公司制作的。所以一般情况下你只能用但不能改它里面的模板否则修改后的 Chart 你就得自己维护了。
而在 KubeVela 中这个问题就很容易解决。具体来说KubeVela 提供一个运维侧的能力叫做 Patch它允许你以声明式的方式给待交付组件比如 Helm 包里封装的资源打 Patch而不用去关心这个字段有没有通过 Chart 模板透出来而且 Patch 操作的时机是在资源对象被 Helm 渲染出来之后、提交到 Kubernetes 集群处理之前的这个时间不会让组件实例重启。
再比如通过 KubeVela 内置的灰度发布系统即AppRollout 对象你还可以将 Helm 包作为一个整体进行渐进式发布且无需关心工作负载类型即哪怕 Chart 里是 OperatorKubeVela 也可以进行灰度发布而不是像 Flagger 等控制器那样只能针对单一的 Deployment 工作负载进行发布。此外如果将 KubeVela 同 Argo Workflow 集成你还可以轻松的指定 Helm 包的发布顺序和拓扑等更复杂的行为。
所以说KubeVela v1.0 不仅支持 Helm它的目标是成为交付、发布和运维 Helm Chart 最强大的平台。一些社区同学已经在本文发布之前就迫不及待的试用了这部分功能大家可以移步到这篇文章来阅读。
3. 全自助式用户体验和云原生时代的运维
得益于 Platform-as-Code 的设计基于 KubeVela 的应用平台天然对用户是自助式的使用方式如图 3 所示。 图 3 - KubeVela 自助式能力交付流程图
具体来说平台团队只需要极小的人力成本就可以在系统中维护大量的、代码化的“能力模板”。而作为平台的终端用户业务团队只需要根据自己的应用部署需求在 PaaS UI 上选择几个能力模板填入参数就可以自助式的完成一次交付无论这个应用多么复杂业务用户的学习成本都非常低并且默认就会遵循模板中所定义的规范而这个应用的部署和运维过程则由 Kubernetes 以自动化的方式去管理从而减轻了业务用户大量的心智负担。
而更为重要的是这种机制的存在让运维人员再次成为了平台团队中的核心角色。具体的说他们通过 CUE 或者 Helm 设计和编写能力模板然后把这些模版安装到 KubeVela 系统中给业务团队使用。大家试想一下这个过程其实就是运维人员把业务对平台的诉求结合整个平台的最佳实践以代码化的方式固化成可被复用和定制的能力模块的过程。而且这个过程中运维并不需要去进行复杂的 K8s 定制和开发只需要理解 k8s 的核心概念即可。另一方面这些代码化的能力模块复用性极高变更和上线非常容易并且大多数情况下不需要额外的研发成本可以说是最敏捷的“云原生”运维实践能够真正让业务感受到云原生“研发、交付、运维高效一体化”的核心价值。
4. 多环境多集群、多版本应用交付
KubeVela v1.0 的另一个重大更新就是改进了系统的部署结构提供了 Control Plane 控制平面模式从而具备了面向多环境、多集群进行版本化应用交付的能力。所以现在一个典型的生产环境 KubeVela 部署形态如下图 4 所示 图 4 - KubeVela 控制平面部署形态示意图
在这个场景下KubeVela 支持为多环境应用进行描述支持为应用配置 Placement 策略以及应用多版本同时部署在线、并通过 Istio 进行灰度的发布模型。大家可以通过这个文档进行深入了解。
在 v1.0 发布之后KubeVela 会围绕上述架构进行持续的演进其中的一个主要的工作项就是将 KubeVela Dashboard、CLI 和 Appfile 全部迁移和升级到同 KubeVela 控制平面通过 gRPC 进行交互而不是像之前的版本那样需要直接跟目标集群打交道。这部分工作目前尚在进行中欢迎对构建下一代“可编程式”开发者体验有心得的同学一起来参与。与此同时欧洲知名科技出版商 Springer Nature 也正在一起参与这部分工作以便从 CloudFoundry 上平滑迁移到 KubeVela。
结语
如果我们总结一下 KubeVela 今天的设计与能力其实不难发现它是今天云原生应用平台发展的一条必然路径
完全基于 Kubernetes 构建天然的被集成能力和普适性天然透出 Kubernetes 及其生态的所有能力而不是叠加抽象基于 X-as-Code 的平台能力模块化配合 OAM 模型实现超低成本的能力封装、抽象和组装机制快速敏捷的响应用户需求提供全自助、无锁定的应用管理与交付体验基于 Kubernetes 控制器模式进行组件解封装和应用部署确保最终一致性、确保应用交付与运维流程的健壮性内置以应用为单位的发布策略和面向多环境、多集群交付策略极大地补充了社区目前以单一工作负载为中心的发布能力无论应用部署多么复杂只需要 1-2 个 Kubernetes YAML 文件就能做完整的描述天然适合并且大大简化 GitOps 工作流极大程度降低了终端用户使用云原生和 Kubernetes 的上手成本并且不带来任何能力或者抽象锁定。
更重要的是KubeVela 以 Platform-as-Code 的设计思想给未来基于云原生的应用平台团队提出了更加合理的组织方式
平台 SRE 负责 Kubernetes 集群和组件的健壮性平台研发工程师负责开发 CRD Controller同 Kubernetes 内置能力一起对应用层提供完整的应用管理、运维和基础设施能力业务运维结合业务诉求负责将最佳实践代码化为 CUE 或者 Helm 模板将平台的能力模块化业务用户以完全自助化的方式使用平台的模块化能力来进行应用管理与交付心智负担低部署效率高。
而基于这套体系KubeVela 应用平台还可以用来实现强大的“无差别”应用交付场景达成完全与环境无关的云端应用交付体验
组件提供方将应用交付所需的能力工作负载、运维行为、云服务定义为 Helm 包或者 CUE 包注册到 KubeVela 系统当中应用交付人员使用 KubeVela 组装上述模块化能力成为一个完全与基础设施无关的应用部署描述同时可以借助 KubeVela 的 Patch 等能力定制和覆盖组件提供方的配置或者定义复杂的部署拓扑通过多环境、多集群交付模型定义应用在不同环境中的部署形态和交付策略配置不同版本应用实例的流量分配策略。
KubeVela v1.0 的发布是我们基于 OAM 模型以及云原生应用交付使用场景最大化验证的结果它不仅代表了稳定的API还代表了成熟的使用范式。然而这不代表结束而是一个全新的开始它开启了一个“可编程式”应用平台的未来这是一个能够充分释放云原生潜力、让最终用户和软件交付方从第一天开始就充分享受云原生技术魅力的有效路径。我们期待这个项目能达成它最朴素的愿景Make shipping applications more enjoyable!
原文链接
本文为阿里云原创内容未经允许不得转载。
