K8s节点重启后IP表未更新 失效Pod残留IP致请求转发404故障

故障表现 #

• GCP Kubernetes（GKE）集群出现负载均衡转发错误：客户端请求被转发到复用了历史Pod IP的新Pod上，导致接口返回404。
• 可在日志浏览器（Logs Explorer）中使用以下查询语句定位异常日志：

resource.type="http_load_balancer"
httpRequest.requestMethod="GET"
httpRequest.status=404

异常日志示例 #

httpRequest: {
latency: "0.017669s"
referer: "https://asdf.com/"
remoteIp: "5.57.50.217"
requestMethod: "GET"
requestSize: "34"
requestUrl: "https://[asdf.com]/api/service2/[...]"
responseSize: "13"
serverIp: "10.19.160.16"
status: 404
userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
}

字段说明：requestUrl为负载均衡收到的入站请求URL，serverIp为请求实际转发到的后端IP。

Pod关联信息排查 #

针对日志中记录的后端IP10.19.160.16，执行如下命令查询关联的Pod信息：

kubectl get pods -o wide | findstr 10.19.160.16

命令返回结果：

service1-675bfc4f97-slq6g    1/1   Terminated   0   40h     10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg
service2-574d69cf69-c7knp    0/1   Error        0   3d16h   10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg
service3-6db4c97784-428pq    1/1   Running      0   16h     10.19.160.16   gke-namespace-te-namespace-te-153a9649-p2mg

根据requestUrl判断，该请求本应转发至service2，但实际被转发到了service3：service3复用了之前service2持有的IP 10.19.160.16，集群错误判定已失效的service2仍占用该IP，最终因service3没有匹配的请求接口返回404。

临时处理方案 #

执行kubectl delete pod <失效Pod名称>手动删除处于Error、Terminated等失败状态的Pod，即可终止异常转发行为。

已知背景信息 #

• 故障疑似在集群升级至v1.23版本后出现，该版本要求按照官方规范将相关网络资源从extensions/v1beta1 API迁移至networking.k8s.io/v1 API。
• 测试环境使用抢占式虚拟机（pre-emptible VM）作为节点，高度怀疑节点被抢占回收后，其上运行的Pod进入Error状态且未被自动清理，进而触发异常。

待确认问题 #

1. 集群留存已失效死亡Pod的IP占用记录的根本原因是什么？
2. 手动删除失效Pod后转发恢复正常的原理是什么？
3. 节点被抢占后，对应节点上的失效Pod未被自动清理的原因是什么？

内容的提问来源于stack exchange，提问作者OnionJack