本文通过记录kubelet连接apiserver超时问题的原因及修复办法。

上篇文章回顾：

无独有偶，这样的事情偏偏被我们碰到了，接到线上大量node not ready的报警后，立刻上线查看，发现所有的node kubelet都报如下错误:

E0415 17:03:11.351872   16624 kubelet_node_status.go:374] Error updating node status, will retry: error getting node "k8s-slave88": Get https://10.13.10.12:6443/api/v1/nodes/k8s-slave88?resourceVersion=0&timeout=5s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)E0415 17:03:16.352108   16624 kubelet_node_status.go:374] Error updating node status, will retry: error getting node "k8s-slave88": Get https://10.13.10.12:6443/api/v1/nodes/k8s-slave88?timeout=5s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)E0415 17:03:21.352335   16624 kubelet_node_status.go:374] Error updating node status, will retry: error getting node "k8s-slave88": Get https://10.13.10.12:6443/api/v1/nodes/k8s-slave88?timeout=5s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)E0415 17:03:26.352548   16624 kubelet_node_status.go:374] Error updating node status, will retry: error getting node "k8s-slave88": Get https://10.13.10.12:6443/api/v1/nodes/k8s-slave88?timeout=5s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)E0415 17:03:31.352790   16624 kubelet_node_status.go:374] Error updating node status, will retry: error getting node "k8s-slave88": Get https://10.13.10.12:6443/api/v1/nodes/k8s-slave88?timeout=5s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)E0415 17:03:31.352810   16624 kubelet_node_status.go:366] Unable to update node status: update node status exceeds retry count复制代码

日志中显示的10.13.10.12是LB的地址。通过这个日志判断是kubelet连接apiserver失败，初步怀疑是网络故障，手动telnet 10.13.10.12 6443后发现一切正常，这就比较奇怪了，明明网络通信正常，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中谈到：

可以看到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 unsetfunc 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的探测。

开发完毕准备上线的时候，想趁这次修复升级一下kubernetes版本到v1.10.11，一般patch release是保证兼容的。在测试v1.10.11的时候惊奇的发现，即使不改任何代码，这个问题也没办法复现了。说明在v1.10.2中是有问题的，在v1.10.11中恢复了，接着在master中又引入了这个问题，看来还得需要仔细阅读一下这部分代码了，到底是发生了什么。

经过阅读代码，发现这个逻辑曾经被修复过，参考下方链接：

并且backport到1.10.3的代码中，当连接异常时会会调用closeAllConns强制关闭掉所有的连接使其重建。

随后又引入了regression，将closeAllConns置为nil，导致连接无法正常关闭。

明白了这个逻辑之后修改就简单了，将closeAllConns再置为正确的值即可，给官方提交了一个pr，官方很乐意就接受了，并backport到了1.14版本中。至此这个就算完全修复了，当然可以通过上文提到的给h2增加Ping frame的方式解决该问题，这是这种方案可能比较复杂，修复时间比较长。