You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When I create a port forward to the wrong port, the port forward gets deleted without a UI notification. The error message in the log is not expressive.
When creating the port forward on a service, rather than on a pod, and the service exposes a different port than the pod does, it's easy to run into that issue, see below.
To Reproduce
kubectl run nginx --image nginx
In k9s, use Shift+F to create a port forward
Enter 81 as container and local ports
curl --verbose 'http://127.0.0.1:81/'
* Trying 127.0.0.1:81...
* Connected to 127.0.0.1 (127.0.0.1) port 81
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 127.0.0.1:81
> User-Agent: curl/8.11.1
> Accept: */*
>
* Recv failure: Connection was aborted
* closing connection #0
curl: (56) Recv failure: Connection was aborted
See the port forward getting deleted without notification.
Find error message in k9s.log:
Flash failed error="lost connection to pod"
Deleted portforward count=1 gvr=nginx||81:81
Expected behavior
UI message stating that the port forward was deleted, potentially giving a possible reason.
Expressive message in the log.
Versions:
OS: Windows 11
K9s: 0.50.4
K8s: 1.32.2
Additional context
I ran into this issue trying to connect to a service, which exposes port 80 and has targetPort 8080. I used port 80 in k9s as I did with kubectl:
kubectl port-forward svc/myservice 80:80
While kubectl forwards to 8080, k9s suggests 8080 but lets you enter any port, 80 in my case.
I didn't notice the pod's port in the kubectl output:
Forwarding from 127.0.0.1:80 -> 8080
Forwarding from [::1]:80 -> 8080
That's how I got stuck with the connection failing with k9s.
The text was updated successfully, but these errors were encountered:
igorakkerman
changed the title
Port Forward deleted without UI notification when forwarding to wrong port. Log: Flash failed error="lost connection to pod"
Port Forward deleted without UI notification when forwarding to wrong port
Apr 25, 2025
@igorakkerman , I tried to replicate your issue manually and got the below response in my cluster.
Forwarding from 127.0.0.1:8081 -> 8080
Forwarding from [::1]:8081 -> 8080
Handling connection for 8081
E0427 14:04:17.081488 117104 portforward.go:413] "Unhandled Error" err=<
an error occurred forwarding 8081 -> 8080: error forwarding port 8080 to pod bcf1907a82cf3332f3541f0a11e59a9ab3d98c1026c014dfed48d1f2f6211f98, uid : exit status 1: 2025/04/27 08:34:17 socat[47289] E connect(5, AF=2 127.0.0.1:8080, 16): Connection refused
>
error: lost connection to pod
Only the error statement is printed to k9s.log. Do you want the log file to have the below message as well?
E0427 14:04:17.081488 117104 portforward.go:413] "Unhandled Error" err=<
an error occurred forwarding 8081 -> 8080: error forwarding port 8080 to pod bcf1907a82cf3332f3541f0a11e59a9ab3d98c1026c014dfed48d1f2f6211f98, uid : exit status 1: 2025/04/27 08:34:17 socat[47289] E connect(5, AF=2 127.0.0.1:8080, 16): Connection refused
Describe the bug
When I create a port forward to the wrong port, the port forward gets deleted without a UI notification. The error message in the log is not expressive.
When creating the port forward on a service, rather than on a pod, and the service exposes a different port than the pod does, it's easy to run into that issue, see below.
To Reproduce
kubectl run nginx --image nginx
81
as container and local portscurl --verbose 'http://127.0.0.1:81/'
Expected behavior
Versions:
Additional context
I ran into this issue trying to connect to a service, which exposes port 80 and has
targetPort
8080. I used port 80 in k9s as I did with kubectl:While kubectl forwards to 8080, k9s suggests 8080 but lets you enter any port,
80
in my case.I didn't notice the pod's port in the kubectl output:
That's how I got stuck with the connection failing with k9s.
The text was updated successfully, but these errors were encountered: