Helm 和 Kustomize:不只是含谷量的区别

Kustomize 问世的时候,我是比较鄙视的——非要造个谷歌的轮子么?不过最近抽出时间熟悉了一下 Kustomize,发现我还是带了有色眼镜。二者功能虽然有所重叠,但是工作思路的差别还是很大的,下面就简单做一点比较,权当引玉之砖。

Helm

Helm 是 Kubernetes 中的第一个对应用程序进行管理的支撑工具,经常会拿来同 Yum、apt 等工具进行类比。Helm 由几个不同的组件构成:

  • CLI:客户端工具,有几大功能
    • 从 Chart 服务器获取列表、搜索 Chart 项目
    • 安装 Chart
    • 构建 Chart
    • 充当 Chart 服务器
    • 和 Tiller 协同管理应用生命周期
    • 渲染 Chart 为 Kubernetes 生成 YAML
  • Tiller:需要用特定授权和 API Server 进行通信,Kubernetes 集群内外部署都可以。
    • 它是 Helm 的内鬼,负责接收来自 Cli 的指令,完成对集群内应用生命周期的控制。
    • 3.0 中将取消 Tiller。
  • Repository:
    • 是存储 Helm Chart 的仓库,可以被 Cli 工具缓存、检索,CLI 也可以获取 Chart 进行后续操作。
    • 和 Tiller 一样,Repository 也不是必要组件,CLI 完全可以仅在本地工作。

Helm Chart

Helm 使用 Chart 对应用程序进行描述,它使用 Go Template 对应用部署所需的 YAML 进行抽象,形成应用部署模板,在需要进行部署时,可以编写 yaml 为模板中的变量进行赋值,也可以在 Helm CLI 的命令行中使用 --set name=value 的方式来对简单变量进行赋值,完成赋值之后,可以选择使用 helm template 指令将 Chart + Value 的组合渲染成为 YAML 供 kubectl 使用,也可以使用 helm install 直接通过 Tiller 进行安装。

Helm 的特色

  • 强大的生命周期管理:有 Tiller 的帮助,可以实现对应用程序实例(Release)的查询、安装、卸载、升级、回滚等复杂操作。
  • 严格的基础版本管控:Chart 是一种模板,Chart 的用户仅能通过对 values 的控制来定制应用的部署行为,模板中没有提供变量的位置,是无法在下游直接进行变更的。
  • 方便的命令行:对于简单变量,可以在部署的同时直接指定内容,方便部署。
  • 插件和工具:Helm 拥趸众多,提供了不少用于 CICD 或者其它方面辅助功能的插件和工具。

Kustomize

Kustomize 是一个新晋选手,只有一个 CLI 工具,在 Kubernetes 1.14 之后,甚至这唯一的工具也成为 kubectl 的一部分,可以说是很轻量级了。

Base + Overlay

在 Kustomize 的文档中明确说明:

kustomize is a command line tool supporting template-free, structured customization of declarative configuration targetted to k8s-style objects.

它放弃了对模板的要求,改用 Base + Overlay 的方式对应用的原始 YAML 进行派生Overlay,顾名思义,就是覆盖。Kustomize 的 Overlay 可以在 Base 的基础上,通过对 resourcegeneratortransformer 等的定义,形成新的应用定义,不论 Base 还是 Overlay,都可以通过 kustomize build 生成有效的 YAML。

Kustomize 的特色

  • 功能简单清晰,kubectl 直接支持。
  • 不考虑派生,仅作为应用的 YAML 组织方式也很有帮助。
  • 也有自己的插件系统。例如可以用简单的 YAML 定义,使用文件生成 Configmap/Secret。

比较

Kustomize 自称因为去掉了模板语法,更易使用,对此我保留看法,如果仅就入门使用来看,二者差异并不大。

Tiller 和 Repository 都并非必须,因此在部署上,Kustomize 的优势也不是很大。

我认为他们的区别主要在工作流程上:

  • Helm 的基础流程比较瀑布:定义 Chart->填充->运行,在 Chart 中没有定义的内容是无法更改的;
  • Kustomize 的用法比较迭代:Base 和 Overlay 都是可以独立运作的,增加新对象,或者对编写 Base 时未预料的内容进行变更,都不在话下。

例如我们定义了一个很基础的应用,由 Deployment + Service 组成,如果后续部署中需要完成两个变更:

  • 新建 Ingress 对象
  • 修改镜像地址/名称/TAG

在 Helm 中需要:

  • 在 Chart 中加入对 Ingress 的定义
  • 用变量控制 Ingress 是否进行渲染
  • Ingress 模板应该包含特定的主机名、注解等变量
  • 把镜像也定义成变量
  • 在 Values.yaml 中对这些变量进行赋值。

而在 Kustomize 中:

  • 无需对 Base 进行修改
  • 直接在新的 Overlay 中写入 Ingress Resource
  • 使用内置的 image transformer 替换原有镜像

结论

要公开发布一个较为复杂的应用,例如 Istio,编写良好的 Chart 能给用户很大帮助,用户在缺失一点发挥空间的情况下,通过对 values.yaml 的阅读,就能对这种复杂的部署产生一个较为深入的认识。

如果是常见的业务应用,因为不同部署之间的差异不大,但是未必可以提前做好变化限制,用 Kustomize 可能会是一个更好的选择。

相关链接

  • Helm:https://helm.sh/
  • Kustomize:https://github.com/kubernetes-sigs/kustomize
  • Helm 3.0:https://helm.sh/blog/helm-3-preview-pt1/
  • Helm 工具:https://www.infoq.cn/article/UemPsPu_AlzemkGEqb4Z
  • Awesome Helm:https://github.com/cdwv/awesome-helm
Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

相关

上一页
comments powered by Disqus