kubectl 端口转发超时问题答案

【问题标题】：kubectl port forwarding timeout issuekubectl 端口转发超时问题
【发布时间】：2017-11-25 09:12:26
【问题描述】：

在使用 kubectl port-forward 功能时，我能够成功地将本地端口转发到远程端口。但是，似乎在空闲几分钟后，连接就断开了。不知道为什么会这样。

这里是用于移植的命令：

kubectl --namespace somenamespace port-forward somepodname 50051:50051

错误信息：

Forwarding from 127.0.0.1:50051 -> 50051
Forwarding from [::1]:50051 -> 50051
E1125 17:18:55.723715    9940 portforward.go:178] lost connection to pod

希望能够保持联系

【问题讨论】：

那个 Pod 的状态是什么？如果它没有重新启动或失败。在我看来，问题与受 pod 行为影响的会话层有关。
你有没有机会使用 aks (azure)？
pod 的状态正常...不，不使用 azure
在 AWS 中的 Kubernetes 部署中始终如一地看到这一点。（奇怪没有更多的讨论）

标签： kubernetes kubectl

【解决方案1】：

将kube的streaming-connection-idle-timeout设置为0应该是正确的解决方案，但是如果你不想改变任何东西，你可以使用while-do构造

格式：while true; do <<YOUR COMMAND HERE>>; done

所以只需在 CLI 中输入：while true; do kubectl --namespace somenamespace port-forward somepodname 50051:50051; done 应该会在连接丢失时保持 kubectl 重新连接

【讨论】：

windows cmd有解决办法吗？
对不起@AndrewSneck，没有使用 Win 控制台的经验。但据我所知，最新的 Windows 内置了 unix cli，您应该尝试一下
+1 这对我来说是更好的解决方案：从没有运行 kubelet 的跳线主机转发到 kubernetes 仪表板
@AndrewSneck powershell: while ($true) { kubectl port-forward your-command-here }
kubectl 进程即使超时也不会退出（得到这种类型的日志：E0621 10:11:52.183060 20798 portforward.go:340] 为端口 9191 创建错误流时出错 -> 9191：发生超时）。所以我怀疑这个while循环是否会在超时时循环。

【解决方案2】：

我通过保持连接活动解决了这个问题，例如使用 curl 或 nc。

转发端口：

kubectl --namespace somenamespace port-forward somepodname 50051:50051

在另一个终端中，通过每 10 秒访问端口来保持连接：

while true ; do nc -vz 127.0.0.1 50051 ; sleep 10 ; done

【讨论】：

这是唯一真正保持连接活动而不更改服务器端任何内容的答案。将端口转发命令置于循环中会中断长轮询连接，这是我首先遇到端口转发超时问题的主要原因。
这成功了！为什么？天知道……PLAIN C的日子在哪里！和 unix 比萨盒...
你能解释一下它为什么起作用吗，我很好奇。@Marcel
@Dolphin 端口转发命令如果不使用就会超时。第二个命令到达端口并使其保持活动状态

【解决方案3】：

似乎有一个 5 分钟的超时，可以用 kubelet 参数覆盖：

https://github.com/kubernetes/kubernetes/issues/19231

如果您想将超过 5 分钟（或无限制）的内容传递到您的 kubelet，您可以指定 streaming-connection-idle-timeout。例如。 --streaming-connection-idle-timeout=4h 将其设置为 4 小时。或者： --streaming-connection-idle-timeout=0 使其不受限制。（已弃用：此参数应通过 Kubelet 的 --config 标志指定的配置文件设置。有关更多信息，请参阅https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。）

【讨论】：

当我尝试这个时我得到unknown flag: --streaming-connection-idle-timeout。
@magnattic --request-timeout 会工作吗？ @RobotNerd 在 2018 年的一个现已删除（由他/她）的回答中提到了这一点。
--request-timeout 是一个有效的选项，但似乎没有按预期工作......

【解决方案4】：

为 windows 做这样的蝙蝠（上帝原谅我）

:1
oc port-forward PODNAME 8003:8080
goto 1

【讨论】：

你被原谅了
这仍然是我想到的不间断执行此命令的最佳解决方案。好吧，我原谅你，但不是我自己在几乎 2021 年每次都写这个声明。我认为这个 bug 仍然存在于 kubernetes 端（在 linode 上运行集群 btw）

【解决方案5】：

如果您在负载均衡器（如 HAProxy）后面运行 Kubernetes 集群，可能会发生 kubelet 中配置的超时大于 HAProxy 中配置的超时。

例如，Kubelet 中的streamingConnectionIdleTimeout 设置默认为 4h：

$ kubectl proxy --port=8001 &
$ NODE_NAME="XXXX"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' | grep streaming
  "streamingConnectionIdleTimeout": "4h0m0s",

但如果在 HAProxy（或您首选的 LB）中，您有以下设置：

defaults
  timeout client 1m
  timeout server 1m
...

如果您在应用程序上没有任何活动，则尝试执行端口转发将超时：

$ date; kubectl port-forward service/XXXX 1234:80
Mon Jul  5 10:58:20 CEST 2021
Forwarding ...
# after a minute
E0705 10:59:21.217577   64160 portforward.go:233] lost connection to pod

为了解决这个问题，一个解决方案是增加超时时间（注意这一点，因为根据您的集群，它可能会产生不良影响）或在直接连接到 API 服务器进行端口转发时绕过 LB（如果您的环境允许）。

【讨论】：