Customizing Manifests with Kustomize

Kustomize takes the opposite approach from Helm: no templating language at all. You write plain, valid YAML manifests once as a base, then layer overlays on top that patch or add to them for each environment. kubectl has supported kustomization.yaml files natively since v1.14 — kubectl apply -k <dir> applies what a directory's kustomization produces, and kubectl kustomize <dir> just prints it without applying anything, useful for reviewing the result first.

A kustomization.yaml (apiVersion: kustomize.config.k8s.io/ v1beta1, kind: Kustomization) lists its resources: — plain manifest files, or another kustomization directory used as a base — and can set cross-cutting fields such as namespace, namePrefix, nameSuffix, labels and commonAnnotations that get applied to everything it references, without editing those referenced files at all.

# base/kustomization.yaml
resources:
  - deployment.yaml
  - service.yaml

# overlays/production/kustomization.yaml
resources:
  - ../../base
namespace: production
patches:
  - path: increase-replicas.yaml
    target:
      kind: Deployment
      name: web

Patching a specific resource is done through the unified patches: field, which accepts either a strategic-merge patch or a JSON 6902 patch and auto-detects which one it's looking at. The older patchesStrategicMerge and patchesJson6902 fields still work but are deprecated in favor of patches; kustomize edit fix can migrate an old kustomization.yaml to the current field automatically.

configMapGenerator and secretGenerator build a ConfigMap or Secret from files or literal key-value pairs listed right in the kustomization file. By default, the generated object's name gets a content-hash suffix appended — so when the data changes, the generated name changes too, which forces anything referencing it by name (like a Deployment's volume) to roll. generatorOptions.disableNameSuffixHash: true turns that behavior off, at the cost of losing the automatic rollout.