用 Kustomize Overlay 管理多环境差异

共享一份 base 清单，每个环境只保留一层轻量 overlay，让预发与生产仅在必要处存在差异，并通过渲染 diff 审查变更。

概述

复制粘贴多份清单会静默产生偏差：生产环境新增的资源限制没有同步到预发，只有压测或故障时才会暴露。Kustomize 把共享部分收敛为唯一的 base，把差异显式写在 overlay 中。评审者看到的是几十行 overlay，而不是两份长 YAML 的逐行比对。overlay 只应声明 namespace、镜像摘要、副本数和必要的补丁，其余字段交给 base 维护。

步骤

在 base 中声明共享资源：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

为生产环境编写 overlay，锁定镜像摘要、副本数与补丁：

namespace: production
resources:
  - ../../base
images:
  - name: ghcr.io/acme/payments
    digest: sha256:6f1c2a9d4b7e8f0a1c3d5e7f9b2a4c6d8e0f1a3b5c7d9e1f3a5b7c9d1e3f5a7b
replicas:
  - name: payments
    count: 3
patches:
  - target:
      kind: Deployment
      name: payments
    patch: |-
      - op: add
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: 512Mi

渲染全部 overlay 并比较预发与生产的差异：

for env in staging production; do
  kubectl kustomize overlays/$env > /tmp/$env.yaml
done
diff -u /tmp/staging.yaml /tmp/production.yaml

应用前先做服务端 dry-run：

kubectl apply -k overlays/production --server-side --dry-run=server

验证

期望 diff 中只出现可解释的差异，例如副本数、镜像、namespace 与资源请求；任何意外字段都说明 base 或补丁写错了。服务端 dry-run 应成功，并只报告 overlay 实际拥有的对象。若补丁未生效，先用 kubectl kustomize 确认渲染后的资源名，因为 namePrefix 会改变名称，补丁必须匹配加了前缀后的名字。

注意事项

Kustomize 不支持条件判断，需要根据计算结果分支时应改用 Helm。
namePrefix 会改变资源名，补丁、HPA 的 scaleTargetRef 等外部引用都要使用新名称。
不要把整份 Deployment 复制进 overlay，补丁越小越容易评审。
镜像建议使用 digest 而不是可变 tag，便于准入策略与供应链校验。
渲染产物应随流水线归档，便于事故复盘时还原实际提交的内容。