Http Kubernetes API服务器丢弃监视连接

30-45分钟后，断开与API服务器的分块HTTP连接：

Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: 55782 (55782), Seq: 751, Ack: 88, Len: 0
.... 0000 0001 0001 = Flags: 0x011 (FIN, ACK)

无论活动级别如何，这种情况都会发生，也就是说，对于长时间处于空闲状态的连接，这种情况也会发生，但对于在整个连接期间都有通知的连接，这种情况也会发生。HTTP 1.0（带有

Connection:Keep-Alive

header）仅结束原始请求，而HTTP 1.1（默认为keepalive）在断开连接之前发送

400错误请求

有可能获得一个长时间保持活动状态的手表连接吗？
手表应该定期断开-它们只是下面的长HTTP get操作，带有超时。这是故意的。这会导致问题吗？
一旦确定客户端正确处理断开连接，您可以使用以下kube apiserver标志来控制apiserver让手表保持打开状态的时间：


--min request timeout=1800：一个可选字段，指示处理程序在超时前必须保持请求打开的最小秒数。目前，只有watch请求处理程序才会执行此操作，它会选择一个高于此数字的随机值作为连接超时，以分散负载。

使用较小的值进行测试，使用较大的值在生产环境中运行。
哪个K8S版本和哪个环境？你可能会打电话，但既然你已经提出了回购协议的问题，那无疑是进行讨论的最佳场所；）版本1.0.6，谢谢，我还将更新github发行版，环境是CoreOS:
CoreOS$uname-a Linux ip-10-10-0-20.ec2.internal 4.0.5#2 SMP Fri Jul 10 06:25:01 UTC 2015 x86_64 Intel（R）Xeon（R）CPU E5-2676 v3@2.40GHz GenuineIntel GNU/Linux
我知道他们是，但我希望它们能持续到客户端决定断开连接为止。所以，是的，它引起了一个问题。websocket是控制手表连接持续时间的唯一方法吗？还是没有办法？健壮的客户端必须能够从断开的连接中恢复。在测试中，我们实际上将超时值设置为~5分钟，以确保执行代码路径。一旦你的客户处理了这个问题，在生产中允许很长的观察期是有意义的；kube apiserver上有标志允许您执行此操作。@lavalamp:当然，我会恢复，但我们有一个时间敏感的应用程序，任何不必要的断开连接都是不可取的。在任何情况下，
--长时间运行的请求regexp
是指什么？