kubectl port-forward connected successfully, then exited after roughly one minute. The application was still running, so restarting the command appeared to fix it only temporarily.
What I checked first
Run the command with client-side debug logging and keep a second terminal open:
kubectl -v=6 port-forward pod/my-pod 8080:8080kubectl get pod my-pod -w
kubectl describe pod my-podThis separates two common cases:
- If the selected pod restarts or terminates, the forwarding session is expected to end. Kubernetes documents that the command must be run again after the selected pod terminates.
- If the pod remains stable and the disconnect happens at a repeatable interval, inspect the network path to the Kubernetes API server. A VPN, corporate proxy, bastion, firewall, or managed load balancer can close a long-lived idle connection.
Do not copy examples that use kubectl port-forward --keepalive=60s. --keepalive is not a documented kubectl port-forward option.
The practical fix
The durable fix is to correct the component that is closing the connection. Compare the failing path with a direct or alternate path to the API server, where your access policy allows it:
kubectl config current-context
kubectl cluster-infoThen test after disconnecting the VPN or bypassing the proxy only if doing so is approved in your environment. If the alternate path stays connected, give the network team the exact interval and the -v=6 timestamps so they can inspect idle timeout settings.
For a local development session, I used a restart loop as a temporary workaround:
while true; do
kubectl port-forward pod/my-pod 8080:8080
echo "port-forward ended; retrying in 2 seconds" >&2
sleep 2
doneThis restores the tunnel after a disconnect, but it does not repair the underlying network timeout. It also should not be used as a production service.
If the pod itself is restarting
Forward to a controller instead of a specific pod when that better matches the use case:
kubectl port-forward deployment/my-app 8080:8080Kubectl selects a matching pod, but the current session still ends if that selected pod terminates. The loop can reconnect and select a new pod, while the real task is to diagnose the restart:
kubectl get pods -l app=my-app
kubectl logs pod/my-pod --previous
kubectl describe pod my-podSafety note
The default listener is localhost. Avoid --address 0.0.0.0 unless you intentionally want other machines to reach the forwarded port and have appropriate firewall and authentication controls.
For a wider Kubernetes debugging workflow, see the Kubernetes troubleshooting guide. If the API server itself is unreachable, use the kubectl connection refused checklist.