以一致的体验交付和管理云原生多集群应用

2022 年 1 月 06 日
本文字数：7483 字
阅读完需：约 25 分钟

作者：冯泳，孙健波

大家好，很高兴能在 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、腾讯等众多云厂商实践到云产品中，同时也被国家信通院立项作为《云计算开放应用架构》行业标准发布。

图 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 一样简单。

创作场景