关于kubernetes:如何不编写-YAML-管理-Kubernetes-应用

6次阅读

共计 3137 个字符，预计需要花费 8 分钟才能阅读完成。

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

当你的团队曾经应用原生的 Kubernetes 一段时间，你多半会发现，并非每个 IT 技术人员都善于编写简单的 Kubernetes 申明式配置文件（YAML）。特地是对于开发人员他们的主要职责是业务开发，学习和编写 YAML 会减少他们的累赘，甚至会冲突应用。

开源我的项目 Rainbond 是一个云原生利用治理平台，它应用 以利用为核心 的设计模式。基于这一设计模式从新形象出了比 workload 更高层次的利用模型。从应用的体验上不须要学习和编写 YAML，实现业务利用的全生命周期治理。利用对应一个残缺的业务零碎，由若干个能够独自治理的服务组件组成，部署业务组件能够从源代码和容器镜像，通过“利落拽”的形式编辑服务调用关系。每一个服务组件，能够基于图形化界面定义应用常见的一些运维特色。在此基础之上，用户还能够利用利用模型这一外围概念，做出更多高级操作，如将整个业务零碎以利用模板的模式公布进去，业务零碎能够基于该模板一键装置 / 降级。在软件交付这个畛域，这种能力非常有用，无论最终交付环境在线或离线，都能够基于利用模板进行疾速交付，甚至个性化交付。

Rainbond 应用的利用模型，让开发人员关注利用和业务自身，更易于被人所承受。对裁剪后保留下来的运维特色通过图形界面展现和交互，极大的升高了应用的难度，通过利用模版绝大多数开发者不用编辑简单申明式配置文件就能够顺畅应用 Kubernetes 了。

整个转化的过程，能够概括为三个步骤：

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

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

属性名称	作用
nodeSelector	节点选择器：指定某种类型节点调度时应用。
labels	标签：用于为服务组件自定义标签以被选择器应用。
volumes	存储卷：用于定义不被 Rainbond 治理的卷类型的挂载。
volumeMounts	挂载卷：与 volumes 搭配应用，将卷挂载给容器。
affinity	亲和性：更高级的调度形式，包含节点亲和性和 Pod 亲和性。
tolerations	容忍度：与节点污点搭配应用，具备指定容忍度的 Pod 才能够调度到指定节点上。
serviceAccountName	服务账户名：为服务组件指定某个已存在的 SA，使对应的 Pod 具备某些权限。
privileged	特权模式：货真价实的配置，非必要不开启。
env	环境变量：用于定义不被 Rainbond 治理的环境变量，反对援用操作。

值得注意的是，扩大后的 RAM 模型，仍然可能公布为利用模板，供后续一键装置 / 降级 / 交付整套业务零碎之用。

以下测试是基于 Rainbond v5.8 进行的，为了测试 Kubernetes 已有利用导入，我打算应用曾经在 wp 命名空间中部署实现的 WordPress 建站零碎来进行一次导入测试。这套零碎由以下资源组成：

[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME                         TYPE                                  DATA   AGE
secret/default-token-nq5rs   kubernetes.io/service-account-token   3      27m
secret/mysql-secret          Opaque                                2      27m
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/wordpress   NodePort    10.43.157.40    <none>        8080:30001/TCP   5m19s
service/wp-mysql    ClusterIP   10.43.132.223   <none>        3306/TCP         27m
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/wordpress   1/1     1            1           5m19s
NAME                        READY   AGE
statefulset.apps/wp-mysql   1/1     27m
NAME                             READY   STATUS    RESTARTS   AGE
pod/wordpress-66bc999449-qv97v   1/1     Running   0          5m19s
pod/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 存储，能够从新进行定义。从新定义后的存储门路会变为空，所以记得找到新旧不同的门路，进行一次数据迁徙。

通过利用模型，让 IT 技术人员能够更多的关怀业务自身，而不是底层简单工具的应用问题。最终的成果是简化操作老本和了解难度，让 Kubernetes 更加容易落地。

正文完