三、 Kustomize的特点
Kustomize的Overlay可以在Base的基础上,通过对resource/generator/transformer等的定义,形成新的应用定义,不管是Base还是Overlay,都可以通过kustomize build生成有效的YAML。
• 功能简单清晰,kubectl直接内部支持。
• 不考虑派生,仅仅作为组件的YAML组织方式也很有帮助。
• 也有自己的插件系统,例如可以用简单的YAML定义,使用文件生成ConfigMap/Secret等。
• 允许注入K8S运行时数据。
四、 Kustomize和Helm的对比
Kustomize相对于Helm而言,更加的轻量,只有一个CLI工具。也集成到了kubectl自身,使用及配置成本接近于0。Kustomize放弃了对模板的要求,改为参考Docker镜像的形式,通过Base+Overlay的方式对应用的原始YAML进行派生。
• Base YAML管控:Helm最大的特点是定制仅限于预先存在的配置选项。不仅如此,Chart作者还必须用有点麻烦的模板化方式实现这些定制选项。这个时候Kustomize不受限制的Overlay会更加灵活,想怎么覆盖就怎么覆盖。所以Helm对Base YAML强管控;而Kustomize虽然也有Base,但Overlay的存在让这个限制几乎不存在。
• 模板语法层面:Kustomize相较于Helm去掉了模板语法,入门门槛更低,更易使用。当然如果玩的高阶,两者都要学习很多东西。
• 部署层面:虽然Kustomize最为轻量,但因为Helm3取消了Tiller依赖,所以差别也不是很大,两者都是二进制命令工具生成YAML后直接下发。
• 工作流程上:
。 Helm:定义Chart->填充->运行。在Chart中没有定义的内容是无法更改的。
。 Kustomize:Base和Overlay都是可以独立运作的,增加新对象,或者对编写Base时未预料到的内容进行变更,都非常简单。
基于上述工作流程的对比,如果是要公开发布一个复杂的组件,编写一个复杂而设计良好的Helm Chart可以给用户很大帮助。用户在缺失了自由性之下,仅仅通过values.yaml的阅读和配置就可以对这种复杂的部署产生一个较为深入的认知。
如果是常见的业务应用,虽然不同的部署之间差异不大(比如日常预发生产),但是因为快速迭代及需求变化,未必可以一开始就做好相关的变化限制,用Kustomize是更好的选择。
对于承载应用(Application)这个概念而言,Kustomize和Helm的短板是一致的,都没有进一步提供包之间的依赖处理、外部资源申请及维护、变量间传递等能力。
对于承载组件(Component)这个概念而言,Kustomize和Helm类似,都是合适的工具。虽然Helm和Kustomize在自身的能力和流程上有着很多区别,但最终流程都是:开发者(一堆YAML)->合适的参数映射及渲染方式->使用者(填参/覆盖)->apply到目标K8S中。萝卜青菜,各有所爱。
五、 SREWorks的Kustomize组件实践
在SREWorks的appmanager中,将Kustomize与Helm并列放在一起成为一种组件类型,当前这种组件类型还未内置到出厂组件中,后续会上架到云端市场,供用户插拔安装。
- revisionName: "CHART|sreworks@management-controlplane@1.0|_" parameterValues: - name: Map value: clusterId: "{{ Global.clusterId }}" product: es userID: "{{ Global.uid }}" vpcID: "{{ Global.vpcID }}" vswitchID: "{{ Global.vswitchID }}" namespaceRegexes: "^(essen|es)$" - revisionName: KUSTOMIZE|elasticsearch-repos@2.0.1@test|_ parameterValues: - name: kubeconfig value: "{{ Global.kubeconfig }}" toFieldPaths: - spec.base64Kubeconfig - name: path value: "./" toFieldPaths: - spec.path dependencies: - component: "CHART|sreworks@management-controlplane@1.0" - revisionName: "STATUS|KUSTOMIZE@esonack-cluster-baselines|_" dependencies: - component: KUSTOMIZE|es-cluster-baselines@3.1.0@test parameterValues: - name: kubeconfig value: "{{ Global.kubeconfig }}" toFieldPaths: - spec.base64Kubeconfig - name: options value: groups: - namespace: sreworks-system labels: app: sreworks resources: - v1/pods toFieldPaths: - spec.options
|
如上面所示,在appmanager中的OAM YAML中,插入Helm和Kustomize两种组件,并且设置依赖关系,在Helm组件下发完成后,再进行Kustomize组件的下发;在Kustomize组件下发完成后,对核心Pod进行状态探测,待Pod正常之后才算作部署完成。
六、 总结
Kustomize是一个通用工具,它的作用是对Kubernetes资源进行定制后产生新的YAML文件,并保持原始的YAML文件不变。从这个意义上来说,你可以把Kustomize看成是Kubernetes YAML文件的转换工具,类似XML和XSLT的关系。
Kustomize的一个重要特征是不使用模板,而是直接工作在原始的YAML文件上。这一点与Helm是不同的。不使用模板好处在于简单易懂,不需要掌握复杂的模板语法,而Helm的YAML文件基本都被预置变量抠得毫无可读性。
Kustomize的另外一个优势是集成在kubectl中,这就意味着不需要安装额外的工具就可以进行定制。需要注意的是,由于实现上的原因,kubectl自带的Kustomize的版本比较低,目前仍然需要安装单独的Kustomize工具。这个问题要到1.20版本才会解决。