咦，于是乎大家兜兜绕绕，又回到了故事的原点。唯一的变化是，咱们今天这个 PaaS 是基于 K8s 实现的，确实轻松了不少。
但实际情况呢？
这个基于 Kubernetes 构建 PaaS 的故事，看似美好，其实整个过程却难免有些“心酸”。说的好听点是开发 PaaS，其实 80% 的工作是在设计和开发 UI，剩下的工作则是安装和运维 K8s 插件。而更令人遗憾的是，我们这样构建出来的 PaaS，其实跟以前的 PaaS 没有本质不同，任何时候用户诉求改变，我们都需要花大量时间重新设计、修改前端、排期上线。结果就是，K8s 日新月异的生态和无限可扩展的特性，都被“封印”在我们亲手构建的 PaaS 之下“不见天日”。终于有一天，业务方也实在忍不住要问了：你们平台团队上了 K8s，到底有啥价值？
上面这个“为了解决 PaaS 的固有限制，结果又引入一个新的 PaaS 和限制”的困局，是现今很多公司在落地云原生技术的过程中遇到的一个核心问题。我们似乎再一次把用户锁定在一层固定的抽象和能力集当中。所谓云原生化的好处，仅仅体现在咱们自己开发这个平台变得简单了 —— 而对业务用户来说，这似乎没什么太大的意义。
更为麻烦的是，云原生和 K8s 的引入，也让运维人员这个角色变得非常微妙。本来，他们所掌握的业务运维最佳实践，是整个公司中最重要的经验和资产。然而，在企业云原生化之后，这个工作的内容都必须交给 K8s 去接管。所以，很多人都说，K8s 要让“运维”失业了，这个说法虽然有点夸张，但确实反映出了这个趋势带来的焦虑。而且我们不禁也在从另一个角度思考，云原生化的背景下，应用运维的经验和最佳实践，又该怎么落实？就拿一个简单的工作负载举例子，一个 K8s Deployment 对象，哪些字段暴露给用户、哪些不能，虽然体现在 PaaS 的 UI 上，但肯定不能是靠前端开发说了算的吧。
[](
)KubeVela：下一代可编程式应用平台
=========================================================================================
阿里巴巴是整个业界在云原生技术上的先行者之一。所以上述这个围绕着应用平台的云原生技术难题，相对也比较早的暴露了出来。在 2019 年末，阿里基础技术团队与研发效能团队合作针对这个问题进行了大量的探索与尝试，最终提出了“可编程式”应用平台的思想，并以 OAM 和 KubeVela 开源项目的方式同大家见面。这套体系，目前已经迅速成为了阿里构建应用平台的主流方式。
简单地说，所谓“可编程”，指的是我们在构建上层平台的过程中，不会直接在 Kubernetes 本身上叠加抽象（哪怕只是一个 UI），而是通过 CUE 模板语言这种代码化（Code）的方式来抽象和管理、并透出基础设施提供的能力。
举个例子，比如阿里的某个 PaaS 要对用户提供一个能力叫做 Web Service，这个能力是指任何需要从外部访问的服务，都以 K8s Deployment + Service 的方式来部署，对用户暴露镜像、端口等配置项。
在传统方法中，我们可能会实现一个 CRD 叫做 WebService，然后在它的 Controller 里来封装 Deployment 和 Service。但这必然会带来前面 PaaS “能力困境”的问题：
-
我们应该给用户暴露几种 Service 类型？未来用户想要其他类型怎么办？
-
用户 A 和用户 B 需要暴露的字段不统一该怎么办？比如我们允许用户 B 修改 Label，但 用户 A 不可以，那这个 PaaS 该怎么设计？
-
……
而在 KubeVela 中，像上面这样面向用户的功能，则可以通过一段简单的 CUE 模板来描述（[这里有完整的例子](
)）。而当你编写好这样一个 CUE 文件之后，直接通过一句 kubectl apply，用户就可以立即使用到这个能力：
$ kubectl apply -f web-service.yaml
更重要的是，只要执行上面这条命令，KubeVela 就会自动根据 CUE 模板内容生成这个能力的帮助文档和前端表单结构，所以用户立刻就会在 PaaS 里面看到这个 WebService 功能如何使用（比如有哪些参数、字段类型），并且直接使用它，如下 图 2 所示：
图 2 - KubeVela 自动生成表单示意图
在 KubeVela 中，平台的所有能力比如金丝雀发布、Ingress，Autoscaler 等等，都是通过这种方式定义、维护和透出给用户的。这种端到端打通用户体验层与 Kubernetes 能力层的设计，使得平台团队可以以极低的成本快速实现 PaaS 以及任何上层平台（比如 AI PaaS，大数据 PaaS），同时高效地响应用户的持续演进诉求。
[](
)1. 不只是 Kubernetes 原生，是 Platform-as-Code
尤为重要的是，在实现层，KubeVela 并不是简单的在客户端去渲染 CUE 模板，而是使用 Kubernetes Controller 去渲染和维护生成的 API 对象。这里的原因有三点：
-
Kubernetes Controller 天然适合维护用户层抽象到底层资源之间的映射，并且通过控制循环（Reconcile）机制永远确保两者的一致性，而不会发生 IaC（Infrastructure-as-Code） 系统里常见的 Configuration Drift（配置漂移）问题（即：底层资源跟用户层的输入发生不一致）。
-
平台团队编写的 CUE 模板 kubectl apply 到集群之后，就变成了一个 Kubernetes 中的一个自定义资源（Custom Resource），它代表了一个抽象化、模块化的平台能力。这个能力可以被全公司的平台团队复用，也可以继续修改演进，而且它是 Namespace 化的资源，所以平台的不同租户可以分配同名但不一样的模板，互不影响。这样彻底解决了不同租户对同一个能力的使用诉求不一样的问题。
-
如果随着时间推移，用户对平台功能的设计提出了新的要求，那么平台维护团队只需要安装一个新的模板，新的设计就会立刻生效，平台本身不需要做任何修改，也不用重启或者重新部署。而且新模板也会立刻被渲染成表单出现在用户 UI 上。
所以说，KubeVela 的上述设计，从根本上解决了传统 IaC 系统用户体验虽好，但是生产环境上“靠不住”的老大难问题，又在绝大多数情况下让整个平台响应用户需求的时间从原先的数周，降低到几小时，完全打通了云原生技术与最终用户体验之间的壁垒。而它完全基于 Kubernetes 原生方式实现，确保了整个平台严格的健壮性，并且无论任何 CI/CD 以及 GitOps 工具，只要它支持 Kubernetes，就一定支持 KubeVela，没有任何集成成本。
这套体系，被大家形象的称为：Platform-as-Code（平台即代码）。
[](
)2. 别急，KubeVela 当然支持 Helm
提到 KubeVela 以及 CUE 模板这些概念，很多小伙伴就开始问了：KubeVela 跟 Helm 又是什么关系啊？
实际上，Helm 和 CUE 一样，都是一种封装和抽象 Kubernetes API 资源的工具，而且 Helm 使用的是 Go 模板语言，天然适配 KubeVela Platform-as-Code 的设计思路。
所以在 KubeVela v1.0 中，任何 Helm 包都可以作为应用组件被部署起来，并且更重要的是，无论是 Helm 组件还是 CUE 组件，KubeVela 里的所有能力对它们都适用。这就使得通过 KubeVela 交付 Helm 包可以给你带来一些非常重要但是现有工具很难提供的能力。
举个例子，Helm 包其实很多是来自第三方的，比如 Kafka Chart，可能就是 Kafka 背后的公司制作的。所以一般情况下，你只能用，但不能改它里面的模板，否则修改后的 Chart 你就得自己维护了。
而在 KubeVela 中，这个问题就很容易解决。具体来说，KubeVela 提供一个运维侧的能力叫做 [Patch](
)，它允许你以声明式的方式给待交付组件（比如 Helm 包）里封装的资源打 Patch，而不用去关心这个字段有没有通过 Chart 模板透出来，而且 Patch 操作的时机，是在资源对象被 Helm 渲染出来之后、提交到 Kubernetes 集群处理之前的这个时间，不会让组件实例重启。
再比如，通过 KubeVela 内置的灰度发布系统（即：[AppRollout](
) 对象），你还可以将 Helm 包作为一个整体进行渐进式发布且无需关心工作负载类型（即：哪怕 Chart 里是 Operator，KubeVela 也可以进行灰度发布），而不是像 Flagger 等控制器那样只能针对单一的 Deployment 工作负载进行发布。此外，如果将 KubeVela 同 Argo Workflow 集成，你还可以轻松的指定 Helm 包的发布顺序和拓扑等更复杂的行为。
所以说，KubeVela v1.0 不仅支持 Helm，它的目标是成为交付、发布和运维 Helm Chart 最强大的平台。一些社区同学已经在本文发布之前就迫不及待的试用了这部分功能，大家可以移步到[这篇文章](
)来阅读。
[](
)3. 全自助式用户体验和云原生时代的运维
得益于 Platform-as-Code 的设计，基于 KubeVela 的应用平台天然对用户是自助式的使用方式，如图 3 所示。
图 3 - KubeVela 自助式能力交付流程图
具体来说，平台团队只需要极小的人力成本就可以在系统中维护大量的、代码化的“能力模板”。而作为平台的终端用户，业务团队只需要根据自己的应用部署需求在 PaaS UI 上选择几个能力模板，填入参数，就可以自助式的完成一次交付，无论这个应用多么复杂，业务用户的学习成本都非常低，并且默认就会遵循模板中所定义的规范；而这个应用的部署和运维过程，则由 Kubernetes 以自动化的方式去管理，从而减轻了业务用户大量的心智负担。
而更为重要的是，这种机制的存在，让运维人员再次成为了平台团队中的核心角色。具体的说，他们通过 CUE 或者 Helm 设计和编写能力模板，然后把这些模版安装到 KubeVela 系统中给业务团队使用。大家试想一下，这个过程，其实就是运维人员把业务对平台的诉求，结合整个平台的最佳实践，以代码化的方式固化成可被复用和定制的能力模块的过程。而且这个过程中，运维并不需要去进行复杂的 K8s 定制和开发，只需要理解 k8s 的核心概念即可。另一方面，这些代码化的能力模块，复用性极高，变更和上线非常容易，并且大多数情况下不需要额外的研发成本，可以说是最敏捷的“云原生”运维实践，能够真正让业务感受到云原生“研发、交付、运维高效一体化”的核心价值。
[](
)4. 多环境多集群、多版本应用交付
KubeVela v1.0 的另一个重大更新，就是改进了系统的部署结构，提供了 Control Plane （控制平面）模式，从而具备了面向多环境、多集群进行版本化应用交付的能力。所以现在，一个典型的生产环境 KubeVela 部署形态如下图 4 所示：
独家面经总结，超级精彩
本人面试腾讯，阿里，百度等企业总结下来的面试经历，都是真实的，分享给大家！
Java面试准备
准确的说这里又分为两部分：
- Java刷题
- 算法刷题
Java刷题：此份文档详细记录了千道面试题与详解；
**[CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】](
Java面试准备
准确的说这里又分为两部分：
- Java刷题
- 算法刷题
Java刷题：此份文档详细记录了千道面试题与详解；
[外链图片转存中…(img-d2c9SfUV-1631175135435)]
[外链图片转存中…(img-3YjXQEGm-1631175135436)]
**[CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】](
)**
5625
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
