先把当时的情况摆出来。本地连测试集群的 MySQL 做数据核对，kubectl port-forward 跑几分钟就自己退出，终端只留一行 connection lost，长一点的查询每次都要重连。
原因不止一个，得分开看。port-forward 走的是 apiserver 的 SPDY 或 WebSocket 通道，网络抖动就会被掐断。另一种情况是apiserver 前面的负载均衡有空闲超时，空闲连接被主动回收。
另外，本地网络切换，比如 Wi-Fi 和有线互相切，TCP 连接直接失效。少数情况下是容器里的目标端口重启过，转发链路对端消失。
动手时先确认断开时的具体报错
kubectl port-forward svc/mysql 13306:3306 --v=6再往下改成后台常驻并自动重连的写法
nohup kubectl port-forward svc/mysql 13306:3306 >/tmp/pf.log 2>&1 &接着用 autossh 之类的方式维持隧道
autossh -M 0 -N -L 13306:127.0.0.1:13306 jump-host剩下的就是验证端口确实在听并且能连上
ss -lntp | grep 13306 && mysql -h127.0.0.1 -P13306 -e 'select 1'怎么算真的好了，看的是同一批现象。本地 13306 端口稳定可用超过半小时，mysql 客户端连续查询不中断，/tmp/pf.log 里不再出现连接丢失的记录。
port-forward 只适合临时调试，别当生产通道用；需要长期访问就把服务改成 NodePort 或者走跳板机的 SSH 隧道，稳定性差很多。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。