Feature Request: Target label selector patches should apply patches

[erikgb]

According to https://fluxcd.io/flux/components/kustomize/kustomizations/#patches, it should be possible to apply patches to a Flux Kustomization using a target label selector. But I think there might be a bug somewhere.

$ tree
.
├── base
│   └── kustomization.yaml
└── kustomization.yaml

2 directories, 2 files
$ cat base/kustomization.yaml 
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
labels:
  - pairs:
      added-by-labels: "v"
configMapGenerator:
  - name: config
    literals:
      - KEY=v
    options:
      labels:
        added-by-options: "v"
$ cat kustomization.yaml 
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: stas
resources:
  - base
patches:
  - patch: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: not-used
      data:
        ADDED_BY_KUSTOMIZE_LABELS: "v"
    target:
      kind: ConfigMap
      labelSelector: added-by-labels=v
  - patch: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: not-used
      data:
        ADDED_BY_KUSTOMIZE_OPTIONS: "v"
    target:
      kind: ConfigMap
      labelSelector: added-by-labels=v

Then if I run kustomize build . it produces the expected output:

apiVersion: v1
data:
  ADDED_BY_KUSTOMIZE_LABELS: v
  ADDED_BY_KUSTOMIZE_OPTIONS: v
  KEY: v
kind: ConfigMap
metadata:
  labels:
    added-by-labels: v
    added-by-options: v
  name: config-49gc847c57
  namespace: stas

But if I do the same with a Flux Kustomization patch, it does not work:

---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: label-patch
spec:
  interval: 1h
  path: ./apps/label-patch/base
  prune: true
  sourceRef:
    kind: GitRepository
    name: tenant
  targetNamespace: stas
  patches:
    - patch: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: not-used
        data:
          ADDED_BY_KUSTOMIZE_LABELS: "v"
      target:
        kind: ConfigMap
        labelSelector: added-by-labels=v
    - patch: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: not-used
        data:
          ADDED_BY_KUSTOMIZE_OPTIONS: "v"
      target:
        kind: ConfigMap
        labelSelector: added-by-labels=v

Which in the cluster looks like this:

kind: ConfigMap
apiVersion: v1
metadata:
  name: config-2969fdbbtk
  namespace: stas
  uid: 386ae55f-4fc0-4e14-8a03-5ac8f5ee5411
  resourceVersion: '2736213362'
  creationTimestamp: '2026-07-09T18:49:34Z'
  labels:
    added-by-labels: v
    added-by-options: v
    kustomize.toolkit.fluxcd.io/name: label-patch
    kustomize.toolkit.fluxcd.io/namespace: stas
  annotations:
    config.kubernetes.io/origin: |
      configuredIn: kustomization.yaml
      configuredBy:
        apiVersion: builtin
        kind: ConfigMapGenerator
  managedFields:
    - manager: kustomize-controller
      operation: Apply
      apiVersion: v1
      time: '2026-07-09T18:49:34Z'
      fieldsType: FieldsV1
      fieldsV1:
        'f:data':
          'f:KEY': {}
        'f:metadata':
          'f:annotations':
            'f:config.kubernetes.io/origin': {}
          'f:labels':
            'f:added-by-labels': {}
            'f:added-by-options': {}
            'f:kustomize.toolkit.fluxcd.io/name': {}
            'f:kustomize.toolkit.fluxcd.io/namespace': {}
data:
  KEY: v

CC @matheuscscp

[matheuscscp]

Thanks for this report @erikgb! I was able to reproduce this example both in kustomize and in Flux.

I also reproduced the behavior you mentioned via DM about how inlining this kustomization makes kustomize work like Flux.

And the conclusion I have from this is the same one you said: it's basically a question of whether I want Flux to behave as a base or an overlay (today it acts as a base modifier). But this is no simple bugfix. This is a feature request. Once we wire Flux as an overlay, this is a very good example of how a subset of behaviors will be different. I expect more of those differences. This means we cannot simply change this behavior without an opt-in knob, which I propose to be: .spec.strategy: Overlay (defaults to Base). This allows us to implement the behavior without making sure everything else behaves exactly the same, we have leeway for more things to differ.

As such, I propose this as a feature for the next minor release.

[matheuscscp]

I'm not quite sure about Base and Overlay for the strategy, btw. These don't make much sense... Maybe a boolean .spec.enableVirtualOverlay.

[matheuscscp]

Which is also not a good name because people (and us) don't really know all the differences, and honestly I don't see a field name that both describes exactly what we would do differently in this case (start rendering a virtual kustomization) and describes also, for example, how this difference implements this particular feature request. If we, for example, decide to lazily document which behaviors are achieved and which behaviors are lost by doing this as they appear in user reports, I don't think it's a good strategy either...

As I know you were using this only for debugging something else and you probably don't have a planned use case for it, I'd like to wait for more user requests to consider implementing this feature 🙏

[erikgb]

Thanks for taking a look! I don't think this should be configurable on Kustomization. But I still think it's worth discussing the Flux behavior here.

If the Flux Kustomization runs its kustomize build as a dedicated overlay, this should have worked. This makes me believe that Flux runs its kustomize build in the directory that path points to and modifies it to append its patches (if any). That would explain the observed behavior. My question is: Is this intentional? Regardless of this issue, I would expect a Flux Kustomization to act as an overlay rather than a base modifier.

[matheuscscp]

This makes me believe that Flux runs its kustomize build in the directory that path points to and modifies it to append its patches (if any). That would explain the observed behavior.

Correct:

kustomize-controller/internal/controller/kustomization_controller.go

Line 371 in 20e3c8a

dirPath, err := securejoin.SecureJoin(tmpDir, obj.Spec.Path)

kustomize-controller/internal/controller/kustomization_controller.go

Line 430 in 20e3c8a

err = r.generate(unstructured.Unstructured{Object: k}, tmpDir, dirPath)

kustomize-controller/internal/controller/kustomization_controller.go

Line 437 in 20e3c8a

resources, err := r.build(ctx, obj, unstructured.Unstructured{Object: k}, tmpDir, dirPath)

If the Flux Kustomization runs its kustomize build as a dedicated overlay, this should have worked.

Also correct, I have tried locally.

Is this intentional?

I don't really know if using .spec.path as the entrypoint and modifying / generating a kustomization.yaml inside that path was ultra intentional at the time it was implemented, but from the code I'd guess it was intentional to some degree.

Regardless of this issue, I would expect a Flux Kustomization to act as an overlay rather than a base modifier.
I don't think this should be configurable on Kustomization.

That's an interesting idea, but maybe someone else could expect the current behavior instead, I don't see why not. One thing is for sure: intentional or not, this is now a bespoke expected behavior. I don't want to risk changing it without any gates, as I expect breaking lots of people by doing that. So if we implement it, we need to make it opt-in. Either via API field or controller feature gate.

[erikgb]

That's an interesting idea, but maybe someone else could expect the current behavior instead, I don't see why not. One thing is for sure: intentional or not, this is now a bespoke expected behavior. I don't want to risk changing it without any gates, as I expect breaking lots of people by doing that. So if we implement it, we need to make it opt-in. Either via API field or controller feature gate.

Good point! This was just discovered as part of a debug-hack I was working on, so no rush from my side. Should we just keep the issue open for now?