K3s集群中Pod Exec命令502错误的排查与解决

问题现象

在使用K3s v1.31.2+k3s1版本构建的集群环境中，管理员发现了一个奇怪的现象：kubectl exec命令在某些工作节点上执行失败，返回502 Bad Gateway错误，而kubectl logs命令却能正常工作。具体表现为：

• 在master节点(kubemaster01)和部分worker节点(kubenode05)上，kubectl exec可以正常执行
• 在其他worker节点(kubenode04和kubenode06)上，kubectl exec会失败并返回502错误
• 所有节点上的kubectl logs命令都能正常工作

技术背景

K3s作为轻量级Kubernetes发行版，其内部通信机制与传统Kubernetes有所不同。当执行kubectl exec命令时，API服务器需要通过kubelet的10250端口与目标节点建立连接。这一过程依赖于K3s特有的websocket隧道机制。

排查过程

1. 网络连通性检查：

   • 确认master节点可以访问所有worker节点的10250端口
   • 确认所有节点位于同一L2网络，没有中间网络设备干扰

2. 日志分析：

   • master节点日志显示"failed to find Session for client"错误
   • 问题节点(kubenode04和kubenode06)的agent服务日志中缺少websocket隧道相关的连接信息

3. 环境配置检查：

   • 集群使用默认的flannel CNI
   • 没有配置特殊网络策略或代理

根本原因

通过分析可以得出以下结论：

1. websocket隧道中断：K3s master与部分worker节点之间的websocket隧道连接异常中断，导致exec请求无法路由到目标节点的kubelet

2. 连接状态不一致：虽然基础网络连通性正常，但高层应用层连接状态出现问题，特别是控制平面与节点间的长连接维护机制

3. CNI兼容性问题：虽然本案例中使用的是默认flannel，但类似问题在使用某些第三方CNI插件时更为常见，特别是那些不遵循节点PodCIDR分配的CNI

解决方案

1. 临时解决方案：

   • 重启问题节点的k3s-agent服务

   systemctl restart k3s-agent.service
   

2. 长期解决方案：

   • 升级到最新稳定版K3s
   • 对于使用非标准CNI的环境，参考K3s文档调整egress selector配置
   • 设置监控告警，及时发现websocket隧道连接异常

3. 配置调整：

   • 对于复杂网络环境，考虑调整K3s的egress selector模式
   • 确保网络策略不会阻断控制平面与节点间的长连接

最佳实践建议

1. 日志监控：建立对K3s控制平面和agent日志的集中监控，特别关注websocket相关错误

2. 版本管理：保持K3s版本更新，及时修复已知的连接问题

3. 网络规划：

   • 确保控制平面与工作节点间的网络延迟稳定
   • 避免网络设备对长连接的不当干扰

4. 健康检查：定期验证所有节点的exec功能，而不仅仅是基础服务健康状态

通过以上分析和解决方案，可以有效预防和解决K3s集群中因websocket隧道问题导致的Pod exec命令失败情况，确保集群管理功能的完整性和可靠性。