补丁式定制与模板式定制的取舍

同样是解决”同一份 Kubernetes 清单在不同环境要有不同取值”的问题，Kustomize 和 Helm 走的是两条相反的路。Helm 靠模板：先把清单里所有可能要变的地方都写成模板占位符，再在各环境分别提供取值，缺点是模板化以后的文件已经不是合法的 YAML，且如果某个字段当初没被模板化，后续就无法在不改模板的前提下定制它。Kustomize 靠补丁：清单本身从头到尾都是合法 YAML，定制通过在 overlay 里声明”对哪个字段做什么修改”来实现，不需要提前预判哪些字段可能要变,但补丁能表达的操作类型不如模板灵活。两者不是谁淘汰谁,实践里常常先用 Kustomize 处理结构化定制,遇到 Kustomize 表达不了的复杂场景再叠一层 Helm。发散：这是”预先声明所有变化点（模板）”和”事后针对具体差异打补丁（补丁）”两种配置管理哲学的正面对照，选择哪种往往取决于变化点在设计时能不能被穷举。