记一次kubernetes集群异常：kubelet连接apiserver超时

接下来就是怎么修复这个问题了。网上找了一下相关的issue，首先找到的是kubernetes/client-go#374这个issue，上面描述的情况和我们碰到的很相似，有人说是因为使用了HTTP/2.0协议(以下简称h2)，查找了一下kubelet的源码，发现kubelet默认是使用h2协议，具体的代码实现在SetTransportDefaults这个函数中。

可以通过设置环境变量DISABLE_HTTP2来禁用h2，简单验证了一下，显式设置该环境变量禁用h2后，让连接使用http1.1确实没有这个问题了。

查阅文档发现这是http1.1与http2.0的差异：在http1.1中，默认采用keep-alive复用网络连接，发起新的请求时，如果当前有闲置的连接就会复用该连接，如果没有则新建一个连接。当kubelet连接异常时，老的连接被占用，一直hang在等待对端响应，kubelet在下一次心跳周期，因为没有可用连接就会新建一个，只要新连接正常通信，心跳包就可以正常发送。

在h2中，为了提高网络性能，一个主机只建立一个连接，所有的请求都通过该连接进行，默认情况下，即使网络异常，他还是重用这个连接，直到操作系统将连接关闭，而操作系统关闭僵尸连接的时间默认是十几分钟，具体的时间可以调整系统参数：

net.ipv4.tcp_retries2, net.ipv4.tcp_keepalive_time, net.ipv4.tcp_keepalive_probes, net.ipv4.tcp_keepalive_intvl

通过调整操作系统断开异常连接的时间实现快速恢复。

h2主动探测连接故障是通过发送Ping frame来实现，这是一个优先级比较高并且payload很少的包，网络正常时是可以快速返回，该frame默认不会发送，需要显式设置才会发送。在一些gRPC等要求可靠性比较高的通信框架中都实现了Ping frame，在 gRPC On HTTP/2: Engineering A Robust, High Performance Protocol 中谈到：

The less clean version is where the endpoint dies or hangs without informing the client. In this case,TCP might undergo retry for as long as 10 minutes before the connection is considered failed.Of course, failing to recognize that the connection is dead for 10 minutes is unacceptable.

gRPC solves this problem using HTTP/2 semantics:when configured using KeepAlive,gRPC will periodically send HTTP/2 PING frames.These frames bypass flow control and are used to establish whether the connection is alive.

If a PING response does not return within a timely fashion,gRPC will consider the connection failed,close the connection,and begin reconnecting (as described above)

可以看到gRPC同样存在这样的问题，为了快速识别故障连接并恢复采用了Ping frame。但是目前kubernetes所建立的连接中并没有实现Ping frame，导致了无法及时发现连接异常并自愈。

社区那个issue已经开了很长时间好像并没有解决的痕迹，还得自己想办法。我们知道一个http.Client本身其实只做了一些http协议的处理，底层的通信是交给Transport来实现，Transport决定如何根据一个request返回对应的response。在kubernetes client-go中关于Transporth2的设置只有这一个函数。

// SetTransportDefaults applies the defaults from http.DefaultTransport
// for the Proxy, Dial, and TLSHandshakeTimeout fields if unset
func SetTransportDefaults(t *http.Transport) *http.Transport {
t = SetOldTransportDefaults(t)
// Allow clients to disable http2 if needed.
if s := os.Getenv(“DISABLE_HTTP2”); len(s) > 0 {
klog.Infof(“HTTP2 has been explicitly disabled”)
} else {
if err := http2.ConfigureTransport(t); err != nil {
klog.Warningf(“Transport failed http2 configuration: %v”, err)
}
}
return t

}

只是调用了http2.ConfigureTransport来设置transport支持h2。这一句代码似乎太过简单，并没有任何Ping frame相关的处理逻辑。查了下golang标准库中Transport与Pingframe相关的方法。

令人遗憾的是，当前golang对于一个tcp连接的抽象ClientConn已经支持发送Ping frame，但是连接是交由连接池clientConnPool管理的，该结构是个内部的私有结构体，我们没法直接操作，封装连接池的Transport也没有暴露任何的接口来实现设置连接池中的所有连接定期发送Ping frame。如果我们想实现这个功能就必须自定义一个Transport并实现一个连接池，要实现一个稳定可靠的Transport似乎并不容易。只能求助golang社区看有没有解决方案，提交了一个issue后， 很快就有人回复并提交了PR，查看了一下，实现还是比较简单的，于是基于这个PR实现了clinet-go的Ping frame的探测。