EKS中Pod重启/删除后Go cobra/fasthttp服务NodePort失效求助

1. NodePort端口被系统残留连接占用 #

Pod重启后新Pod IP变更，但kube-proxy未及时清理旧连接跟踪条目，或者操作系统的TIME_WAIT/FIN_WAIT状态连接持续占用NodePort，导致新请求无法被转发。

• 在节点执行 ss -tulpn | grep <你的NodePort>，查看端口是否有残留连接或异常进程占用
• 执行 conntrack -L | grep <你的NodePort>，检查是否存在大量未清理的旧连接跟踪条目

2. kube-proxy规则更新异常 #

K8s 1.24默认使用iptables模式kube-proxy，当Pod端点更新时，若kube-proxy进程异常或规则应用失败，会导致Service流量无法转发到新Pod。

• 查看kube-proxy日志：kubectl logs -n kube-system kube-proxy-<节点名称>，搜索端点更新失败、iptables规则错误相关日志
• 手动重启节点上的kube-proxy：kubectl delete pod -n kube-system kube-proxy-<节点名称>，观察服务是否恢复

3. Go程序监听配置问题 #

你的fasthttp服务器可能存在监听异常：比如重启后未正确释放端口，或仅绑定了旧Pod的IP而非0.0.0.0，导致流量无法进入容器（尽管Pod状态显示健康）。

• 进入新Pod执行netstat -tulpn（容器需预装该工具），确认服务器是否监听0.0.0.0:<容器端口>
• 检查Go代码，确保监听地址设置为0.0.0.0，而非固定IP

4. Endpoints资源未更新 #

Service对应的Endpoints可能未同步到新Pod的IP，导致流量仍发往已销毁的旧Pod。

• 执行kubectl get endpoints <你的Service名称>，对比Endpoints中的IP与新Pod IP是否一致
• 查看kube-controller-manager日志：kubectl logs -n kube-system kube-controller-manager-<主节点名称>，搜索端点更新失败的记录

5. NodePort残留iptables规则冲突 #

Pod重启时kube-proxy未清理旧规则，新旧规则冲突导致流量转发失败，更换端口相当于创建全新规则，因此能恢复服务。

• 在节点执行iptables-save | grep <你的NodePort>，检查是否存在重复或错误规则
• 谨慎清理冲突规则：iptables -t nat -D KUBE-SERVICES -p tcp --dport <NodePort> -j KUBE-NODEPORTS，随后重启kube-proxy

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