Exclude Resource in kustomization.yaml

You can omit the specific resource by using a delete directive of Strategic Merge Patch like this.

Folder structure

$ tree ..├── base│   ├── kustomization.yaml│   └── namespace.yaml└── overlays    ├── dev    │   └── kustomization.yaml    └── prod        ├── delete-ns-b.yaml        └── kustomization.yaml

File content

$ cat base/kustomization.yamlresources:  - namespace.yaml$  cat base/namespace.yamlapiVersion: v1kind: Namespacemetadata:  name: ns-a---apiVersion: v1kind: Namespacemetadata:  name: ns-b$ cat overlays/dev/kustomization.yamlbases:  - ../../base$ cat overlays/prod/delete-ns-b.yaml$patch: deleteapiVersion: v1kind: Namespacemetadata:  name: ns-b$ cat overlays/prod/kustomization.yamlbases:  - ../../basepatchesStrategicMerge:  - delete-ns-b.yaml

Behavior of kustomize

$ kustomize build overlays/devapiVersion: v1kind: Namespacemetadata:  name: ns-a---apiVersion: v1kind: Namespacemetadata:  name: ns-b$ kustomize build overlays/prodapiVersion: v1kind: Namespacemetadata:  name: ns-a

In this case, we have two namespaces in the base folder. In dev, kustomize produces 2 namespaces because there is no patch. But, in prod, kustomize produces only one namespace because delete patch deletes namespace ns-b.

I found that my understanding of not being able to change a namespace name was incorrect. Using the patch capability, you actually can change the name of a resource including namespaces.

This is what I ended up using:

patches:- target:    kind: Namespace    name: application  patch: |-    - op: replace      path: /metadata/name      value: my-application

I encountered this problem and eventually took a different approach to solving it. It's worth thinking back through your requirements and asking yourself why you would want kustomize to omit a resource? In my case - and I would imagine this is the most common use-case - I wanted kustomize to omit a resource because I didn't want to apply it to the target kubernetes cluster but kustomize doesn't provide an easy way to do this. Would it not be better for the filtration to take place when applying the resource to the cluster rather than when generating them? The solution which I eventually applied was to filter the resources by label when applying to the cluster. You can add an exclusion label in an overlay to prevent the resource from being applied.

e.g.

$ kustomize build . | kubectl apply -l apply-resource!=no -f -