2022-08-08号下午的时候,有个环境突然报了很多服务异常,登录master节点查看发现 coredns有一个pod所在的机器notready了,导致这个coredns的pod漂移到另外一台机器上了
查看服务日志发现有很多服务出现了域名解析超时 could not be resolved (110: Operation timed out) 的情况(奇怪的是这些服务都是openresty的),为了快速恢复,将这些openresty的pod全部重启了一遍,服务就恢复了,没有再出现域名解析超时的情况
这个诡异的现象导致了大部分的openresty服务几乎都瘫痪了,虽然重启后问题解决了,但是对线上造成了很大的影响
一、复现问题
为了解决这个问题,我们决定在sit环境复现一下,预设的复现的操作包含两个
1、重启coredns的其中一个pod
2、重启coredns其中一个pod所在的服务器
结果在操作第一个的时候,就复现了该问题,所以第二个也没有再继续操作了
复现问题后观察结果如下
1、coredns pod重启后马上创建了一个新的pod出来,符合预期
2、在master节点上观察coredns的ipvs 规则,发现已经正常更新为新的pod IP,符合预期
3、在openresty所在的服务器上查看ipvs规则,发现已经被删除的coredns的pod IP仍然在规则列表中没有被移除,仅仅是将权重设置为0,但仍然有连接,这就是导致openresty服务的DNS请求仍然会访问到被删除的pod IP上的原因
在机器上抓包的文件也显示仍然有往老的pod IP访问的情况,但肯定是没有响应的
二、分析结果
那么到现在为止问题已经很清楚了,就是因为ipvs没有将已经过期的规则删除,导致了该问题
我们查阅了网上的资料,发现了一个类似的问题(kube-proxy的ipvs模式udp转发规则过期问题 | Potterhe's Site)
并且该问题在k8s 1.14.2版本得到了解决,正好这个集群的k8s版本是 1.14.1
所以我们升级了一台有问题服务器的kube-proxy版本到1.14.10之后,再次复现,发现问题已经不会再出现了,在coredns的pod被删除后,ipvs马上更新了规则,将老的IP规则移除了,并且服务日志也没有再出现 could not be resolved (110: Operation timed out) 的情况
PS:在宿主机手动删除已过期的IPVS规则也可以恢复 ipvsadm -d -u 172.20.0.2:53 -r 172.30.227.142:53,不过不能从根本上解决
至此问题已经得到解决,只需将k8s的kube-proxy版本升级到1.14.2以上的版本即可