Name‑suffix + patch ordering causes unintended configmap override

[Ahmedie-m]

What happened?

When two bases define resources with the same metadata.name, and one base applies a nameSuffix, overlay patches can - depending on patch order - end up overriding both resources. This violates the intended isolation provided by name suffixing. Specifically, a patch meant for the “pod” configmap can incorrectly apply to the “pod-api” configmap when the API base uses nameSuffix.

What did you expect to happen?

Each patch should only apply to the resource it is intended for, after any name transformations (like nameSuffix) are applied. Specifically:

• The patch for service-pod-config should only modify that ConfigMap.
• The patch for service-pod-config-api should only modify that ConfigMap.
• Patch application should be deterministic and not depend on patch order.
• Using nameSuffix should guarantee that the API ConfigMap is treated as a separate resource and cannot be accidentally overridden by a patch targeting the base name.

How can we reproduce it (as minimally and precisely as possible)?

Tarball attached below with the following folder structure:

kustomize-repro/
├── base/
│   ├── service-pod/
│   │   ├── configmap.yaml
│   │   └── kustomization.yaml
│   └── service-pod-api/
│       ├── configmap.yaml
│       └── kustomization.yaml
└── overlays/
    └── dev/
        ├── pod-config-override.yaml
        ├── pod-api-config-override.yaml
        ├── kustomization-a.yaml
        └── kustomization-b.yaml

kustomize-repro.tar.gz

Reproducible by:

tar -xf kustomize-repro.tar.gz
cd kustomize-repro
Use kustomization-a:
kustomize build overlays/dev > out-order-a.yaml
Use kustomization-b:
kustomize build overlays/dev > out-order-b.yaml

Expected output

apiVersion: v1
kind: ConfigMap
metadata:
  name: service-pod-config
data:
  value: overlay-pod
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: service-pod-config-api
data:
  value: overlay-pod-api
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-pod
spec:
  template:
    metadata:
      labels:
        app: service-pod
    spec:
      containers:
      - image: nginx
        name: app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-pod-api
spec:
  template:
    metadata:
      labels:
        app: service-pod-api
    spec:
      containers:
      - image: nginx
        name: api

Actual output

Using patch order A (API patch first):

apiVersion: v1
kind: ConfigMap
metadata:
  name: service-pod-config
data:
  value: overlay-pod
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: service-pod-config-api
data:
  value: overlay-pod       # <- incorrect: should be overlay-pod-api
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-pod
spec:
  template:
    metadata:
      labels:
        app: service-pod
    spec:
      containers:
      - image: nginx
        name: app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-pod-api
spec:
  template:
    metadata:
      labels:
        app: service-pod-api
    spec:
      containers:
      - image: nginx
        name: api

Kustomize version

5.7.1

Operating system

MacOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.