PATCH merges Services with same port, different protocol

[thockin]

xref: #47221 (comment)

Specifically, DNS uses the same port number in TCP and UDP. This is valid when the object is created, but any PATCH operation related to Service ports will merge those together, which is wrong.

@mengqiy This is the gift that keeps on giving. I am so sorry.

[k8s-github-robot]

@thockin There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here and label list here

[xiangpengzhao]

/sig network

[mengqiy]

/assign

[mengqiy]

cc: @pwittrock

[xiangpengzhao]

Any updates here?

xref: #49295

[mengqiy]

@xiangpengzhao #46161 and kubernetes/community#476 are trying to solve this issue. But they will not get in in 1.8 :(

[xiangpengzhao]

Thanks @mengqiy! I will wait for it at the next milestone:)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[mengqiy]

/remove-lifecycle rotten
/lifecycle frozen

[athenabot]

@mengqiy
If this issue has been triaged, please comment /remove-triage unresolved.

If you aren't able to handle this issue, consider unassigning yourself and/or adding the help-wanted label.

🤖 I am a bot run by vllry. 👩‍🔬

[Ewocker]

Trying to create a bug and found this existing issue. Will put some content here for those who are interested in reproduce.

What happened:
On patching targetPorts of service that contains "ports" with duplicate port number, only the first port is updated with the change.

What you expected to happen:
Both port should get updated with correct targetPort.

How to reproduce it (as minimally and precisely as possible):

$ kubectl create ns test

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: test
  namespace: test
  labels:
    app: "test"
spec:
  selector:
    k8s-app: kube-dns
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP
EOF

# Note the targetPort values change here
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: test
  namespace: test
  labels:
    app: "test"
spec:
  selector:
    k8s-app: kube-dns
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 5678
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 1234
EOF

# Notice the targetPort value for port "dns" has the value 5678
# which is configured for port "dns-tcp"
$ kubectl get svc test -n test -o yaml

Anything else we need to know?:
The fundamental problem is patchMergeKey for service is "port" whereas the uniqueness of a port comes from "port+protocol" (Ex. you cannot have duplicate port with same port number and protocol). Similar issue also happens for "ContainerPort".
Sample usage can be found in coredns and kubedns deploy spec.

Note that below is the patch spec for above example:

{
  "spec": {
    "$setElementOrder/ports": [
      {
        "port": 53
      },
      {
        "port": 53
      }
    ],
    "ports": [
      {
        "port": 53,
        "targetPort": "1234"
      },
      {
        "port": 53,
        "targetPort": "5678"
      }
    ]
  }
}

[khenidak]

#104486

[thockin]

Dup of #103544 which has more information