Kustomize namespace: Set Namespace on All Resources

By Daniel Zoghalchali·Latchkey

The namespace field stamps a single namespace onto every namespaced resource in the build.

One line moves a whole overlay into a target namespace. Kustomize also rewrites references such as ServiceAccount subjects in RoleBindings to match.

What it does

Setting namespace adds or overwrites metadata.namespace on every namespaced resource the build produces. Kustomize also updates known cross-references, for example the namespace of subjects in a RoleBinding that point at a ServiceAccount in the same build.

Common usage

# overlays/prod/kustomization.yaml
namespace: prod-web
resources:
  - ../../base

Behavior

In CI

Use namespace per overlay so dev and prod land in separate namespaces from one base. Confirm the namespace exists or include a Namespace manifest, since kubectl apply -k will fail if the target namespace is missing and not created in the same apply.

Common errors in CI

"namespaces \"prod-web\" not found" at apply time means the namespace is not created by this build; add a Namespace resource or create it first. The transformer does not touch cluster-scoped objects, so do not expect a ClusterRole to gain a namespace. If references are not rewritten, the subject kind or name does not match a resource in the same build.

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

Frequently asked questions

Related guides

References

• GitHub Actions documentation