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

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之间的通信链路。典型的数据流路径是:

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

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

2. 关键排查点

通过深入排查,发现了几个重要线索:

  1. 版本不一致:虽然集群已升级到v1.31.7,但kubectl客户端版本为v1.32.1,存在版本偏差。不过将客户端降级到v1.31.5后问题依旧存在。

  2. 节点状态异常:问题节点处于Ready但SchedulingDisabled状态,这是运维人员有意为之的配置,用于隔离GitLab Runner的工作负载。

  3. 网络组件差异:集群前端确实部署了HAProxy 2.9.5作为负载均衡,但错误消息中出现的Nginx 1.27.3并非集群的标准组件。

  4. 节点重启效应:执行节点滚动重启后,问题自行消失,表明存在某种临时性的网络配置问题。

根本原因

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

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

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

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

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

解决方案与最佳实践

1. 临时解决方案

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

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

2. 根本性解决方案

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

  1. 网络配置检查

    • 使用ip routeiptables-save检查节点路由和防火墙规则
    • 确保kubelet的10250端口没有被其他服务占用或转发
  2. 组件一致性检查

    • 保持kubectl客户端与服务器版本一致
    • 定期验证所有节点的网络配置一致性
  3. 监控与告警

    • 设置对kubelet连接状态的监控
    • 对非预期的HTTP响应(如Nginx 404)建立告警机制
  4. 升级策略优化

    • 在升级前执行完整的预检查
    • 采用更稳妥的滚动升级策略

经验总结

这个案例展示了Kubernetes网络问题排查的典型思路:

  1. 首先确认问题范围(是特定节点还是全局性问题)
  2. 分析错误信息的特征(如Nginx版本信息)
  3. 检查组件版本一致性
  4. 验证网络通信链路
  5. 考虑临时性配置问题的可能性

对于生产环境中的Kubernetes集群,建议建立完善的变更管理和监控体系,确保能够快速发现和定位此类网络异常。同时,保持所有组件的版本一致性,定期验证网络配置的正确性,可以有效预防类似问题的发生。

通过这次事件,我们再次认识到Kubernetes网络通信的复杂性,以及全面监控系统的重要性。只有深入理解各组件间的交互机制,才能在出现问题时快速定位并解决。

登录后查看全文
热门项目推荐

最新内容推荐

项目优选

收起
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
176
261
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
858
511
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
129
182
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
258
298
ShopXO开源商城ShopXO开源商城
🔥🔥🔥ShopXO企业级免费开源商城系统,可视化DIY拖拽装修、包含PC、H5、多端小程序(微信+支付宝+百度+头条&抖音+QQ+快手)、APP、多仓库、多商户、多门店、IM客服、进销存,遵循MIT开源协议发布、基于ThinkPHP8框架研发
JavaScript
93
15
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
332
1.08 K
HarmonyOS-ExamplesHarmonyOS-Examples
本仓将收集和展示仓颉鸿蒙应用示例代码,欢迎大家投稿,在仓颉鸿蒙社区展现你的妙趣设计!
Cangjie
398
371
note-gennote-gen
一款跨平台的 Markdown AI 笔记软件,致力于使用 AI 建立记录和写作的桥梁。
TSX
83
4
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.07 K
0
kernelkernel
deepin linux kernel
C
22
5