云原生 DevOps，模型化应用交付能力很重要

Posted 2021-12-13 阿里云云栖号

简介： DevOps 文化及其支撑其落地实践的自动化工具与平台能力在云原生架构渐为普及的背后，发挥了关键的价值。

撰稿：溪洋

云原生正在成为企业业务创新和解决规模化挑战的加速器。

云原生带来的变革绝不限于基础设施和应用架构等技术层面，更是对于研发理念、交付流程和 IT 组织方式的变革，也在推进企业 IT 组织、流程和文化的变革。在云原生架构渐为普及的背后， DevOps 文化及其支撑其落地实践的自动化工具与平台能力，发挥了关键的价值。

云原生带来的研发与运维协作界面

相较于云原生，DevOps 并不是什么新鲜的事情，其实践早已深入企业现代应用程序架构。DevOps 强调团队间的沟通和快速反馈，通过构建自动化的持续交付（Continuous Delivery）及流水线的应用发布方式，达到快速响应业务需求、交付产品和提高交付质量的目的。随着容器技术在企业的规模化应用，云计算可编程基础设施和 Kubernetes 声明式的 API 等能力加速了开发和运维角色的融合。

云原生的大势所趋使上云成为企业标配，围绕云原生去定义下一代研发平台成为必然，也倒逼着 IT 组织方式进一步发生变化——新的平台工程团队开始浮现。在这样的背景下，如何在云原生的环境下更高效地实践 DevOps 成为一个新的课题和诉求。

下一代 DevOps 平台演进趋势

伴随着 Kubernetes 生态从底层到应用层能力的逐步完善，平台工程团队可以更方便地基于业务场景和终端用户实际需求来构建不同的应用平台，却也为上层应用开发者带来了挑战和困扰。

Kubernetes 生态本身的能力池固然丰富，但是社区里却并没有一个可扩展的、方便快捷的方式，为云原生架构下混合、分布式的部署环境引入一致的上层抽象来为应用交付进行建模。应用交付过程上层抽象能力的缺失，使 Kubernetes 的复杂性无法做到向应用开发人员屏蔽。

下图展示了一个云原生下的 DevOps 流水线的典型流程。首先是代码的开发，代码托管到 Github，再接入单元测试的工具 Jenkins，此时基本研发已完成。再接着到镜像的构建，涉及到配置、编排等。云原生中可以用 HELM 打包应用。打包好的应用部署到各个环境中。但整个过程中会面临很多挑战。

首先，在不同的环境需要不同的运维能力。其次，配置的过程中要创建云上数据库，需要另外打开一个控制台来创建数据库。还需要配置负载均衡。在应用启动以后还需要配置额外的功能，包括日志、策略、安全防护等等。可以发现，云资源和 DevOps 平台体验是割裂的，里面充斥着借助外部平台创建的过程。这对新手来说是非常痛苦的。

在容器出现之前的传统的 DevOps 模式需要不同的流程和工作流。容器技术是以 DevOps 的视角构建的。抽象的容器所提供的功能会影响我们如何看待 DevOps，因为随着微服务的出现，传统的架构开发将发生变化。这意味着要遵循在 Kubernetes 上运行容器的最佳实践，并将 DevOps 的理念向 GitOps、DevSecOps 扩展，使云原生下的 DevOps 更加高效、安全、稳定、可靠。

OAM（Open Application Model） 试图提供一种云原生应用的建模语言，以实现研发和运维的视角分离，使 Kubernetes 的复杂性无需透传至研发，运维通过提供模块化、可移植、可扩展的特性组件，支撑各种复杂的应用交付场景，从而实现云原生应用交付的敏捷性和平台无关性。其在 Kubernetes 上的完整实现 KubeVela，已经被业界认为是构建下一代持续交付方式及 DevOps 实践的核心工具。

最近，阿里云在 2021 云栖大会上发布了云效应用交付平台 AppStack ，旨在进一步加速企业云原生 DevOps 规模化落地。据云效应用交付平台 AppStack 研发团队介绍，其在设计之初就全面支持原生 Kubernetes 和 OAM/KubeVela ，以实现对应用部署架构无绑定、无侵入，使企业不用担心迁移以及技术改造成本。这也标志着 KubeVela 正在成为云原生时代应用交付领域的重要基石。

基于 KubeVela，构建以应用为中心的交付系统

