Kubernetes API 服务器丢弃监视连接答案

【问题标题】：Kubernetes API server drops watch connectionsKubernetes API 服务器丢弃监视连接
【发布时间】：2015-11-03 05:34:14
【问题描述】：

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 标头）只是结束原始请求，而默认情况下保持活动状态的HTTP 1.1 在断开连接之前发送400 Bad Request。

是否有可能获得长时间保持活动的手表连接？

【问题讨论】：

哪个K8S版本，哪个环境？您可能正在点击github.com/kubernetes/kubernetes/issues/8700，但由于您已经在 repo 上提出了一个问题，因此这是进行讨论的最佳场所；）
版本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

标签： http kubernetes

【解决方案1】：

一旦您确定您的客户端正确处理断开连接，您可以使用以下 kube-apiserver 标志来控制 apiserver 让手表保持打开状态的时间：

https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-apiserver.md

--min-request-timeout=1800: An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load.

用小值测试，用大值在生产环境中运行。

【讨论】：

【解决方案2】：

Watches 应该定期丢弃 - 它们只是下面的长 HTTP GET 操作，带有超时。这是故意的。是不是有问题？

【讨论】：

我知道它们是 GET，但我希望它们能持续到客户端决定断开连接。所以，是的，它导致了一个问题。 websocket 是控制监视连接持续多长时间的唯一方法吗？还是没有办法？
强大的客户端必须能够从断开的连接中恢复。在测试中，我们实际上将超时值设置为约 5 分钟，以确保执行代码路径。但是，一旦您的客户处理了这种情况，在生产中允许很长的观察时间是有意义的； kube-apiserver 上有一些标志可以让你这样做。
@lavalamp：当然，我恢复了，但我们有一个时间敏感的应用程序，任何不必要的断开都是不可取的。不管怎样，你指的是--long-running-request-regexp吗？