议题简介：在云原生理念迅速普及的今天，混合环境部署（混合云/多云/分布式云/边缘）已经成为了大多数企业应用、SaaS 服务、应用持续交付平台的必然选择，而云原生技术的发展趋势也正在朝着“一致的、跨云、跨环境的应用交付”不断迈进。CNCF 沙箱项目 KubeVela，作为一个开箱即用、面向现代微服务架构的应用交付与管理平台，面对混合云环境的应用交付难题，提出一个开源、标准，又不失灵活度的解法。
分享人：曾庆国（悦达），KubeVela 开源产品经理，阿里云技术专家。目前负责 OAM/KubeVela 产品和开源社区布道，从事云原生、应用交付、开源领域研究和实践多年，致力于推动云原生应用标准化和云原生技术“亲民化”。
目录：
• 云原生应用交付流水线案例
• CIOps：做 CI 很好，CD 问题很多
• 云原生应用持续交付，用户的核心诉求
正文：
云原生生态里已经出现了大量的优秀实践和技术，都可以给我们提供生产力，但各种方案如何有效的组合，更简单地呈现给广大的开发者，变成了一个课题。
一、一个典型的云原生应用交付流水线
目前中大型企业在做应用发布时，较多的企业都已经将其应用运行环境升级为了K8s 容器化环境，与云原生实践接轨。上图是一个典型的云原生应用交付过程，也就是我们常说的DevOps，我们大体上可以分为CI、CD两部分：
1、CI：
如图示上方是一个典型的CI流程， 可分为三个部分：镜像构建（Build）、测试(Test)和应用打包(Artifacts)。这个流水线过程的目的是输入源码到输出云原生制品。在这个过程中针对代码处理和制品处理的工具链已经很丰富，比如Jenkins的插件体系。
目前也有比较多的企业在 CI 流水线的最后一步直接进行应用的部署，它的目标可能有主机、容器环境、K8s环境、甚至更大规模的多集群K8s环境等，把服务进行发布上线的过程就是接下来我们要聊的CD环节。
2、CD：
图示下方是将CD环节拆开来看，将制品进行部署的过程包括环境和参数配置、资源组装、流程编排、部署到多环境等，在开发环境、预发环境、生产环境、私有环境或各个边缘环境中去部署和发布。 发布过程需要可观测，可追踪、可回退，发布的后续动作还会包括监控、运维等。我们可以发现，CD 环节需要面对的复杂性不亚于CI环节，相反，它还是影响业务稳定的最重要环节。
3、CIOps: 围绕 CI 工具的持续交付
• kubectl apply
• helm upgrade
• 其它模板方案然后apply...
以上是围绕CI做发布的常见形式，比较笼统的将服务配置下发的目标集群上。
二、CIOps：做 CI 很好，CD 问题很多
1. 问题一：“基础设施的复杂性”暴露给开发者
业务开发者需要学习的东西很多，比如：原子的、碎片化的声明式对象，海量的、琐碎的基础设施细节。在整个发布过程中用到的云原生技术有很多，包括可视化、安全、灰度、自动扩缩容、微服务治理等等。这里我们都希望有一种技术，把海量的基础设施配置，通过一种标准形式更简单化的管理起来。
2. 问题二：“编排的复杂性” 需要开发者人工处理
目前中大型公司已经开始了上云、 容器化的工作，整个云的形态已经朝着分布式的形式发展，但由于发布环境各异，需求各异，导致编排极其复杂。
a. 场景现状：
• 同一个应用，在不同环境下部署的组件依赖差异巨大；
• 数据库、负载均衡、K8s, 在不同云上也存在诸多差异；
b. 开发现状：
• 开发者心智负担重，单一系统缺乏统一交付能力；
• 需要补充大量人工操作，缺乏自动化；
c. 同一个应用，在不同场景下的运维能力要求差异巨大
• 开发测试环境：需要进行热加载、调试、查看开发日志以及实时运行的情况等；
• 预发联调环境：需要考虑服务之间的调用，测试时需要观看响应指标，绑定资源，错误定位，进行攻防演练等；
• 生产环境：包括可观测性、流量、云服务等。
3. 问题三：以“脚本”为中心的系统缺乏自动化
上图中用Jenkins做脚本执行流水线，发布服务到不同的集群。在需要把应用从低版本向高版本升级时，假设我们先在发布到预发布环境，此时服务配置可能还不稳定，开发者进行在线开发调试。甚至当我们进行生产上线时，可能也会因为不同的环境因素导致故障从而进行紧急运维变更，但此时脚本侧不会进行记录。
如果我们发布的环境包括国内国外多个集群，网络不稳定会导致可能部分集群发布失败，一次性执行的脚本服务不会再维护状态，这时又不得不人工接入排查。
以“脚本”为中心的弊端：
a. 管理成本高：难以扩展、复用、维护
b. 配置漂移：难以维护、追踪和审计；大规模应用管理的噩梦；
c. 不具备自愈能力：部署动作执行后的任何异常都意味着需要重新发布。
当然它的优势就是使用简单，对于简单业务，简单环境场景非常适用。
4. 问题四：权限和安全风险没有收敛
上图在做CI/CD的过程中，CI环节读取源代码到制品库，需要有源代码的读取权限，打包时需要调用一些计算资源，推送到镜像仓库时，需要镜像仓库的写入权限；CD环节读取镜像，需要镜像仓库的读取权限，需要K8s等相应集群的管理权限。
问题：
• CI/CD的安全域无法隔离，各种权限混合使用；
• CI系统的权限难以控制，多集群、多租户。
三、云原生应用持续交付，用户的核心诉求是什么？
1. 用户对云原生应用持续交付的核心诉求
CD持续发布过程中的诉求：
• 统一抽象：K8s持续演进帮助我们把底层各种各样的基础设施完全抽象化，抽象化过程需要不同企业的相应类似描述文件，描述文件相同的是描述、日志等，不同的是服务名称、镜像、服务端口等；
• 自动化编排：屏蔽编排的复杂性，提供自动化能力；
• 部署能力：安全、稳定、大规模地把此资源分发到不同环境和集群里。
目标是开发者在制品仓库输入变量，后面的过程可以完全自动化的进行，将复杂巨大的程序都屏蔽在底层，如果有问题可以由专业的工程师做相应的维护和调试。
2. 如何实现
K8s带来的启示：声明式是用户侧抽象的最佳表达方式，将复杂管理逻辑下沉到K8s中，对用户仅暴露终态/意图的输入。
K8s是基于终态的状态机维护，通过当前状态和预期状态持续比对，基于K8s控制平面来达到最终状态，这也是K8s的一个很好的理念。平台最终操作的资源各种各样，包含有K8s资源、云厂商资源、自建私有云资源等。各种资源都可能是我们的操作对象，来匹配用户的诉求。
基于Kubernetes的工作流让我们的交付具备了以下特性，也是大规模应用交付的核心要素：
• 自动化
• 收敛性
• 幂等性
• 确定性
四、阿里巴巴的开源解决方案– KubeVela
KubeVela为广大开发者提供了一个面向现代云原生环境的应用交付/持续交付系统：
• 以应用为中心的开发者体验；
• 面向终态的声明式交付工作流；
• 面向混合环境，基础设施无关；
• laC/可编程，高度可扩展；
CNCF项目地址：https://github. com/oam-dev/kubevela
1. 基于 K8s 控制平面，面向混合环境统一交付
基于K8s的“应用交付控制平面”架构
基于K8s的“应用交付控制平面”，不侵入到用户的应用运行时集群，架构分为两层：
• 下方是核心控制器，运行交付工作流帮我们到达终态，架构在多集群（易构的边缘集群、中心集群等）多环境基础之上；
• 上方是面对用户是标准的Application描述文件；面对开发者，业务包括服务、第三方、云服务等。核心应用包含了服务组件，组件可以挂相应的标准描述运维特征（日志收集、指标监控、链路追踪、服务注册、网关策略等），可以通过UI或命令行两种终端形态进行完整的生命周期管理。
2. 架构特点：
a. 与运行时解耦：
用户可以使用任何来自社区的K8s插件运维和管理应用，交付引擎在控制平面管理和操作这些插件；
b. 天然支持多环境/多集群应用交付：
围绕着应用描述，提供了完整的多集群应用交付能力、用户可通过配置应用在多个集群的调度策略、差异性配置策略即可便捷完成多集群复杂应用的安全交付。
c. 面向终态的统一云资源管理；
KubeVela集成了Terraform 的云资源描述能力，继而集成了Terraform 的云资源支持生态，通过Application 描述用户可以同时交付普通服务和云服务组成完整交付应用。
d. 云边一体的统一交付模式；
集成边缘应用的描述规范，边缘环境以KubeAPI 规范接入到管控平面，实现边缘应用的维护和分发。
e. 面向不同场景需求用户分层集成；
KubeVela 架构上分为核心模块和上层终端产品VelaUX，对于大型企业的PaaS平台开发者，可直接集成 KubeVela 核心模块，获取应用引擎能力。对于中小型终端客户，可借助终端产品生态快速落地。同时VelaUX也具备了必要的扩展能力，通过编辑配置即可适应不同企业的应用管理诉求。
3. Application Demo示例：
1) 待交付组件
比如容器镜像、Helm chart、云资源Terraform模块等...定义任意可交付制品!
2) 运维能力
应用部署后的持续运维，比如路由规则、自动扩缩容规则等...像乐高一样可以附着作用于组件上!
3) 交付策略
比如环境部署策略、差异性配置策略、健康检查策略、防火墙规则等，任何一个部署前需要遵守的规则都可以在这个阶段声明和执行!
4) 工作流定义
比如跨环境部署、手动审批、通知等管道式持续交付能力!
统一的声明式应用交付抽象定义：
• 开发者唯一需要用户学习的API；
• 完全声明式，面向终态的自动化管理,可以直接被GitOps驱动。
4. 灵活的扩展机制
KubeVela的设计就是一个微内核状态，先安装基础的微内核，然后需要什么能力就去安装对应的扩展插件，整个完整的插件体系可以帮助开发者快速的接入相应的能力。
5. 生态项目对比
a. 纯粹的GitOps系统：本质上是在运行时集群中的agent,无法跨环境交付；
b. 经典应用CI/CD交付平台：
• 本质上是面向过程的执行，不具备声明式系统的自动、幂等、收敛、确定等特性；
• 安全性问题的本质：基于过程式的Push vs基于统一模型的Pull；
c. 各类Kubernetes发行版：定位上就严格遵守K8s的API,不提供K8s之.上的应用层能力；
d. 经典PaaS/各类“云原生"应用管理平台：本质上是不具备开放性的封闭抽象
• 只能处理容器交付，不能面向云进行统一交付
• 不可扩展(需要重写代码和重新部署)，不能跟随用户一起成长和演进
• 被集成性差:用户需要做出唯-性选择，不能够跟其他平台共存
6. OAM：现代微服务与应用交付模型
要屏蔽繁杂的底层，一个重要的问题就是标准化。将应用通过标准化的描述，让业务和基础测试有完美的衔接，KubeVela体系完全基于OAM的生态去做，欢迎各大厂商共建，普惠云的开发者。
7. 实践案例 - Serverless 应用引擎（SAE）
SAE的核心能力是支持微服务或者PHP应用的开发者，只需要提供war、jar、php的源码包，就可以完成后面所有微服务治理和整个部署链路的管理事项，其背后就是KubeVela进行支撑。
8. 社区和生态
• Star: 超过3300个
• 镜像下载: 超100万次
• 贡献者超过: 120位
• Commit: 超过2000个
参考资料：
GitHub地址：https://github.com/oam-dev/kubevela
KubeVela文档：https //kubevela.io
给项目点Star：https //gith:ib. com/oam-dev/kubeveta
用户注册登记：https:// github.com/oam-dev/ kubevela/issues/1662s
