kube-proxy: remove port opener

[khenidak]

What type of PR is this?

/kind bug
/kind cleanup

What this PR does / why we need it:

kube-proxy holds service node ports open (Listen() without Read()/Receive() pump). The original idea was to stop users from mistakenly create a listener on the node that listens to a node port which would have created debugging problems. It is important to note that if the opener failed we just log and keep going. However port-opener introduced more problems than value. The problems can be be briefly described as the following:

1. We open the port before we commit the forwarding/LB rules, the rules typically take much longer to process before committing. That means if the user connected before rules were set they will indeed connect to kube-proxy not the actual pod backing the service. This usually require restarting the client (be it pod or external proce) or the proxy itself. This is more visible as more nodes get introduced to existing clusters with large number of service (the time between open-port and fwd/lb rules is longer).
2. Port opener also leaves many dangling tcp connections due to this behavior as described here: Nodeport led to many CLOSE_WAIT TCP connections by using kube-proxy iptables mode. #106713

further discussions can be found here: #100643

a script or a stand alone tool can be built (runs on node) to scan services+node-ports and performs a bind(2) on address for debugging purposes. But the scan loop will not be part of kube-proxy.

Which issue(s) this PR fixes:

Fixes #
#100643
#106713

Special notes for your reviewer:

N/A

Does this PR introduce a user-facing change?

kube-proxy will no longer hold service node ports open on the node. Users are still advised not to run any listener on node ports range used by kube-proxy. 

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

N/A 

/sig network

[k8s-ci-robot]

@khenidak: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

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.

[khenidak]

fyi @aojea @thockin

[aojea]

Kubernetes e2e suite: [sig-network] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort service expand_more

/test pull-kubernetes-e2e-gci-gce-ipvs

[khenidak]

Kubernetes e2e suite: [sig-network] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort service expand_more

/test pull-kubernetes-e2e-gci-gce-ipvs

other than this (it is a mistake, i will fix) https://github.com/kubernetes/kubernetes/pull/108496/files#diff-1f2043db3a45960023376d03e4dd43762d1382ad7ea94e3f26c956410b749c97L1455 i didn't remove anything that interacts with conntrack.

[aojea]

Kubernetes e2e suite: [sig-network] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort service expand_more

/test pull-kubernetes-e2e-gci-gce-ipvs

other than this (it is a mistake, i will fix) https://github.com/kubernetes/kubernetes/pull/108496/files#diff-1f2043db3a45960023376d03e4dd43762d1382ad7ea94e3f26c956410b749c97L1455 i didn't remove anything that interacts with conntrack.

/hold
/test pull-kubernetes-e2e-gci-gce-ipvs

it seems it only fails in this PR 🤔 , we have to be sure

https://prow.k8s.io/job-history/gs/kubernetes-jenkins/pr-logs/directory/pull-kubernetes-e2e-gci-gce-ipvs

[thockin]

Oh, I see Kal beat me to it :)

[thockin]

Good riddance to bad rubbish!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: khenidak, thockin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/proxy/OWNERS [khenidak,thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aojea]

@danwinship is ok to unhold or do you still have concerns?

[aojea]

I don't see anybody disagrees with removing them, that doesn't mean that we should not explore new options to protect users I will put on hold for some time in case I got it wrong and there are opposition to remove them, or just unhold it if we all agree on removing it

/lgtm /hold

/hold cancel

let's use silence as no disagreement

[k8s-triage-robot]

The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass.

This bot retests PRs for certain kubernetes repos according to the following rules:

• The PR does have any do-not-merge/* labels
• The PR does not have the needs-ok-to-test label
• The PR is mergeable (does not have a needs-rebase label)
• The PR is approved (has cncf-cla: yes, lgtm, approved labels)
• The PR is failing tests required for merge

You can:

• Review the full test history for this PR
• Prevent this bot from retesting with /lgtm cancel or /hold
• Help make our tests less flaky by following our Flaky Tests Guide

/retest

[aojea]

/retest

[danwinship]

It's already possible in that case - kube-proxy will log that :22 was in use, but then it will go ahead and capture the port anyway!