32

I have a kustomize base that I'd like to re-use without editing it. Unfortunately, it creates a namespace I don't want to create. I'd like to simply remove that resource from consideration when compiling the manifests and add a resource for mine since I can't patch a namespace to change the name.

Can this be done? How?

Josiah
  • 2,666
  • 5
  • 30
  • 40

3 Answers3

70

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.yaml
resources:
  - namespace.yaml

$  cat base/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ns-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ cat overlays/dev/kustomization.yaml
bases:
  - ../../base

$ cat overlays/prod/delete-ns-b.yaml
$patch: delete
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ cat overlays/prod/kustomization.yaml
bases:
  - ../../base
patches:
  - path: delete-ns-b.yaml

Behavior of kustomize

$ kustomize build overlays/dev
apiVersion: v1
kind: Namespace
metadata:
  name: ns-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: ns-b

$ kustomize build overlays/prod
apiVersion: v1
kind: Namespace
metadata:
  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.

arve0
  • 3,424
  • 26
  • 33
Toshinori Sugita
  • 1,674
  • 1
  • 13
  • 12
8

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
Josiah
  • 2,666
  • 5
  • 30
  • 40
7

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 -
Ben Davies
  • 607
  • 8
  • 8
  • 1
    That's a neat solution for quick deployments, but will it work in the gitops use of Flux or ArgoCD? I also tend to prefer to make changes to the results as close to the original as possible to reduce confusion as it passes through the process. For some simple one-off situations where I don't need to automate and reproduce my results, this is elegant and quick. – Josiah Feb 10 '22 at 14:15
  • I like this solution for quick tests too. But I dislike that the "-l" filter is missing in the VCS – Datz Nov 16 '22 at 07:14
  • Works very well, but a shorter version is 'kubectl apply -k . -l apply-resource!=no' – stackoverflowed Mar 23 '23 at 10:07
  • 1
    @stackoverflowed Not all kustomize features are supported natively by kubectl so those of us who have run into that generally just pipe and save the brain cells needed to figure out which circumstance we're in. – Josiah Jul 24 '23 at 20:12