开发者学堂课程【4天定制混合云应用交付流水线-1024程序员节创造营公益课：K8s 生态现状和应用交付的“下一站”】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/893/detail/14267
K8s 生态现状和应用交付的“下一站”
目录：
一、Kubemetes 和云原生技术带来的变化
二、问题和具体解决方法
三、发展趋势
一、Kubemetes 和云原生技术带来的变化
1. 云原生的本质
用云的两个特性：
第一，云可以帮助我们降低成本。
云的资源都是磁化共享的，我们可以弹性的按需去使用我们需要的资源。当我们不需要使用它的时候，我们就不需要去花钱，这样可以降低我们的拥有和使用成本。
第二，云可以帮助我们提升效率。
因为现在复杂的应用的运维操作，它都以一种标准的云服务的方式提供出来。这就好比今天去麦当劳点外卖一样，我们不需要自己去做了。那今天我们在使用云服务也是一样的，很多底层的细节我们不需要去关心，也不需要去操作了。我们可以花更多的时间专注于业务逻辑本身，从而提高研发和交付效率。
云原生正是这么一套方法论和 best practice 来帮助我们去实现这两个特性，而这套方法论它进一步的具化成了具体的开源项目。
正是有了这些具体的开源项目，才把释放云的红利这件事情给真正的落实下来，从而让我们真正能够享受到云的降本和提效两个特性。
2. 云原生促进了混合环境的流行
Kubemetes 如此重要，是因为它提供了统一、一致的基础设施层抽象。
通过 Kubemetes，我们就有了一套统一的 API 去使用不同云的，包括计算存储网络在内的基础设施资源。通过Kubemetes，我们搭建一个混合云环境架构，它变得如此容易。而我们可以看到一个趋势就是云原生技术会使得很多环境不断的更加的流行起来。K8s 和云原生技术使搭建混合环境架构变得容易。
3. 混合环境带来的好处
第一，它能够让我们弹性降本，我们可以使用云上的资源来快速扩缩容，从而快速的应对流量的高峰，以及在流量高峰过去的时候快速销毁资源，从而来节省成本。
第二，它能够让我们多云容灾，我们可以使用云在更广阔的地域部署不同的实力，从而当某个地域出现问题的时候，保证服务依然对用户可用。
第三，我们可以借助云的基础设施实现全球部署，这往往是单个公司没法去做到的，而云服务厂商却有能力去做到，并且以一种标准化的服务给提供出来。这对于很多出海业务是非常有帮助的。
第四，今天很多中间件还有应用的运维能力等等，都通过标准的云服务提供出来。这让开发不需要再去关心底层的细节，从而更加专注于业务逻辑本身，真正提升研发的效率。
总之，正是因为混合环境带来了诸多好处，所以混合环境逐渐成为企业上云的一种新常态。
二、问题和具体解决方法
1. 混合环境也带来了新的挑战
不同云基础设施的底层能力是不一样的。混合环境的基础设施能力不一致包括：不同的数据库（PolarDB vs MySQL），不同的监控平台（ARMS vs Prometheus/Loki/Grafana），不同的交付流水线（Flow vs Jenkins），还有不同的应用运维操作等等。
这导致用户需要去学习更多的东西，用户的使用难度变大了，学习成本变高了，这反而会导致整个团队的交付效率、开发效率变低，并且操作起来也更容易出错。
但是这些问题通过正确的路径，正确的流程方法和架构，都是可以去避免的。
所以业界的下一个焦点必然是如何去设计一套好的系统和项目，去做高效安全的面向混合环境的应用交付，从而让开发者真正享受到云带来的红利，真正的去提升交付和开发的效率。
2. OAM：以应用为中心的标准交付模型
阿里云联合微软云在2019年末共同发布了Open Application Model（OAM），这是以应用为中心的一套标准交付模型，它的出现正是为了解决之前谈到的问题。
OAM 旨在实现标准、统一、面向混合云的应用交付流程。
我们可以看到 OAM 以应用为中心去定义服务的组件以及服务需要的运维能力，真正让开发者去关注应用本身，而不需要去关心底层的运维细节。
3. 阿里应用管理平台的演进
2018年，阿里的整个基础设施都进行了全面的 K8s 升级。
2019年初，阿里的主要应用平台（EDAS等）的核心发布链路开始切换到K8s。
2019年末，阿里联合微软发布统一应用模型 OAM，同时启动EDAS内核升级，将 PaaS 产品的边界扩展到混合环境上。
2020年，阿里全面推进云原生这个 PaaS 产品整体升级，以 OAM 和 KubeVela 为统一架构来支持各类应用交付和运维场景，着手打造一个跨环境跨基础设施的统一应用管理体系。
4. 整个平台架构升级的过程中暴露的问题，沉淀的解法
问题：
第一个问题，封装能力的问题。我们通常使用的模板语言（如Go template）不够灵活，并且大规模难以管理。
第二个问题，交付模型设计的问题。应用交付流程是一个面向过程的一个工作流程，而 K8s 面向终态的模型不太适用。
第三个问题，平台扩展性的问题。平台的功能往往是与业务紧耦合的，缺乏通用的扩展性，致使迭代效率越来越低。我们需要的一个更通用的平台底座。
第四个问题，架构合理性问题。经典架构设计往往作为一个 K8s 插件来实现，无法做到面向多集群来进行交付。
相应的解法：
针对封装能力的问题：选型 CUE 语言来做封装抽象，CUE 源于 Google Borg 系统，是一个用户友好的数据配置语言，非常简单易用，并且能够满足大规模的场景。
针对交付模型的设计问题：抽象出一层能够表达工作流的应用交付模型。
针对平台可扩展性的问题：把整个平台系统的所有能力都设计成可插拔的，并且提供这个IaC的方式来扩展平台能力。
针对架构合理性的问题：把架构设计成为一个“应用交付平面”，与运行时解耦，提供集群和环境等概念，统一管理包括云服务等所有资源。
5. Infrastructure-as-Code (IaC)
IaC 是指运维专家把他的知识通过一些框架，比如 Pulumi 写成代码，然后 commit 到 GitHub 代码仓库里面去，接下来 CICD 又从 Git 仓库把这段代码拉下来，用 Pulumi 去执行起来。而 Pulumi 会去对接和操作相应的云基础设施，把需要的基础设施资源给拉起来。
三、发展趋势
1.经典扩展云原生平台的方式
一种是使用模板语言。
模板语言可以把像 deployment 和 pod 等复杂的对象通过封装，然后透出简单的字段来给用户使用。而模板语言的问题在于灵活性不够，并且当它数量大了的时候，它的结构复杂难懂，且难以大规模维护。
另一种方式是去写 K8s Controller。
通过 Kubemetes 对应的 SDK 来去构建相应的 API 和服务。然后，Kubemetes 需要写大量的代码来去做相应的运维逻辑。最后，还要打包并部署到 Kubemetes 上面去。
虽然这种方式很灵活，但是它的难度太大，它的专业要求度太高，且代码量大。并且由于它的部署的本质，它整个开发响应的速度非常的慢。
2.IaC 是扩展平台的最佳方式
从下面图中我们可以看到，首先对于用户，它可以通过编写简单的 q 的配置语言的代码，然后就把它打包成一个Template 并注册到 KubeVela 原生平台上去。
然后，当用户部署一个交付计划的时候，相应的 Template 能立刻做出响应。而不需要像写 controller 一样重新打包，并且它的整个语言的方式、表达能力是比传统的模板语言更强大。
总结下来，IaC 有三个好处。第一，灵活可编程。第二，响应速度快。第三，大规模易维护。
3.KubeVela 项目
项目特点：
第一，它提供了上层应用交付抽象，它是基于标准开放应用模型（OAM），抽象了基础设施底层细节，只透出用户关心的应用 API。
第二，它内置了轻量高效的工作流，整个工作流无需额外启动进程或容器，它运行起来更加清亮高效。
第三，它用 IaC 的方式扩展平台，将运维逻辑用 CUE 语言代码化，比模板语言更灵活，比写 controller 简单了一个量级。
第四，它面向混合环境的应用交付平面，提供了环境和集群等围绕应用的概念抽象，统一管控所有应用依赖的资源（包括云服务等）。
KubeVela 项目的主旨：
让应用的交付和管理变得简单、可靠、高效，让用户真正实现高效、安全的混合环境应用交付。
4.KubeVela Application（应用部署计划）
内容：
第一，待部署组件 components。
它里面包含了像 Helm chart，Kustomize，云资源，Cloud Formation 模板，Terraform 模块等等，几乎可以包括一切交付品。
第二，运维能力 treat。
它是指应用部署后的持续运维，比如路由规则，自动扩速容规则、监控规则等等，都可以像乐高一样附着于服务组件上。
第三，应用的全局策略。
比如集群分发策略、健康检查策略、SLO 等等，任何一个部署前需要遵守的规则都可以在这里声明。
第四，交付工作流 workflow。
比如蓝绿部署、带流量的渐进式部署、手动审批等等面向过程的管道式持续交付操作。
作用：
一，简单易用。Properties 字段只需填用户关心的简化过的参数，其他底层细节被彻底抽象封装。
二，组件能力“胶水”。高度可扩展：模块化接入，拼测试衔接，管道式编排。能力“可编程”：高效响应需求变化，没有系统变更负担。
5.KubeVela 的多集群管理技术原理
这个也是混合环境背后的技术原理。
KubeVela 背后有一个叫做 Cluster Gateway 的项目，用户首先把集群连接信息，比如 Kubeconfig 注册上去。
然后，Cluster 在下发这个工作负载的时候，它会往 class 的各位发一个 request。
Request 内容除了正常的工作负载以外，还会包含目标集群的信息，而Gateway会负责找到目标集群的连接信息，把工作负载对应的下发下去。
6、KubeVela 实现混合环境的统一应用交付
KubeVela 能力：
多集群灰度发布
多集群副本调度
子集群状态回流
跨集群资源拓扑
跨可用区容灾分布
环境差异化配置
统一可观测性
7、KubeVela 1.2规划
① 发布一站式 DevOps 体验的 Dashboard，默认内置 CICD 能力和常用的应用交付运维能力
② 增强 Vela CLI，提供 vela doctor 等辅助 debug 能力
③ Vela Workflow 支持主流 CI 接入：Jenkins、Github Action、GitLab
④ 改善 Workflow 出错信息，帮助用户快速定位中间环节问题
⑤ 可观测性：新增应用交付相关的 metrics，如发布频率、发布时长、MTTR 等
