记一次kube-proxy BUG导致的DNS解析失败

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以上的版本即可