search

kubernetes / kubectl

Issue tracker and mirror of kubectl code
Apache License 2.0
2.85k stars 921 forks source link

Stop port-forwarding after errors occured - let the user decide. #1249

Open ghost opened 2 years ago

ghost commented 2 years ago

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.

eddiezane commented 2 years ago

Brian is working on a PR to better handle connection reset by peer.

/assign @brianpursley

eddiezane commented 2 years ago

/triage accepted

brianpursley commented 2 years ago

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

k8s-triage-robot commented 1 year ago

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:

You can:

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

/lifecycle stale

EraYaN commented 1 year ago

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

k8s-triage-robot commented 9 months ago

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

k8s-triage-robot commented 6 months ago

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

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

You can:

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

/lifecycle stale

EraYaN commented 6 months ago

This has not been addressed, the posted PR was closed.

/remove-lifecycle stale

k8s-triage-robot commented 3 months ago

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

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

You can:

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

/lifecycle stale

EraYaN commented 3 months ago

This has not been addressed, the posted PR was closed.

/remove-lifecycle stale

k8s-triage-robot commented 1 week ago

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

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

You can:

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

/lifecycle stale

9numbernine9 commented 1 week ago

I don't believe this has been addressed yet.

/remove-lifecycle stale