网站建设公司怎么做业务,深圳团购网站设计多少钱,wordpress首页自定义广告位,贝贝网网站开发背景简介#xff1a;时间来到 2022 年#xff0c;KubeVela 也正式进入了第四个阶段#xff0c;在原先核心控制器 API 基本稳定的基础上#xff0c;我们以插件的形式增加了一系列开箱即用的功能。让开发者可以通过 UI 控制台的方式#xff0c;连接 CI/CD 完整流程#xff0c;端…简介时间来到 2022 年KubeVela 也正式进入了第四个阶段在原先核心控制器 API 基本稳定的基础上我们以插件的形式增加了一系列开箱即用的功能。让开发者可以通过 UI 控制台的方式连接 CI/CD 完整流程端到端发布多集群应用进一步提升开发者体验。
作者KubeVela 社区
随着云原生的不断发展和成熟越来越多的基础设施能力逐渐标准化成为 PaaS 平台或者 SaaS 化产品。一个产品的诞生不再像过去那样需要建立一个团队从开发、测试一直到运维、基础设施全部分多种角色系统完成。如今敏捷组织文化和云原生技术驱动使得这些职责更多的是“左移”到了开发者身上测试左移、监控左移、安全左移以及 DevOps 等一系列理念都是在强调通过开源项目或者云的产品和服务将测试、监控、安全、运维等一系列事务提前到开发阶段完成。这看似美好的愿景却给开发者带来了巨大的挑战开发者对底层五花八门的产品和复杂 API 缺乏掌控力他们不仅仅是在做选择更多的需要去理解和协调底层复杂异构的基础设施能力以便满足上层业务的快速发展和迭代需求。
这种复杂性和不确定性无疑大大降低了开发者的体验降低了业务系统的交付效率增加了运维风险。开发者体验的核心是“简单”和“高效率”不管是开发者还是企业都需要更好用的开发者工具或者平台来达成。在现代云原生技术之上打造一款帮助开发者从开发、交付以及后续持续运维的一体化平台一直是 KubeVela 演进的核心目标。如图 1 所示在 v1.2 版本中我们围绕开发者体验新增了 UI 控制台组件VelaUX简化了编排 YAML 的复杂性完善了插件体系建设丰富了云资源的扩展能力增加了大量 CI/CD 等生态对接的能力进一步完善了开发者端到端的使用体验。 图 1KubeVela 架构设计
发展历程回顾
让我们再来简单回顾一下 OAM 和 KubeVela 的发展阶段和历程
OAMOpen Application Model诞生和成长
在复杂的世界中要创造简单首先我们需要解决的问题就是抽象和标准化。阿里云和微软联合推出 OAM 模型创新性地提出“关注点分离”的理念开发者关注业务本身、运维关注模块化能力。OAM 模型围绕“一切皆服务全面模块化”的思想为各大厂商和云原生的平台构建者们实现自己的应用管理平台提供了简单易用与高度可扩展相结合的标准实践方式。该模型提出后的短短一年内便得到了包括 AWS、Oracle、腾讯、华为在内的国内外各大厂商响应被国家信通院立项作为行业标准。因为大家有共同的目标降低云原生的使用门槛让应用交付和管理更简单。
KubeVela 开源项目 v1.0 发布为社区带来了 OAM 的标准实现
有了 OAM 模型作为实践指导社区高级玩家也开始创造自己的工具来实践包括阿里、微软、Oracle、Upbond、腾讯在内的一系列公司都基于 OAM 的指导构建了自己的业务平台。但对于更广大的开发者和中小型企业群体来说他们却无法直接享受模型带来的红利于是KubeVela 作为 OAM 社区的官方实现引擎诞生了。它从一开始就由 7 家来自不同组织的 OAM 社区成员从零到一构建。KubeVela 的实现吸收了多家公司针对 OAM 的实践经验同时结合 Kubernetes 社区生态优势实现了自动化、可收敛、幂等且稳定的应用发布控制器围绕 IaC基础设施即配置构造了用户友好的抽象层帮助开发者实现了开箱基于的 OAM 实现引擎。
KubeVela v1.1 发布实现应用交付工作流原生支持混合环境多集群应用交付
随着企业上云进程的推进混合云、分布式云等多元化基础设施逐渐成为常态。KubeVela 作为现代应用管理系统也顺应潮流整体架构升级为面向混合环境做应用交付和管理的控制平面将所有的功能天然构筑在多集群技术之上。我们相信出于高可用、成本性能、数据安全等多方面因素未来大多数企业应用的形态都将是异构多元的。KubeVela v1.1 版本的发布同时也实现了高度可扩展的应用发布工作流它天然以混合环境架构呈现创新性的实现了交付工作流与应用抽象相结合的工作模式实现了面向终态的应用交付工作流大大简化了流程编排的复杂性。
时间来到 2022 年KubeVela 也正式进入了第四个阶段在原先核心控制器 API 基本稳定的基础上我们以插件的形式增加了一系列开箱即用的功能。让开发者可以通过 UI 控制台的方式连接 CI/CD 完整流程端到端发布多集群应用进一步提升开发者体验。
v1.2 版本的核心能力
图形化操作控制台VelaUX
提供好用的图形化操作界面是降低开发者使用门槛的首选途径从 KubeVela 诞生以来社区对 UI 控制台的呼声一直很高。从 v1.2 版本开始它正式到来了。打造 UI 控制台的目的是帮助开发者以更标准化的方式组装和管理异构业务应用帮助他们分析和更快的发现业务故障和阻碍。
VelaUX[1] 是 KubeVela 的前端项目设计实现时它充分考虑了 KubeVela 的可扩展性这一核心要点。引入了低代码平台的理念来打造前端我们的目标是打造一个可以通过拖拉拽方式就能做到自定义应用交付输入参数并且实现运行数据可观测的平台。为此我们设计了前端描述规范UISchema[2]配合 KubeVela 的模块化定义X-Definition[3]通过配置就可以渲染出丰富的前端交互元素。同时为了让前端的数据查询也配置化我们设计了多维数据自定义查询语言VelaQL[4]这样的设计形成了 KubeVela 交付和管理异构应用的基础。
目前通过 VelaUX 用户可以管理扩展连接 Kubernetes 集群分配交付目标规划环境和交付各类型应用并观测应用运行状态实现应用交付的完整闭环。 图 2VelaUX 预览
如图 2 所示VelaUX 中出现了一些新名词请参考核心概念[5]文档进行学习和了解。
多环境统一化管理
KubeVela 将 N 个Kubernetes 集群N 个云厂商服务或其他私有云服务统一为大的基础设施资源池。在此基础上我们的开发者可以按照业务需求、流程需求、团队需求等多种业务维度划分环境。在大资源池的基础上形成环境空间。同一个应用可发布到不同的环境环境之间从管理到运行态完全隔离。 图 3多环境/多集群应用管理页面
如图 3 所示应用可被发布到生产、测试、默认三个环境中每一个环境可以包括多个交付目标每一个交付目标背后可以是独立的 Kubernetes 集群。
异构应用标准化交付
在云原生体系中我们交付应用的形式选择非常多。基于 Kubernetes 基础设施我们既可以通过成熟的 Helm Chart 包交付中间件和第三方开源应用也可以通过镜像交付企业业务应用还可以通过 OpenYurt 交付管理边缘应用。基于云服务商的开放能力我们可以交付数据库、消息、缓存等中间件也有日志、应用监控等运维能力。
对于这么多的可选项KubeVela 采用标准的 OAM 规范实现对异构应用的统一交付和管理。KubeVela 实现了高度可扩展的交付系统通过内置、社区共享等形态帮助用户扩展平台以一致化的交付和管理体验处理异构的应用。在 KubeVela 之上开发者看到的都是模块化、一切皆服务的管理形态。 图 4云服务应用管理页面
如图 4 所示我们可以看到相同的应用管理页面用户可以非常便捷得获取到云服务应用。开发者可以通过阅读下面几篇文档查看异构应用的交付过程
交付 Docker 镜像[6]交付 Helm Chart 包[7]交付 Kubernetes 资源[8]交付 云服务[9]
扩展体系Addon
KubeVela 从一开始就是设计为一款微内核高可扩展的系统上文我们说到异构应用KubeVela 可以通过扩展体系以标准化的形态扩充无限的应用交付能力。既匹配企业差异性诉求也不带来过多的认知负担。KubeVela 中可扩展的点包括了组件类型、运维能力、工作流类型、应用交付策略等。在当前版本中我们发布了 Addon 扩展体系。Addon 是组织各种扩展能力的承载体它便于分发和管理。 图 5KubeVela 插件管理页面
目前在官方仓库中已经存在如图 5 所示的可用 Addon。同时在实验性仓库中我们正在联合社区用户积极创造更多的扩展能力。当然这里需要每一个社区开发者的积极参与。
截止到现在KubeVela 已经成长为一款可直接服务于广大开发者的应用交付平台那么企业哪些场景可以直接利用 KubeVela 呢我们整理了以下几个常见场景
企业开发场景解决方案
多集群应用 DevOps
在过往社区的交流中我们发现企业主流的研发体系都类似如图 6 所示的结构他们使用云服务厂商提供的计算资源作为生产、演示环境。使用自己购买或历史遗留的服务器搭建开发、测试环境。如果业务有多区域或灾备需求生产环境可能需要部署到多个区域或多云。 图 6多集群应用实践架构
对于基础的 DevOps 流程包括了代码托管和 CI/CD 的环节。KubeVela 目前为你提供 CD 环节的支持。对于企业实践的步骤如下
根据实际情况准备本地或云服务资源。至少单项打通本地和云资源的网络便于资源集中管理。 将 KubeVela 系统搭建在生产环境中保障持续的可用性。 通过 KubeVela 部署 Gitlab、Jenkins、Sonar 等 DevOps 工具并打通工具链。通常情况下代码托管和开发工具的可用性至关重要我们需要将其部署在生产环境中如果你本地机房具备生产可用性且希望代码数据在本地环境流转可部署在本地机房。 通过 KubeVela 规划本地开发环境部署本地测试用中间件规划生产环境和部署云服务中间件。 通过 Jenkins 搭建业务代码 CI 流水线产出 Docker 镜像交由 KubeVela 进行多环境部署形成完整应用交付工作流。
结合 KubeVela 的多集群应用 DevOps 方案有如下优势
1开发者无需掌握过多的 Kubernetes 生态知识可实现异构应用云原生部署。
2多集群多环境统一管理原生可部署跨集群应用。
3统一的应用管理模式无论是业务应用还是开发工具链。
4灵活的工作流帮助企业打通各种开发规范流程。
混合环境一体化管理
不同的企业往往都存在不一样的基础设施和业务诉求。在基础设施侧企业可能搭建了私有云可能购买了公有云可能还有边缘计算资源。在业务侧不同的业务规模不同资源需求不同可能有多云多活应用也有企业遗留系统。在研发侧业务研发往往需要开发、测试、预发和生产环境。在管理侧不同的业务团队需要相互隔离又可能需要业务互通。
随着时间的累积企业由于职责边界和不同分工的影响会逐渐形成不同业务团队相互独立甚至割裂的状态这种割裂包括了开发工具割裂技术架构割裂业务管理形态割裂。KubeVela 秉持着“尊重现实积极创新”的原则带来的方案是追求统一的过程中用高扩展的能力去兼容差异性。
面对基础设施差异我们支持以 Kubernetes API、云服务 API 或其他自定义 API 的形态去对基础设施进行充分的模型化。最终通过统一的 OAM 模型向上暴露一致的概念。面对业务架构差异应用模型是开放的对架构无要求的。KubeVela 做的是连接和赋能连接已有系统通过扩展机制加持新的生态技术。面对开发工具链的差异企业中可能已经存在不同的开发工具链产出不同的业务制品。KubeVela 通过扩展和标准模型去支持各类制品实现其标准化交付。当然它的标准逐步衍生到前置环节帮助企业逐步实现工具链一致化。因此你不用担心你是用的 Gitlab 还是 Jenkins它都能对接。面对运维能力差异企业中不同团队的运维能力、工具方案可以在 KubeVela 的规范下逐步积累能力互通。更多运维能力也同样在社区的维度进行共享和复用。
因此使用 KubeVela 来作为企业打通业务进行统一能力建设的基础平台它是可落地、有未来的方案。
自定义企业发布平台
从 Heroku 、Cloud Foundry 时代开始市场上一直在产生不同的 PaaS 平台我们都知道固定模式的发布平台往往不适合所有的企业。举个例子某些规范化程度较高的企业他们基于业务的特性发布应用时仅需更新镜像名称然而使用通用 PaaS 就不得不去理解大量的概念和参数。再比如某个企业生产的是 AI 应用对于 AI 应用的发布与普通应用有比较大的区别这时就需要定制 AI 场景的 PaaS企业不得不付更多的费用和学习更多的概念。
通用产品不符合企业需求时自研是真实存在的诉求。但是对于从零开始自研平台必然又需要投入大量的人力物力甚至超过了企业核心业务的投入这显得得不偿失。KubeVela 也考虑到了具备自研能力企业的独特诉求他们可以基于 KubeVela 微内核、高可扩展的设计针对自己的业务场景和领域知识打造属于自己的、更为简单易用的业务平台。
对于需要自研发布平台的企业来说KubeVela 的微内核是一个 PaaS 平台研发框架。一方面企业可以根据自己的需求自研或者安装社区的各种功能插件另一方面企业也可以基于 OAM 模型修改模块化配置新增或裁剪用户使用的参数。这种模块化的设计可以大大降低企业的投入成本同时可以跟上社区的发展潮流随时将社区更多的先进技术转化为自身的生产力。
参与社区
做了这么多的介绍你是否对 KubeVela 的发展有了一些新的认识没有哪个产品是绝对的银弹也没有一个方案可以解决所有的问题。但是我们的理想是可以创造一个标准化模式让更多的企业和开发者用户参与到这场为了“简单”和“高效”的开发者体验战役中来。KubeVela 还很年轻我们希望你可以参与进来共同打造。这里非常感谢在过去参与 KubeVela 贡献的 100 多位开发者[10]正是因为你们的携手努力才让我们的社区生态变得更加繁荣。
共建 OAM 应用规范
对于 OAM 应用规范模型的更新和升级基于 KubeVela 实践驱动但是它并不绑定 KubeVela 实现。它是 KubeVela 在云原生应用交付和管理层面实践经验的总结和抽象是创造规范化应用管理体系的最佳实践和核心理念。我们非常欢迎云厂商、平台厂商、最终用户可以参与进来同时我们也欣喜的看到国内包括腾讯在内的多家厂商对 OAM 应用规范的关注和支持。任何人、组织都可以发表你的想法、建议和思考。
参与 OAM 模型讨论
https://github.com/oam-dev/spec
共建 Addon 扩展生态
如上文介绍的一样我们已经开启了 Addon 的扩展体系非常欢迎社区的创造者、开发者可以来贡献更多的扩展能力。
如何扩展和贡献 Addon 参考文档
自定义插件 | KubeVela
贡献云服务能力
KubeVela 通过集成 Terraform Module 来扩展云服务集成能力我们已经支持了常用的云资源[11] 欢迎社区朋友参考并贡献更多的云服务厂商和产品。
如何扩展和贡献云资源 参考文档
扩展云资源 | KubeVela
反馈你的需求或痛点
或许你是普通开发者也或许你是云原生领域的从业者如果你认可我们的方向认可我们正在做的事情我们非常欢迎你可以参与到 KubeVela 社区讨论中来。
社区讨论
https://github.com/oam-dev/kubevela
KubeVela 网站加速访问
KubeVela 的官方文档托管在 GitHub https://github.com/oam-dev/kubevela.io 上如果你发现有任何错漏或者想要参与翻译欢迎直接到项目中贡献。同时为了国内用户可以加速访问我们增加了 kubevela.net 这个域名可以方便国内用户更快的访问内容与 kubevela.io 的域名完全一致、实时同步。
KubeVela 是 CNCF 沙箱项目了解更多信息请点击此处查阅官方文档。
相关链接
[1] VelaUX
https://github.com/oam-dev/velaux
[2] UISchema
UI-Schema | KubeVela
[3] X-Definition
模块定义X-Definition | KubeVela
[4] VelaQL
VelaQL | KubeVela
[5] 核心概念
核心概念 | KubeVela
[6] 交付 Docker 镜像
交付容器镜像 | KubeVela
[7] 交付 Helm Chart 包
交付 Helm Chart | KubeVela
[8] 交付 Kubernetes 资源
交付 Kubernetes 原生资源 | KubeVela
[9] 交付云服务
交付云服务 | KubeVela
[10] 100 多位开发者
https://github.com/oam-dev/kubevela/graphs/contributors
[11] 常用的云资源
https://kubevela.io/zh/docs/end-user/components/cloud-services/provider-and-consume-cloud-services#支持的云资源列表
原文链接
本文为阿里云原创内容未经允许不得转载。
