大规模集群配置管理选型：Kustomize还是Jsonnet？

核心优缺点对比 #

Jsonnet 优势 #

• 原生支持全局变量透传：你可以在顶层定义一次通用变量（比如镜像拉取Secret名、集群域名、资源配额阈值），直接在全链路所有配置模板里引用，完全不需要搜索替换，变量修改后重新渲染即可生效，配合版本控制天然支持回滚，完全解决你现在全局修改变量的痛点。
• 配置逻辑可追溯：没有大量base文件夹的嵌套结构，所有配置字段的来源都可以通过函数调用、对象继承链路直接定位，甚至可以给字段加注释说明配置逻辑，排查问题不需要翻多层目录找补丁。
• 灵活的配置复用能力：你可以把dex的三种认证配置分别封装成独立的可复用模块，需要用的时候直接导入三个模块合并到你的dex配置里即可，不需要手动比对不同环境的补丁差异，复用粒度可以自由控制到单个字段、单个补丁、整个组件。
• 支持复杂逻辑渲染：可以写条件判断、循环、计算逻辑生成配置，比如需要给所有Deployment统一加Sidecar、统一加环境变量，只需要写一个遍历函数处理所有资源即可，不需要给每个Deployment单独写Kustomize补丁。

Jsonnet 劣势 #

• 学习曲线更陡：你需要额外学习Jsonnet的语法、函数、面向对象的配置编写方式，以及Tanka的工具链用法，入门成本比只需要写YAML补丁的Kustomize高不少。
• 生态适配不如Kustomize：Kustomize是Kubernetes官方内置支持的工具，几乎所有云原生开源项目的官方部署清单都默认提供Kustomize适配，而Jsonnet的公共库、官方适配的项目相对少，你如果要适配现有Kubeflow的Kustomize清单，需要做一层转换或者导入逻辑，前期有迁移成本。
• 团队协作门槛高：如果你的团队其他成员都只熟悉Kustomize，推广Jsonnet需要额外的培训成本，后续维护的人员要求也更高。
• 配置复杂度容易失控：如果没有规范约束，很容易写出逻辑嵌套过深的配置模板，后续排查问题的难度反而会比纯YAML的Kustomize高。

是否值得迁移使用的判断建议 #

如果你的场景符合以下任意几种情况，非常值得学习并落地Jsonnet+Tanka：

你当前的Kubeflow部署需要频繁做全局配置修改、多环境配置复用，后续还会持续扩展部署的组件、环境数量
你的团队有精力投入学习新工具，并且可以制定统一的Jsonnet配置编写规范
你需要经常做批量的配置修改（比如批量加Sidecar、批量调整资源配额）

如果符合以下情况，不建议迁移：

你的Kubeflow配置后续改动很少，只是偶尔做小调整
团队规模小，没有多余精力学习新工具，或者团队成员对新工具接受度很低
你需要大量复用官方提供的Kustomize补丁，不愿意做迁移适配的额外工作

内容的提问来源于stack exchange，提问作者TDN