patches has odd behaviour when an entry is missing its' merge key

[Gikkman]

What happened?

If you have a Deployment defined with more than one container, and one of those containers is missing their name field, applying a patch on one of the other containers, the properly named containers risks disappearing.

This is similar to issue #5150. In this case however, I have one or more containers that do have their merge key present. It still seems like kustomize drops all containers that has a proper merge key, only keeping the containers that lacks one.

The same phenomena can be seen in other places, for example with an env list. If the base deployment has two proper entries, and a patch tries to add a 3rd missing it's merge key (i.e. it only has a value, no name), then list gets empties completely.

What did you expect to happen?

Given the example I provide below, I'd expected either of these (with nr 2 being the more likely):

1. The container that lacks a name is kept as-is, since it's name is effectively "" (Or maybe null? I don't know the internals well enough), differentiating it from the other containers.
2. The container without a merge key is dropped.

In either case, I think kustomize should output some kind of warning, or even fail outright since the input manifest is broken, and entries with missing merge keys can have unexpected consequences (such as a env entry with a missing name).

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

echo "---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment.yaml

patches:
- path: patch.yaml
" > kustomization.yaml

echo "---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
        - name: container-1
          image: image-1
        - image: image-2
" > deployment.yaml

echo "---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
        - name: container-1
          image: image-1
          imagePullPolicy: Always
" > patch.yaml

kustomize build .

Expected output

kustomize build .
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
      - name: container-1
         image: image-1
         imagePullPolicy: Always
      - image: image-2

Actual output

kustomize build .
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
      - image: image-2

Kustomize version

5.1.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/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Gikkman]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Gikkman]

/remove-lifecycle stale