概述
Rainbond 自 V5.8 版本起面向已经熟练使用 Kubernetes 的用户推出利用 Yaml 或 Helm 部署应用的能力。当前指南指导用户如何将已经可以在原生 Kubernetes 中部署的 Yaml 或 Helm Chart 部署到 Rainbond 中,这个过程会自动完成应用模型的转化,后续的管理可以通过 Rainbond 完成。
转化原理
Rainbond 扩展了原有的 RAM (Rainbond Application Model) 模型边界,除了最常用的各种运维属性之外,以 其他设置 > Kubernetes属性
的形式设置更多属性。保持易用性的同时兼顾了灵活性。为自动化的将原生 Kubernetes 定义转化为 RAM 模型提供了前提条件。
Rainbond 可以从 Yaml 或 Helm Chart 中获取指定类型的 Workload 定义,并转化成为 Rainbond 界面中可管理的组件,目前支持的 Workload 类型包括 Deployment、StatefulSet、Job 和 CronJob。对一些非 Workload 类型的资源,如 Service、Sercet 等资源则进行了额外的处理。
以 Yaml 定义的 Wordpress 建站 系统为例,下图展示了对各种不同资源的处理方式。

Rainbond 在设计上并未完全继承原生 Kubernetes 的设计思想,由于以下设计上的差异,Rainbond 在接受 Yaml 或 Helm 应用部署时,需要进行一系列转化,了解这些差异对部署 Yaml 或 Helm 类应用很有帮助。
非Workload资源转化至应用
区别于原生 Kubernetes 的使用方式,Rainbond 更加凸显应用这一核心概念的使用。应用这一概念,并非是 Kubernetes 中的某种资源,它是对一组具有关联关系的 Workload 的组合,就像一个网站类的业务系统,往往具有一个由 Deployment 部署的 Web 站点服务,以及一个由 StatefulSet 部署的数据库服务组成。对于 Kubernetes 而言,这是两个可以分开管理的 Workload ,而在 Rainbond 世界里,除了能够精细化的独立管理每个 Workload 之外,更注重将其作为一个完整的应用统一管理。
在原生 Kubernetes 中没有概念与 Rainbond 中的应用概念对应,但用户可以指定将 Yaml 中所有的资源定义都部署到 Rainbond 中的应用中去。当用户在 Yaml 中定义了非 Workload 类的资源(如 Service 、Sercet 等)时,Rainbond 会将其转化后保存在 应用 > k8s资源
列表中,并提供编辑入口供用户后续管理。管理方式参见 非 Workload 类资源管理