如何不编写 YAML 管理 Kubernetes 应用？

Kubernetes 将自身边界内的事物都抽象为资源。其中的主要部分，是以 Deployment、StatefulSet 为代表的 workload 工作负载控制器，其他各类资源都围绕这些主要的资源工作。这些资源合并起来，可以为 IT 技术工作者展现出一个以 workload 为中心的模型。Kubernetes 中所有的资源，都通过声明式配置文件来编辑描述，一条条的 Yaml 字段定义，给了 IT 技术人员大的自由度的同时，也对技术人员的能力提出了极高的要求。

通过应用模型简化Kubernetes管理#

当你的团队已经使用原生的 Kubernetes 一段时间，你多半会发现，并非每个 IT 技术人员都擅长编写复杂的 Kubernetes 声明式配置文件（YAML）。特别是对于开发人员他们的主要职责是业务开发，学习和编写YAML会增加他们的负担，甚至会抵触使用。

开源项目Rainbond 是一个 云原生应用管理平台，它使用 以应用为中心 的设计模式。基于这一设计模式重新抽象出了比 workload 更高层次的应用模型。从使用的体验上不需要学习和编写YAML，实现业务应用的全生命周期管理。应用对应一个完整的业务系统，由若干个可以单独管理的服务组件组成，部署业务组件可以从源代码和容器镜像，通过“拖拉拽”的方式编辑服务调用关系。每一个服务组件，可以基于图形化界面定义使用常见的一些运维特征。在此基础之上，用户还可以利用应用模型这一核心概念，做出更多操作，如将整个业务系统以应用模板的形式发布出来，业务系统可以基于该模板一键安装/升级。在软件交付这个领域，这种能力十分有用，无论终交付环境在线或离线，都可以基于应用模板进行快速交付，甚至个性化交付。

Rainbond 使用的应用模型，让开发人员关注应用和业务本身，更易于被人所接受。对裁剪后保留下来的运维特征通过图形界面展示和交互，极大的降低了使用的难度，通过应用模版绝大多数开发者不必编辑复杂声明式配置文件就可以顺畅使用 Kubernetes 了。

将Kubernetes的YAML转换成应用模型#

整个转化的过程，可以概括为三个步骤：

1. 对于开发人员常用Workload，可以从源码和容器镜像向导式的自动生成，或导入已有YAML和运行应用，导入过程自动识别所有可转化的 Workload 类型资源，包括 Deployment、StatefulSet， Job、CronJob 类型。这些资源会被转化成应用模型，转化后会以服务组件的形式运行。
2. 导入生成的服务组件后，基本的Workload属性通过界面就可以查看和编辑，如环境变量、镜像地址等。转化过程中会将识别到的Workload 属性添加给服务组件，以Key/Value 或 Yaml 形式查看和管理。
3. 非 Workload 的资源类型，如 Secret、ServiceAccount、Role 等资源，会被分类识别和加载到应用界面的 k8s资源 页面中，供操作人员以交互体验方式进行编辑。

可被纳管和转化的 Workload 属性包括：