Kustomize namePrefix and nameSuffix
namePrefix and nameSuffix add a fixed string to the front or back of every resource name in the build.
These fields let two overlays from one base coexist in a cluster by giving every object a distinct, predictable name, with references kept in sync.
What it does
namePrefix prepends a string and nameSuffix appends one to metadata.name of every resource. Kustomize then rewrites references to those names (a Deployment that mounts a ConfigMap, a Service selector target by name) so the manifests stay internally consistent.
Common usage
# overlays/prod/kustomization.yaml
namePrefix: prod-
nameSuffix: -v2
resources:
- ../../baseFields
| Field | What it does |
|---|---|
| namePrefix | String prepended to every metadata.name |
| nameSuffix | String appended to every metadata.name |
| (reference rewrite) | ConfigMap/Secret/Service references updated automatically |
In CI
Prefixes stack when overlays nest, so an overlay over an overlay gets both prefixes. Watch the 63-character Kubernetes name limit: a long base name plus prefix and suffix can exceed it and fail validation at apply time. Generated names (ConfigMaps) also pick up the prefix before their content hash.
Common errors in CI
"metadata.name: Invalid value ... must be no more than 63 characters" means the prefix or suffix pushed a name over the limit. If a volume or env reference still points at the old name, the referenced kind is one Kustomize does not rewrite by default; use a nameReference configuration or a replacement. A Service whose selector does not match pods often means the prefix was applied to names but selectors are label-based and untouched.
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