K8S 资源到 Rainbond 应用模型的转换原理
核心概念
Rainbond 从 V5.8 版本开始支持直接将原生 Kubernetes 的 YAML 文件或 Helm Chart 部署到平台中。本文档阐述 Rainbond 为何需要进行应用模型转换,以及转换的技术原理和意义。
为什么需要模型转换
Rainbond 和 Kubernetes 在设计理念上存在以下关键差异:
-
应用中心化 vs 资源中心化:Rainbond 围绕"应用"这一核心概念设计,将相关联的多个服务视为一个整体;而 Kubernetes 采用资源中心化的设计,各类资源(Deployment、Service等)相对独立。
-
抽象层次不同:Rainbond 提供了比 Kubernetes 更高层次的抽象,通过扩展 RAM(Rainbond Application Model)模型,在保持易用性的同时提供了必要的灵活性。
-
管理模式差异:Kubernetes 注重全面、精细的资源定义能力,而 Rainbond 优化了常用操作的使用体验,将复杂的资源规格定义转化为直观的界面操作。
这些差异决定了在导入 Kubernetes 资源时必须进行模型转换,以确保两种系统的兼容性和功能完整性。
转换原理与技术实现
资源识别与分类处理
Rainbond 将 Kubernetes 资源分为两类进行处理:
-
Workload 类资源:包括 Deployment、StatefulSet、Job 和 CronJob,这些资源被转换为 Rainbond 的组件(Component)。
-
非 Workload 类资源:如 Service、ConfigMap、Secret 等,被存储在应用的
k8s资源列表中统一管理。

Workload 转换逻辑
Rainbond 在转换 Workload 时采用以下处理流程:
-
提取核心定义:从 YAML 或 Helm Chart 中提取 Workload 的规格定义(Spec)。
-
映射到 RAM 模型:将提取的定义映射到 Rainbond 应用模型的各个属性:
- 容器镜像、端口、环境变量等常用配置被映射到对应的 Rainbond 界面元素
- 特殊或扩展属性被存储在
其他设置 > Kubernetes属性中
-
自动识别关联:自动识别资源间的依赖关系,构建应用内组件的连接关系
Rainbond 通过识别 YAML 文件中的资源类型,将其转换为 Rainbond 中的组件类型和相应的抽象层。以下是按照类型划分的详细支持资源清单:
组件类型资源
该类型资源导入完成后会转换成 Rainbond 中的组件:
| k8s资源 | Rainbond模型 |
|---|---|
| Deployment | 无状态组件 |
| StatefulSet | 有状态组件 |
| CronJob | 定时任务组件 |
| Job | 任务组件 |