在云原生理念迅速普及的今天，混合环境部署（混合云/多云/分布式云/边缘）已经成为了大多数企业应用、SaaS 服务、应用持续交付平台的必然选择，而云原生技术的发展趋势也正在朝着“一致的、跨云、跨环境的的应用交付”不断迈进。

KubeVela 作为一个开箱即用、面向现代微服务架构的应用交付与管理平台，已经正式发布 1.1 版本。在此版本中，KubeVela 更加聚焦面向混合环境的应用交付流程，带来了多集群交付、交付流程定义、灰度发布、公有云资源接入等多个开箱即用的能力和更加友好的用户体验，帮助开发者从“静态配置、模板、胶水代码”的初级阶段，直接升级至“自动化、声明式、统一模型、天然面向多环境”的下一代以工作流为核心的交付体验当中。

基于 KubeVela，用户可以非常轻松地处理以下场景：

多环境、多集群应用交付

面向 Kubernetes 的多环境、多集群交付已是一个标准性需求。从 1.1 版本开始，KubeVela 不仅实现了多集群的应用交付，并且既可以独立工作直接纳管多个集群，也可以集成 OCM、Karmada 等各类多集群管理工具来进行更复杂的交付动作。在多集群交付策略的基础上，用户还可以通过定义 Workflow 来控制交付到不同集群的顺序、条件等工作流步骤。

定义交付工作流（Workflow）

Workflow 的具体使用场景则很多，比如在多环境应用交付场景中，用户可以定义不同的环境交付的顺序和前置条件等 。KubeVela 的工作流是面向 CD 过程的，同时也是声明式的，所以它既可以作为 CD 系统直接同 CI 系统（比如 Jenkins 等）对接，也可以嵌入到现有 CI/CD 体系中作为增强和补充，落地方式非常灵活。

在模型上，Workflow 是由一系列 Step 组成的，而在实现上，每一个 Step 则是一个独立的能力模块，由其具体的类型和参数来决定其具体步骤的能力。在 1.1 版本中，KubeVela 内置的 Step 已经比较丰富，也非常容易扩展，帮助用户轻松对接已有的平台能力，做到无缝迁移。

以应用为中心的云资源交付

KubeVela 的设计是从“以应用为中心”的视角出发，因此可以帮助开发者以完全 Serverless 的方式更好、更方便的管理云资源，而不是疲于应付各种不同的云产品和控制台。在实现上，KubeVela 内置集成了 Terraform 来作为云资源的编排工具，并且能够以统一的应用模型支持各个云厂商上百种不同类型云服务的部署、绑定和管理。

在使用上，目前 KubeVela 将云资源分为以下三类：

• 作为组件：比如数据库、中间件、SaaS 服务等。比如 KubeVela 中的 Alibaba-RDS 服务就属于这种
• 作为运维特征：比如日志分析、监控可视化、监控报警等服务
• 作为应用运行基础设施：比如 Kubernetes 托管集群、SLB 负载均衡、NAS文件存储服务等

更容易落地的 GitOps 持续交付实践

KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用（可单独使用，也可配合 ArgoCD 等工具），并且能够为 GitOps 场景提供更多端到端的能力和增强、帮助 GitOps 理念以更加亲民和解决实际问题的方式在企业中落地。这些能力包括：

• 定义应用交付工作流（CD 流水线）
• 处理部署过程中的各种依赖关系和拓扑结构
• 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程
• 统一进行云服务的声明、部署和服务绑定
• 提供开箱即用的交付策略（金丝雀、蓝绿发布等）
• 提供开箱即用的混合环境/多集群部署策略（放置规则、集群过滤规则、跨环境Promotion 等）
• 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而用户无需学习任何 Kustomize 本身的细节
• ……

KubeVela 1.2 版本即将重磅发布

持续打造天然面向混合环境的企业应用操作系统、让开发者享受交付应用的过程，这是 Kubevela 项目的目标和愿景。在接下来的 1.2 版本，KubeVela 将带来以应用为中心的控制面板 UI，实现便捷的企业应用组装、分发、交付流程，提供给开发者更简单的应用交付体验，同时覆盖边缘应用交付等更多的使用场景。

KubeVela 1.2 版本将在 2021 年 12 月举办的 KubeCon China 上重磅发布，敬请持续关注 KubVela 社区以及阿里巴巴云原生动态！

原文链接
本文为阿里云原创内容，未经允许不得转载。