[系统运维]KubeVela 1.4：让应用交付更安全、上手更简单、过程更透明

作者：孙健波，曾庆国

KubeVela 是一个现代化的软件交付控制平面，目标是让应用的部署和运维在如今的混合多云环境下更简单、敏捷、可靠。自 1.1 版本发布以来，KubeVela 架构上天然打通了企业面向混合多云环境的交付难题，且围绕 OAM 模型提供了充分的可扩展性，赢得了大量企业开发者的喜爱，这也使得 KubeVela 的迭代速度不断加快。

1.2 版本我们发布了开箱即用的可视化控制台，终端用户可以通过界面发布和管理多样化的工作负载；1.3 版本 的发布则完善了以 OAM 模型为核心的扩展体系，提供了丰富的插件功能，并给用户提供了包括 LDAP 权限认证在内的大量企业级功能，同时为企业集成提供了巨大的便利。至今为止，你已经可以在 KubeVela 社区的插件中心里获得 30 多种插件，其中不仅包含了 argocd、istio、traefik 这样的 CNCF 知名项目，更有 flink、mysql 等数据库中间件，以及上百种不同云厂商资源可供直接使用。

在这次发布的 1.4 版本中，我们围绕让应用交付更安全、上手更简单、过程更透明三个核心，加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能，全面加固了多租户场景下的交付安全性，提升了应用开发和交付的一致性体验，也让应用交付过程更加透明化。

核心功能解读

开箱即用的认证和授权，对接 Kubernetes RBAC，天然支持多集群

在全面解决了架构升级、扩展性等挑战之后，我们观察到应用交付的安全性是如今整个业界亟需解决的难题。从接触到的用户案例中，我们发现许多安全隐患：

• 大量用户在使用传统 CI/CD 的过程中，会直接将生产集群的 admin 权限嵌入到 CI 的环境变量里，只对最基本的交付到哪些集群有一定的权限分离。而 CI 体系通常也会被密集的用于开发和测试，很容易引入不受控制的风险。中心化的管理加上粗粒度的权限控制，一旦 CI 体系被黑客攻击、或者出现一些人为误操作，很容易产生巨大的破坏性，后果不堪设想。
• 大量 CRD 控制器依赖 admin 权限对集群资源进行操作，且没有对 API 的访问进行约束。虽然 Kubernetes 本身具备丰富的 RBAC 控制能力，但是由于学习权限管理门槛较高、且与具体功能实现无关，大多数用户并不真正关心其中细节，通常只是选择默认的配置便投入生产使用。灵活性较高的控制器（如能够分发 Helm Chart），很容易成为黑客攻击的靶子，比如在 helm 中嵌入一个 YAML 脚本窃取其他命名空间中的秘钥。

KubeVela 1.4 中加入了认证和授权能力，且天然支持多集群混合环境，对于每一个 KubeVela 的平台管理员而言，他们不仅可以细粒度的定制任意的 API 权限组合、对接 Kubernetes RBAC 体系，将这些权限模块授权给开发者用户，严格限制其权限；还可以简便的使用 KubeVela 平台预置的权限模块，如直接授予用户某个集群的特定命名空间权限，授予某个用户“只读”权限等，极大的简化了用户的学习成本和心智负担，全面加固了应用交付的安全性。对于使用 UI 的用户，系统针对项目可用的资源范围和类型自动完成底层授权并严格校验，从而使得业务层 RBAC 权限与底层 Kubernetes RBAC 体系打通并协同工作，做到从外到内的安全，不在任何环节扩大权限。

具体而言，平台管理员对一个用户授权完成以后，用户的请求会经过如图所示的几个阶段。

1. KubeVela 的 webhook 首先会拦截用户的请求，将用户的权限信息（ServiceAccount）打到 Application 对象上。
2. KubeVela Controller 在执行 Application 的部署计划时，会基于 Kubernetes 的 角色扮演机制(impersonate) 转换为对应用户的权限去执行。
3. KubeVela 多集群模块（ClusterGateway）会传递对应的权限到子集群，子集群的 Kubernetes APIServer 会根据子集群的权限做认证。子集群的权限则是由 KubeVela 的授权流程创建的。

简而言之，KubeVela 的多集群认证和授权功能保证了每一个最终用户的权限都被严格约束，不会被交付系统放大，同时 KubeVela 自身的权限也收敛至最小，而且整个使用体验很简单。

如果你想了解更多功能及其背后的实现原理，欢迎阅读官方的权限认证和授权文档深入了解背后的运行机制。

参考案例

