Kubernetes集群中kubectl exec返回Nginx 404错误的故障排查与解决

2025-04-28 03:29:40作者：翟江哲Frasier

在Kubernetes生产环境中，运维人员偶尔会遇到一些看似简单但排查过程复杂的网络问题。近期在某次Kubernetes v1.31.6到v1.31.7的版本升级后，出现了一个典型现象：当对特定节点上的Pod执行kubectl exec命令时，返回了意外的Nginx 404错误。本文将深入分析这一问题的排查思路和解决方案。

问题现象

运维人员在对集群执行常规管理操作时发现，当针对节点kube-b3ci07.local上的任何Pod执行kubectl exec命令时，都会收到如下错误响应：

error: Internal error occurred: unable to upgrade connection: <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.27.3</center>
</body>
</html>

值得注意的是，这个错误只出现在特定节点上，其他节点上的Pod操作完全正常。集群的基础组件包括：

Kubernetes版本：v1.31.7
容器运行时：containerd 1.7.25
CNI插件：Calico v3.28.2
部署方式：kubeadm
运行环境：Debian GNU/Linux 11

问题分析

1. 网络流量路径分析

kubectl exec命令的正常执行依赖于Kubernetes的API Server和kubelet之间的通信链路。典型的数据流路径是：

kubectl客户端发起exec请求
请求通过负载均衡器（本例中是HAProxy）到达API Server
API Server与目标节点的kubelet建立连接
kubelet与容器运行时交互执行命令

出现Nginx 404错误表明，在这个通信链路的某个环节，请求被错误地路由到了Nginx服务器，而非预期的Kubernetes组件。

2. 关键排查点

通过深入排查，发现了几个重要线索：

版本不一致：虽然集群已升级到v1.31.7，但kubectl客户端版本为v1.32.1，存在版本偏差。不过将客户端降级到v1.31.5后问题依旧存在。
节点状态异常：问题节点处于Ready但SchedulingDisabled状态，这是运维人员有意为之的配置，用于隔离GitLab Runner的工作负载。
网络组件差异：集群前端确实部署了HAProxy 2.9.5作为负载均衡，但错误消息中出现的Nginx 1.27.3并非集群的标准组件。
节点重启效应：执行节点滚动重启后，问题自行消失，表明存在某种临时性的网络配置问题。

根本原因

综合各种线索，问题的根本原因可以归结为：

在特定节点上，kubelet与API Server之间的SPDY/WebSocket连接被错误地路由到了某个Nginx实例。这种情况通常发生在：

节点网络配置出现异常，导致kubelet的10250端口（默认kubelet端口）的流量被错误转发
节点上存在残留的iptables/nftables规则，干扰了正常的kubelet通信
节点间的网络路由表出现暂时性不一致
某些网络中间件（如负载均衡器或代理）配置不当

在本案例中，由于节点重启后问题消失，最可能的原因是节点上的网络配置出现了临时性不一致，可能是由于：

未完全清理的旧网络策略
残留的临时路由规则
网络接口状态异常

解决方案与最佳实践

1. 临时解决方案

执行节点滚动重启可以立即解决问题：

kubectl drain <问题节点>
systemctl reboot
kubectl uncordon <问题节点>

2. 根本性解决方案

为防止问题再次发生，建议采取以下措施：

网络配置检查：
- 使用ip route和iptables-save检查节点路由和防火墙规则
- 确保kubelet的10250端口没有被其他服务占用或转发
组件一致性检查：
- 保持kubectl客户端与服务器版本一致
- 定期验证所有节点的网络配置一致性
监控与告警：
- 设置对kubelet连接状态的监控
- 对非预期的HTTP响应（如Nginx 404）建立告警机制
升级策略优化：
- 在升级前执行完整的预检查
- 采用更稳妥的滚动升级策略