背景

在使用了 k8s 作为基础设施之后，就需要关心 如何管理部署，最原始的清单管理方式在 多环境 下就开始失效了，这个时候可以用 customize , 相当于有一个 base 的清单，不同环境的各自修改自己的，在部署前进行合并覆盖。

但如果你的应用更加复杂，拥有好几个服务，这时用清单管理就不太方便了，而用 helm charts 就是一个不错的方式。

helm charts

helm 的使用可以参考 helm的一些简单使用
也有简单的关于 helm charts 的简单介绍

helm charts 和 k8s 原生的清单相比，一部分职能相当于是 清单模板管理器，templates 目录下存放的，就是用 模板语法包裹起来的清单，最后渲染的结果，就是一份份的资源清单。

但 helm 通过模板语法，给清单增加了逻辑判断能力，极大地增加了清单的扩展性。

charts 的优点在于： 强大。 缺点在于： 有额外学习的成本。

从清单的视角看 templates

对于 k8s 清单，最常见的资源包括：

• 持久类的 pvc
• 访问类的 service / ingress
• 服务类的 deployment / daemonset / statefulset
• 配置类的 configmap / secrets

更详细的资源参考 kubectl的一些总结

一个常见的服务，就包含上面这些。 如果服务中希望访问集群信息，可能还需要 ClusterRole 和 RoleBinding 用来绑定权限。

在 charts 的 templates 中，我们主要编写的也就是这些资源的模板。

charts 的主要关注点

对于 charts 的编写过程，主要关注这几类事务：

1. 公共项 ( 镜像仓库、服务名、公共配置 )
2. 勾稽关系类 ( 模块开关、service name 等 )

一个抽象得当的 charts ，在同类型的业务应用服务中，通常可以直接复用，修改一下 values.yaml 即可使用。

观摩三方charts

minio

• 用 _helpers.tpl 定义了一些公共的名字，例如 minio.name
• 用 _helpers.tpl 做了 k8s 版本的判断，例如 minio.deployment.apiVersion
• 把 shell 脚本放到 template 中，相当于给 shell 加了一层 template，并在 configmap 中用 include 引入了 (这里加了 $.Template.BasePath)
• 在 clusterroles.yaml 中，有 .Capabilities 的使用，这个可以拿到 k8s 的信息
• if 判断中，大量使用了 and or 操作
• 用了 helm 的 hook 做部署和更新时触发的 job
• secrets.yaml 中使用了 base64 存储 accesskey

redis

• NOTES.txt 可以在部署完之后被看到

spinnaker

• templates 中的层级多了一层目录，区分不同类型的资源

postgresql

• 把 init.sql 放在了 charts 中，并且在 init-configmap.yaml 中通过 (.Files.Glob "init/*").AsConfig 的方式把文件放到 configmap 中

总结

charts 的写法都是基于 k8s 清单来的，所以，要写一个 charts ，第一步是把这个应用所需要的所有 manifest 写好，第二步是使用模板语法给特定申明项添加逻辑 (或判断、或取值)。

charts 的 template 语法还是需要学习和持续练习才能熟练掌握的，如果本身使用的不多，其实也可以先大体浏览一次官网，然后找一大堆的 charts 做参考，在真正要封装 charts 的时候，再对照着别人的 charts 改改，这或许是最高效的方式。

其他

charts 在绝大多数时候已经很够用了。 但在一些场景下，业务有特定领域的模型，如果还是按照 k8s manifest 的各个项，就增加了运维同学对相关概念的转换负担，这种时候就会使用另一个强大的武器： CRD + operator。具体可以参考 k8s的扩展点之一–CRD

---

You really can change the world if you care enough.
— Marian Wright Edelman