Kustomize generatorOptions
generatorOptions applies shared settings, such as disabling the name hash, to every ConfigMap and Secret generator.
When you want all generated ConfigMaps and Secrets to skip the hash suffix or share labels, generatorOptions sets it once instead of per generator.
What it does
generatorOptions sets defaults for all generators in the kustomization: disableNameSuffixHash turns off the content hash on every generated name, while labels and annotations attach metadata to every generated ConfigMap and Secret. A per-generator options block overrides these globals.
Common usage
generatorOptions:
disableNameSuffixHash: true
labels:
generated-by: kustomize
annotations:
note: shared-generator-options
configMapGenerator:
- name: app-config
literals:
- LOG_LEVEL=infoFields
| Field | What it does |
|---|---|
| disableNameSuffixHash | Skip the content hash suffix on generated names |
| labels | Labels added to every generated resource |
| annotations | Annotations added to every generated resource |
| immutable | Mark generated ConfigMaps/Secrets immutable |
In CI
Disabling the hash trades automatic rollouts for stable names. If you set disableNameSuffixHash: true, you must trigger rollouts yourself (for example kubectl rollout restart) when config changes, since the Deployment spec no longer changes. Keep the hash on unless an external consumer needs a fixed name.
Common errors in CI
Config changes that do not roll out are the classic symptom of disableNameSuffixHash: true; the ConfigMap updates in place but pods keep the old mounted copy until restarted. With immutable: true, any later edit to the data fails apply with "field is immutable" because immutable ConfigMaps cannot be updated; delete and recreate instead.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes