如果 client-go 在创建 /exec 请求并升级其 SPDY 连接后立即挂起，这意味着什么？

问题描述

如何判断 kubectl exec 函数挂起的原因？

我有一个 golang 程序（它是 k8s e2e 二进制文件），它严重依赖 client-go 对用于测试 pod 到 pod 网络的各种 pod 进行多次 exec 调用。总的来说，这个程序非常健壮（它在 Kubernetes CI 中运行以获取拉取请求，并且已经在 linux 环境中大量运行）。一般来说，它也可以在少数 Windows 环境中运行良好。

但是，在特定的 Windows 环境（网络速度较慢）中，我看到有时该程序的各种 exec 调用会“挂断”并且永远不会返回。

我怎么知道为什么？我已将 client-go 调用的日志记录级别增加到 10，并且能够看到所采取的最后一个健康操作是

I0115 14:01:09.282852   60665 round_trippers.go:445] POST https://12.10.10.205:6443/api/v1/namespaces/netpol-9600-y/pods/a/exec?command=%2Fagnhost&command=connect&command=s-netpol-9600-y-a.netpol-9600-y.svc.cluster.local%3A80&command=--timeout%3D1s&command=--protocol%3Dtcp&container=cont-81-tcp&container=cont-81-tcp&stderr=true&stdout=true 101 Switching Protocols in 55 milliseconds

详情

我在 Windows Kubernetes 节点上运行了一些测试，这些测试创建了几个在 Windows 容器内运行的 exec 调用。我发现在某些情况下，这些测试会冻结，而且似乎是在 client-go 为“exec”进程连接到 kubelet 时它们会冻结。

• 我相信在 exec 函数期间 APIServer 和 kubelet 之间会发生一些奇妙的切换。
• 但是我知道 12.10.10.205 是我的 APIServer 的 IP 地址。所以我假设下面粘贴的错误是在这次交接之前发生的。

这些测试中的特定“挂起”场景以此作为输出的最后一行结束：

 I0115 14:01:09.282852   60665 round_trippers.go:445] POST https://12.10.10.205:6443/api/v1/namespaces/netpol-9600-y/pods/a/exec?command=%2Fagnhost&command=connect&command=s-netpol-9600-y-a.netpol-9600-y.svc.cluster.local%3A80&command=--timeout%3D1s&command=--protocol%3Dtcp&container=cont-81-tcp&container=cont-81-tcp&stderr=true&stdout=true 101 Switching Protocols in 55 milliseconds
    I0115 14:01:09.284586   60665 round_trippers.go:451] Response Headers:
    I0115 14:01:09.284601   60665 round_trippers.go:454]     Connection: Upgrade
    I0115 14:01:09.284609   60665 round_trippers.go:454]     Upgrade: SPDY/3.1
    I0115 14:01:09.284622   60665 round_trippers.go:454]     X-Stream-Protocol-Version: v4.channel.k8s.io
    I0115 14:01:09.284627   60665 round_trippers.go:454]     Date: Sat,16 Jan 2021 06:01:07 GMT

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）