在当今的多集群业务场景下，我们经常遇到的需求有：分发到多个指定集群、按业务规划实现分组分发、以及对多集群进行差异化配置等等。

KubeVela v1.3 在之前的多集群功能上进行了迭代，本文将为你揭示，如何使用 KubeVela 进行多集群应用的部署与管理，实现以上的业务需求。

招商银行云平台开发团队自2021年开始接触 KubeVela，并探索 KubeVela 在招商银行云平台的落地实践，借此提升云原生应用交付与管理能力。同时因为金融保险行业的特殊性，网络安全管控措施相对严格，行内网络无法直接拉取 Docker Hub 镜像，同时行内暂时没有可用的 Helm 镜像源。因此，要想实现 KubeVela 在行内私有环境的落地，必须进行完全的离线部署。

本文将以 KubeVela v1.2.5 版本为例，介绍招商银行 KubeVela 的离线部署实践，来帮助其他用户在离线环境中更便捷的完成 KubeVela 的部署。

在云原生快速发展的当下，如何让云的技术赋能业务开发？在上线应用时，如何让云的开发者在现代化的多集群、混合云环境中便捷地进行应用的开发和调试？在部署过程中，又该如何让应用部署具备充分的验证和可靠性？

这些至关重要的问题，都是我们急需解决的。

在本文中，我们将结合 KubeVela 以及 Nocalhost 开源项目，给出一个基于 Kubernetes 和容器生态的端云联调、一键完成多集群混合环境部署的解决方案，来回答上述问题。

在机器学习浪潮迸发的当下，AI 工程师除了需要训练、调试自己的模型之外，还需要将模型进行部署上线，从而验证模型的效果（当然，有的时候，这部分工作由 AI 系统工程师来完成）。这一部分工作对于 AI 工程师们来说是繁琐、且消耗额外精力的。

而在云原生时代，我们的模型训练和模型服务也通常在云上进行。这样做不仅提高了可扩展性，还能够提升资源的利用率。这对于需要消耗大量计算资源的机器学习场景来说，是十分有效的。

但是 AI 工程师要想使用云原生的能力通常比较困难。随着时间的推移，云原生的概念已经越来越复杂。想要在云原生之上部署一个简单的模型服务，可能对于 AI 工程师来说，需要额外学习数种概念：比如 Deployment、Service、Ingress 等。

而 KubeVela 作为一个简单、易用、且高可扩展的云原生应用管理工具，能让开发人员方便快捷地在 Kubernetes 上定义与交付应用，无需了解任何底层云原生基础设施相关的细节。KubeVela 拥有着丰富的可扩展性，其 AI 插件提供了模型训练、模型服务、A/B 测试等功能，覆盖了 AI 工程师的基本需求，能够帮助 AI 工程师快速在云原生环境中进行模型训练和模型服务。

本文主要介绍如何使用 KubeVela 的 AI 插件，来帮助工程师更便捷地完成模型训练及模型服务。

KubeVela 目前已经支持了 AWS、Azure、GCP、阿里云、腾讯云、百度云、UCloud 等云厂商，也提供了简单快捷的命令行工具引入云服务商的云资源，但是在 KubeVela 里一个一个地支持云服务商的云资源不利于快速满足用户对于云资源的需求，本文提供了一个方案，用不到 100 行代码快速引入 AWS 前 50 最受欢迎的云资源。

同时，我们也期望用户受到本文的启发，贡献其他云服务商的云资源。

随着云原生的不断发展和成熟，越来越多的基础设施能力逐渐标准化成为 PaaS 平台或者 SaaS 化产品。一个产品的诞生不再像过去那样需要建立一个团队，从开发、测试一直到运维、基础设施全部分多种角色系统完成。如今，敏捷组织文化和云原生技术驱动，使得这些职责更多的是“左移”到了开发者身上，测试左移、监控左移、安全左移，以及 DevOps 等一系列理念都是在强调，通过开源项目或者云的产品和服务将测试、监控、安全、运维等一系列事务提前到开发阶段完成。这看似美好的愿景却给开发者带来了巨大的挑战，开发者对底层五花八门的产品和复杂 API 缺乏掌控力，他们不仅仅是在做选择，更多的需要去理解和协调底层复杂异构的基础设施能力，以便满足上层业务的快速发展和迭代需求。

这种复杂性和不确定性无疑大大降低了开发者的体验，降低了业务系统的交付效率，增加了运维风险。开发者体验的核心是“简单”和“高效率”，不管是开发者还是企业都需要更好用的开发者工具或者平台来达成。在现代云原生技术之上打造一款帮助开发者从开发、交付以及后续持续运维的一体化平台，一直是 KubeVela 演进的核心目标。如图 1 所示，在 v1.2 版本中，我们围绕开发者体验新增了 UI 控制台组件（VelaUX），简化了编排 YAML 的复杂性，完善了插件体系建设，丰富了云资源的扩展能力，增加了大量 CI/CD 等生态对接的能力，进一步完善了开发者端到端的使用体验。

图1：KubeVela 架构设计

KubeVela 作为一个简单、易用、且高可扩展的云原生应用管理工具，能让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 基础设施相关的细节。

KubeVela 背后的 OAM 模型天然解决了应用构建过程中对复杂资源的组合、编排等管理问题，同时也将后期的运维策略模型化，这意味着 KubeVela 可以结合 GitOps 管理复杂大规模应用，收敛团队与系统规模变大以后的系统复杂度问题。

在云原生理念迅速普及的今天，混合环境部署（混合云/多云/分布式云/边缘）已经成为了大多数企业应用、SaaS 服务、应用持续交付平台的必然选择，而云原生技术的发展趋势也正在朝着“一致的、跨云、跨环境的的应用交付”不断迈进。然而，无论是 Kubernetes 本身还是现有的各类应用交付系统，都没有在现今混合、分布式的部署环境之上引入一致的上层抽象来为应用交付进行建模。这种缺乏统一上层抽象的应用交付过程，往往同底层基础设施紧密耦合，导致用户心智负担很重并且严重依赖于用户个人的经验和能力。这不仅会大幅影响用户体验、降低生产效率，甚至还会导致错误和故障的发生。

而现在，这个问题终于有了一个开源、标准，又不失灵活度的解法。它就是：

KubeVela 作为一个开箱即用、面向现代微服务架构的应用交付与管理平台，今天正式发布了 1.1 版本，以更加用户友好和完善的功能集，开启了”让混合环境应用交付更加简单高效“的重要里程碑。

KubeVela 打通了应用与基础设施之间的交付管控的壁垒，相较于原生的 Kubernetes 对象，KubeVela 的 Application 更好地简化抽象了开发者需要关心的配置，将复杂的基础设施能力及编排细节留给了平台工程师。而 KubeVela 的 apiserver 则是进一步为开发者提供了使用 HTTP Request 直接操纵 Application 的途径，使得开发者即使没有 Kubernetes 的使用经验与集群访问权限也可以轻松部署自己的应用。

本文就以经典的持续集成 (Continuous Integration) 工具 Jenkins 为基础，简单介绍如何打造基于 GitOps 的应用持续交付的“高速公路”。

作为一个应用管理和集成平台，在生产环境中，KubeVela 需要处理数以千计的应用。 为了评估 KubeVela 的性能，开发团队基于模拟环境进行了性能测试，并展示了同时管理大量应用的能力。