本文通过记录kubelet连接apiserver超时问题的原因及修复办法。
背景
kubernetes是master-slave结构，master node是集群的大脑，当master node发生故障时整个集群都"out of control"。master node中最重要的当属apiserver组件，它负责处理所有请求，并持久化状态到etcd。一般我们会部署多份apiserver实现高可用。官方建议在多个apiserver前面部署一个LB进行负载均衡，当其中一台apiserver发生故障之后，LB自动将流量切换到其他实例上面。这样虽然简单，但是也引入了额外的依赖，如果LB发生故障将会导致全部apiserver不可用。我们知道在kubernetes中node节点上kubelet与apiserver心跳超时后，controller-manager会将该node状态置为notReady，随后驱逐其上的pod，使这些pod在其他地方重建。所以当LB发生故障时，集群中所有的node都会变为notReady状态，进而导致大规模的pod驱逐。
故障发生
无独有偶，这样的事情偏偏被我们碰到了，接到线上大量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?
赶紧用tcpdump抓包分析了一下，发现kubelet不断地给apiservre发送包却没有收到对端的ACK，登录master查看apiserver服务也一切正常。后来同事发现重启kubelet就好了，为了尽快解决问题只能把kubelet全部重启了，后面再慢慢定位问题。
定位问题
集群恢复之后，发现有故障通报LB发生了故障，联系了相关同学发现时间点刚好相符，怀疑是因为LB异常导致kubelet无法连接apiserver。
经过沟通后发现：LB会为其转发的每一个connection维护一些数据结构，当新的一台LB server上线之后会均摊一部分原来的流量，但是在其维护的数据结构中找不到该connection的记录就会认为这个请求非法，直接DROP掉。类似的事确实还发生不少，在kubernetes的isuse里有不少这样的案例，甚至需要公有云的的LB也会有这样的问题。例如：kubernetes#41916，kubernetes#48638，kubernetes-incubator/kube-aws#598
大概明白原因之后，push LB的同学改进的同时，kubelet也应该做一些改进：当kubelet连接apiserver超时之后，应该reset掉连接，进行重试。简单做了一个测试，使用iptables规则drop掉kubelet发出的流量来模拟网络异常。
首先确保kubelet与apiserver连接正常，执行netstat -antpl | grep 6443可以看到kubelet与apiserver 10.132.106.115:6443连接正常：
[root@c4-jm-i1-k8stest03 ~]# netstat -antpl |grep kubelet
tcp 0 0 127.0.0.1:10248 0.0.0.0:* LISTEN 23665/./kubelet
tcp 0 0 10.162.1.26:63876 10.132.106.115:6443 ESTABLISHED 23665/./kubelet
tcp6 0 0 :::4194 :::* LISTEN 23665/./kubelet
tcp6 0 0 :::10250 :::* LISTEN 23665/./kubelet
tcp6 0 0 :::10255 :::* LISTEN 23665/./kubelet
tcp6 0 0 10.162.1.26:10250 10.132.1.30:61218 ESTABLISHED 23665/./kubelet
此时执行
iptables -I OUTPUT -p tcp --sport 63876 -j DROP
将kubelet发出的包丢掉，模拟网络故障，此时可以看到netstat的输出中该连接的Send-Q正在逐步增加，并且kubelet也打印出日志显示无法连接：
[root@c4-jm-i1-k8stest03 ~]# netstat -antpl |grep kubelet
tcp 0 0 127.0.0.1:10248 0.0.0.0:* LISTEN 23665/./kubelet
tcp 0 928 10.162.1.26:63876 10.132.106.115:6443 ESTABLISHED 23665/./kubelet
连接被hang住了，重启kubelet之后，一切又恢复了。
这个现象和当时发生故障的情况一模一样：连接异常导致kubelet心跳超时，重启kubelet后会新建连接，恢复正常心跳。因为我们当前采用的kubernetes版本是v1.10.2，下载master分支的代码编译试了下，也是有这个问题的，感觉这个问题一直存在。
