Open ghost opened 2 years ago
Brian is working on a PR to better handle connection reset by peer.
/assign @brianpursley
/triage accepted
PR to handle connection reset by peer and not stop the port forwarding listener: https://github.com/kubernetes/kubernetes/pull/111860
Feel free to comment here or on the PR if you have any thoughts
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
This is still relevant I think.
The linked PR was closed but there seems to be a new issue with https://github.com/kubernetes/kubernetes/issues/113568 though it doesn't seem quite the same.
/remove-lifecycle stale
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
This has not been addressed, the posted PR was closed.
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
This has not been addressed, the posted PR was closed.
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I don't believe this has been addressed yet.
/remove-lifecycle stale
What would you like to be added:
https://github.com/kubernetes/kubernetes/pull/103526 changed to port-forwarding logic so that kubectl exits after an error, for example a "connection reset by peer". I would like to propose a flag that lets the user decide whether this should happen or not, as it seems there are cases where exiting is justified, and there are cases where this is an annoying behaviour.
Why is this needed:
As mentioned in https://github.com/kubernetes/kubectl/issues/1169#issuecomment-1165140134 and verified by tcpdump postgresql does send a RST when a connection that is using TLS is closed. From my understanding in a perfect world this is what should happen when closing a psql connection
CL: I would like to close my database connection. SE: Fine, let's close this database connection. CL: And now I would like to close the TLS session. FIN SE: Wonderful. Let's close the TLS session. FIN ACK
but instead this is happening
CL: I would like to close my database connection. SE: Fine, let's close this database connection. CL: And now I would like to close the TLS session. FIN SE: You are still here? Go away. RST
Some google foo lead me to a discussion on the postgres mailing list dating back to 2019 where the postgres people are very adamant that this is no bug, and waiting for the TLS session ending would add no further value, but block valuable resources on the server side. Shortcutting a connection close via RST is considered legit.
Diabling TLS on postgres is often not an option, even if the access happens only within the cluster (compliance reasons e.g.).
This brings us to port-forwarding to a postgres server that is running within kubernetes. Many tools do not just open and reuse one connection, but open and close many connections (database viewer of IntelliJ for example). Those tools fail and can not be used with kubecl port-forwarding any more, as kubectl exits after the first connection is closed (properly by the client, but with a "connection reset" by the server). Of course the postgres server pod has NOT ceased to work, so server further port-forwards should be no problem (and this was indeed the case before https://github.com/kubernetes/kubernetes/pull/103526 was introduced).
As I think there are also reasons where exiting kubectl is a good idea, the best option here would be to let the user decide, by introducing a command line option, keeping the current state (exit after error) as the default.