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

2022 年 9 月 04 日
北京
本文字数：2711 字
阅读完需：约 9 分钟

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

通过应用模型简化 Kubernetes 管理

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

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

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

将 Kubernetes 的 YAML 转换成应用模型

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

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

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

值得注意的是，扩展后的 RAM 模型，依然能够发布为应用模板，供后续一键安装/升级/交付整套业务系统之用。

导入已有 Kubernetes 应用的测试和实践

以下测试是基于 Rainbond v5.8 进行的，为了测试 Kubernetes 已有应用导入，我计划使用已经在 wp 命名空间中部署完成的 Wordpress 建站系统来进行一次导入测试。这套系统由以下资源组成：

[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wpNAME                         TYPE                                  DATA   AGEsecret/default-token-nq5rs   kubernetes.io/service-account-token   3      27msecret/mysql-secret          Opaque                                2      27mNAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGEservice/wordpress   NodePort    10.43.157.40    <none>        8080:30001/TCP   5m19sservice/wp-mysql    ClusterIP   10.43.132.223   <none>        3306/TCP         27mNAME                        READY   UP-TO-DATE   AVAILABLE   AGEdeployment.apps/wordpress   1/1     1            1           5m19sNAME                        READY   AGEstatefulset.apps/wp-mysql   1/1     27mNAME                             READY   STATUS    RESTARTS   AGEpod/wordpress-66bc999449-qv97v   1/1     Running   0          5m19spod/wp-mysql-0                   1/1     Running   0          27m

复制代码

访问 Rainbond ，在集群处选择导入，在这个页面中，可以选择要导入资源的命名空间 wp。平台会根据 label 来对资源进行分组：

Rainbond 根据资源定义的 label 来划分应用，如符合 app.kubernetes.io/name:wp-mysql 或 app:wordpress 的资源，会分布到图中两个不同的应用中去，而不具备上述 label 的资源，则会统一划分到一个未分组的应用中去。应用的划分非常关键，因为应用模型的高级应用是针对一个应用整体而言的，所以导入之前一定要仔细规划，添加合理的 label。

导入过程中，Rainbond 将不同的属性，交由扩展后的模型管理，大部分运维操作已经变得很易用了，而另一部分，则交由 Kubernetes 属性页面进行管理。

一旦完成导入，wordpress 和 wp-mysql 两个应用就可以使用 Rainbond 进行管理了。

端口管理

wordpress 在导入之前依靠 NodePort 类型的 Service 对外暴露，但导入 Rainbond 管理之后，就可以借助网关对外暴露自己的 80 端口了。需要注意的是，你必须重启一次 wordpress 服务组件，来让访问策略生效。

对于某些业务而言，访问的入口不支持动态指定，这就需要业务侧也做出一些改动，来适应新的访问入口。对于 Wordpress 而言，需要重新定义常规选项中的站点地址。

存储管理

我部署的这套 wordpress 系统，所有组件的存储都使用的 hostpath 模式，这种配置虽说简单，但是并不适用于 Pod 可能发生漂移的大规模 Kubernetes 环境。Rainbond 部署后，会提供易用的共享存储，这种存储支持多个 Pod 间共享数据，以及 Pod 跨主机的迁移。原有的 hostpath 存储，可以重新进行定义。重新定义后的存储路径会变为空，所以记得找到新旧不同的路径，进行一次数据迁移。