阿里巴巴新一代“可编程”云原生应 用交付和管理平台实践 孙健波（天元） 阿里云 技术专家 孙健波（天元） 阿里云 – 云原生应用平台团队 OAM/KubeVela 项目负责人 云原生应用模型（OAM）以及 KubeVela 项目核心作者 负责推动标准化云原生应用交付和应用管理体系在阿里集团、 阿里云、开源社区全面落地。 技术布道师/开源爱好者 连续多届 ArchSummit、KubeCon 等大会讲师 从 2015 年开始参与贡献 Docker、Kubernetes 等 多个云原生开源项目，是《Docker 容器与容器云》主 要作者之一。 微信/Github ID @wonderflow Email： jianbo.sjb@alibaba-inc.com 一个典型的云原生应用交付流水线 推送代码 镜像构建 测试 应用打包 多区域分发 多区域分发 多区域分发 制品仓库 业务研发 测试环境 预发环境 环境和参数配置 资源组装 流程编排 部署到多环境 多集群 CIOps: 围绕 CI 工具的持续交付 • • • kubectl apply helm upgrade 其他模板方案然后 apply… 监 控 报 警 … … 生产环境 灰 度 发 布 弹 性 扩 缩 私有环境 高 可 用 …… CIOps：做 CI 很好，CD 问题很多.. 问题一： “基础设施的复杂性”暴露给开发者 业务使用方学习曲线陡峭 提交 发布 应用发布流程 制品仓库 基础 工作负载 YAML 文件 可观测性策略 （日志&监控） 安全扫描 策略 sidecar PV/PVC Mutating Webhook 原子的、碎片化的声明式对象 Validating Webhook Service HorizontalPodAutoscaler Istio Virtual Service 海量的、琐碎的基础设施细节 CRD Deployment StatefulSet 流量策略 Rollout Controller Prometheus Service Monitor 实例灰度/ 扩缩容策略 Job Label & Annotations Pod namespace 问题二：“编排的复杂性”需要开发者人工处理 开发测试环境 端云联调 集群环境初始化 远端 exec 断点调试 实时日志 云资源创建/销毁 热 加 载 现代微服务应用 ECS 依赖编排 预发联调环境 资源绑定 可观测性策略 （日志&metrics） 可观测性策略 （日志&metrics） 生产环境 流量策略 云资源绑定 巡检策略 故障注入 攻 防 演 练 实例灰度/ 扩缩容 策略 RDS ARM S 业务 Pod 业务 Pod Prometheus 云厂商 数据库 自建机房 同一个应用，在不同环境下部署的组件依赖差异巨大 数据库、负载均衡、K8s，在不同云上也存在诸多差异 安全扫描策略 通知、告警 SLB 多 集 群 同一个应用，在不同场景下的运维能力要求差异巨大 开发者心智负担重，单一系统缺乏统一交付能力。 需要补充大量人工操作，缺乏自动化。 问题三：以“脚本”为中心的系统缺乏自动化 开发调试 预发环境 v1 • 管理成本高 • • • v1->v2 配置漂移 难以维护、追踪和审计 • 大规模应用管理的噩梦 不具备自愈能力 • v2.x 配置漂移 难以扩展、复用、维护 • v2 紧急运维 北京集群 v1 v2 v3 配置漂移 模板渲染 脚本部署 网络出错 英国集群 v1 v1 配置漂移 部署动作执行后的任何异常都 意味着需要重新发布 集群 服务不ready A v1 v2 ❌ 问题四：权限和安全风险没有收敛 典型的 CI/CD pipeline 权限 • CI/CD 的安全域无法隔离 • CI 系统的权限难以控制 • 镜像仓库权限 Git 权限 镜像仓库权限 CI 权限 多集群、多租户 开发 RW RO 代码仓库 RW CI Pipeline RW 镜像（制品 ） 仓 库 RO Cluster API RW 镜像仓库权限 K8s 权限 CI CD 云原生持续部署（CD），用户的核心诉求是什么？ 用户对云原生持续部署的核心诉求 提供用户侧抽象，渐进 式的给出基础设施能力 屏蔽编排的复杂性， 提供自动化能力 提供部署能力：安全、稳定、大规模 Prod K8s 集群 1 K8s 集群 2 云资源 制品仓库 render orchestrate deploy Staging 统一抽象 -> 自动化编排 -> 部署能力 K8s 集群 1 K8s 带来的启示：声明式是用户侧抽象的最佳表达方式 ● 复杂管理逻辑下沉到 K8s 中，对用户仅暴露终态/意图的输 入 基于 Kubernetes 的声明式交付工作流 开始 基于 Kubernetes 的工作流让我们的交付具备了以下特性： ● ● ● ● 自动化 收敛性 幂等性 确定性 这也是大规模应用交付的核心要素。 预发环境 审批? 运行中 暂停 VPC 实例 终 态 生产环境 运行中 通知 结束 RDS 实例 K8s 控制平面 (作为工作流执行引擎) 容器 阿里巴巴的解决方案 -- KubeVela • 一个面向现代云原生环境的应用交付/持续交付系统 ● 以应用为中心的开发者体验 CI Pipeline ● 面向终态的声明式交付工作流 Jenkins Kubernetes Clusters KubeVela Render Orchestrate ● 面向混合环境，基础设施无关 ● IaC/可编程，高度可扩展 Deploy Clouds ● CNCF 项目: ● https://github.com/oam- ... dev/kubevela IoT/Edge CI CD 基于 K8s 控制平面，面向混合环境统一交付 开发运维人员 一个基于 K8s 的“应用交付控制平面”，不侵入到用户的应 Application（统一应用定义） 用运行时集群 • 与运行时解耦：用户可以使用任何来自社区的 K8s 插件运 维和管理应用，交付引擎在控制平面管理和操作这些插件 • 天然支持多环境/多集群应用交付 • • Step 3 Step 1 Trait 1 Step 2 面向多集群并且同时支持 Push 和 Pull 模式 Workflow 基于 Terraform 构建 K8s 控制器 云边一体的统一交付模式 • Component B Trait 2 面向终态的统一云资源管理 • • Component A 统一应用交付引擎 基于 OpenYurt 实现边缘节点的管理 新一代 K8s 多集群技术（OCM等） K8s 边缘管理能力（OpenYurt） IoT/Edge Clouds Kubernetes Clusters 统一的声明式应用交付抽象定义 待交付组件 • 开发者唯一需要用户学习的 API • 完全声明式，面向终态的自动化管理， 比如 容器镜像、Helm chart、云资源 Terraform 模块等… 定义任意可交付制 品！ 可以直接被 GitOps 驱动 运维能力 应用部署后的持续运维，比如路由规则、 自动扩缩容规则等… 像乐高一样可以附 着作用于组件上！ 交付策略 比如环境部署策略、健康检查策略、防 火墙规则等，任何一个部署前需要遵守 的规则都可以在这个阶段声明和执行！ 工作流定义 比如跨环境部署、手动审批、通知等管 道式持续交付能力！ 声明式交付工作流 VS jenkinsfile 可编程的交付工作流 然后，KubeVela 直接使用 K8s 来作为工作流执行引擎 • 确定性 • 交付 10 个实例，不断运行直到 10 个正常运 行 • 收敛性 • • 幂等性 • • 1 个实例被误删，一定能够自己恢复回来 整个工作流在失败、重试时保持健壮 自动化 • 工作流提交后就可以“撒手不管” 优点：绝对健壮的交付工作流，这是 KubeVela 能 够被应用在大规模持续交付场景中的必备素质 缺点：需要依赖和部署一个管控 K8s，在后续版本 KubeVela 的应用交付计划，只用来承接用户输入，然后就会被整体的渲染为一个 基于 IaC （Infrastructure as Code） 代码实现的 DAG（工作流） 中我们计划给出简化部署模式（Standalone 模式） 内置的可编程 IaC 模块示例 • • • • 可复用 可组合 可互相之间传递数据 可版本化 详见：KubeVela 平台管理员文档 基于 KubeVela 的GitOps 多集群/多环境应用交付 CI Pipeline CI 代码开发仓库 开发人员 Jenkins 读写 制品仓库 读写 运维人员 配置仓库 Application YAML CD 自动或手动 镜像触发CD Download Artifacts Push app.yaml (legacy mode) 只读 Sync Open Cluster Management 读写 Kubernetes Clusters 只读 KubeVela • CI/CD 安全域隔离 • 完全基于 Pull 模式的 GitOps 支持，子集群数据 Control Plane K8s Clouds 不出地域，基于集群环境自治 • 面向开发者的一致体验，CI/CD全自动 • 无缝对接各类传统 CI 制品 • Pull 模式下，控制面数据下发以后，runtime集群会自 动订阅数据repo的变化，形成区域自治 IoT/Edge 订阅模型 生态项目对比 • 纯粹的 GitOps 系统： • • 本质上是在运行时集群中的 agent，无法跨环境交付 经典应用 CI/CD 交付平台： • 本质上是面向过程的执行，不具备声明式系统的自动、幂等、收敛、确定等特性 • 安全性问题的本质 • • 各类 Kubernetes 发行版： • • 基于过程式的 Push vs 基于统一模型的 Pull 定位上就严格遵守 K8s 的 API，不提供 K8s 之上的应用层能力 经典 PaaS/各类“云原生”应用管理平台 • 本