0

I am not managing to include a kustomization.yaml that only contains patches. As a minimal example of the problem I'm solving, I can illustrate with the folder structure below:

.
├── kustomization.yaml
├── nested
│   ├── kustomization.yaml
│   └── serviceaccount-patch.yaml
└── service-account.yaml

The files are:

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization 
metadata:
  name: top
resources:
  - service-account.yaml
  - nested

# service-account.yaml
kind: ServiceAccount
apiVersion: v1
metadata:
  name: base
spec:
  automountServiceAccountToken: false

# nested/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization 
metadata:
  name: nested
patches:
  - path: serviceaccount-patch.yaml
    target:
      kind: ServiceAccount
      name: base

# nested/serviceaccount-patch.yaml
- op: replace
  path: /metadata/name
  value: replaced

The patch is not applied. When putting the patch straight into kustomization.yaml it does work. I'd like to keep this structure, as my actual use case is to have the following:

.
├── base
│   ├── env
│   │   ├── app
│   │   │   ├── kustomization.yaml
│   │   │   └── service-account.yaml
│   │   └── kustomization.yaml
│   ├── kustomization.yaml
│   └── shared
│       ├── kustomization.yaml
│       └── pod.yaml
├── overlay
│   └── dev
│       ├── env
│       │   ├── app
│       │   │   ├── kustomization.yaml
│       │   │   └── serviceaccount-patch2.yaml
│       │   ├── kustomization.yaml
│       │   └── serviceaccount-patch.yaml
│       ├── kustomization.yaml
│       └── shared
│           └── kustomization.yaml

Here, I would have two parts for each environment: env and shared. I would overrule the namespace in overlay/dev/env/kustomization.yaml. That file would also include the base base/env, making sure that the namespace of the shared base is not modified. The above also illustrates which patch works (serviceaccount-patch.yaml) and which doesn't (serviceaccount-patch2.yaml).

If there is a better way to achieve this, I'd love to hear it.

Joachim Nielandt
  • 145
  • 8

1 Answers1

0

A patch can only be applied to resources that are generated by the kustomization.yaml that includes the patch. In other words, running kustomize build without the patch defined must create the resources that you want to patch.

Running kustomize build in your nested directory produces no output -- that file includes no resources, so your patch is no-op.

I'm not entirely sure I understand your desired layout; in particular, it's not clear what the difference between dev/ and /dev/env/ is meant to be. You would generally set things up like this:

.
├── base
│   ├── kustomization.yaml
│   └── service-account.yaml
└── overlay
    ├── dev
    │   ├── kustomization.yaml
    │   └── serviceaccount-patch.yaml
    ├── us-east
    │   ├── kustomization.yaml
    │   └── ...
    └── us-west
    │   ├── kustomization.yaml
    │   └── ...

Where overlay/dev/kustomization.yaml looks like:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: serviceaccount-patch.yaml
    target:
      kind: ServiceAccount
      name: base

Running kustomize build overlay/dev shows that the patch is applied as expected:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: replaced
spec:
  automountServiceAccountToken: false
larsks
  • 277,717
  • 41
  • 399
  • 399
  • Good to know that indeed the patch needs to be applied to what kustomization.yaml imports as a resource. I guess I'm running into issues as I'm now trying to add patches on top of my base that uses nested kustomizations. I noticed my example was not completely showing that, I have edited it in the question above. – Joachim Nielandt Jan 26 '23 at 08:15
  • To clarify the change: base was supposed to be able to be applied by itself. It has a kustomization, which in its turn loads the various apps that are defined in their own kustomizations. However, as I was overwriting the namespace in the overlays, I had to branch off the 'shared' parts into their own kustomization. Hence, the `shared`. So there's a layered structure here. The overlays mirror the structure of base. `env` is supposed to become the namespace for `dev`, etc. This namespace is set in the overlay's kustomization. – Joachim Nielandt Jan 26 '23 at 08:15
  • By splitting `env` and `shared` into separate bases, I thought I could then override the namespace by using the `namespace` attribute of kustomization. In `overlays/dev/env/kustomization.yaml` I would put `namespace: dev`, for example, thus setting the namespace for all included resources. I'd consider `dev` a _base_ then, just like `shared` would be a _base_. – Joachim Nielandt Jan 26 '23 at 08:23
  • You can treat `dev` as a base by having `dev/env` include `..` as a resource (and then your patch would apply), rather than having `dev` include `env`. – larsks Jan 26 '23 at 12:52
  • I think that's eventually the way to go for me. Thanks, @larsks! – Joachim Nielandt Jan 26 '23 at 12:54