本文作者 / 龙少
开源软件、自动化爱好者。资深马拉松酱油选手。
Helm 是 Kubernetes 中的第一个对应用程序进行管理的支撑工具,经常会拿来同 Yum、apt 等工具进行类比。Helm 由几个不同的组件构成:
Helm 使用 Chart 对应用程序进行描述,它使用 Go Template 对应用部署所需的 YAML 进行抽象,形成应用部署模板,在需要进行部署时,可以编写 yaml 为模板中的变量进行赋值,也可以在 Helm CLI 的命令行中使用 --set name=value
的方式来对简单变量进行赋值,完成赋值之后,可以选择使用 helm template
指令将 Chart + Value 的组合渲染成为 YAML 供 kubectl
使用,也可以使用 helm install
直接通过 Tiller 进行安装。
values
的控制来定制应用的部署行为,模板中没有提供变量的位置,是无法在下游直接进行变更的。Kustomize 是一个新晋选手,只有一个 CLI 工具,在 Kubernetes 1.14 之后,甚至这唯一的工具也成为 kubectl 的一部分,可以说是很轻量级了。
在 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 的基础上,通过对 resource
、generator
、transformer
等的定义,形成新的应用定义,不论 Base
还是 Overlay,都可以通过 kustomize build
生成有效的 YAML。
Kustomize 自称因为去掉了模板语法,更易使用,对此我保留看法,如果仅就入门使用来看,二者差异并不大。
Tiller 和 Repository 都并非必须,因此在部署上,Kustomize 的优势也不是很大。
我认为他们的区别主要在工作流程上:
瀑布
:
定义 Chart->填充->运行,在 Chart 中没有定义的内容是无法更改的;迭代
:
Base 和 Overlay 都是可以独立运作的,增加新对象,或者对编写 Base 时未预料的内容进行变更,都不在话下。例如我们定义了一个很基础的应用,由 Deployment + Service 组成,如果后续部署中需要完成两个变更:
在 Helm 中需要:
而在 Kustomize 中:
image transformer
替换原有镜像要公开发布一个较为复杂的应用,例如 Istio
,编写良好的 Chart 能给用户很大帮助,用户在缺失一点发挥空间的情况下,通过对 values.yaml
的阅读,就能对这种复杂的部署产生一个较为深入的认识。
如果是常见的业务应用,因为不同部署之间的差异不大,但是未必可以提前做好变化限制,用 Kustomize 可能会是一个更好的选择。
https://helm.sh/
https://github.com/kubernetes-sigs/kustomize
https://helm.sh/blog/helm-3-preview-pt1/
https://www.infoq.cn/article/UemPsPu_AlzemkGEqb4Z
https://github.com/cdwv/awesome-helm
猜你还想看这些内容
· END ·
记得文末点个好看鸭~
点就完事儿了!