patchesStrategicMerge is not working for service of single port but multiple protocols.

Describe the bug base: service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80

overlay: service-patch.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - name: rtmpk
    port: 1986
    protocol: UDP
    targetPort: 1986
  - name: rtmp
    port: 1935
    targetPort: 1935
  - name: rtmpq
    port: 1935
    protocol: UDP
    targetPort: 1935
  - name: https
    port: 443
    targetPort: 443
  - name: http3
    port: 443
    protocol: UDP
    targetPort: 443

kustomization.yaml

resources:
- ../../base
patchesStrategicMerge:
- service-patch.yaml

Files that can reproduce the issue

Expected output expected output

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - name: rtmpk
    port: 1986
    protocol: UDP
    targetPort: 1986
  - name: rtmp
    port: 1935
    targetPort: 1935
  - name: rtmpq
    port: 1935
    protocol: UDP
    targetPort: 1935
  - name: https
    port: 443
    targetPort: 443
  - name: http3
    port: 443
    protocol: UDP
    targetPort: 443
   - name: http
    port: 80
    protocol: TCP
    targetPort: 80

Actual output Actually output:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - name: rtmpk
    port: 1986
    protocol: UDP
    targetPort: 1986
  - name: rtmpq
    port: 1935
    protocol: UDP
    targetPort: 1935
  - name: http3
    port: 443
    protocol: UDP
    targetPort: 443
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80

Kustomize version {Version:kustomize/v4.5.7 GitCommit:56d82a8378dfc8dc3b3b1085e5a6e67b82966bd7 BuildDate:2022-08-02T16:28:01Z GoOs:darwin GoArch:amd64}

Platform

Additional context

Using similar port configuration for a deployment merge test, does not work neither.

/triage accepted

This reproduces. cc @natasha41575 -- I know you've done a lot of work with port merging in the past

As a workaround, the result seems correct if you explicitly specify the TCP protocol on the ports that are relying on the default in the sample.

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.

/assign

Unassigning due to lack of activity