分布式云容器平台ACK One（Alibaba Cloud Distributed Cloud Container Platform）是阿里云面向混合云、多集群、分布式计算、容灾等场景推出的企业级云原生平台。KubeVela 多集群控制面是 ACK One 的核心实现，在 ACK One 中基于该 Feature 实现了基于角色扮演的应用多集群分发。

参考文档：https://help.aliyun.com/document_detail/419336.html

轻量便捷的应用开发控制平面，本地开发和生产部署一致体验

随着生态的不断繁荣，我们也看到越来越多的开发者开始关注云原生技术，但经常苦于没有好的入门方式，主要原因有如下两点：

• 应用的开发环境与生产环境不一致，体验差别非常大。云原生是最近五六年逐渐出现的技术趋势，虽然它发展迅猛，但是绝大多数公司依旧习惯了内部自研一套平台屏蔽底层技术。这就导致普通的业务开发者即使学习了云原生技术，也很难在实际工作中实践，最好的情况可能也要重新对接一遍 API 和配置，更谈不上一致体验了。
• 以 Kubernetes 为核心的云原生技术部署和使用很复杂，如果只是为了入门学习去购买云厂商的托管服务成本又很高。即使花了很多精力学会了部署出一套可用的本地环境，也很难把众多云原生技术串联起来走完一整个 CI/CD 的流程，这里面涉及了大量运维领域的知识，而普通开发者平时不需要关心也很难接触得到。

我们在社区中也观察到，越来越多的公司开始意识到内部自建的平台跟不上社区生态发展的速度，期望通过 KubeVela 和 OAM 模型提供一致体验、又不丢失生态的可扩展性，但是苦于 KubeVela 的控制平面依赖 Kubernetes、上手门槛依旧不低。针对这个问题，社区一直在思考并寻找解决方案，最终我们的结论是需要一款工具来满足，且具备这几个特性：

• 只依赖容器环境（如 Docker）就能部署运行，让每一个开发者都能轻易地获取并使用；
• 本地开发与生产环境体验完全一致，且配置可复用，能够模拟混合多集群环境；
• 单一二进制包，支持离线部署，环境初始化的时间不超过喝一杯水的时间（3分钟）；

经过几个月的努力孵化，我们终于可以在 1.4 中正式发布这个工具： VelaD ，D 既代表 Daemon 也代表 Developer，它可以帮助 KubeVela 在单机上运行，不依赖任何现有的 Kubernetes 集群，同时与 KubeVela 整体作为一个轻量级的应用开发控制平面，帮助开发者获得一体化的开发、测试、交付体验，简化云原生应用部署和管理的复杂度。

你可以通过 Demo 文档安装并试用这个工具，了解更多的实现细节，安装初始化仅需 3 分钟。

展示资源拓扑和状态，让交付过程变得透明化

在应用交付中另一个很大的诉求是对资源交付流程的透明化管理，比如社区里很多用户喜欢使用 Helm Chart ，把一大堆复杂的 YAML 打包在一起，但是一旦部署出现问题，如底层存储未正常提供、关联资源未正常创建、底层配置不正确等，即使是一个很小的问题也会因为整体黑盒化而难以排查。尤其是在现代混合的多集群混合环境下，资源类型众多、错综复杂，如何从中获取到有效信息并解决问题是一个非常大的难题。

在 1.4 版本中，我们加入了资源拓扑图查询功能，进一步完善了 KubeVela 以应用为中心的交付体验。开发者在发起应用交付时只需要关心简单一致的 API ，需要排查问题或者关注交付过程时，可以通过资源拓扑功能，快速获取资源在不同集群的编排关系，从应用一直追踪到 Pod 实例运行状态，自动化地获取资源的关联关系，包括复杂且黑盒化的 Helm Chart。

以上图所示的应用为例，用户通过 Helm Chart 包交付了一个 Redis 集群，图的第一层为应用名称，第二层为集群，第三层为应用直接渲染出来的资源，后续的三层，四层则根据不同的资源追踪的下级关联资源。

用户在交付应用过程中，可以通过图形来观测其衍生出的资源以及状态，不正常时节点会显示为黄色或红色状态并显示具体原因。比如下图所示应用，是一个基础的 Webservice 服务交付到了2个集群，开发者可以发现该应用实际在两个集群分别创建了Deployment 和 Service 资源，而 ask-hongkong 这个集群中的 Deployment 资源显示黄色，是因为 Pod 实例还没有完全启动。

