kustomize build 报“no matches for kind 'Kustomization'”是因为文件名必须严格为小写的 kustomization.yaml（非 Kustomization.yaml 或 kustomization.yml），且需存在于指定路径下。
为什么 kustomize build 会报 no matches for kind "Kustomization"
这是初用 Kustomize 最常卡住的地方：你写了 kustomization.yaml，但文件名写成了 Kustomization.yaml 或 kustomization.yml。Kustomize 只认小写 kustomization.yaml（注意是 .yaml，不是 .yml），且必须在当前目录或指定路径下存在。
- 检查文件名是否严格为
kustomization.yaml，大小写敏感 - 运行
kustomize build .前，先ls -l kustomization.yaml确认存在 - 如果用 Go 工具链调用（比如
exec.Command("kustomize", "build", "...")），确保工作目录正确，不能依赖相对路径“猜” - Go 中通过
github.com/kubernetes-sigs/kustomize/api/krusty编程调用时，必须显式传入krusty.MakeDefaultOptions()，否则默认不启用某些内置 transformer，也可能导致资源未生成
base 和 overlays 目录结构怎么组织才不踩坑
很多人把所有环境塞进一个 kustomization.yaml，结果 patch 冲突、envsubst 混乱、CI 调试困难。Kustomize 的设计哲学是“base 不含环境变量，overlay 只做差异化”。Go 项目里尤其要注意：base 应该能独立 kustomize build 出合法 YAML，否则 CI 阶段校验就失败。
-
base/放通用资源：deployment.yaml、service.yaml，不含env、replicas、image等环境相关字段 -
overlays/staging/和overlays/prod/各自声明resources: [../../base]，再用patchesStrategicMerge或images:覆盖镜像、副本数等 - 避免在 overlay 里重复定义 base 已有的资源——Kustomize 不会合并同名资源，而是报错
id collision - Go 程序中若需动态生成 overlay（比如根据 git tag 渲染 prod 配置），别拼接 YAML 字符串，改用
kyaml库操作 AST，否则注释丢失、字段顺序错乱会导致 Helm/Kubectl 解析异常
如何让 Go 程序安全注入环境变量到 kustomize 配置
直接在 kustomization.yaml 里写 ${ENV_NAME} 是危险的：Kustomize 默认不展开 shell 变量，除非你启用 vars: + replacements:，且 Go 调用时得手动注入值。更糟的是，有人用 os.Setenv 然后指望 kustomize build 命令行读取——这在容器化 CI 中常因进程隔离失效。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐做法：在 overlay 的
kustomization.yaml中定义vars:，例如- name: APP_VERSION，再在replacements:中指定字段路径（如spec.template.spec.containers.[0].image） - Go 中构建时，用
krusty.Options的Vars字段传入 map[string]string，而不是依赖系统环境变量 - 禁止在 ConfigMap/Secret 的
data字段里用$(FOO)——Kustomize 不处理这种语法，那是 Helm 的事；要用configMapGenerator+literals静态生成 - 如果必须动态值（如时间戳、随机 token），不要塞进 kustomize 流程，改由 Go 程序生成临时 ConfigMap YAML，再作为
resources加入 overlay
Go 调用 kustomize API 时为何生成的 Deployment 镜像没更新
常见原因是没理解 images: 字段的匹配逻辑：它只替换 containers[].image 和 initContainers[].image，且必须完全匹配（包括 registry 前缀）。如果你 base 里写的是 myapp:1.0，而 overlay 的 images: 写成 - name: myapp，那只会匹配无 tag 的镜像；若 base 是 quay.io/myorg/myapp:1.0，overlay 就得写全名或用 newName+newTag 显式指定。
立即学习“go语言免费学习笔记（深入）”；
- 调试技巧：先用命令行
kustomize build overlays/prod --enable-alpha-plugins看输出，确认镜像已变，再对比 Go 调用结果 - Go 中使用
krusty.MakeDefaultOptions()后，务必检查options.ImageTag是否被其他逻辑覆盖（比如某些封装库会重设） - 多 stage 构建场景下，base 可能有多个 container（build、run），确保
images:列表按顺序或 name 精确匹配，否则只改第一个 - 如果用
ConfigMapGenerator生成 env 文件，别指望它自动注入到容器 envFrom —— 那是另一个独立字段，要手动在 patch 里加
Go 多环境部署真正的复杂点不在语法，而在 base 和 overlay 的职责边界是否清晰。一旦有人在 base 里写 replicas: 3 或硬编码 namespace，整个流程就退化成字符串替换，后续所有自动化、diff、审计都会失准。
