Kustomize build 仅构建 YAML，不管理多环境配置；应通过 base/ 和 overlays/ 分层管理差异，Go 程序调用 kustomize build 命令生成各环境配置，并用 kubectl --dry-run=client 验证合法性。
为什么不用 kustomize build 直接生成 YAML 就完事？
因为 kustomize build 只是“构建”，不是“管理”。你真正需要的是：同一套基础配置，按环境（dev/staging/prod）自动注入不同镜像、资源限制、Secret 引用、甚至不同 Service 类型。硬编码多份 YAML 会迅速失控，而靠脚本拼接又难维护、难审计。
核心做法是分层：一个 base/ 目录放通用资源（Deployment、Service），多个 overlays/dev/、overlays/staging/ 各自只写差异——比如 patchesStrategicMerge 改副本数，images 换镜像 tag，vars 绑定 ConfigMap 字段到容器 env。
-
kustomization.yaml必须在每个目录下存在，且resources:指向 base（相对路径） - 不要在 overlay 里重复定义 base 已有的资源；Kustomize 会报错
id conflict - 如果你用 Go 写工具链，注意
kustomizeCLI 是独立二进制，Go SDK（sigs.k8s.io/kustomize/api）不推荐直接集成——版本耦合紧、API 不稳定
如何让 Go 程序动态生成不同环境的 Kustomize 配置？
别试图用 Go 去“生成” kustomization.yaml 文件。正确姿势是：Go 程序读取环境变量或配置文件（如 env.yaml），然后调用系统命令执行 kustomize build overlays/$ENV，把输出写入指定路径。
这样既利用 Kustomize 原生能力，又保留 Go 的灵活性（比如从 Vault 拉密钥、做 CI 环境校验）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
exec.Command("kustomize", "build", "overlays/prod")，不是run—— 要捕获StdoutPipe()写入文件 - 确保工作目录是 kustomize 项目根目录，否则
resources:路径会解析失败 - 如果 Go 程序要支持 Windows，注意
kustomize.exe路径需显式指定，不能只依赖 PATH（很多 CI 环境没配）
遇到 no matches for kind "Deployment" in version "apps/v1" 怎么办？
这不是 Go 或 Kustomize 的错，是 Kustomize 版本太低，不认识新版 Kubernetes API。v3.2 以下默认用旧版 schema，不会自动升级 group/version。
解决方法只有两个：升级 Kustomize，或显式声明 apiVersion。
- 检查版本：
kustomize version，必须 ≥ v3.8.0（推荐 v4.5+） - 如果无法升级，就在 base 的 Deployment 文件顶部加
apiVersion: apps/v1—— 即使 base 是从kubectl get deploy -o yaml导出的，也常漏掉这一行 - 别信 “Kustomize 自动适配” 的说法，它不改你的 YAML 内容，只负责 patch 和 merge
Go 中调用 kustomize build 后，怎么验证生成的 YAML 是否合法？
不能只看命令是否返回 0。Kustomize 成功 build，不代表 YAML 能被 kube-apiserver 接收。常见问题：字段类型错（比如把 replicas: "3" 写成字符串）、引用了不存在的 Secret、ServicePort 重复。
最轻量的验证方式：用 kubectl apply --dry-run=client -f - 管道接收输出。
- Go 里拼接命令：
exec.Command("kubectl", "apply", "--dry-run=client", "-f", "-") - 把
kustomize build的 stdout 当作 stdin 传给 kubectl，避免落地临时文件 - 注意
--dry-run=client不连集群，但能校验结构；若要真校验（如 RBAC 权限），得用server模式——那必须有可用 kubeconfig
复杂点在于，不同环境的 overlay 可能依赖不同集群特性（比如 prod 开了 PodDisruptionBudget，dev 没开），这些没法靠一次 dry-run 全覆盖。得按环境分别验证，且把 kubectl 的 stderr 错误原样透出——别吞掉。