该功能也支持通过不同集群，不同组件进行搜索筛选查询，帮助开发者快速聚焦并发现问题，以极低的门槛了解应用底层的交付运转状态。

如果你想了解更多功能及其背后的实现原理，欢迎阅读官方博客 ?追踪和可视化多集群 Kubernetes 资源拓扑 ?深入了解背后的运行机制。

其他关键变更

除了核心功能和插件生态之外，1.4 版本也对工作流等核心功能做了增强：

• 应用状态维持支持配置字段忽略规则，从而实现了 KubeVela 和其他控制器协同工作，比如 HPA 和 Istio 等。
• 应用资源回收支持基于资源类型设置，目前已支持基于组件名称，组件类型，特征类型和资源类型。
• 工作流支持子步骤能力，子步骤支持并发执行，加速了多集群高可用场景下的资源交付速度。
• 工作流步骤支持暂停某一段时间，暂停时间到达后自动继续执行工作流。
• 资源部署和回收支持遵循组件依赖规则设置，支持资源按顺序部署、按顺序回收。
• 工作流步骤支持条件判断，目前支持 if: always 规则，代表该步骤在任何情况下执行，从而支持部署失败通知。
• 运维特征支持设置部署范围，可实现运维特征与组件部署状态分离，运维特征可以独立部署在管控集群。

感谢来自阿里云、招商银行、Napptive 等三十多个海内外组织和个人的持续贡献，正是你们的不断努力，在短短 2 个月的时间内完成了 200 多个功能特性和修复，才使得这次迭代为社区交付出如此多优秀的功能！

更多的变更细节，请参考 Release 说明。

插件生态（Addon）

随着 1.3 插件体系的完善，我们的插件生态也在快速扩充中：

• 更新 fluxcd addon 支持了 OCI registry ，支持在部署时选择 chart 中不同的 values 文件。
• 新增 cert-manager 插件，自动化管理 Kubernetes 证书。
• 新增 flink-kubernetes-operator 插件，交付 flink 工作负载。
• 新增 kruise-rollout 插件，支持灰度发布，金丝雀发布等多种发布策略。
• 新增 pyroscope 插件，支持持续的性能调优。
• 新增 traefik 插件，支持配置 API 网关。
• 新增 vegeta 插件，支持对工作负载做自动化压测。
• 新增 argocd 插件，支持基于 ArgoCD 的 Helm 交付和 GitOps。
• 新增 dapr 插件，支持 Dapr 订阅、发布的运维能力。
• 新增 istio 插件，支持基于 Istio 的网关能力和流量灰度。
• 新增 mysql-operator 插件，支持部署高可用的分布式 mysql 数据库。

非常欢迎开发者们参与到社区，制作插件扩展 KubeVela 的系统能力。

如何参与社区

KubeVela 是 CNCF 基金会中全球 Top 级活跃度的开源项目，在这里有超过 300 位国内外贡献者、40 多位社区成员和 Maintainer，从代码、文档到社区沟通交流均为中英双语国际化运作方式，有超过 4000 多位社群成员。

如果你对参与到开源社区感兴趣，我们非常欢迎你加入到 KubeVela 的社区中来，你可以通过 KubeVela 社区的开发者文档详细的了解参与到开源社区的方式和方法，社区的工程师们也会耐心指导你入门。

近期的规划

KubeVela 将围绕两个月一个迭代周期持续演进，接下来的版本中，我们将聚焦这三个维度：

• 可观测性，围绕 log、metrics、tracing 等维度提供端到端丰富的应用洞察能力，为应用交付的稳定性、智能化打下坚实的基础。

• 工作流交付能力，提供更丰富的框架和集成能力，包括自定义步骤超时、基于上下文信息的条件判断和分支工作流等，衔接 CI/CD，为用户提供更丰富的使用案例和场景。

• 应用（含插件）管理能力，支持应用的关闭、重启，支持应用的导入、导出、上传至应用（插件）市场等。

如果你想了解更多的规划、成为贡献者或者合作伙伴，可以通过参与社区沟通（ https://github.com/kubevela/community ）联系我们，期待你的加入！

您可以通过如下材料了解更多关于?KubeVela?以及?OAM?项目的细节：

• 项目代码库：github.com/oam-dev/kubevela?欢迎?Star/Watch/Fork！

• 项目官方主页与文档：kubevela.io?，从?1.1?版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。

• 项目钉钉群：23310022；Slack：CNCF?#kubevela?Channel

• 加入微信群：请先添加以下?maintainer?微信号，表明进入KubeVela用户群：

点击“此处”，查看 KubeVela 项目官网。